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