This article is more than 1 year old
Serverless neither magically faster nor cheaper, dev laments
Seems there is some work involved, as one AWS punter discovers
Adopting the latest hip technology – like "going serverless" – does not always work out as well as we'd hope.
Take AWS customer Einar Egilsson, who decided to migrate his .NET Core web API application from a classic setup using Linux VMs and Elastic Beanstalk (which scales resources up and down as required) to serverless with AWS Lambda – but found it both slower and hugely more expensive.
Egilsson said he was attracted by faster deployment as well as wanting to experiment with the latest tech. On Elastic Beanstalk, .NET Core apps are only supported in Docker containers, taking several minutes to deploy, whereas on Lambda the support is native.
So he set up a parallel deployment on Lambda, also using API Gateway to publish and manage his API application.
Deployment time went down by 20 per cent or so, but he was disappointed to find performance around 15 per cent slower than before.
The shocker, though, was the cost. His app receives around 10 million requests per day. On Elastic Beanstalk, the cost was around $164 per month. On Lambda and API Gateway, it was going to be around $1,350 per month, had he not spotted the mounting bill and reverted.
Much of the cost is for API Gateway, around $1,000 per month for this usage, and until recently API Gateway was the only way to publish an HTTP endpoint for a Lambda function.
After Egilsson posted about his experience, the tech community was quick to dive in with suggestions. For example, it is no longer necessary to use API Gateway if you do not need its features. Since November 2018, you can use standard Application Load Balancers, which should be much cheaper. Reserved instances would save money.
Then there is this insight from Hacker News:
Serverless is not a replacement for cloud VMs/containers. Migrating your Rails/Express/Flask/.Net/whatever stack over to Lambda/API Gateway is not going to improve performance or costs.
You really have to architect your app from the ground up for serverless by designing single-responsibility microservices that run in separate lambdas, building a heavy javascript front-end in your favorite framework (React/Ember/Amber/etc), and taking advantage of every service you can (Cognito, AppSync, S3, Cloudfront, API Gateway, etc) to eliminate the need for a web framework.
Egilsson's experience is worth noting, though. There is always a trade-off, and the scalability and low maintenance of a serverless solution does not come for free. The presumption is that you benefit from not having to think about server or VM maintenance.
Second, it is essential to do the sums. Services that seem to perform similar functions can be very different in cost. The mitigating factor is that cloud services, unlike misguided hardware purchases, are relatively easy to turn off. ®
Biting the hand that feeds IT
