undefined | Better HN

0 pointsjasode2y ago0 comments

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

0 comments

zsoltkacsandi2y ago

> "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_hearn2y ago

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.

j / k navigate · click thread line to collapse