> Turns all your code into spaghetti, this is probably the biggest one.

This is a nonsensical claim. Nothing about serverless requires 'spaghetti' code. Vice versa, nothing aboud non-serverless deployments suddenly ensures well written code.

> Cold boot performance is highly varible and generally worsens with added function complexity but this depends on tech choice.

For many use-cases this isn't a problem. If it is a problem, then sure, don't use serverless.

> Infinite concurrency is a bit of a curse. Want to use that MySQL DB that contains all your business critical data? Better use some MySQL Serverless proxy nonsense because unbounded connections isn't fun.

Sure, but:

A) You get a lot of scalability before that becomes an issue.
B) Setting up a proxy isn't exactly hard. (I get one for free since we use Hasura).

> Lock-in is awful, migration story is awful.

This is nonsense.

Our serverless code runs in docker containers, running perfectly normal ASP.net code. This code could be deployed to a VM, appengine, or k8s in less than a day if needed.

> Amount of Infrastructure as Code overhead, ala Terraform, CloudFormation, whatever else floats your boat to support serverless is insane. The sheer number of objects that need to defined, kept in sync etc is just bonkers. Not to mention if you have multiple services setup like this it's all boilerplate you either need to abstract or carry around.

One of the advantages of our use of serverless is that we don't yet need any of that complexity.

> Hides serious programming deficiencies like memory leaks because context is thrown away after servicing request.

What you descried is literally not a serious deficiencies. If you code leaks memory, but never runs long enough for that to have meaningful impact, it's not a problem.

> Unpredictable runtime makes observability more complicated, probably forcing you into poor decisions as a result, i.e prom push gateway.

The serverless solutions we use have observability built in for free... and datadog automatically can pull that in if you wnat a starting point for more.

> Runtime/execution time limits mean people trying to do all-serverless end up doing horrible things to accomplish long-running tasks.

If you have something that must be long running, serveless isn't a great pick for that one thing (at least, witht he solutions I'm aware of).

That said, there are some elegant ways to handle that using serverless (e.g. by breaking it into smaller tasks with shorter durations)... and going non-serverless isn't a silver bullet, I've seen terrible architectures for long-running code in all kinds of deployments.

> All of the above leads to increasing pressure to make poor architectural decisions to work around limitations of the runtime.

Completely ignoring that serverless can encourage better architectural decisions.

> EDIT: Actually I forgot the worst con. The cost. The $/CPU/RAM cost of Serverless is beyond bonkers. When I was pricing up Cloud Functions vs Spot instances on GKE I think I came to the conclusion Cloud Functions are about 300x as expensive.

Curious.

Let's have a 1s task on Cloud Run with 1 CPU and 1GB of memory:

CPU: $0.00002400/s
Memory: $0.00000250/s
Request: $0.40 / million

Total = $0.0000269 for 1 request lasting 1s.

Current spot pricing for C3 instances is:

$0.003086 / vCPU hour
$0.000413 / GB hour

Or for 1s that would be:
0.00000097/s

Which is 27x cheaper - so you're already off by an order of a magnitude.

It gets worse - that's 1GB of RAM, however the VM needs RAM for it's own OS etc, so maybe you need to provision 2GB of memory, a bit more CPU etc.

The minimum billing time for compute instances according to docs is 60s... so 60x cost if you only need to do this hourly or less.

You're entirely responsible for all time spent, including startup, shut down, idle etc. This just adds more and more cost.

The expected availability model is completely different - serverless should be available in milliseconds, seconds at the worst. Spot instances have no such expectations.

It's a fundamentally different model - a spot VM can't loadbalance, serve code or anything without devops. So now we're spending likely $XXX/hour on devops to try to save fractions of pennies an hour.

When this is all said and done, I don't think you really understand the cost or use-cases of serverless well - and dramatically underestimate the costs of the solutions you present.