"means there is no physical or virtual hosts to manage"
We're just swapping one type of management for another, really. Becoming proficient in all the permutations of AWS stack, for example, to
* make sure you don't get overbilled,
* have appropriate memory/limit resources on your lambdas,
* have correct backup/redundancy on s3,
* make sure all your IAM policies are correct and not allowing malicious actors, etc.
and more... it's ... just a different set of things to worry about. Yay - I don't have a 'server' that can go down. I now just have to make sure I don't get billed $87k because I forgot to click the correct button.
It's not that hard to configure a lambda to run in just as limited a way as a physical machine.
Not having to worry about MCEs or disk failure patching makes the concerns less like a "different set" and more like a subset of things to worry about relative to managing servers.
I know most of this stuff is really well trod-over, but from your comment I think one'd get the impression that people are switching just because of a trend or something, not because there's an actual layer of management they're paying to have outsourced.
(I would acknowledge that view of it being a subset rather than a different set is invalid once you're debugging performance at a gritty level, where cold starts etc. etc. introduce their own equivalent layer of complication, but most people doing most things never need to)
How many times did you update your Node.js AWS Lambdas or GCP Cloud Functions because of the Linux kernel CVE of the week? You didn't because all you're responsible for is your few lines of Node.js logic that kept on scaling and humming along. The cloud vendor cares for the rest.
Just because you didn't doesn't mean they did and you didn't actually have any vulnerabilities. There is no such provable attestation of security in serverless model.
> Lambda provides support for these runtimes by continuously scanning for and deploying compatible updates and security patches, and by performing other runtime maintenance activity.
We're just swapping one type of management for another, really. Becoming proficient in all the permutations of AWS stack, for example, to
* make sure you don't get overbilled,
* have appropriate memory/limit resources on your lambdas,
* have correct backup/redundancy on s3,
* make sure all your IAM policies are correct and not allowing malicious actors, etc.
and more... it's ... just a different set of things to worry about. Yay - I don't have a 'server' that can go down. I now just have to make sure I don't get billed $87k because I forgot to click the correct button.