Hacker News Reader

Can you please not post in the flamewar style to HN, as you did here and elsewhere in this thread? You can make your substantive points without that. We're trying for a different kind of discussion.

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.

> The author apparently does not have any experience in building systems/infrastructure.

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

I don’t care what he built if he justifies his arguments with distorted facts and complains about lack of things that have been around for a decade.

When you make statements like this:

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

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?

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.

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

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

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

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

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.

I built a CD for AWS (beakerstudio.com). The author is correct about everything being super complicated. Tools like Terraform help automate changes, but you still have to _learn_ all of the strange ways AWS works and juggle configuration requirements that are oftentimes so bizarre it makes you wonder if they are trying to funnel developers into support plans.

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.

Been looking at a few solutions similar to yours! I'm currently on Render and looking to move elsewhere so I can have more control and particularly insight into system metrics. Do you support zero downtime deploys? It wasn't clear to me from your home page.

Tasks are run on ECS with Fargate. If you setup your server with a load balancer, which is required on ECS to point DNS to the server, then the load balancer will wait for health checks to pass before switching over to the newly deployed tasks. ECS with Fargate is reliable in my experience, and Beaker Studio uses an alternate installation of itself to deploy itself, so everything is dogfooded. A big drawback imo is that AWS is expensive and Beaker Studio does not attempt to hack its way around their pricing. Right now I'm not billing users (within reason) who provide feedback, so please feel free to sign up and email me your notes.

Thanks for clarifying. I'll send you an email once I try it.

Just because you disagree with someone doesn't mean they don't know what they're talking about.

> I don’t even understand what the author wants here. There is no such thing “truly serverless”

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.

Let's see:

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

I think it's important to understand that this was his opinion in 2021. Things have changed since, and hopefully, all these solutions are available now.

TBH, in 2018 I already used the things he was complaining about, so my opinion still stands.

I would not agree. Author basically describes Google App Engine.

He is from spotify, he dont have any experience full stop.