I’ll go ahead and say it: When looking closer at the total cost of ownership (TCO) associated with Kubernetes, more traditional development methods still have compelling advantages. As we’re wrapping up another KubeCon, perhaps it is time to dig into this.
This is a rare position to take. I’ve used containers and Kubernetes since they first appeared on the cloud computing scene many years ago. I’ve designed and built numerous scalable systems on public clouds using this technology, so I know that it works, and it works well. My point is that it is often overapplied. Systems builders are motivated by what the cool kids are doing these days rather than finding the solutions that return the most business value.
As a result, I’m sure that millions of dollars are wasted as these architectural mistakes carry on. It’s time for us to do better. Perhaps you agree.
What to consider
As we go through this analysis, you’ll find that some of this may or may not apply to you and your organization. Saying “it depends” seems like a cop-out to many, but it’s usually the correct answer. You must evaluate each workload and data set whether you’re migrating to the cloud or building net-new systems. You need to be prepared to use the best technology solutions for your system needs. Sorry to be the bearer of bad news.
Kubernetes introduces a level of complexity that more traditional development tools don’t. Managing a Kubernetes cluster requires a deep understanding of its architecture and components, from networking to storage to security. This complexity requires skilled personnel capable of managing and optimizing a Kubernetes environment.
By contrast, traditional development approaches and tools often rely on more straightforward architectures that can be managed with the skill sets most enterprises already have. Of course, this will vary greatly from one company to another, but the cost of obtaining Kubernetes skills or training existing staff is usually much higher than any benefit of using this technology.
A Kubernetes cluster requires a great deal of overhead, although Kubernetes promises to reduce infrastructure costs through efficient container orchestration. This includes the nodes that make up the cluster and the resources needed to manage failover. Also, it would help if you had the infrastructure to manage redundancy and scalability; there can be way more resources you have to pay for than are needed.
Traditional development approaches may utilize more monolithic architectures. Being less flexible could result in lower initial capital expenditures and ongoing costs. I had one project build the same system using both approaches; the traditional monolithic architecture infrastructure cost was one-third of the Kubernetes deployment—just for that specific system. Of course, there could be other reasons to go with Kubernetes beyond the fact that it looks good on the CV.
Maintaining a Kubernetes environment is operationally complex. Continuous monitoring, tuning, and updates are required to ensure the environment is secure, efficient, and reliable. Again, this ongoing maintenance requires skilled staff and modern tools, both driving up the TCO and, in some cases, doubling it.
Initial setup and configuration can be time-consuming and complicated, even though Kubernetes can automate and streamline deployment processes. This can delay the time to deployment and time to market for many systems, leaving you open to more potential errors. Traditional development and deployment methods might need more container automation and scalability benefits. However, they are often simpler and faster to deploy for certain applications.
The distributed nature of these systems introduces new risks and points of failure. Kubernetes and container-based deployments offer high scalability and fault tolerance levels, which is why we use them, but they do have issues we don’t see with traditional development. These can range from “container sprawl” to security vulnerabilities within the container ecosystem, with new tools that need updated skills to run them properly. I’ve found that it’s not when a failure will occur; it’s how many will occur. Failures are always more numerous with Kubernetes deployments.
Traditional architectures may offer fewer scalability options but can provide a more contained environment that is easier to secure and manage. This translates into fewer costs but also fewer capabilities. Sometimes, that trade-off makes good business sense.
The importance of a TCO analysis
Although Kubernetes and containers offer significant advantages in scalability, efficiency, and resource utilization, their TCO can sometimes be out of whack. Of course, I’ve found that TCO analysis is often overlooked; those picking the technology don’t have a good handle on what trade-offs are being made. I usually ask questions about the trade-off of using more traditional approaches and most often get blank stares and non-answers, which shows that the TCO analysis was not done. On the other hand, I get asked if I’m going to KubeCon a great deal, so there is that.
The complexities and costs of managing a Kubernetes environment highlight that traditional development and deployment methods still hold value. Indeed, if you’re an organization with limited IT resources, you really need to pay attention to TCO.
Money spent on Kubernetes-based systems removes resources from other more pressing needs. I don’t know of a single IT organization with an unlimited budget to try all new technologies. You need to pick and choose your battles carefully.
Copyright © 2024 IDG Communications, Inc.
