Is It Time For Kubernetes Yet?

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.

Here'd I'd make a pitch for Opta, RunX's open source tool to make this exact task quite a bit easier

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.

Comments

[Juan Diego Palomino]

Another great article, and the links where very informative. I tend to agree with the arguments, but we must make a critical distinction between 2 types of audience: those who are currently revenue generating enterprises and those who are not (e.g. new companies with no products yet). For the former, the cost of K8s adoption is at least twice that of the latter as they will need to maintain both the old system, and the new, and solve the migration problem. The latter also has it far easier in that they can make many more mistakes without big monetary consequences and will not face resistance to change.

As such, I heavily advise that nouveau startup audience to start with K8s and containerization now, with the fortune of learning while young and fast, and save themselves an expensive multi-year drama (as all the sources above say it will be). The initial setup may take considerable time (and again, another shameless plug I work with Nočnica at Runx and this is literally the main problem we try to solve with Opta) but I promise it gets way easier afterwards-- K8s, especially managed K8s like EKS, GKE, or AKS is very stable.

For more mature enterprises, yes I agree you need to make a careful consideration but you should not let "later" become "never". There will always be other high priority initiatives and it's very easy for one with such an abstract concept to be de-prioritized.