Hacker News Reader

Comment by mjb | Hacker News Reader

Event-driven and serverless are related, but distinct ideas. Event-driven architectures can be built in a datacenter, on virts, in containers, or on serverless. On the other hand, serverless architectures don't necessarily need to be event driven. These patterns do have natural affinity, so they are often referred to together.

Serverless is a set of financial, scaling and operational properties of an architecture. One of those common properties is phrased as "scaled per request", which is particularly interesting in event-driven architectures.

View on HN

I understand your point; my issue is that "serverless" as a term is a misnomer. You cannot have a serverless architecture without some servers to support it.

The "serverless" distinction is a useful one to make, because it implies something about the architecture as you mention—my only point is that we could have done much better with the name we use to reference said architecture.

It seems like a pretty good name to me. The point of the term "serverless" is that you aren't presented with any abstraction of a server; operations like "spin up more servers to handle the load" or "SSH to the server to figure out what's going on" or "reboot the server because it's acting weird" don't exist for you.

The term does get abused to refer to any server cluster with a bit of autoscaling logic, and in that sense it is a misnomer. But I don't think that's what it originally meant.

But didn’t we already have this concept with Platform-as-a-Service (PaaS)?

What you described sounds like Heroku, Azure Apps, etc.

In many simple cases, Heroku is effectively serverless. But there are situations (in particular monitoring and billing) where you're forced to think about the individual dynos your app is running on.

No, it's a terrible name because your definition implies that VMware or EC2 instances would be servers since you can SSH into both. A significant portion of ops people would never refer to a VM as a server so you've already run into big problems.

Then there is the problem of who it is 'serverless' for. If the developers use a lambda like service hosted by their own org in their datacenter (operated by separate ops people), is it still serverless? If so, then it has nothing to do with actual servers and it's all about making operating system runtime specifics transparent. If not, then it's just a marketing term for letting Amazon or Google run your company's hardware.

Reply on news.ycombinator.com