Like many trends in software there’s no one clear view of what ‘Serverless’ is, and that isn’t helped by it really coming to mean two different [things depending heavily upon servers]
Kids these days and their lousy 正名.
Why is this called serverless to begin with? There clearly are (virtual) servers involved. Just some buzzword BS?
This was more or less my reaction; the term seems poorly chosen. I get the thought behind it; the developers aren’t developing a server. So their product backlog is “Serverless”. But the application itself not only has one server, it has many, and all of them are out of your control.
I can see the appeal in terms of expediency, but in my mind it’s adding a lot of brittleness to your project. You are relying on all those third party services to have whatever level of availability you want to provide to your customers. Your availability is not only going to be worse than the worst of your dependencies, but it will be the aggregate of all of them (since their downtimes will likely not be concurrent, unless they all run on AWS.)
I’m curious as to what alternative names you’d suggest. I kind of like “Lambda Architecture,” but AWS naming their proprietary service “Lambda” makes it a non-starter. “Functional Architecture” might work, but could also mean lots of other things.
That seems extremely vague to me, not to mention likely to cause confusion with both Service Oriented Architecture and Microservice Architecture.
Server less and SOA do seem to have a lot in common.
To me the primary difference is that I’m no longer responsible for managing my code at a unix-process level.
I’d call it ‘process-less architecture’ to reflect that but it’s also a little confusing.
Lambda architecture already exists.
I guess they replaced ‘cloud’ with ‘serverless’
I think the confusion is between server meaning a machine, of which there are still obviously some, and server meaning a program that is in a forever loop waiting for connections, handling them, etc. In the latter sense, this is an architecture where you do not write a server. Your code handles a single task, and something outside of it is responsible for dealing with connections, queuing, etc.
I am gritting my teeth a tiny bit, because this is in essence what PHP always did really well. Apache handled all the contextual junk, while you dropped a file into a directory and that’s about it. The more things change, etc.
Right, but the servers aren’t part of the architecture.
Getting away from the process model and towards a unit of work model is a potential win on several fronts, especially logging/perf monitoring can be rethought in interesting ways.
A real pity lambda is tied to a runtime instead of a shared library call. That was a huge lost opportunity for aws to build something both more useful and more interoperable. I suspect the interop killed that approach though.
It would be interesting if amazon provided a docker image template so you could cut out all those fussy middle bits.
The intention is surely not to say that there are no servers which exist at all. It is obvious enough that this is not possible. Instead, the goal is to work with an architecture which doesn’t require anyone to scale and otherwise maintain their own VPCs, and the name is (albeit, it feels a bit sensationalist) promoting this.
[Comment removed by author]
There’s still a power supply & fibre when you use the cloud, but those things stop being part of your architecture.
Maybe we should rebrand “cloud” as “powerless architecture” in that case.
“There is NO CLOUD, just other people’s computers”, as a sticker someone gave me claims.