Docker isn't serverless | Hacker News Reader

Docker isn't serverless

serverlesscode.com

62 pointsjayfk63 comments

"Well, serverless isn’t really a technique for building distributed apps - it’s about building useful apps"

"But serverless doesn’t mean there is no Docker – in fact, Docker is serverless."

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.

Yes, Docker is not serverless, because it runs on a server, like your lambda functions.

The idea that words themselves can be harmful is ridiculous. People create and use words. The people who say words can be harmful, if they are presenting facts in the way they see them, as opposed to the way they are observed in reality. Stop attacking words and start addressing those who use them in a harmful and dissonance creating way.

The reason people become polarized over a given subject, especially when it's boiled down to a single term, is because we all have different perceptions based on our roles and responsibilities. The term "serverless" can be applied to the users of a given application. Gmail is "serverless" for me, but not Google. For Google ops, Gmail is definately "server" based. Flipping terms, by those who seek additional resources for themselves, their company and their limited partners, is simply a means to hide the truth of the matter behind running their software.

To achieve infrastructure which is trustworthy and not owned by self, we must implement trusted architectures which can adapt to changing conditions and provide fault tolerance to a given level for an immediate cost. Docker has barely scratched the surface of what must be done to address these architectural requirements. The unfortunate bit is that their business model is likely to take them in the opposite direction of where we need to go with all this. That's just the way innovation works when it's driven by VC capital.

There are harmful words in use, but obviously it needs a user base to spread, the two can't live without each other. I'm not talking about swear words, but words that offend or misinform people or summarize a concept that can be harmful or generate controversy. Take web 2.0 for example. It caused quite a stir because nobody was sure what's 1.0 vs 2.0 was, then it faded away. I consider homeopathy a harmful word too. It sounds innocent, memorable and somewhat legit, but it's a dangerous thing.

I think that if many people point out that a word is pointless, inaccurate and deceptive, then that user base can fade too, therefore it makes sense to attack the word and not go ad hominem on the users.

> Gmail is "serverless" for me, but not Google.

Thanks for bringing this up, for me as a user, gmail is nothing but a webapp for an email server. So is SaaS a better category for it or serverless? Without net connection (to a server) it's pretty useless. Even from the user point of view it's not clear what the term should cover.

After all, we should focus on the technology, because that's promising at least.

Kudos to the author for writing this. Serverless is a thing, but Docker definitely isn't it. Nor is AWS lambda.

Serverless is client-only code, or even Peer-to-Peer between self-coordinating clients.

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.

>Serverless is client-only code, or even Peer-to-Peer between self-coordinating clients.

That's a valid definition but it's just one of many. The Function-as-a-Service has also been called "serverless".

Your definition of "serverless" demarcates on where the code runs.

The FaaS "serverless"[1] differentiates on what part of the stack you don't have to manage the housekeeping for. With FaaS-serverless, you don't worry about upgrading a particular Linux kernel version if you can decompose a computation into a function that runs on AWS Lambda. So, deploy computation to the cloud without the Linux server embedded inside an image (AMI) -- and it seems natural for a bunch of human beings to call that "serverless".

Likewise, the "server" in X Window X11 is the display services to differentiate it from the "client" of a terminal app.[2]

All 3 meanings of "server/serverless" can coexist without confusion and it doesn't seem like terminology we have to bikeshed. Personally, the context surrounding serverless always makes it clear what we're talking about. Is anyone truly confused between SQLite being "serverless" and AWS Lambda being "serverless" because they happen to use the same word?

As for Ryan Scott Brown's definition of "serverless", is there near universal consensus on his criteria?

[1]https://en.wikipedia.org/wiki/Function_as_a_Service

[2]https://en.wikipedia.org/wiki/X_Window_System#Software_archi...

I think the deeper we go into this discussion the more philosophically ambiguous it gets.

If I think of the most basic, abstract definition of a server I can, I'd say it's a piece of software at a known location outside of the client process, to which a client goes to transmit a message (and optionally have future messages back and forth in the same "session").

I would say Lambda is not serverless because it depends on software outside of the client process, and I know where it is.

X is not serverless because the client process is separate from the server.

SQLite is serverless because my process is calling the sqlite library.

Torrenting initially has a server (clients need a way to find peers) but very quickly becomes serverless.

So I'd say my definition isn't about where it runs, but who is running it and in what context.

That's my thoughts on it anyway.

>If I think of the most basic, abstract definition of a server I can, I'd say it's a piece of software at a known location outside of the client process,

But you're trying to reduce it down to a perfect singular definition. English doesn't work like that and we'll just end up in contradictions as I will demonstrate further down in my comment.

>I would say Lambda is not serverless because it depends on software outside of the client process, and I know where it is.

Right... and I acknowledged and agreed that your particular definition of serverless doesn't include Lambda. However, I can also explain why others call deployment without-the-Linux-kernel as "serverless". I guess a different chain of memes might have resulted in alternative terminology such as "Linuxless" computations or "os-free" functions but somehow the word "serverless" gained currency.

>SQLite is serverless because my process is calling the sqlite library.

So what if my web browser submits a REST API call to a web server that uses SQLite as it's backend? Is SQLite the "db server"? Yes and no. It depends on which definition of "server/serverless". (Machine location vs os in-process/out-of-process)

If we insist on 1 definition, we will have contradictions.

> If we insist on 1 definition, we will have contradictions.

And if we keep on using catch-all buzzwords such as "serverless", it makes words void of any real meaning.

Serverless has a very definite meaning to me if I'm tired of administering Linux servers.

> If we insist on 1 definition, we will have contradictions.

Yeah, the thing with using a clear language is that what you say may be wrong. If we grow out of our clarity prison we'll be able to babble any combination of words, and still not be wrong!

It seems like in any case, use of "server" is generalizable or stable over situations where we have "an entity communicating requests to another entity which is responsible for servicing those requests." The problem here is that the word is invoked so as to distinguish entities at different layers of abstraction (a physical machine, a "platform", a set of supporting libraries and runtimes, a process, a function).

Yet, if we do not have clearly defined definitions, then we may as well not be speaking at all.

A clear description of Docker encapsulates it as a container.

A clear description of Lambda explains its relationships with functions and statelessness.

Using a term abstractly, in such a way that it can collide with a word that for all intents and purposes appears to be its opposite [0], shouts to a degradation of language use. Metalanguage is in use within various fields, to make it easier to communicate concepts. Here, using a nonstandard word without clear meaning is pointless.

That this is being discussed is proof enough for me that the word is ill-suited to its task.

[0] "I deployed a serverless stack that serves up information from our database."

> If we insist on 1 definition, we will have contradictions.

No, we will have things that doesn't fit the definition, and we will also have people who use the defintion wrongly.

But that's okay.

That's the whole point of definition, to be able to say whether things fit the definition.

If we insisted the "red" only has one definition, then we can tell that white is not red. And that's okay.

In your SQLite example, no, SQLite does not becomes db server because a server application wrap over it. File does not becomes file server just because it's shared over network.

I always understood a 'server' to be the process (or machine) that accepts the connection; the client is the process (or machine) that initiates the connection. Sometimes the same machine can be both the client and server. In your BitTorrent example, users are both clients and servers.

If you try to nail it down to a specific definition, you'll wind up in contradictions. English doesn't work like that; when I use a word, it means just what I choose it to mean, no more and no less.

Doubleplusgood, fine sir. Doubleminusgood on the language opressors!

Since the reader has no way of telling what definition you happen to choose for each of those words - as any explanation is itself made using other undecipherable words - communication is impossible.

I have therefore decided to assume you are declaring war on Austria.

And thus, the first world war.

> means just what I choose it to mean

No. Not if both parties don't agree on a common definition, one party can "move the goalposts".

It could mean A one day and then B another. Look at all the trouble with TLAs.

Then you should just be talking to only yourself.

> Your definition of "serverless" demarcates on where the code runs.

Additionally, that's an assumption you're making about what I said - I said no server. Nothing about where the server is

The only thing serverless about AWS lambda is the pricing model.

p2p is not serverless, your computer / client is a server.

Yes, and writing with a pencil is not serverless, because paper is a server. /s

I can understand why people try to come up with a definitive definition of "serverless" but....

"Serverless" is an adjective.

Adjectives are used to provide auxiliary meaning to the noun it's attached to, which means it depends on context.

It could be a "serverless website", it could be a "serverless hosting", it could even be a "serverless diner"!

It's funny to watch people debate the meaning of this word as though it's some rigorously technical term that has been around forever. It's just the latest buzz word for the latest evolution in simplifying/hiding operations from developers.

You echoed my thoughts exactly!

From marketing point of view, I think it's the best naming ever, since it makes people talk about it more.

Ugh, of all the jargon the dev world has come up with serverless is the worst - if it runs on another computer it is not server less.

I think it's an inside joke:

2 people bet each other a dollar they could take a fundamentally simple concept and wax poetic insanity around it until the text was so insane no one could actually read through it - so people just shrug, wash the virtual slime off and move on. Their will power so drained by reading the BS they can't even be bothered to complain.

Then comes the fake accounts to gush how 'serverless' and 'function-as-a-service' are completely new and different and awesomer bra.

The next bet will probably be "mathematicsless": how we solve collision detection without math - and you should too!

It's not quite as bad as Salesforce's "No Software" campaign.

I wonder when Salesforce is going to go serverless so we can run no-software on our not-servers.

And this is why we have so many crappy blog posts and comments trying to define serverless. People are trying to define a term that fundamentally is incorrect about what it's trying to describe.

Just call it "cloud". That's already a meaningless catch-all term that covers everything.

Whenever I hear serverless, I think of

http://dilbert.com/strip/2015-12-20

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

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.

Strongly agree "serverless" is not well defined in general.

> Reducing maintenance by not running your own platform

This is my favorite technique too but it's nothing new.

Heroku, App Engine and Lambda satisfy this for custom code.

But I do agree with the author.

Docker is not a service or serverless.

Swarm, Kubernetes, Mesos are all software in every sense.

You install them on servers and you perform complex operations to keep them running well.

Doing this unlocks all sorts of new utility, but it's the opposite of "use cloud services" in almost every way.

> if your backend is [...] S3, it's certainly serverless

Is it really serverless if you have to configure the web server serving the files? If you have to manage ACLs, regional distribution, compression, CDN mirroring, versioning, DNS...

If you move to Lambda, you're also tossing in the API gateway configuration, Kenesis streams, datastores, IAM permissions and roles, throttling behavior, scheduled tasks, VPCs, subnets...

Just because you're not starting and stopping the processes doesn't mean you're not managing the server.

/devilsadvocate

The things that actually fits best with the new serverless term is - shared hosting. Just FTP some PHP files into a directory, and it's running.

Excuse me, I'm off to sell my marketing consultation services to GoDaddy and Hostgator.

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

How could someone claim docker is serverless? It's pretty much the definition of server.

It's servermore if anything.

"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo"

That's pretty much all I'm seeing in the comments, just with "Serverless" instead.

If I'm not mistaken, congratulations on getting the capitalization just right there.

Only if you forget to pay your hosting bills do your services become serverless.

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.

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?"

Reading the article I can see how it can be construed to be serverless but it is a real stretch.

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.

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.

Then if the function isn't called for a while, terminate or scale down the container(s)

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.

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.

Serverless isn't serverless either - it's pretending someone else's server doesn't exist.

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?

I was going to make a comment about how doing that would mean we couldn't get to the next phase of the cycle, when we start talking about "serverless microservices". Then I saw we're already there[1], and died a little on the inside.

[1] https://gun.io/blog/serverless-microservices-with-zappa-and-...

Related recently published podcast: http://softwareengineeringdaily.com/2016/08/23/serverless-ar...

I also was on SEDaily a while back on the same topic http://softwareengineeringdaily.com/2016/06/20/serverless-co...

Sounds like ol' Murky and ilk is at it again...

To me Servlerless is a PaaS model, but more specifically a payment model on top of a PaaS model.

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.

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 https://github.com/SocketCluster/socketcluster 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.

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

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

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

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

There are lots of great teams building new platforms on top of Docker which will make it easier to use than BaaS.

I totally agree with your comment. I think that the potential of container schedulers will start showing and will become popular.

Martin Fowler defined serverless as "bringing entire applications up and down for every request". http://martinfowler.com/articles/serverless.html

I don't think that this is what we do with containers, they mostly stay active when there are no requests since they take more than 20ms to boot up.

Thing is, it's not what Amazon does with Lambda either; so if the prime example of serverless, isn't, what is?

https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

Serverless just means PaaS, right?

I would consider a project in Docker serverless if it is used in something like AWS EC2 Container Service (ECS).

Why? Even with ECS the container's host is maintained by you. It's hardly more "serverless" (less serverful?) than just running docker on EC2.

Here's some nuance to consider...

If configured properly everything in an ECS stack is a service offered by AWS:

AMI maintenance is a service provided by the ECS team

The ASG service automates cluster side

CloudWatch Logs service ingests all your logs and offers archival and search services

ELB and ALB are managed services

CloudFormation service can configure all this.

I live in a world where I configure all this but maintenance is trending way down.

It's not zero like on Heroku but maybe it's a happy trade off for the extra customization...

Hmmmm perhaps my definition of serverless is non-standard :) My thinking is that if you just have an endpoint that you can throw a container at, or something like RDS for databases, then that's serverless enough for me (at least it takes out a huge operations cost, especially for smaller companies). But I get that it's not true 'servless' in compared to lambda etc.

Reply on news.ycombinator.com