So devops conferences will no longer sound like "Docker docker Docker? Docker. Docker docker docker docker? Ahh, Docker docker Docker docker docker." Now they'll sound like "Moby moby moby...?"
This seems absurd from a branding point of view.
I personally find this a little bit vindicating. I'm 39, which is like 120 in programmer years. I feel like one of the advantages of being an "old" (in quotes!) programmer is that I'm pretty good at spotting a fad. Unfortunately whenever I point one out I get mocked and down voted to oblivion, so I've learned to just sit on the sidelines and watch the fads go past and just work to avoid them in my own projects.
Programming is very faddish, and I've seen fads come and go. Here's a few of the ones I've seen in my tenure:
- "Design patterns" heavy "enterprise" programming, such as commonly seen in the older work in the Java and .NET ecosystem.
- XML for everything.
- Agile. Oh god, agile.
- Test driven development.
- Dynamic languages (as productivity magic pixie dust).
- Service oriented architecture (SOA).
... I could go on.
Not everything in these fads is bad. Fads often contain good ideas and some fads contain non-fad elements that stick around. But they're fads insofar as they are over-hyped as magic cure-alls.
The key characteristic of a fad is this:
It's heavily hyped as a cure to some set of very hard problems in programming or system administration, but all it really does is move the problem somewhere else or hack around it in some trivial gimmicky way. There is no real innovation. Meanwhile the fad often introduces new problems that nobody thinks about until the shine wears off.
My simple heuristic for recognizing a fad is to ask "where's the innovation?" A real innovation is a conceptual leap forward. It has a certain "meaty" feel to it and seems worthy of at least one solid CS paper. It often reduces complexity, since when deployed you can now dispense with all the mountains of hacks you used to work around the problem prior to the innovation.
Here's some current things that I very strongly think are fads:
- Microservices, which is just a reboot of SOA. The idea is not inherently bad and often results in more scalable systems, but the faddish part is the idea that replacing local API calls with RPC API calls or event queues is going to make some major class of programming problems go away. No, and you've also just introduced a new set of problems around network unreliability.
- "Serverless" cloud, a.k.a. total lock-in to a proprietary mainframe. Everyone doing this is going to regret it in 5-10 years except Amazon's shareholders. It's a roach motel. Compute will get another order of magnitude cheaper and prices for everything else will drop accordingly, but these prices will not since you drank the kool-aid haha.
- Containers.
... yes, containers.
Like most fads, containers are a response to a real set of problems. These are mainly:
- System/VM configuration drift and variability.
- Dependency and DLL hell.
- The fact that Linux/Unix has devolved into a single-tenant operating system where it's hard to deploy more than one thing on one "server." (This debacle is deserving of a whole very long blog post.)
Containers are a fad because they don't address any of those problems with real innovation.
System configuration drift, dependencies, and DLL hell are are addressed by the gimmicky hack of basically tar'ing up whole Linux images and treating them like gigantic statically linked binaries.
If you're going to do that, why do you need Docker/moby/whatever? Just use a static Linux distribution like http://sta.li and run every service in its own home or chroot. Keep your service trees in git and manage systems with Chef, Puppet, or f'ing shell scripts.
I fail to see why orchestration (a.k.a. provisioning) systems like Kubernetes could not work in such an environment without the container cruft.
Containers don't solve multi-tenancy much in practice. Their security profile is not good enough for true multi-tenancy, and if you try to run too many on one server you're going to run into stability problems that derive from all the bugs that exist in all that extra complexity they add.
Real solutions to these problems would... you know... really solve them. A real solution would make it possible to deploy stuff easily and forget about DLL and dependency hell. A real solution would restore true multi-tenancy to Unix, allowing users (not root) to install and run services on commodity identically-configured Unix systems. A real solution would reduce complexity.
Edit:
I do wonder a little if the idea of throwing out dynamic linking, which both containers and some newer compilers like Go do, is not a bad idea. Maybe it's obsolete. Maybe the tiny memory savings of dynamic linking are no longer justified by the complexity overhead of dependency management.