This powerful tool is right for many applications and wrong for others. Here’s how to tell when a square Kubernetes peg won’t fit into a round application hole.
Kubernetes is just the latest example of a powerful technology that can provide a solid solution in many instances. Although it may seem like all the cool kids are choosing Kubernetes-related technology, it’s not right for every application. When a technology has such a huge following that its use becomes a forgone conclusion, that’s when mistakes are made and projects get derailed.
Most enterprises that are moving to cloud-based platforms will consider using containers and Kubernetes. Many enterprises using cloud already are also using Kubernetes. Kubernetes does provide many resources that make it easier to manage and scale distributed systems, including microservices. It’s also an orchestration system, meaning we can bind together processes and services to form larger, more holistic solutions.
As presented on the official Kubernetes documentation website, “Kubernetes provides you with a framework to run resilient distributed systems. It takes care of scaling and failover for your application, provides deployment patterns, and more.”
Automation and orchestration are frequent reasons to leverage Kubernetes. Keep in mind that automation and orchestration often get confused, and for good reason. Automation can help make a business process more efficient by reducing or removing human involvement with software or hardware that performs specific tasks. For example, automation can launch a process to reorder raw materials automatically when other processes notice that supplies are below a specific level. In short, a single task is automated.
Orchestration, in contrast, allows you to automate a workflow. Orchestration can keep track of sequence and activities, and can even invoke many single-task automations that are part of the workflow. Orchestration is a powerful Kubernetes tool that also allows you to invoke services such as database access across disparate systems.
What’s happening now is that many developers and architects choose Kubernetes to automate processes using the orchestration engine. That’s like hitting a thumbtack with a sledgehammer. You’ll end up spending way too many dollars on development and cloud resources to solve a simple, specific problem.
Another fact that often gets overlooked is that Kubernetes is a complex system itself; it requires special expertise and at times can increase risk. You’ll have to understand containers, networks, security, resiliency, portability, and a ton more to be successful with this platform.
Keep in mind that Kubernetes is not a traditional virtualized environment. Many who don’t have these skill sets will struggle to build, deploy, and operate Kubernetes-based systems, and the project often fails. Postmortems show that the chosen platform and tools were way too complex. The applications could have been better built with fewer and less expensive tools that existing staff already understood.
Finally, there’s cost. I’ve stated many times here that Kubernetes will always be an expensive way to build, deploy, and operate applications. Lately, many others have agreed with me, including Gartner.
Put the cost of complexity aside for now. One popular reason to build applications in Kubernetes is for portability. It’s a pretty basic idea. Portability is nice to have but costs more, and most of the time it is never needed. As Gartner states: “Kubernetes or not, application portability always comes at a price that you must be willing to pay—the “portability tax.”
Those of you who think this is a shot across the bow of Kubernetes, think again. This is actually an attempt to encourage you to leverage Kubernetes for the right reasons while understanding its limitations. In turn, your knowledge will assure the long-term success of Kubernetes.
