This is nit-picky. "Serverless" refers to the "dev", not the "ops", and has done for a while.

Fortunately we have Terraform that’s made this possible for a decade(?).

Setting up production-grade DBs in Terraform is easy?

Oh, yes, it is. Setting up the resources actually the easiest part, most of the problems originate from the phenomenon that as the developers starts to use more and more "serverless" things, they know less about how the underlying technology works, how to use indexes, structure the database, how replication or transaction works. Production readiness is not just how a resource is configured. It is about how the application uses a resource efficiently.

> This is nit-picky. "Serverless" refers to the "dev", not the "ops", and has done for a while.

There is no "dev" and "ops" serverless. Your application will run on one or multiple CPUs, will use the memory, the disk, the network. When you write the application all of these matter, memory management, network communication, CPU caches, parallel execution, concurrency, disk access. It does not matter if you call it serverless, cloud, bare metal, etc. The basics are the same.

>Your application will run on one or multiple CPUs, will use the memory, the disk, the network.

But the term "serverless" has never meant "serverless does not run on cpu, does not use any RAM, and does not use disk or network."

You're attempting a clarification for "serverless" that nobody needs because reasonable people didn't actually think serverless/LambdaFunctions/CloudWorkers/etc defied the laws of physics.

"Serverless" from the beginning has always meant not having to do "os management/operations" type of tasks in a vm such as:

  sudo apt-get update
  sudo apt-get install <package>
  [...]

And yes -- to pre-empt the discussion from going around in circles... the "cloud's runtime" for stateless functions do ultimately run on a "server" which runs on cpu/memory/disk. And yes, "the cloud is just somebody else's computer". I think we all know that.

So you mean that serverless is when someone else types in the commands of installing the dependencies of your software.

I am genuinely curious, how difficult/expensive learning and issuing these commands on a VM, putting them into a packerfile, Dockerfile or ansible playbook, considering the whole software development lifecycle?

In your interpretation the serverless is when the person who runs these “Linux housekeeping” commands is working at AWS (or insert any other provider here) and not at your company.

1. Provisioning VMs and copying the right files up to them.

2. Linking them together behind an HTTP load balancer, which itself needs to be on one or more VMs and possibly DNS balancing.

3. Configuring that load balancer to respond on HTTPS endpoints and health check backends.

4. Collecting logs etc to a central place.

5. Making sure servers restart if they need to for versioning or crash reasons.

6. Shutting it all down and cleaning it up if you stop using them.

That's pretty much it. People like it because doing UNIX sysadmin work sucks. The usability just isn't very good.

The autor does make some weird arguments and seem to be creating an emotional setting for something. Like his own product you guys mentioned.

My pods ARE ready in seconds. Wondering why his are not.

That's what I was thinking too. What kind of underpowered, crappy k8s cluster is this person running where pods take minutes to spin up?

Well, he built https://modal.com , one of the coolest things since sliced mangoes, and before that https://github.com/spotify/luigi

> There is no such thing “truly serverless”. Your code will be executed by a server. Period.

It indicates that maybe you are the one who's missing the point. The author is not saying anything about wanting code that magically runs on a server without running on a server.

The author says what they want. It's literally their next sentence:

"As in, I don't want to think about future resource needs, I just want things to magically handle it."

and they have four bullet points with examples of what this means to them earlier.

I think it's fair to argue about the desirability, achievability, etc of this. I don't think it's fair to act as if the author is just spewing buzzwords without explanation.

- Why do I have to think about the underlying pool of resources? Just maintain it for me.

- I don't ever want to provision anything in advance of load.

- I don't want to pay for idle resources. Just let me pay for whatever resources I'm actually using.

- Serverless doesn't mean it's a burstable VM that saves its instance state to disk during periods of idle.

This article was written in 2021.

AWS Lambda was introduced in 2014 that fulfilled all of those requirements in those bullet points that you mentioned. Google App Engine is the same, it was introduced in 2008.

So again, this article tells only one thing: that the author does not know what he is talking about.

Honestly, the experience of building Beaker Studio made me bearish on AWS. They price gouge and the DX is so bad teams pretty much need CDs. Once I get the time I want to update Beaker Studio so people can deploy to any old Linux box instead. Teams deserve so much better than AWS/Google/Azure.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.