[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.