When you start reading about Kubernetes, there are no obvious downsides. It’s open source so you don’t need to pony up for licensing. The word “automation” gets thrown around so it’s obviously going take work off your plate. Google made it and they seem to know something about working at scale. There’s even a convention, KubeCon, so a lot of people are excited about it. Why wouldn’t we want to be in the loving embrace of Kubernetes?
Defining a Purpose
I think, due to age, I tend to be skeptical when new things are trending in the web technology space. It’s a “get off my lawn” mentality that can be difficult to shake. I mean, we were making websites before Docker and containers and continuous integration and all such things. We did just fine. There’s still a book on the shelf here that invites you to teach yourself HTML 3.2, funnily enough. It’s worth a laugh to crack open and see it talk about the tag. So maybe new things are good occasionally?
There needs to be a purpose, though. What problem are we trying to solve if we implement Kubernetes? It’s an odd question, because it’s not strictly necessary. You can have a dedicated server created with a hosting provider, install the appropriate packages, and deploy your website. It will work. The end users won’t even know the difference.
The marketing pitch for Kubernetes is shooting for the heavens. It’s used by the biggest corporations on the planet and it permeates the very nature of the cloud. But what about those of us with real life servers in our infrastructure? It doesn’t make sense for us to offload our internal infrastructure to the cloud. Does it make sense at that scale? Spending some time with it was the only way I would know.
Deciding If It’s Right for Us
After spending some time with Kubernetes, it really serves three purposes for us. And please note the “for us” in that statement, because Kubernetes is large enough where it will serve many different purposes for many different people.
The first purpose is that it allows us to define what services make up our infrastructure and Kubernetes spends all of time ensuring that those services are up and running. The service definitions are almost a form of documentation. Not precisely human readable, but close enough where you can use it as a reference point.
The second purpose is it forces better habits. Because of the very nature of orchestration, it’s difficult to cut corners. With a tradition persistent server, you can just go in and fix something in place. Site’s down. Change the code directly on production. Site’s up. Six months later you forgot what you did and push code and eradicate the change. Site’s down and you’re back to square one. With orchestration the container itself doesn’t persist. You don’t push files – you’re pushing the entire server and the old server is eradicated. The only way to make a change is to get it checked into source control and deploy a new image based on what’s in source control. It’s what you were taught to do and what you know is right – but now there’s no shortcut.
And finally, it automates what developers shouldn’t need to worry about. We used to have a rigid structure for the testing pipeline. It goes to development then it goes to stage then it goes to production. This was because it took a human in another department with a different skillset to stand up additional testing environments. Another environment could be made, sure, but it was an exception. Now there’s a testing website for every branch. A developer makes a feature branch, pushes the changes, and seconds later it can be reviewed by QA.
How to Get There from Here
Rolling out Kubernetes here has been and will continue to be a long road. The next post in this series will lay out the pieces of Kubernetes itself as well as the surrounding infrastructure needed to run it on your own servers.
Additional resources
If you just want to experiment with Kubernetes, please check out the Minikube feature. This blog series will discuss our unique Kubernetes environment, but it is full-fledged production. Simply learning more about Kubernetes doesn’t require the effort I’m going to describe. Additionally, the Kubernetes documentation includes interactive tutorials which I would recommend.