[kitd]

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

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?

[szszrk]

If done perpetually - yes.

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.

[cassianoleal]

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

[zsoltkacsandi]

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

[jasode]

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

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

Instead, the cloud vendors created ability to run stateless functions which are executed in a "cloud runtime". The "dev" focuses the effort on coding the stateless functions instead of Linux os housekeeping tasks.

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.

[zsoltkacsandi]

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

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.

[mike_hearn]

Serverless/FaaS takes care of the following things that you otherwise need to do yourself:

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.