Why I Believe in Tools Like Kubernetes and Podman So Strongly

History Lesson on PaaS

People often rewrite history in their minds. They see the way the landscape looks today, forget the chronological order of events, and reconstruct a false model of cause and effect. I am guilty of doing this from time to time. One such history is that of PaaS. The year was 2012, and PaaS was all the rage. Heroku was killing it, Cloud Foundry had been announced the year before, and OpenShift V2 was launched. All of the fancy developer advocates and evangelists (or technical marketers, or whatever they were called then) preached that the 9-5 developer should “just” focus on code, and not worry about the operations environment.

PaaS is great for certain well defined use cases (and demos), but like Visual Basic, as soon as you need to go outside the well defined use case, it falls down. And, of course, it’s hard to discover every developer’s use case, define it well enough to put on a product plan, and codify it in a PaaS platform. It’s also difficult to build an engineering team big enough to prioritize developer needs and develop them fast enough to beat developers in creating their own thing. PaaS is essentially a top down approach instead of a crowd sourced approach to development environments. This is always going to create bottlenecks.

PaaS Gets Disrupted by a Command Line Tool

In October 2013, Docker exploded onto the seen with a command line tool and daemon called a container engine. A command line tool lit the world on fire – not a pretty GUI, not an app for your phone, a command line utility. But, how is it possible that a command line utility and daemon changed the world if developers wanted PaaS? That’s the million dollar question. Let’s walk through the timeline a bit.

• 2012 – PaaS is all the rage
• 2013 – heard about docker and kept reading blogs. Was annoyed by some blah blah blah new technology, and just wanted to focus on the technology I knew (Linux, VMs, JBoss, ActiveMQ, httpd, etc). To be honest, the technorati of the DevOps community had already knew about Docker and the unofficial consensus was we wanted containers, not PaaS.
• 2013, October 29th – dotCloud is becoming Docker. 200 contributors. Meetups around the world. 15,000 users, thousands of images, thousands of downloads, etc, etc. Popularity was starting quickly.
• 2013, November – Red Hat announces partnership with Docker in the Fedora community
• 2014, February 18th – Docker v0.8.1 released
• 2014, February 25th at 9:51AM – from Google search history, it appears this is the first time I put fingers on keyboard with Docker. I apparently didn’t stop messing around with it until 4:51PM (at least that’s when Google searches stopped). I remember being blown away. Being no stranger to Command Line Interfaces (CLIs) and application Programming Interfaces (APIs) I immediately recognized the elegance of containers, fell in love and pivoted my career back in 2014. That’s how much I believed in containers. Aaaand, it panned out better than any bet I have ever made in my entire life.
• 2014, March 5th – I created my first Wiki entry on Docker
• 2014, March 21st, I created my first presentation on Docker: A Practical Introduction to Docker at Red Hat
• 2014, May 1st – I created my first blog entry on Docker: A Practical Introduction to Docker Containers
• 2014, June 7th – first Kubernetes GitHub commit – 46K lines of code, so they had been working on it for a while
• 2014, June 9th – Docker v1.0.0 released
• 2014, November – Docker container services were announced for the Amazon Elastic Compute Cloud (EC2)
• 2014, December, 4th – IBM announced a strategic partnership with Docker that enables Docker to integrate more closely with the IBM Cloud
• 2015, June 22nd – Open Containers Initiative Standards work announced
• 2015, June 24th – OpenShift 3.0 launched based on Docker & Kubernetes
• 2015, July 21st – Kubernetes 1.0 launched
• 2016, April – Docker 1.11.2 released
• 2016, July – Docker for Mac and Docker for Windows released – theoretically, this helped bring Docker to the masses, but Docker was already wildly popular.
• 2016, July 28th – Docker 1.12.0 released
• 2016 – Today – and so on and so forth. Kubernetes, Podman, Buildah, Skopeo, and friends make a lot of noise
• Today – people still arguing that developers want and need PaaS. Maybe, maybe not. It depends.

Analyzing the above timeline, it’s pretty easy to see a few things:

1. All the same players that signed on for PaaS, signed on for Containers
2. Docker announced strategic deals with all the big players, long before a Docker for Mac or Docker for Windows existed
3. A command line tool disrupted PaaS
4. All paths lead back to PaaS for PaaS minded people 🙂

So, why did this happen? Well, vendors will tell you that developers want ease of use but I am here to tell you that’s a lie. Instead, developers want elegance of use. Visual Basic was easy to use, but DotNet replaced it. Cold Fusion was easy to use, but PHP killed it. Windows was easy to use, but Linux disrupted the industry. I mean…Microsoft even loves Linux now. So, what’s going on here? In each of these cases, the “easiest to use” technology didn’t win. Instead, the technology that balanced control and elegance won. Clearly elegance of use, not ease of use, is the deciding factor in many technology debates, especially with empowered constituencies like developers. I mean, think about it, they write code, they are comfortable learning sophisticated APIs, why would they not be comfort learning a simple command line interface?

Elegance

But, what do I mean by elegance. Let me use an analogy. Dump trucks are elegant (stay with me). Carrying dirt in Honda Civic. Not elegant, but easy. I can drive a Honda Civic. I can load dirt with a shovel. It’s easy. No special license, no special tools. No special skills. But, it’s NOT elegant. Now, swap in a Backhoe and a dump truck. We need a special license, we definitely have to learn some new skills (but it’s fun), but after the learning curve, we have an elegant solution for moving dirt.

Developers move dirt. Well, technically, we shave yacks. But whatever, you get what I mean. We are professionals, so we are OK learning technology. That’s why I am so excited about tools like Podman and Kubernetes. PaaS is easy to use, but Kubernetes is the most popular open source project, possibly in the history of the world. Command line tools might not be the easiest to use, compared with GUI programs, but depending on the use case, they are way more elegant. Again, engineers are paid to write code, and do math, and process complex information. Developers tell computers what to do with code, and math, and statistics, not natural languages. Scientists prove theorems with formulas, not natural language. While symbolic languages are not as easy to learn as your first native language, they are quite elegant for making computers do what you want. Developers write code, so they are fine with using tools like Podman and Kubernetes.

I see these arguments over and over and over:

1. The world wants PaaS
2. People won’t use it unless it’s super easy
3. It’s too complex
4. I don’t understand it (you might not be the target user)
5. It needs a GUI
6. It needs an easy install

Sure some people want easy, hell we all want easy, but we are smart enough to stack rank things. As soon as you have an advanced use case, you stack rank elegant and powerful over easy. I will leave you with a final quote from one my best Computer Science Professors, Dr. Liszka – in our Data Structures and Algorithms I class in 1998, she told us, “someday, you will write a piece of code, and it will be elegant. You might not understand that right now, but someday, you will…”

Stay elegant my friend 😉