Like "cloud computing", the name "serverless" doesn't make much sense when used literally. It doesn't mean that there are no servers involved, just that there are none to be directly managed by the developer.

P2P also doesn't mean "no servers", but that every node is as much server as client.

Amazon popularized but didn't invent the term "serverless", which appears to have been first used in 2012.[1]

[1] http://readwrite.com/2012/10/15/why-the-future-of-software-a...

> It doesn't mean that there are no servers involved, just that there are none to be directly managed by the developer.

They already had stuff like that. S3. RDS. Elasticache. At least the cloud gives you the nebulous feeling of servers off in the ether somewhere.

But serverless is neither specific nor accurate. It doesn't work. It's nothing more than lazy marketing-speak.

> S3. RDS. Elasticache.

A requirement for serverless would be having access to a general programming language which is why those examples don't really apply.

Functions-as-a-service seems clearer to me

Me too! It also works nicely when thinking about the IaaS ⟷ PaaS ⟷ FaaS continuum of abstraction.

Eventually we'll get to LaaS, where instead of having to find, test, and integrate libraries, you type in some natural language like "send an email", and pop down a guaranteed-compatible-for-X-years, 100% uptime, edge-case-handled function that automatically bills per execution directly to your FaaS account, no registration or invoicing required.

The name for "just give us your code and we'll run it" has been PaaS for a while.

They actually mean this - https://en.wikipedia.org/wiki/Common_Gateway_Interface.

1993 is the new 2018.

edit: And the life of the Apache Web Server (the first AWS) started with that interface.

Clearly the next big development in this space will be some form of server-side scripting language which can be embedded in HTML and is tightly coupled with the web server, some sort of Hypertext Preprocessor.

I bet if AWS acquired ColdFusion from Adobe and rebranded it Elastic Markup Platform it'd be the hot new thing

I was just telling my wife this morning that this "Serverless" business was just CGI reinvented. I don't get it.

I remember CGI; curious if you're able to elaborate how you see the analogy.

Pure CGI applications (before the mod_x / long-running workers strategy took over) are "stateless" / "function as a service" insofar as the application's internal state can only live for one request lifecycle. However, they generally ran with the external state (ex. local filesystem) preserved between requests, so the approach was still often a bit different than it is for modern FaaS applications, where state can only live off-server (ex. in a remote datastore or another service).

If you take a CGI based implementation and constrained it to use only external managed services, and you use Lambda to serve it up, you won't need to manage servers explicitly.

The real serverless apps are pure clients that use 3rd party services for everything - i.e. the developer doesn't write any backend code that runs on their own infra.

Is something like mod_php what you'd consider a CGI application? I always think of CGIs from before the day when webservers made it easy to integrate a runtime. For me, CGIs were usually binary executables that the webserver handed data to. I always thought it was about the data exchange, instead of about application state, because http requests are by default generically stateless.

To me it's about the application lifecycle, so no, I wouldn't consider mod_php CGI (which is why I specifically called it out in my parent comment).

CGI does the same thing Lambda does: it binds the application lifecycle to the request lifecycle. HTTP requests to an application server that runs across multiple requests are not stateless, they're inherently bound to the server's internal process state. If the server is well-written this shouldn't matter, but the entire reason an application has to be refactored at all to become a Lambda is that this is not usually the case. Most modern application-server style web apps are loaded with mutable global state that lives through many requests - from thread / connection pools to global caches to updatable configuration stores to even dynamically loaded code/modules.

Serverless means you don't have to explicit manage hosts yourself. They are transparent to you. In that case Lambda is no different from blockchain, where you have either AWS/server farm to run the actual code for you.

Which in term, makes this project weird. Because in order to use it, you still needs to hosts a group of servers yourself. If someones else hosts it for you, you don't really care what framework they are using.

> Serverless means you don't have to explicit manage hosts yourself

So they say but it still sounds daft.

I have a ticket to fly from London to NYC but all I have to do is turn-up and sit in a seat, someone else manages the imfrastructure. Aeroplaneless architecture!

I haven’t seen option 2 things referred to as serverless. Their descriptions often involve the word blockchain from what I gather.

Seeverless is a catchy name, and a better one perhaps would have been function oriented or function service or some such. But it really does mean swrverless in that (a) there isn’t one server and (b) there is zero configuration and maintenance of the server for you to perform.

> I haven’t seen option 2 things referred to as serverless.

People use "blockchain" to describe it to other non-technical people, but they do need a way to describe their architecture. Among blockchain/crypto developers the word "blockchain" has become washed down too much that it really doesn't mean anything. So when they need to explain their architecture they do need a way to describe how their app doesn't have a server.

What I've seen is people say "my app is 'TRULY' serverless", or "My app does not require a centralized server". This was actually my point, because it looks like people who are actually building truly "serverless" apps find themselves in a situation where the word has been hijacked by server vendors, so they have to use qualifiers like "truly", or explain it out in more detail to actually express that they indeed don't have a server. Not saying all the FaaS guys don't have a point, just saying it's kind of a funny situation not so different from when "hoverboard" was viral a few years ago. Everyone knew it didn't "hover" but it was too late because the brand was already taken.

> But it really does mean swrverless in that (a) there isn’t one server

Normally when you say "X-less", it means "there is NO X", not "there are more than one X".

Would you say that if you use Zipcar and don’t own your own vehicle, you live a carless lifestyle?

And are you saying that people in the crypto world have blockchain as such an implicit given that they don’t need to describe it, but a distributed nature of its operation is something that explicitly needs to be stated every time? That seems really silly. “As a public ledger” is better than serverless in that case. Or “smart contracts”. But serverless really is a misnomer buzzword in that case.

> Would you say that if you use Zipcar and don’t own your own vehicle, you live a carless lifestyle?

This is all wordplay and we can go on forever like this. Using your measure, we can also say any SaaS is "serverless"--heroku is serverless, aws is serverless, digitalocean is serverless--because nobody owns a physical server anymore.

> And are you saying that people in the crypto world have blockchain as such an implicit given that they don’t need to describe it, but a distributed nature of its operation is something that explicitly needs to be stated every time? That seems really silly. “As a public ledger” is better than serverless in that case. Or “smart contracts”. But serverless really is a misnomer buzzword in that case.

Again, this is really difference in interpretation of expressions. When you use Ethereum to write a smart contract, you basically store your application state on Ethereum. Compared to ordinary apps where you host your app on a server you own, this sound pretty much "serverless". If you have an AWS instance you have to pay monthly fee. If you deploy a contract to Ethereum, you just pay once when you deploy, but once deployed you don't pay for hosting.

"Public Ledger" is an ambiguous terminology which doesn't fully describe what blockchains do either. You could have a public ledger without it being decentralized nor transparent. A central authority could just make their own database public, but they could always manipulate the data if they own the database. The whole point of blockchain is that no one party should be able to control the truth.

"smart contract" is also generally considered a ridiculous terminology by those who actually do work on building "smart contracts". They are mostly "dumb" contracts. In fact, when you write these contracts, the dumber the contract is the better it is. If you try to be too clever, you end up with stupid mistakes like the parity hack. Therefore most "smart contracts" are ideally nothing more than transparent auto-updating distributed databases which can send messages to one another.

I'm not saying you're wrong and I'm right. I'm not even saying blockchains should be called "serverless" instead of FaaS owning the brand. I'm just stating what I've observed: Most FaaS services are hosted on a server that the owner needs to pay for every month. Blockchains don't have an owner and there is no "server". I think blockchains are closer to "serverless" than FaaS because of this, but by no means I consider this a perfect description of the technology.

Language construct trip - Less Sugar vs Sugarless.

On a separate track - Is it the sign of my age, that I am either concerned about developers not knowing the impact of their code on the hardware, or just whimsical and miss the days when one opened strace or kdb to see how efficiently the code executes? Does someone else feel this way?

One of the less desirable side effects of hardware becoming cheaper is that there are many places for a lousy programmer to hide.

I just interpret 'serverless' to mean 'an abstraction layer above the server'. The term is poorly named, but just like git commands you gotta go with what takes off. shrug unicode

I thought there were nodes in blockchain.

I think that the best name is "server for dummies".

As far as I know, all the projects that promote themselves as "serverless" are stateless functions and not designed to store states, which means if you want a database you will need to store it elsewhere and utilize it from the "serverless" container. So no DB for you out of the box if you want to use serverless architecture.

So I don't think it's for "dummies". Dummies want an all-in-one server.

> As far as I know, all the projects that promote themselves as "serverless" are stateless functions…

Any normal PHP app is just a collection of stateless functions, but that doesn't automatically make all PHP apps "serverless" apps. What makes something "serverless" is the FaaS[1] execution model.

[1] https://martinfowler.com/articles/serverless.html

Or, you know, it's better to reference the source: https://tools.ietf.org/html/draft-robinson-www-interface-00

Most PHP apps are run by DBs. They are not stateless.

Most "FaaS" apps also access a remote datastore as well. The fundamental value of most web software applications revolves around state transformation in some way or another. FaaS just "cleans up" the application state insofar as it forces the state boundary to a comparatively slow edge and doesn't let you, for example, store things in in-memory shared datastores.

in the past year or so i've seen serverless extended to anything where the underlying compute is abstracted away. so ex. bigquery and dynamodb, two very stateful services, are also described as serverless.