[arno1]

Yeah, this is normal. One bus can't fit more people than it physically can.

The high load can be alleviated by the use of more MX server DNS records (and the MX servers of course, across the different locations), LBs, smarter thresholds. Of course nothing is a panacea.

Either way you will hit the AWS's limits or will get a huge bill. And then, even if you set up the budget limits, it still won't make the service more available once you reach the limits.

[danenania]

If you're running a saas and the increased traffic comes from paying customers, you likely prefer a huge bill to downtime.

But apart from that, there's a huge benefit in saying "I'm happy to spend any amount up to X" and not needing to do any capacity planning beyond that vs. continually trying to guess what's the right % to over-provision your VMs and having downtime when you get it wrong.

[arno1]

Yep, but how can you be sure the serverless provider will never go down? I've witnessed multiple times when AWS's services went down.

> If you're running a saas and the increased traffic comes from paying customers, you likely prefer a huge bill to downtime.

Well, in such situation, I would probably run more advanced container orchestrators such as Kubernetes which you will then configure to automatically spawn the additional server instances.

Of course there are certain advantages in running a serverless code as you have just mentioned, but since my primary concerns are "my data is mine" + "no vendor lock-in" + "I control all the gears", it is not the best option for me. Unless I want to run & provide the serverless services by & for myself.

It's always a game between the security (more freedom) and the convenience (less freedom). Though, for some, there is more freedom in the convenience (until they start to see their hands are in the digital cuffs :P)

[danenania]

The serverless provider can go down just like the VM provider can go down, but the key difference is that it won't go down due to traffic bursts.

Auto-scaling helps, but it still takes awhile to spin up new VMs, and you'll have downtime in the meantime for sufficiently large bursts.

On lock-in, in my experience with any non-trivial infrastructure you end up tied to your provider anyway. You're still going to need IAM users and VPCs and subnets and provider-specific auto-scaling and all that jazz. Serverless lock-in is deeper, but either way switching is a big project.

[arno1]

This is why the important projects must be thoroughly planned and tested in order avoid non-trivial infra or a blind cat situation. And then it is a really good idea to leverage IaaC (Infrastructure as a code) which would bring the whole thing up really quick.