"Well, serverless isn’t really a technique for building distributed apps - it’s about building useful apps"<p>"But serverless doesn’t mean there is no Docker – in fact, Docker is serverless."<p>Yet another case where it's clear that "serverless" is a harmful term. Everybody means something else by it and there's no wonder that posts like this surface.<p>Yes, Docker is not serverless, because it runs on a server, like your lambda functions.
Kudos to the author for writing this. Serverless is a thing, but Docker definitely isn't it. Nor is AWS lambda.<p>Serverless is client-only code, or even Peer-to-Peer between self-coordinating clients.<p>There's a lot of stuff that overlaps in this domain, including microservices, containers, serverless, and if we want to talk about them we should use the right terminology.
I can understand why people try to come up with a definitive definition of "serverless" but....<p>"Serverless" is an adjective.<p>Adjectives are used to provide auxiliary meaning to the noun it's attached to, which means it depends on context.<p>It could be a "serverless website", it could be a "serverless hosting", it could even be a "serverless diner"!
"serverless" is a new term that people have been using in tons of different ways. To the author, frankly I don't think you get to say what's serverless and what isn't. I think only point 1 is agreed upon - the rest is up in the air. Point 3: that it must be function-as-a-service: I dont agree there. Counter-point: if your backend is google sheets, or plain S3, it's certainly serverless.<p>Docker? Maybe. Depends how it's architected. I get that they're trying to latch onto the up-and-coming big movement, but since that big term has no definition, they have as much right as the author to claim to belong to it.
I kind of feel that Erlang programmers are shaking their heads in frustration at all this and saying "we've been doing things this way since the 80s and saying they're great but nobody listens".
"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo"<p>That's pretty much all I'm seeing in the comments, just with "Serverless" instead.
Serverless is a word that only has meaning within the existing paradigms of web development. A "Server" is nothing more than a metaphor for a machine with stuff a "client" (another machine) can request. Everyone acts confused/amazed at what is essentially semantics for describing infinitely more complex systems.<p>It's the same process with any buzzword. They're terms that are so all-encompassing that, yeah, every sensible, modern project operating in a related space could probably be described by them. Like horoscopes for engineering.
As an avid Docker user and also a user of AWS Lambda my only reactive when seeing this article is... "This wasn't obvious already?"<p>Reading the article I can see how it can be construed to be serverless but it is a real stretch.<p>I don't agree with other posters that the only true serverless is client-only technology. P2P has its place and is generally awesome but I feel that distributing your app as small functions that can run on distributed systems where you don't know or care what hardware or OS is underneath is a compelling definition in lack of a better word.
> In the demo, a new container is created for every function invocation which would introduce latency that wouldn’t really be acceptable for most user-facing systems.<p>That seems like an implementation issue that can be overcome, an alternative approach could be to spin up a few containers, deploy the function artefact/JAR/script/whatever and then continuously invoke it via a load balancer.<p>Then if the function isn't called for a while, terminate or scale down the container(s)<p>I believe AWS lambda works in a similar way to the above approach.
A PaaS is not serverless either. We embrace the fluidity of language because that is the pragmatic choice, but using counter-intuitive terms with misleading semantics is not pragmatic so we should reject such terms instead of muddling the meaning of well established terms of art.<p>Everyone can pretty much agree on what constitutes a "server" so I don't see why we should use confusing terms that belie our shared understanding of this term.
I think serverless has bad semantics for it's new connotation (which doesn't even seem to be universally agreed upon). Maybe we should just focus on value, not paying for more infrastructure than you need, and building useful things. Maybe we could just call it practical?
Related recently published podcast: <a href="http://softwareengineeringdaily.com/2016/08/23/serverless-architecture-with-mike-roberts/" rel="nofollow">http://softwareengineeringdaily.com/2016/08/23/serverless-ar...</a>
I agree that Docker is not serverless, but I think that it does replace the need for serverless services if coupled with an orchestrator such as Kubernetes, Swarm or Mesos.<p>The first bullet point in the article is true when taken in its entirety but it's also misleading because using Docker with an orchestrator like Kubernetes does significantly reduce the need for maintenance - You do have to design your apps in a particular way (so that they can auto-scale themselves - And this is no small feat) but once you do, it's really easy on the maintenance side. I think it's a matter of time before open source projects start to become 'built for Kubernetes' - I already did this with my own project <a href="https://github.com/SocketCluster/socketcluster" rel="nofollow">https://github.com/SocketCluster/socketcluster</a> and I know lots of big open source developers who are also doing the same. Kubernetes/Swarm/Mesos are becoming 'cloud' operating systems - Once their popularity reaches a critical threshold, developers will build apps on top of Kubernetes or Swarm in the same way that developers today build apps to run on Linux or OSX.<p>Eventually, when people ask "What OS does your software run on?", the most common answer will probably be "Kubernetes" or "Swarm" - Instead of saying "Linux", "OSX" or "Windows".<p>The second point is also correct when taken literally but also misleading. While Docker doesn't use third-party services to reduce the amount of code... It does allow you to use third-party Docker images to reduce the amount of code... Same result, different approach. I think the second approach is better (and cheaper sine you don't have to pay ongoing costs).<p>The third point makes sense but the concept of 'lambda functions' is completely redundant in a self-orchestrated Docker environment. Lambda functions were invented to fix a problem which BaaS introduced - By the very fact that it doesn't offer you direct access to the backend. In my opinion, Lambdas are not as good a solution as having your own backend code running in auto-orchestrated containers (Lambdas often have lots of limits related to resource usage, timeouts, including third-party modules, etc...).<p>I think that until now, BaaS providers have had the upper hand because they're really easy to use, but I'm certain that Docker/Kubernetes/Mesos will win out in the end for the simple fact that they are decentralized, that they are way more flexible, that they leverage open source technology and that ultimately they will cost much less (because of their high flexibility, customizability and composability).<p>There are lots of great teams building new platforms on top of Docker which will make it easier to use than BaaS.