Hacker News Reader

> cons of serverless:

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

Overall agree with you, but I don't think spaghetti is the right term here - even if the typo is corrected :)

Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies.

Understanding & tracking dependencies is actually easier with serveless, it's pretty clear what dependency that one tiny micro service has.

But where it becomes worse is regarding the code logic mess, you've now turned it in a distributed system problem where, in addition to having a even hard time with cyclomatic complexity, you also have to think about transient failures/retries at each service boundaries.

That and the other problems you describe (performance hit etc)

Yeah I completely agree with all of that.

How about spaghetti architecture.

I like that one.

Prior art:

https://preview.redd.it/y3pw78z0s3oz.jpg?auto=webp&v=enabled...

> Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies.

I started using distributed monolith.

I saw this described recently as the "Lambda Pinball" architecture.

* https://www.thoughtworks.com/radar/techniques?blipid=2019110...

When even Thoughtworks thinks you are doing it wrong you know you are in trouble.

> Spaghetti code is more of a term for monolithic mess where you have a hard time following all the code logic (cyclomatic complexity) and dependencies.

The only thing worse than a monolithic mess, is the same thing but distributed

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

Or just set the Lambda concurrency to a fixed value proportional to your MySQL DB's capacity. It's an easy parameter.

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

This is just nonsense. What is "unpredictable" about the runtime? What is difficult about enabling X-Ray?

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

"All-serverless" is just as stupid an idea as "no-serverless."

Aside from lock-in, your "cons" are just the cons of anyone trying to build large-scale systems without knowing what they are doing. There is absolutely no way anyone who read the documentation would run into your cons of serverless.

https://docs.aws.amazon.com/wellarchitected/latest/serverles...

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

https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-...

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