In this post I’ll go over some of the things I’ve seen over the years of consulting, and get as candid as I can about the realities companies need to face when adopting Kubernetes. I’ll focus on OpenShift specifically, since that’s where I have the most experience, but most of this applies to any flavor of Kubernetes.
Containers show up first, strategy second
Outside of a handful of large tech companies, containers usually get introduced by a development team that’s tired of waiting on infrastructure to get them what they need. Developers want a canvas to be productive, and when the infrastructure team can’t deliver one fast enough, developers get creative. Containers are low-resource and easy to run on a laptop or a small server, so they spread — often without a plan. That sprawl is a problem for another post. Here, I want to focus on what an organization actually needs in place to run something like Kubernetes or OpenShift well.
Do you even automate?
This is one of the first things I look at when I start an OpenShift engagement: what does the current process look like for infrastructure and development?
Does the infrastructure team practice infrastructure as code, and provide self-service for internal customers like developers? Is infrastructure one cross-functional team covering compute, network, and storage, or three separate teams that have to coordinate every time? These are things to work out before adopting Kubernetes, because the platform bundles all of those concerns into one automated package. There’s no point deploying something as powerful as Kubernetes if you’re going to manage it the way you managed a rack of VMs.
On the development side, I look at the current code-promotion process and try to simplify it as much as possible. If you’re not practicing CI/CD, you’re buying a Ferrari and putting cheap tires on it. The same goes for the application itself — if it’s slow or bloated on a VM or bare metal, it will be worse in a container. I’ve been to places where someone manually copies an artifact to a network share, and that’s the deployment pipeline. If you want to get the most out of Kubernetes, you need to be fast, and you need to be automated.
Wrapping up
This is a handful of examples out of many things worth thinking through before you shift to Kubernetes. It’s the hot buzzword right now, but there are real, unglamorous steps to take if you want the adoption to actually succeed. If you’re not sure where to start, give us a shout — we’ve done this before, and we can help.