61–70 of 207 posts
Just the opposite of serious for me. Example: there's a website for all the weather radar stations in Canada that lets you see the last two hours of 10-minute radar snapshots. I wanted a dump of them to try some ML algorithms, but even after requests and emails there simply wasn't one. So I set up a lambda to run every hour, load the website for all 31 weather stations and save all 6 images from the last hour to S3.…
The "serverless" architecture is cool, but it irks me every time I hear the given name for it. For a marketing term mainly aimed at developers, I'm amazed they picked one so terrible.
A substantial part of a few of our systems use Azure Functions.
We've actually found them excellent to work with, fairly cheap and scaling very efficiently.
The main issues we've had are internal disagreements about how to pass app settings in efficiently. Originally we put all the app settings in the ARM templates used to deploy them. Then we put them as variables in VSTS. And then finally we decided to put them inti variable groups, which are within task groups, which are used by releases. It's a bit of a weird chain of dependencies, but now all of our parameters are located in one place
Software developer at Transport for London here. A substantial part of a few of our systems use Azure Functions. We've actually found them excellent to work with, fairly cheap and scaling very efficiently. The main issues we've had are internal disagreements about how to pass app settings in efficiently. Originally we put all the app settings in the ARM templates used to deploy them. Then we put them as variables in…
Just the opposite of serious for me. Example: there's a website for all the weather radar stations in Canada that lets you see the last two hours of 10-minute radar snapshots. I wanted a dump of them to try some ML algorithms, but even after requests and emails there simply wasn't one. So I set up a lambda to run every hour, load the website for all 31 weather stations and save all 6 images from the last hour to S3.…
Software developer at Transport for London here. A substantial part of a few of our systems use Azure Functions. We've actually found them excellent to work with, fairly cheap and scaling very efficiently. The main issues we've had are internal disagreements about how to pass app settings in efficiently. Originally we put all the app settings in the ARM templates used to deploy them. Then we put them as variables in…
Was latency a concern for you at all? If serverless did not exist, would the functions have been (micro) services with similar latency overhead?
I think we currently don't have any functions in time-sensitive streams (they're rather new, so they are used for new features such as Oyster automated refunds, which can be applied a few days later if need be), so when I say we haven't had any performance issues with them, it has to be taken with a pinch of salt.
I think if we were using microservices, they would have substantially more logic in them than the individual functions have, so they would have a lower network overhead. They wouldn't scale automatically, so we'd have to have quite a few machines on all the time, which would cost a bit more.
The main benefit we enjoy from functions is the ability to change code with zero downtime, low risk and minimum disruptions to the whole service.
We've found the interfaces in Azure also to be great - we can write end-to-end tests that can poll service bus to check when all messages are delivered to assert against any final case.
The "serverless" architecture is cool, but it irks me every time I hear the given name for it. For a marketing term mainly aimed at developers, I'm amazed they picked one so terrible.
The message is "you don't need sysadmins anymore", which is exactly what developers want to hear.
It's also very good for the cloud vendors, because with noone in the sysadmin role, developers are far more likely address scaling issues by just throwing resources (money) at the problem.
The "serverless" architecture is cool, but it irks me every time I hear the given name for it. For a marketing term mainly aimed at developers, I'm amazed they picked one so terrible.
The "serverless" architecture is cool, but it irks me every time I hear the given name for it. For a marketing term mainly aimed at developers, I'm amazed they picked one so terrible.
I think the marketing is aimed mainly at technology management, not developers. Obviously, they have to evangelize developers, too, to a certain extent because they need a critical mass with familiarity so that the managers aren't saying “that’s nice, but who do we hire to build stuff on it”, but developers aren't the ultimate target of the marketing for serverless or most other cloud technologies.
We use it internally when fetching usage metrics, receiving notifications for new sign-ups, and to monitor page changes on our enterprise app (https://readme.io), and use these endpoints frequently from Slack channels.
We manage versioning, rate limiting, logging, documentation, and have offer private services and user management for teams.
Creating an API is as easy as:
$ npm install api -g
$ api init
$ api deploy
Serverless rules. I'd love to hear any feedback on our implementation of it! Give Build a try at http://readme.build, and feel free email your thoughts to achal[at]readme.io.