Post

Which does beg the question of why does lambda compute have to cost more per unit of work, however you define it. I may be wrong, but I would think that, from a cloud provider point of view, it is actually more efficient at resources and energy utilization, so is it just because of the convenience?

Serverless ability to scale to 0 can lead to more efficient resource usage on bursty workloads where servers might otherwise be idling a lot. But there is compute overhead (for the cloud provider) in spinning up a container/microVM to run your workload, so per “unit of compute” it is more costly.

Two things: 1. it doesn't necessarily cost more per unit of work. I have seen large EC2 clusters avg sub 5% CPU, if you move those workloads to Lambda, cost per unit of work would be lower because you carry less waste.

2. you get a lot of things out-of-the-box, e.g. * multi-az redundancy * load balancing across AZs * large pool of capacity to scale into on-demand (that you're not paying for when you're not using) * OS patching on the host * network security on the host * patching for managed runtimes

When I was at DAZN, we didn't operate at Netflix scale, but we still had to deal with millions of concurrent users at peak. Services along our critical path will experience sudden spikes from hundreds reqs/sec to tens of thousands reqs/sec in a matter of seconds.

But outside of that critical path, Lambda was used heavily across many workloads, including critical business areas like payment processing & account management. Even some services on the critical path were able to use Lambda and API Gateway because their API responses were highly cacheable.

So a quick rule-of-thumb from a throughput POV is: * Stable high-traffic workloads => containers * Bursty, occasional workloads => lambda And don't forget about caching. It's literally a cheat code for building scalable and high-performance systems!