HN Reader

The way I view serverless such as AWS Lambda, and services like SQS and SNS, in that you're supposed to use it to program the cloud environment, not to stick your business apps in it.

The thing i hated the most about aws lambda is connecting to postgres or using bcrypt... it's possible, but it felt like defeating Malenia.

I really loved serverless for while, particularly in the early days, when building small projects. But AWS Lambdas, for example, is constant maintenance hell for larger applications, including building and dependency issues, debugging and slow deployment.

One feat is still amazes me - my AWS Lambda React webapp example (Todo with server rendering) which were deployed in 2019, still works as today, and I have not changed, or redeployed it since.

> If your workload is truly intermittent and stateless, and you want zero operational effort, serverless can work.

And it works pretty well. A lot of internal and external JSON APIs are a good fit.

I've found the article ok, but it would have been a much nicer read without all the emotional stuff and just kept - serverless is pushed as panacea but actually isn't a good fit because...

this is a fair critique of what I would call "first-gen" serverless platforms, like AWS Lambda. it's a shame that it's ~5ish years late to the party.

because "just use a container" is more or less the solution that "second-gen" serverless platforms all offer.

but also this:

> A container keeps state (just add a Docker volume!)

is just absolutely terrible as general-purpose advice.

like, yes, it can be annoying that "serverless" platforms are generally stateless, which forces you to move your state into a hosted database of some kind.

but...that reflects the underlying reality of the cloud platform. the servers that your "serverless" code runs on are generally themselves stateless.

if you were to blindly follow this "just add a Docker volume" approach to managing state, you're in for a rude awakening the moment you want to scale your "serverless" code from 1 server to 2 servers.

and unsurprisingly, the article glosses over this a few paragraphs farther down:

> You can deploy one container, or ten. Scale them. Monitor them. Keep state. Run background jobs. Use your own database.

run 10 containers...each with their own Docker volume? use my own database? what. this is blogspam nonsense.

So he learned containers and wants everyone to use them because it raises his competitive advantage. I didn't learn containers, am stuck at VPS and virtual machines stage, it's easier for me. I do think containers is a scam.

Under-rated, but probably the best serverless offering: Cloud run on GCP. Pay like for a VM, but only for the time you're getting/serving requests.

(IMO, if it can get a fly.io like command line experience, it will thrive more.)

this article is actually fairly balanced.

Seems like a pitch for sliplane to me.