Ask HN: When does serverless become more expensive than microservices? | Hacker News Reader

Ask HN: When does serverless become more expensive than microservices?

If it makes sense to deploy an application both as serverless as well as microservices, when will a serverless architecture start being more expensive economically, or in general having tradeoffs in comparison to microservices. Again, the question relates to cases in which both architectures would make sense for a particular application.

Other than maybe vendor lock-in, and cold starts, what other drawbacks does serverless have in comparison to microservices?

View on HN

Comparing AWS EC2 pricing [1] and AWS Lambda [2].

Assumption: Let's say you run an application / function with 5 qps traffic, needing 256 MB RAM max, 50ms execution time.

EC2: t2.micro instance - 1 instance available as always free, hence using as a baseline. This comes with 1 vCPU and 1GiB RAM - cost $0.0116 / hour x 750 hours a month = $8.7 / month.

Lambda: For 5 qps traffic, it would amount to 13,392,000 requests in a month. With a 256MB instance, and 50ms of execution time, that comes to $2.48 / month, after accounting for 1M free requests.

The math goes in EC2's favor once you cross 20 qps.

Can a t2.micro run such a load - oh yeah!

[1]: AWS EC2 On-demand pricing: https://aws.amazon.com/ec2/pricing/on-demand/ [2]: AWS Lambda pricing: https://dashbird.io/lambda-cost-calculator/

Thanks for the detailed reply! :) So thinking from a business development standpoint, would it just make sense to go for FaaS if one knows that the average traffic of the application will remain below this mark (20qps)? And for an application that is intended to grow without a cap, then pick EC2 from the beginning?

It also depends on traffic patterns. For EC2 you're paying per hour regardless of whether you had traffic or not. For Lambda you're paying per unit of time used and you pay nothing when the function isn't invoked.

Yes, FaaS is a good choice for early stage products, where the traction cannot be predicted, or the user volumes would be predictably low. Combine Lambda (execution) with other free tier + subsequent low cost serverless offerings like DynamoDB for data, you can achieve a truly cost-effective solution with FaaS. Cold-start is not that big an issue, for full functionality web-apps, every now and then, the first request seems to take maybe a second longer. Cons: Learning + debugging curves are higher. Source: Built a SaaS product mostly based on Lambda and it was very cost effective - as in - 1/20 the costs of the traditional EC2 route. EC2 can be a good pick if your engineers are more comfortable with leveraging what they know and speed / a quick go-to-market is of more importance.

FaaS has been remarkably good for many companies with very late stage products running with very large numbers of users for a very long time. The speed of development even in a mature product and the much lower maintenance overhead make FaaS (or rather serverless) applications a very compelling way for teams to get solutions out fast and cheap over a long term and with very large user bases. This is after designing, building and working with dozens of teams to build serverless applications using Lambda and many other AWS services since 2016

As use goes up serverless gets more expensive.

If you have 20 connections per month, you have to pay for the VM or container running all month even though it's getting no traffic 99% the time.

If you have many millions of connections a month and the service is always on and responding, non-serverless will be much cheaper.

You could draw a curve of where those two points intersect for each cloud platform. I wonder if anyone has done that. Would be a nice visual.

Another drawback of serverless is that it is new so the tooling around it is not as mature as VMs or containers. Stuff like debugging can be pretty rough.

Yes! Exactly that is what I am wondering, where the intersection might be. It would be nice to see that in a plot. Thanks for the reply!

Depends on the rate of requests. If you’re frequently getting hit, just do the math and see when to switch over.

One disadvantage I’ve encountered is actually from a support perspective depending on your stack: if your team uses Spring for example, then you’ll know the set up having something Lambda VS EC2s is really different and there’s extra training. People generally don’t like doing stuff they’re not comfy with.

I’m a little confused by the question. When you say “microservices” do you mean individual servers with something running in them? Because serverless just means using some proprietary cloud tech to run code whereas a microservice refers to the responsibilities and role of that aforementioned code. The two aren’t really comparable in any sense.

I mean, instead of running your code with FaaS, you deploy it in microservices, taking care yourself of running it in containers and all the container orchestration. So, yes, microservices was probably not the right term, I meant compared to handling all the container orchestration and deployment yourself.

Ah I see. I guess, as with everything, it depends :) the lines are also so blurred - you can now have container-orchestration-as-a-service e.g AWS Fargate.

The programming model and the operational tasks are also quite different across serverless and microservices.

Microservices are by now an old and well known way to develop software (and even there transactions and orchestration aren't easy).

Serverless could force you to break down application logic very differently and slow your coding. Which serverless platform and language are you considering? What's the tooling like? What the Developer Experience like?

Operational workload should be less in theory with serverless. But that only holds if your software scales smoothly. Or else you'll have more complexity to deal with than microservices.

Reply on news.ycombinator.com