[SNvD7vEJ]

What a ridiculous and strange definition this is.

Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers...

Why not just call it "Multiserver" instead.

If they mean "containerless servers" or "microservices", then why don't they say so?

If they mean "distributed servers" why not call it that.

If they mean that the client relies on multiple services (each hosted on different servers) why not just call it a thick/fat/stateful client?

Even a database is a remote service (if not embedded), that is run on some sort of server.

Calling anything serverless is just ridiculous as long as it depends on services on the network.

This smells really bad of just another attempt at marketing a pointless definition just to get more business.

[adamt]

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way.

With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to:

  * Manage/deploy servers
  * Monitor/maintain/upgrade servers
  * Figuring out tools to deploy your app to your server
  * Scaling an app globally.
  * Coping with outages in a data-centre/availability
  * Worry about load-balancing & scaling infrastructure 

So obviously there are still servers there, but they are largely invisible to the developer.

I think this is more than just a marketing gimmick. It is part of a big change in application architectures.

At one end as a small developer of of web/mobile app this can considerably reduce the amount of code/maintenance you need.

At the opposite end of the spectrum the likes of Google (Borg) and Facebook (Tupperware) have developed their own in-house solutions where by servers are largely abstracted out as an entity that developers need to worry about.

Managed docker services (e.g. Google Container Platform, Docker Cloud) are another approach of achieving a largely 'serverless' goal.

(edits for formatting)

[sergiosgc]

> So obviously there are still servers there, but they are largely invisible to the developer.

This would only be true if the abstraction were not leaky. Frankly, upon a very cursory inspection, my opinion is that AWS Lambda leaks like a sieve.

[fauigerzigerk]

I would call that a deployment strategy, not an application architecture.

[ronreiter]

No! That's EXACTLY the point - this is EXACTLY what it isn't - a deployment strategy.

Docker vs Ansible is a deployment strategy.

Relying on others to make your code run on a server is VERY different than doing it yourself. It's practically the difference between a company with a DevOps team and one without it.

[fauigerzigerk]

So my job is:

Write server-side code as part of my application, targetting some platform API. Once finished, invoke some deployment routine.

The service provider's job is:

Receive a request from me to deploy my server-side code and keep it running on some server cluster.

That's not a serverless applications architecture because the application contains server-side code.

If you don't want to call it a deployment strategy, fine, I won't insist on that name, even though in my view using a service provider for deployment deserves to be called a deployment strategy.

More generally, it's an approach to make my server-side code run once I'm finished writing it. Call it what you will.

[sergiosgc]

I agree. It is preempting definition use from a true serverless architecture: a swarm of symmetrical client/servers that implement an application and distributively store application state.

[LinuxBender]

I agree. Someone is still hosting the servers and services. It is just someone else. It is also just a re-spin of the term Application Service Provider. That term never gained popularity.

There are some discussions of API's. Whether or not a service has an API is orthogonal to something being a hosted service.

[Illniyar]

No, the idea is simple - the servers are invisible to the user, he doesn't know what or how many are in use.

Since the servers are completely abstracted away, they could have just as well not be - hence serverless.

An analogy escapes me but I sure there are some.

[SNvD7vEJ]

So it is about how the user perceives the application?! If so, why is it called "an architecture"?

Or do you mean that the user don't have to care on how to configure the application? Then "Zero-configuration" is a better name.

Or do you mean that the application hides that it use services on the net? Then it is even worse.

[freyr]

> So it is about how the user perceives the application

The user here is the developer. Here's an explanation from the article:

> "some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party ... One way to think of this is Functions as a Service."

FaaS is probably a better name.

[scrollaway]

I also dislike the term serverless. It's confusing, doesn't relay the information it should. I can't suggest a good replacement, but it's painfully obvious that even here, most people commenting don't actually know what serverless means and what its implications are.

Serverless really is an auto-scalable distributed infrastructure, perfect for small CPU-intensive tasks in an app which doesn't know how many CPUs it'll need at any one time.

[robotresearcher]

> they could have just as well not be

That's a weird logical leap.

Let's make the servers not be by unplugging them. How's the abstraction working now?

[wpietri]

I think you're misunderstanding. I read it as "they could just as well not be servers". It could be Diamond Age rod logic. It could be processing implemented on quantum foam. It could be gnomes. The point is that from the user's perspective, they no longer have to think about servers.

[robotresearcher]

Sure, I get it. But we already have that idea.

The whole idea of a server is to abstract away the details of the upstream computer and its software stack, so the user can think of it only as a provider of an abstract service. The irrelevance of their implementation as a host, VM, box, rack of boxes, pool of quantum foam, string and sparkles, is already built into the concept.

We all know that there's no unique process that is http://amazon.com. It's a service, provided by a (vast distributed) server.

[wpietri]

You use "server" to mean "a vast array of servers"? I don't think I've heard that before.

[robotresearcher]

I'd say that http://amazon.com is the address of Amazon's web server, yes. Does that sound wrong?

[hughw]

Now that it has a name, it can develop a hierarchy of experts, annual conferences, and a consultancy bonanza for a few years.

[matthewaveryusa]

I think Fowler tends to do this in general. Here's a comment from 2 years ago I posted along the same lines: https://www.reddit.com/r/programming/comments/2051mx/microse...

(And yes, 2 years ago I was a little more violent with my wording. Time has taught me things.)

[freyr]

This article wasn't written by Fowler.

[dboreham]

In this context "server" doesn't mean "entity listening on some network endpoint, providing some service to network-connected clients" (which is I think the definition you're assuming). Instead "server" here means "Unix Machine".

Thus "serverless" means software and humans writing and deploying said software that do not need to know anything about /etc/<whatever> and installing packages and disk partitioning and swapping and whether Python 2 or Python 3 gets installed by default this week and ...

IMHO a good thing, mostly.

[bronson]

So my car is engineless if I never look under the hood?

[rileyphone]

I think this architecture is public transportation in that analogy.

[bobbyi_settv]

Your car isn't engineless because when its engine dies, you will know about it and have to do something. S3 is serverless because if one of the servers storing my files die, I have no way of even knowing it happened.

[Sanddancer]

S3's had downtime, and had data loss incidents. S3's only serverless if you believe Amazon's infallible.

[dboreham]

I didn't invent the terminology. Like many many things in this business the terms used are often confusing/wrong/overloaded/re-invented-from-the-1980's and so on. Part of the landscape unfortunately.

[themihai]

Maybe worry free if you don't need to look under the hood. If the manufacturer would lock the hood you would never know :)

[dingaling]

They actually did lock the hood with the Audi A1. Just had a flap through which you could top-up water and oil.

Perhaps we could adopt 'A1' instead of the confusing term 'serverless'...

[audleman]

As a DevOps guy the definition makes sense to me. I've got several parts of my operation that require me to spin up 3 - 30 instances to handle parallel load. I'm always monitoring queues to see if I'm scaling correctly. If I went 'Serverless' Amazon would handle that whole chunk for me. That's approximately 20% of my job taken care of.

I think to an end-user the definition is meaningless, but to its intended audience it fits.

[themihai]

I think it's basically a stateless PaaS/microservice with a set of constrains/APIs on top. The BaaS/Serveless architectures also seem to have their own sub-categories based on the constrains/target. Some are fat(i.e. a kind of full blown PaaS with a common/advanced API gateway on top like parse.com) and others are lightweight(i.e. amazon lambda) meant to run as a function(e.g. update a record on event changes). In the end they are various abstractions that hopefully will improve the security and help you to manage your infrastructure easier.

[mattbillenstein]

You're missing the point in that _you_ don't have servers. Just as cloud is "someone else's computer" -- serverless is someone else's server.

[Can_Not]

He's not missing the point. He might have a preference that technical terms have semantically useful meanings.

[kowdermeister]

That's true for all types of cloud providers, but we don't call them serverless.

This is marketing bullshit for microservice architecture. It just sounds better with some added philosophy.

[ben_jones]

I imagine serverless is a powerful buzzword because it implies cost savings on servers.