The text ; and the piddly recantion

Paul Biggar, a recent CompSci graduateⁱ with serious social integration problemsⁱⁱ had what drunks know as "a moment of clarity" last year, out of which (and a dubious lack of impulse control) came a text, which he published. Soon thereafter he also published a rather shameful retraction. Their interplay will be our subject of study here today, in the vague hope that a teenager or two may be spared the sad fate of turning a lively intelligence into whatever sort of a sad swamp dweller Paul Biggar is.

First, in normal, citizenship black, the text :

Hey, my boss said to talk to you - I hear you know a lot about web apps?

-Yeah, I’m more of a distributed systems guy now. I’m just back from ContainerCamp and Gluecon and I’m going to Dockercon next week. Really excited about the way the industry is moving - making everything simpler and more reliable. It’s the future!

Cool. I’m just building a simple web app at the moment - a normal CRUD app using Rails, going to deploy to Heroku. Is that still the way to go?

-Oh no. That’s old school. Heroku is deadⁱⁱⁱ - no-one uses it anymore. You need to use Docker now. It’s the future.

Oh, OK. What’s that?

-Docker is this new way of doing containerization. It’s like LXC, but it’s also a packaging format, a distribution platform, and tools to make distributed systems really easy.

Containeri.. — what now? What’s LXE?

-It’s LXC. It’s like chroot on steroids!

What’s cher-oot?

-OK, look. Docker. Containerization. It’s the future. It’s like virtualization but faster and cheaper.

Oh, so like Vagrant.

-No, Vagrant is dead. Everything is going to be containerized now, it’s the future.

OK, so I don’t need to know anything about virtualization?

-No, you still need virtualization, because containers don’t provide a full security story just yet. So if you want to run anything in a multi-tenant environment, you need to make sure you can’t escape the sandbox.

OK, I’m getting a little lost here. Let’s back it up. So there’s a thing like virtualization, called containers. And I can use this on Heroku?

-Well, Heroku has some support for docker, but I told you: Heroku’s dead. You want to run your containers on CoreOS.

OK, what’s that?

-It’s this cool Host OS you can use with Docker. Hell, you don’t even need Docker, you can use rkt.

Rocket?

-No, rkt.

Right, Rocket.

-No, it’s called rkt now. Totally different. It’s an alternative containerization format that isn’t as bundled together as Docker is, and so it’s more composable.

Is that good?

-Of course it’s good. Composability is the future.

OK, how do you use it?

-I don’t know. I don’t think anyone uses it.

Sigh. You were saying something about CoreOS?

-Yeah, so it’s a Host OS you use with Docker.

What’s a Host OS?

-A Host OS runs all your containers.

Runs my containers?

-Yeah, you gotta have something run your containers. So you set up like an EC2 instance, you put CoreOS on it, then run the Docker daemon, and then you can deploy Docker images to it.

Which part of that is the container?

-All of it. Look, you take your app, write a Dockerfile, turn it into an image locally, then you can push that to any Docker host.

Ah, like Heroku?

-No, not Heroku. I told you. Heroku is dead. You run your own cloud now using Docker.

What?

-Yeah, it’s real easy. Look up #gifee.

Gify?

-“Google’s infrastructure for everyone else”. You take some off the shelf tools and stacks, using containers, and you can have the same infrastructure Google has.

Why don’t I just use Google’s thing?

-You think that’s going to be around in 6 months?

OK, doesn’t someone else do hosting of this stuff? I really don’t want to host my own stuff.

-Well, Amazon has ECS, but you gotta write XML or some shit.

What about something on OpenStack?

-Ew.

Ew?

-Ew.

Look I really don’t want to host my own stuff.

-No, it’s really easy. You just set up a Kubernetes cluster.

I need a cluster?

-Kubernetes cluster. It’ll manage the deployments of all your services.

I only have one service.

-What do you mean? You have an app right, so you gotta have at least 8-12 services?

What? No, just one app. Service, whatever. Just one of them.

-No, look into microservices. It’s the future. It’s how we do everything now. You take your monolithic app and you split it into like 12 services. One for each job you do.

That seems excessive.

-It’s the only way to make sure it’s reliable. So if your authentication service goes down…

Authentication service? I was just going to use this gem I’ve used a few times before.

-Great. Use the gem. Put it into it’s own project. Put a RESTful API on it. Then your other services use that API, and gracefully handle failure and stuff. Put it in a container and continuously deliver that shit.

OK, so now that I’ve got dozens of unmanageable services, now what?

-Yeah, I was saying about Kubernetes. That let’s you orchestrate all your services.

Orchestrate them?

-Yeah, so you’ve got these services and they have to be reliable so you need multiple copies of them. So Kubernetes makes sure that you have enough of them, and that they’re distributed across multiple hosts in your fleet, so it’s always available.

I need a fleet now?

-Yeah, for reliability. But Kubernetes manages it for you. And you know Kubernetes works cause Google built it and it runs on etcd.

What’s etcd?

-It’s an implementation of RAFT.

OK, so what’s Raft?

-It’s like Paxos.

Christ, how deep down this fucking rabbit hole are we going? I just want to launch an app. Sigh. Fuck, OK, deep breaths. Jesus. OK, what’s Paxos?

-Paxos is like this really old distributed consensus protocol from the 70s that no-one understands or uses.

Great, thanks for telling me about it then. And Raft is what?

-Since no-one understands Paxos, this guy Diego…

Oh, you know him?

-No, he works at CoreOS. Anyway, Diego built Raft for his PhD thesis cause Paxos was too hard. Wicked smart dude. And then he wrote etcd as an implementation, and Aphyr said it wasn’t shit.

What’s Aphyr?^iv

-Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed systems and BDSM guy?

What? Did you say BDSM?

-Yeah, BDSM. It’s San Francisco. Everyone’s into distributed systems and BDSM.

Uh, OK. And he wrote that Katy Perry song?

-No, he wrote a set of blog posts about how every database fails CAP.

What’s CAP?

-The CAP theorem. It says that you can only have 2 out of 3 of Consistency, Availability and Partition tolerance.

OK, and all DBs fail CAP? What does that even mean?

-It means they’re shit. Like Mongo.

I thought Mongo was web scale?

-No one else did.

OK, so etcd?

-Yeah, etcd is a distributed key-value store.

Oh, like Redis.

-No, nothing like Redis. etcd is distributed. Redis loses half its writes if the network partitions.

OK, so it’s a distributed key-value store. Why is this useful?

-Kubernetes sets up a standard 5-node cluster using etcd as a message bus. It combines with a few of Kubernetes’ own services to provide a pretty resilient orchestration system.

5 nodes? I have one app. How many machines am I gonna need with all this?

-Well, you’re going to have about 12 services, and of course you need a few redundant copies of each, a few load balancers, the etcd cluster, your database, and the kubernetes cluster. So that’s like maybe 50 running containers.

WTF!

-No big deal! Containers are really efficient, so you should be able to distribute these across like 8 machines! Isn’t that amazing?

That’s one way to put it. And with all this, I’ll be able to simply deploy my app?

-Sure. I mean, storage is still an open question with Docker and Kubernetes, and networking will take a bit of work, but you’re basically there!

I see. OK, I think I’m getting it.

-Great!

Thanks for explaining it.

-No problem.

Let me just repeat it back to see if I’ve got it right.

-Sure!

So I just need to split my simple CRUD app into 12 microservices, each with their own APIs which call each others’ APIs but handle failure resiliently, put them into Docker containers, launch a fleet of 8 machines which are Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes cluster running etcd, figure out the “open questions” of networking and storage, and then I continuously deliver multiple redundant copies of each microservice to my fleet. Is that it?

-Yes! Isn’t it glorious?

I’m going back to Heroku.

Second, in the gray of subhumanity, the recantion :

Last week I wrote It’s the Future^v, a piece that satirized the container ecosystem, lightly mocking Docker and Google and CoreOS and a bunch of other technologies. Lots of Docker enthusiasts enjoying being the butt of the joke, but it was also much loved and shared by lots of people yelling “I told you this was all bullshit”.

For one thing, the mocking of Docker and CoreOS was nothing light. It was the essential, life-threatening sort of terrorism only fragile, doomed systems can experience.

Mixing Google in the meta-discussion is entirely unwarranted on the basis of the text ; but it carries for the author the significance of solidity. He hopes that by pretending a doomed, "let's-go-through-the-motions" attempt by Google's committees to compete with Bezos in the virtualization space somehow is just as integral to Google as it is for its downstream spawn, some sort of magical amulet may be constructed that'll somehow protect the various "corporations" with no money formed by "experts" with no experience from their inevitable doom once the bottom falls out.^vi

It’s very easy to see why people might think the container ecosystem is bullshit, in exactly the way I satirized.

That'd be for the obvious reason : because it exactly is bullshit, without remainder.

After all, it’s not exactly clear at first glance what Docker is.

Or, as it happens, at the nth glance, or the mth look, or the qth investigation.

It’s containerization, which is like virtualization, but not quite. It’s got a Dockerfile which is kinda like Chef, but it’s combined with something called layers which involves a weird filesystem or something. It solves similar problems to AWS and Heroku and VMware and Vagrant, but in each case it’s slightly different in a way that’s not particularly clear at first and also it’s really not clear why at all.

The author seems blissfully unaware, and dead set on depending on a readership that is blissfully unaware that similar crud gets crushed all the time.

Recall, for instance, the battlestarislands lulz ? That similarly was a this-of-that and hurr-with-durr etc etc. That similarly consisted of a lengthy string of Lacanian symbolology, connected by pure conjunctive tissue, without any meaningful definition in sight. "Pears are like apples, but not quite" might pass muster in a context dominated by five year olds ; but for anyone with pretension to a life of the mind such nonsense is entirely disqualifying.

It'd appear Paul Biggar's expectation is that an in-the-field diagnosis of AD&D will work together with some imaginary hurry - that only exists in his mind - to make the reader swallow this latest product of Sokal's machine. This doesn't speak in favour of his intelligence - an altogether different affair from what he's been induced to believe intelligence is so far - not to mention the nonsense he's trying to peddle. By and large, if something doesn't have a definition it's because that something doesn't exist, not because that something somehow magically doesn't need one.^vii

It’s got 27 competing versions of tools that do you-can’t-tell-exactly-what, with funny names like machine and swarm and flannel and weave and etcd and rkt and kubernetes and compose and flocker.

More importantly, and very characteristically, it's "got" 27 "competing" version of "tools" that aren't actually useful, for the very simple reason that they do not work. Not in the Werner Koch sense of "works - but sabotaged" ; rather in the sense that they exist marginally at best, mostly consisting of vague thoughts in the head of their soi dissant "developer", and otherwise a collection of napkin sketches and assorted bad prose. Such an item doesn't merit the moniker of "tool", and it's altogether dubious they'd even meet the considerably lower bar of "prototype".

It should be pointed out that merely using the word competition to describe anything in that monkey cage is flagitium in flagitia and nothing less. Not one of the participants ever had as much as a stray thought of their own, nor for that matter as much as a girlfriend with whom they interacted on a paradigm other than "checking out what the instagram comments say". The concept of competition is much further to these oversugared chimps than the considerable space between their after-dinner doodles and proper tools.^viii

It’s somehow linked to microservices which are new and shiny but seem like a fantastically stupid idea considering how hard it is to keep a single service running in the first place.

Which is exactly correct : a fantastically stupid idea. Not, of course, for the reasons the author would like to pretend, so then he can win imaginary wars with strawmen in his own head ; not because, somehow, replication wasn't a correct approach to stability ; but because it's fucking stupid to overshoot, and to overengineer, and generally to waste one's life, one's productive labour and one's inheritance chasing dreams and posturing wildly.

And after all that, it’s got this weird culty vibe to it, with dozens of startups and big corps all competing to get “developer mindshare” which might somehow someday relate to money and it’s all very 1999 and there’s definitely some kind of Koolaid being drunk.

There's two important things you must read to get your telescope correctly calibrated for this topic. One's that one with the tin women : the problem of too much money ; the other's the sad story of how the US ignored the warning and then lost its future : The future of Bitcoin regulation. It's easy enough to imagine that waste has no actual impact ; that somehow the "boundless recuperative capacities of the new continent" will see to it no matter what they do. No such thing.

It’s really not unreasonable to look at the whole Docker and container thing and conclude that it’s all bullshit.

Quite.

Except it’s not.

It’s actually the future of how we build applications.

Entirely out of the question. For one thing, there's no "we". The author is suffering from that bizarre geek derealization where he perceives himself multiple people. For the other thing, there's not really any future for "apps"^ix altogether, let alone this marmalade.

Why the Haterade?

Many of the folks who reacted to It’s the Future were those who felt that it was 100% accurate, not satirical at all, and who questioned the hype around this whole container thing. Why?

For one thing, because for each of the fifty or so derpy kids who "truly believe", there's a few thousand people who are both older and actually compos mentis who point and laugh. Statistically unavoidable situation.

The Docker and container ecosystem (hereafter “Docker”) is taking a bunch of staples of the application developer world, such as virtualization, service-oriented architectures, and operating systems, and redelivering them with different goals and benefits. As it does so, it raises the hackles of a large portion of the developer community: curmudgeons who hate anything new.

The problem here is that you can't "take" the named things. You can't "take" virtualization, in the manner your sister takes the cock. It's not a cock. You definitely can't "take" a pinch of virtualization, add to a well stirred service-oriented goop, bake for thirty minutes and at the end retrieve a fruitcake just like your granma used to make.

The difference between realia and idealia is precisely this : that the entire domain limitation for realia is given in the object ; whereas all domain limitations for idealia are outside the object. So, if you can use raisins, cocks or thin plastic foil a certain way, then there you go, you'll get something or the other. Not like the universe is going to BSOD on you because you put a single raisin inside the microwave and the dumbass demiurge in charge of development forgot to add a test for that.

Meanwhile, that you can string words together in any particular way makes absolutely no guarantees of any kind. The results of random manipulation of abstract concepts is necessarily meaningless, notwithstanding how attractive it is to the monkey brain. You can't "take" some cool, you'll have to do the things which constituted that cool, in such a way as they constitute it again. You can't "take" virtualization. Calling it "a staple" does give away that you are aware you're being stupid, but does not work as an incantation to protect you from that stupidity. It's not a fucking staple, programming computers isn't your grandma's fucking home ec class, and the mental process that outputs that sort of noise is just broken.

Curmudgeonry has exactly nothing to do with any of this. It's the second in a chain of copouts by a kid who knows he's being stupid yet doesn't want to desist, but it has no more juju than the rest of the gargle.

The software industry, contrary to what you might expect, is absolutely filled with people who hate progress. The sort of people who would walk into the Sistine Chapel after Michelangelo was done and declare that they already had a perfectly good picture of god, they prefer their ceilings to be white, and that frescos aren’t that cool anyway.

If your definition of progress is "vaguely black pompous butthead", like a sort of Dan Quayle who fell through cocoa powder, then yes, absolutely - every place is filled with people who hate progress, because that progress is ominous.

That aside, the tendency of idiots to pretend engineering "is art" has already been well dissected by Maciej Cegłowski in that piece about Paul Graham, a work which I recommend warmly on its own merits and insistently on the grounds that apparently every idiot sooner or later ends up with the same "ideas".

At the same time, most of the software industry makes its decisions like a high school teenager: they obsessively check for what’s cool in their clique, maybe look around at what’s on Instagram and Facebook, and then follow blindly where they are led. Around these technologies they form cliques of conformity, even going so far as to carve their own identities around the technological niche they fit into—they even cover their laptops with their gang colors–and hate and complain about things that are strange or different.

I am no part of this "software industry" which, ridiculously, seems to have no fucking idea what the word "industry" even means, so much so that they run screaming from even cursory encounters with the process.

Into that world drops Docker: a new way of doing almost everything.

No, it's not "a new way of doing almost everything". It's a new way of doing absolutely nothing at all - because apparently "measuring traffic" wasn't enough of a pointless timesink for the "industry".

It throws away old rules about operating systems, and deployment, and ops, and packaging, and firewalls, and PaaSes, and everything else.

The concerning mental model transparent from this description is of a schoolboy who imagines "don't start a fire in the crotch of the underwear you're currently wearing" is something of the nature of "the rule of law", malum prohibitum. Supposedly "throwing away old rules about fire in your underwear" is then the halmark of progress.

It would appear so to him, because his lack of experience couples detrimentally with his overlong nurture period^x to create a patently insane view of reality. In any case, engineering rules aren't there because it never occured to anyone they shouldn't be - much like the reason you can't fly batting your arms has nothing to do with "the rule" and everything to do with actual rules.

Some developers instantly love it, sometimes for valid reasons such as the problems it solves,

"Problems it solves" that are yet to be mentioned. Can you think of any problem this nonsense actually solves ? Let me know.

and sometimes because it’s a shiny toy that allows them to be cool before the other kids get to it. Other developers hate it—its pure hype, they say; it’s just the same as what came before and I don’t see why everyone is talking about it, they say—often for reasons that are more tribal than rational.

So reactions to Docker are not necessarily based on the technology itself.

Actually, this is a ploy older than dirt. Given an unselected group, so that intelligence distributes normally, a scammer comes in with an item that is both self contradictory and vaguely defined to the degree that only about half the group has the werewithal to notice. The scammer then eschews the fact that the item is vaguely defined deliberately, by him, and instead pushes the theory that "haters react irrationally to something they couldn't even possibly know". This twist has the merit of turning at least some of the group members (in practice, the more... intellectually vulnerable, so to speak) against their natural salvation : their superiors. The scammer now carved himself a little niche he might extract some value out of - the whole process being rather reminescent of how pathogen-cell interaction functions.

Obviously, Paul Biggar's audience is supposed to be rather... innocent, mentally, given that even a half hour's reading on the trails of MPOE-PR, for instance, would suffice to disabuse anyone with a working noggin of this nonsense.

Most haters are not really reacting to Docker’s solutions to important and complex problems.

Let's name them.

Mostly, this is because those problems are ones you might not have noticed if you haven’t spent time scaling big systems.

"My theory which is mine has the support of great people as well as armies just over the horizon"
"Which great people ?"
"Oh these great people are great indeed!"

Bitch... really ?

If you don’t intuitively and deeply understand what’s meant by “cattle not pets” and why that’s important, then a lot of the choices made by Docker and related tools are going to seem weird and scary to you.

Nice slide into "scary", but the problem here isn't that I'm afraid. The fear is projected, entirely Paul Biggar's. What does he fear ? Well, in a word... this. Exactly this. Precisely that someone who actually is someone instead of aspiring to one day be someone sees through the whole charade and tells him what he sees.

So... kiddo... welcome to your worst nightmare, I guess. Was it worth it ?

Merging worlds

Docker is at the merge point of two disciplines: web applications and distributed systems.

Neither of these are disciplines. Maybe he wanted to say staples ?

For the past decade, we in the web community

No.

Seriously, "the web community" ?

Just no.

have largely been pretending that we can build web applications by knowing how to code. We write some HTML

Html is a mark-up language. This is coding exactly in the sense altering labels constitutes social reform.

and some JavaScript and some Rails and we have a site. We add some forms and some handlers and maybe an API and we’re done: that’s enough to launch a product that can gain traction and customers and revenue and change the world!

Neither javascript nor rails are acceptable parts of a website. Stop importing that shit, nobody needs it, wants it, likes it or wants to see it.

Meanwhile, over the last two decades, the distributed systems people have been doing some rather boring shit. They’ve experimented with complex protocols like CORBA and SOAP, and learned how to deal with issues like the CAP theorem,

The "cap theorem" is not a theorem.

Here's what a theorem is : a proposition whose truth is established deductively. Zooko-triangle-metooisms, insufficiently formal to qualify as propositions, or have any sort of properly defined truth domain, aren't theorems. They're heuristics at best, and bon mots in general. They also come with a ready Shannonizing interface, you can produce them by the pail.^xi

and how clock synchronization is impossible,

This is nonsense the author brought from home.

and the Two Generals Problem, that appear largely theoretical to most.

I think the joke embedded there must be lost on him. Sad.

And those problems and their solutions have been rather uninteresting to anyone who is simply trying to take their knowledge of how to code and use it to ship web applications.

But then something interesting happened. Web applications got large enough that they started to need to scale. Enough people arrived on the internet that web apps could no longer sit on a single VPS,

This is such rank nonsense. For one thing, there's infinitely fewer anythings on the web of today, as curated by these idiots and their corporate patrons, than there were a decade ago. For the other thing, the cheapest dedicated box can carry worlds on its shoulders of staggering size^xii, until recently inconceivable. The "need" is entirely self-created, and will die with the weeds.

or just scale up vertically. And as we started to scale, we started seeing all these bugs in our applications, bugs with interesting names like “race conditions”

This obnoxious cocksucker imagining "race conditions" are things discovered just about the time he was discovering which way the slit goes on a woman is utterly galling. What the fuck else did he invent, one wonders.

and “network partitions” and “deadlock” and “Byzantine failures”. These were problems the distributed systems folks had been working on for quite some time, problems whose solutions were not only difficult, but in many cases theoretically impossible.

Name one of these "theoretically impossible" things that were "made possible" by practice. What is this, the US democrat party campaign trail ?

In the early years of this scalability crisis, Heroku happened. And Heroku made it really easy to scale infrastructure horizontally, allowing us to pretend once again that we were really just making simple web apps. And we bought ourselves, as an industry, maybe 5 years of pretending and self-delusion.

This is in no sense a fair description of Heroku. For one thing, it never worked, and consequently it never did anything. Bezos (no, pointedly not "Amazon" - Bezos alone, all the "engineers" bitching and whining under his iron fist aren't worth a name or a bullet) did make clusters work better than they worked before, and importantly marketed them to the monkeys, which finally registered "it" as "a thing" in their TV-oriented brains. But nobody actually involved in the technology would claim anything fundamental - it is entirely incremental improvement on ancient basis. And, importantly - it barely works (and only for definitions of "working" that are permissive enough to not include you know, actually working).

We’ve now hit the limit of that self-delusion, and as we come out of it, we find ourselves trying to build scalability early, and re-architecting broken things so that they can scale,

Virtually nothing worth building today will ever need to "scale", in the sense of necessitating more than one single box. It's a fact.

The things that do scale past that - such as Bitcoin - do not in any way use any of the nonsense here contemplated, which circumstance has no small part in their success.

and learning about the downsides of monolithic architectures and why using a single database won’t just keep working for us.

What's the definition of "single" contemplated here ? Because I suspect, and on the basis of this schmuck's record to date I have excellent reason to suspect, that the distinction is entirely without a difference.

And we come up with phrases like Immutable Architecture, “Pets vs Cattle”, Microservices, and a whole set of best and worst practices to try and make some of this easier.

Words never made anything easier.

At this point, during this shift, Docker comes in and tries to solve a lot of problems.

Name one.

But instead of telling us we can pretend the problem of scaling doesn’t exist and we can keep doing things in basically the same way, like Heroku did, Docker tells us that distributed systems are fundamentally what we’ve been doing all along, and so we need to accept it and start to work within this model. Instead of dealing with simple things like web frameworks, databases, and operating systems, we are now presented with tools like Swarm and Weave and Kubernetes and etcd, tools that don’t pretend that everything is simple, and that actually require us to step up our game to not only solve problems, but to understand deeply the problems that we are solving.

Alternatively, Docker adds yet another layer of pointless complexity, so pointless complexitists like Paul Biggar, all his friends and all the ugly roadkill they've ever fucked can keep on pretending like they have things to do so they don't have to go outside and notice the other kids are pointing at them.

Nice, and I suppose it beats masturbation.

The upside is that we gain the ability to build scalable architecture so long as we don’t pretend we can abstract it away. We now need to know what a network partition is and how to deal with it, and how to choose between an AP and a CP system, and how to build architectures that can actually scale under the duresses of real networks and machines. Sometimes there’s an electrical storm in Virginia, and sometimes things get set on fire, and sometimes a shark bites an undersea cable, and sometimes there is latency, and delivery failures, and machines die, and abstractions leak.

The sharks biting undersea cables belong right in there with "fuck you, I'm a dragon" and other avatars of Dreamer culture.

Everything needs to be more resilient, more reliable, and we need to acknowledge that those are things we need to think about as part of developing applications. And we need to do it not because it’s shiny, or because it’s some mythical best practices, but because people like Amazon and Netflix and Google have put 15 years of sweat and blood and industry experience into working this shit out and telling us how to build systems at real scale.

Actually, everything does need to be more resilient and more reliable. The correct path to this is through removing cruft - such as TRB has been doing - and especially through removing the tendrils of the USG. From anything and everything. Which specifically means that Paul Biggar, his "company", his friends and anyone he ever met at those dumbass VC conferences can't possibly ever have a job in anything to do with computers ever again.

Such an irreparable loss - for no one outside of them.

Real problems solved

So what exactly is Docker solving for us, then? Everything that we’re doing as we build web applications is extremely fragile, and Docker is forcing some sanity to it:

• Up until now we’ve been deploying machines (the ops part of DevOps) separately from applications (the dev part). And we’ve even had two different teams administering these parts of the application stack. Which is ludicrous because the application relies on the machine and the OS as well as the code, and thinking of them separately makes no sense. Containers unify the OS and the app within the developer’s toolkit.

So Docker is a... workforce management tool now ?! Because why, because HR didn't dare make sense of the workforce before holy Docker came by to give it permission ?

Get off your fucking high horse, kiddos. The entire "we" consists of separate, individual lonely men doing everything and "wearing all the hats" in between flights paid for by someone else ; catered meals paid for by someone else and time alone in the sad box.

Up until now, we’ve been running our service-oriented architectures on AWS and Heroku and other IaaSes and PaaSes that lack any real tools for managing service-oriented architectures. Kubernetes and Swarm manage and orchestrate these services.

Except they don't manage to "orchestrate" anything, which is why it has to be called "orchestrate". If it worked it'd be called something sane, if anything at all.

More importantly, actual applications doing actual heavy lifting (such as for instance Phuctor) do not use AWS. They use monster dedicated servers. The only practical utility of AWS is for quick deployment of prototypes, and for other seasonal miscellanea.

Up until now, we have used entire operating systems to deploy our applications, with all of the security footprint that they entail, rather than the absolute minimal thing which we could deploy. Containers allow you to expose a very minimal application, with only the ports you need, which can even be as small as a single static binary.

The notion that all this layered cake of shit somehow improves the security profile of the end product is shocking in itself. Given the contents of the septic tank in which it floats, it is perhaps unremarkable, but god damned is Paul Biggar a shithead.

Up until now, we have been fiddling with machines after they went live, either using “configuration management” tools or by redeploying an application to the same machine multiple times. Since containers are scaled up and down by orchestration frameworks, only immutable images are started, and running machines are never reused, removing potential points of failure.

"I find anal rape hurts less when I keep my eyes closed."

I suppose the voice of experience should count for something.

Up until now, we have been using languages and frameworks that are largely designed for single applications on a single machine. The equivalent of Rails’ routes for service-oriented architectures hasn’t really existed before. Now Kubernetes and Compose allow you to specify topologies that cross services.

There isn't proper language support for threading, or come to think of it kernel support - and this schmuck is going to somehow make threading-over-lan work ? Pass the koolaid, brother.

Up until now, we’ve been deploying heavy-weight virtualized servers in sizes that AWS provides. We couldn’t say “I want 0.1 of a CPU and 200MB of RAM”. We’ve been wasting both virtualization overhead as well as using more resources than our applications need. Containers can be deployed with much smaller requirements, and do a better job of sharing.

This has got to be the dumbest thing I ever read.

An entire "industry" which is "the future" predicated on "Bezos will be too lazy to add a simple, costless (to him) size selection interface" ?

Up until now, we’ve been deploying applications and services using multi-user operating systems. Unix was built to have dozens of users running on it simultaneously, sharing binaries and databases and filesystems and services. This is a complete mismatch for what we do when we build web services. Again, containers can hold just simple binaries instead of entire OSes, which results in a lot less to think about in your application or service.

It's entirely unclear what sort of unfamiliarity with computers is required before someone imagines that "simple binaries" is the proper way to reference a system-in-a-turd.

The only constant is change

Not all the time and not everywhere. I am starting to deeply dislike this particular kitschy phrase.

Our industry moves so quickly to deify new and exciting technologies that it doesn’t wait for those technologies to mature. Docker is moving at an incredible pace, meaning that it hasn’t come close to stabilizing or maturing. We have multiple options for container run-times and image formats and orchestration tools and host OSes, each with a different level of utility, scope, traction and community support.

In fact, computing hasn't moved appreciably in many decades now - in no small part because the kids are too fucking aggitated. They can't be bothered to sit down five minutes and read the code, because too busy running all over the monkey cage "revolutionizing" nothing at all. Change for the sake of changing necessarily will end up in a big fat zero. Not that it makes any difference to the monkeys in question - they'll still "have needs" which someone (else) will "have to meet", and why should they care that their inept wranging covered essential infrastructure in so much shit nobody knows how to run anything anymore ?

Looking around the rest of our industry, things don’t get stable until they become old and boring.

No, actually, the problem is entirely the reverse and purely psychogenic. A generation of acultural twits who are conditioned to be unable to productively resolve their conflicts will necessarily misapprehend stability as "the bad thing" - and what's worse to the narcissist than "old" ie ugly and "boring" ie death ?

As an example, how many protocols had to die before we got REST? We built REST and AJAX and JSON over the corpses of SOAP and CORBA, using the lessons we learned while building them. That’s two major technology transitions, over the course of about 10 years. Yet, we still haven’t got the same level of tooling for REST-based APIs that we had for SOAP a decade ago, and SOAP in particular has yet to fully die.

Leaving aside the dubious utility of the items listed^xiii, it is entirely nonsensical to pretend some sort of continuity. None of these "build" on anything - and especially not on each other, if they build on anything it's the wanna-be "developer"'s existential vacuity and quintessential frantic activity (as a cover for impotence). It is about as dishonest to pretend anything in the manner of scientific evolution - such as for instance seen in Physics - is at work here as it was early on. The man will latch on anything - actual sciences, Google, you name it.

The same thing is happening in the frontend, and indeed lots of folks compared my parody of the Docker ecosystem to the shit-show that’s going on in frontend development. And the same thing has been going on with programming languages since we escaped Java a decade ago.

Wait, they escaped java ?!

Consistently, until problems are good and solved, developers will continually come up with new solutions. And the Docker ecosystem has tons of problems to be solved.

Most of them, of its own making.

So we can expect that Docker isn’t that mature yet. There will still be many edge cases and weirdnesses that you’re going to hit when you try it, and some of its decisions are weird and may actually be plain wrong when we look back on them from a few years hence. Best practices still have to be tried and failed and retried and refailed until we get them right.

Who the fuck thinks this is how you engineer ?

"Oh hi, this bridge will fall and kill people and fall and kill people until we figure out why chewing gum is no mortar and why tin foil, while technically sheet metal, still doesn't work for the purpose of holding up trucks. It really makes no sense, it's just as opaque as anything, should be fine."

It’s going to take a number of years until we figure all this stuff out and it settles down. But that doesn’t mean that containers are bullshit, or that we can ignore them. We are always faced with a choice between staying still with the technologies we know, or taking a bit of a leap and trying the new thing, learning the lessons and adapting and iterating and improving the industry around us.

No. It will take a number of years until you grow tired and go away, to wither like the previous generation of fatuous, vapid idiots, beggars in a desert of your own making. Meanwhile actual people will be doing actual things, and you won't be invited to the party.

If you’re looking for me, I’ll be in the future.

Fortunately, you'll be in an alt future that'll never happen. Good riddance.

———

1. Yes, "last decade" is "recent". [↩]
2. I can tell because CompSci.

   The one true fact about pseudoscientific fields is that they attract the mentally broken. Depending on size and the exact flows of kink that year, sane and otherwise whole people may find themselves ensconced in the goop of a pseudoscientific field. Nevertheless - they're always marginal, and their message is always typical of the alienation the sane suffers among the idiotarian tribe. Meanwhile those who are happy to pose as "Earth scientists", alchemists, dillutionists, "Computer scientists" and so following are always defective. [↩]

3. Heroku was bought in 2010 by salesforce.com. As that spam outfit isn't on Paul Graham's list of things which may exist - therefore "Heroku is dead" and "nobody" uses it anymore.

   These shitheads couldn't be more transparent if they tried - and speaking of which, if you make a blog on medium I'm going to kill your children. All of them. With my penis. [↩]

4. Believe it or not this isn't a fictitious name. [↩]
5. Ie, the item above. [↩]
6. The bottom has arguably already fallen out.

   Apple's "app store" has ~no revenue to show for ever increasing "developer mindshare", especially in places you can't compete with, such as India, and there's trouble afoot across the board. The once-proud "hope of the future" solution for USG-style full spectrum dominance, bridging a vast span from Apple-likes TiVoizing the consumption on one end all the way to CISCO shitware peddlers eating away at network infrastructure on the other end, with a bevy of Intel-Amd Fritz chips in between - the whole kaboodle lies in ruins, its various broken cogs whirring and whizzing sadly.

   It's not just that CISCO died suddenly in 2013, or that the Chinese are attacking and likely will dismantle the Xilinx stack before the decade's out (a development whose significance I doubt you are equipped to evaluate), or that the Republic stands proud, its currency far above any fiat, not to mention castrated substitutes. Even the holy secrets of "Equation Group Which Is Not NSA" are on sale - and notice the flaming butthurt at the choice of marketplace.

   Bitcoin has come quite a ways since the days back in 2014, when Buffett was still daring to pretend "there are no shorts" ; the Republic stands ever closer to its goal of crushing the Empire and salting the land where it stood.

   All these major economic shifts are of course not perceptible to the immersed termite, and so there they go, trying their best to allign with an impossible vector, at the usual cost of their life's labour and ultimately their sanity. [↩]

7. Perception is no proof of existence. If this is not directly obvious, there's a funny gif of a racoon playing with a water jet that should make the point to you. [↩]
8. A hammer is a tool. A drill is a tool. These aren't "invented", they're discovered - because a tool is a necessary configuration, not merely an "interesting", and much less a "novel" one. If Shakespeare hadn't written Your Mother's A Whore, we wouldn't have ever read that poem ; but if my great-grandfather hadn't invented the six bladed dildo, your grandfather would have. [↩]
9. Note that everyone everywhere likes to tell himself "hay mas futuro!". Even the hopelessly idiotic Argentines. [↩]
10. They do spend too long in school, kids today. They should be out there getting killed left and right as soon as 15, not being coddled into cloying security by the motherhood-statal complex. [↩]
11. "You can have two out of three : polygyny, 1950s households and a loyal mate."
    "You can have two out of three : good underwear ; cheap underwear ; abundant underwear."
    "There's two kinds of threeple in the world : 01, 10 and 11".

    They don't even have to mean anything! Entirely post-structuralist nonsense, go write a sequel to Murphy's laws and submit it to the Social Sciences Today "peer reviewed" fishwrapper why don't you. [↩]

12. To put that in its proper context : at the peak of the newspaper trade, a million circulation a day was a pinnacle of performance reserved for very few entities in the world - maybe half a dozen. [↩]
13. AJAX for instance is nothing other than a fad that failed to catch on and died, an exact equivalent of "3d cinema" in this space. They will be resurrected later, of course, and under the same tired old pretenses no doubt - because there's really nothing older, or more boring, than the "excitement" of a memoryless, change-addled people. [↩]