Image by Khtan66, available via a CC Attribution-ShareAlike 4.0 International License.
As anyone who’s ever been in a hardware store knows, it can be easy to look at a powerful tool and think “I need that.” For a developer, Kubernetes might seem like one such tool. It’s developed by Google to meet their astronomical deployment needs! It offers a high level of automation of several functions that are a hassle to maintain manually! It’s open source! However, if you’re working on a young application that does not yet have a large user base demanding constant access to complex functions, Kubernetes might be the equivalent of buying a bandsaw instead of a handsaw: a lot of cost, and some real risks, for relatively few use-cases. So: when is it worth it to add Kubernetes? And if it’s not time for Kubernetes, what should you be doing instead?
First, it’s worth keeping in mind that cloud computing, containerization, and container orchestration can sometimes be treated as a bundle, when really, these are three distinct tactics, not all of which are right for all dev teams. Cloud computing (moving some of your machines to the Cloud rather than maintaining your own servers) is hardly the same as container orchestration (automating the deployment, maintenance, scaling, and networking of multiple containers, which might not even be in the Cloud.) If your team isn’t doing any of those yet, but you want to start moving in that direction, it makes sense to start simple, by just asking: could we save time and heartache in the long-term if we moved some of our machines to the Cloud? Or do we want to start experimenting with containerization?
Pini Reznik has a fantastic step-by-step guide to everything that you need to do before you consider using Kubernetes to manage your application. He notes that at each stage of this process, you’ll encounter new costs and culture changes, and says that it doesn’t necessarily make sense to add multiple layers of complexity to your operation at a time. Pushing your team to learn several new tools at once is likely to slow actual development to a halt. Evolution is more stable than revolution in most cases.
It might seem self-evident, but it also doesn’t make sense to think about container orchestration if you’re not yet doing containerization. If you haven’t yet started using something like Docker, it’s probably not yet time for Kubernetes. It can be tempting to skip ahead to the greatest level of complexity available, but there are real downsides. I’ve written at length here about the cost-benefit analysis of container orchestration for smaller projects.
Finally, when deciding to use any complex tool, you need to think about who’s going to be operating it. Kubernetes might be able to automate a number of sophisticated processes, but Ron Powell argues that it’s not worth it to have Kubernetes if you’re not going to have people specifically tasked with configuring and maintaining it.
If the problems that Kubernetes would solve are currently being handled competently by one human, and you don’t anticipate that changing any time soon, it’s probably not worth it to pivot to a brand-new tool. He also makes it clear that there are several tools that handle specific aspects of what Kubernetes can do, such as configuration management or cloud services that allow for autoscaling, and that these may be better fits for a small team with a monolithic application.
If you’re still not sure, it’s worth looking at the case studies on the Kubernetes website. Do any of these sound like issues that your product is currently facing? If you’re thinking “oh jeez, we do not have that level of complexity in our ops right now”, it’s probably too soon. You’ll know when it’s time to add Kubernetes to your toolkit because you’ll be at a stage of development where containers are either getting out of hand or are about to be. Don’t be seduced by the bandsaw if you’re still in the handsaw stage--and certainly consider whether it’s likely to cut you off at the knees.