EDIT: Added a bit more information, and additional tools. (09/29/16)
For those of you who've read a bit about me, you'll know that I am continually working toward a deeper understanding of the modern technological landscape. Cloud has, of course, been a buzzword for a bit now. Adoption of virtualization and modern DevOps technologies and workflows is still slow going especially at more established and monolithic organisations.
To get acquainted with the landscape, I've done quite a bit of research and started to do some practical hands-on experimentation. However, I quickly realized that there is still a lot of confusion and no real clear canonically accepted workflow or class of tool, technology, or product. There is considerable overlap and considerable diversity of maturity. The rapid pace of change makes it incredibly difficult to follow for a newcomer. I'd imagine even more difficult for an engineer to identify how their organisation might grow and pivot toward the future.
What is DevOps?
This post will be published before my review of the book The Pheonix Project (which is phenomenal) on DevOps and how it looks in practice. There's quite a lot written about it out there, but for the purposes of this post a quick summary is probably necessary.
DevOps as far as I can understand it is the integration of the operations and development endeavors of any business. It is the automation of development, integration, and delivery. The overall purpose is short, rapid cycles of development to enable fail fast innovation and fast time to value. A DevOps operation is more nimble and spends most of its time moving forward rather than merely supporting current operations.
To enable this a wide array of tools and technologies have been created to enable this end. The list is staggering and something like The Periodic Table of DevOps Tools.
The Thicket
This leads me to the word soup in the title. The more that I'm learning about the different tools and use cases for each of these, the more complicated I'm seeing this becoming.
Just for container orchestration (itself a very loaded term) there are an absurd number of tools:
- Rancher
- Kubernetes
- Fleet
- Mesos
- Nomad
- Helios
- Marathon
- Tectonic
- and others...
However, except they're not drop-in replacements for each other and aren't even necessarily peers. For example, Fleet is CoreOS' low-level systemd abstraction for clusters and needs other tools to handle higher level tasks that Kubernetes has built-in. Others are just rebranding of existing tools -- Tectonic, for example, is an enterprise-grade implementation of Kubernetes.
Each of these has a different scope, limitations, and use cases. There are situations where 2-3 of these separate tools could be used in coordination, but not necessarily. It's somewhat absurd, and it certainly can be overwhelming.
Then there is the fact that each of these tools have a surrounding ecosystem of services and tools that enable their operation within a full 'stack'.
So what? Who cares?
For someone trying to get an understanding of the landscape and a read of future trends, it's incredibly important to understand the high-level problems that are being solved here.
Starting with the history and original use cases for each, I will be attempting to get an understanding of the landscape, environment, and ecosystems. It's not a small task, but I'm hopeful it'll be a fruitful endeavour.
It's my hope, then, that this will be the first post in a series on some of these tools as this amateur sees it. Stay tuned.