Hi there! I'm Corey Quinn. You may know me from my newsletter Last Week in AWS. This may come as something of a surprise to some of you, but snarking about large cloud providers (while personally entertaining) isn't how I spend the bulk of my time. I do a number of things– one of which is acting as an advisor to companies doing interesting things. One of those companies is ReactiveOps.
If you've not heard of them before, they solve operational problems for companies– generally by applying Kubernetes to anything that holds still long enough– today. ReactiveOps sees Kubernetes as the means to transform how software gets delivered and run; they don't see it as an end unto itself.
Lately, the term "Kubernetes" has been on the lips of every large enterprise, hip infrastructure startup, angel investor, analyst firm, breakfast cereal box, and botox clinic on the planet. "That's great, and I'm thrilled to take the money you're spending like a drunken sailor on shore leave" is the attitude of many companies innovating in this space– but what I haven't seen discussed much is the dangerous question, "What's the business value to you of deploying Kubernetes?"
Don't get me wrong– I'm not saying that going whole hog into a bleeding edge technology that you can neither spell nor pronounce properly is inherently a bad thing, but the 2001 Dot Com Collapse has receded sufficiently far in the rearview mirror that we may be losing the lessons of that heady time. Most notably, "because it's cool" isn't a viable reason to build something in a vacuum.
For those who don't breathlessly pore over Gartner Magic Quadrants, container orchestration company press releases, or have Google Alerts set up for a variety of Greek Mythology terms, Kubernetes is a system to manage containers. It's often abbreviated as "K8S" as a part of Silicon Valley's insistence on finding new and innovative ways to be intensely annoying to large swaths of people.
"I have an application that's comprised of a web server, an application server, and a database" can now be laid down in very simple files, and Kubernetes manages the heavy lifting of keeping the application running. If a webserver dies, Kubernetes restarts it. If there's a job queue that's backing up, Kubernetes spins up more workers to handle it. If you have ten web servers, Kubernetes takes care not to put 8 of them on the same physical node.
Where this gossamer dream meets the iron bar of reality lies in a few harsh truths.
- Your application must support running in a containerized world.
- The way code goes from developer environments to production has to be altered significantly in many cases.
- This requires a non-trivial amount of work.
Deploying Kubernetes for its own sake doesn't speak to business value, and is the wrong way to look at it. Instead, the value that its proponents see comes from the ability to speed deployment of new features, improve an infrastructure's durability, and hand off a lot of the "busy-work" of building, running, and maintaining production environments to software instead of people. Kubernetes makes things easier and more efficient for your developers to use and maintain– which gives your developers more time to focus on their product. Increased feature velocity equates to faster time to market, while improved durability equates to both less time spent firefighting, as well as helps to stem the erosion of customer goodwill that recurring outages inflict. Ask your doctor whether Kubernetes is right for you.
In the coming weeks, we’ll explore more of these themes; I hope you’ll join me.