Why Not Use Kubernetes?
Many teams are excited to start using Kubernetes. Some are interested in the resilience, elasticity, portability, reliability and other advantages Kubernetes offers natively. Some are technology enthusiasts and just want an opportunity to work with this platform, to get to know more about it. Some developers want to acquire experience with it, so they can add another highly demanded skill to their resumé. In general, most developers these days want to work with Kubernetes at some point.
That may be a really good idea and it may not.
Kubernetes is Designed to Solve Distributed Architecture Issues
As defined by the official documentation website,
“Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more.”
It’s not exclusively made for distributed systems, but for containerized applications. Even so, it does provide many resources that make it easier to manage and scale distributed systems, like Microservices solutions. It’s also considered an orchestration system.
Automation and orchestration are different, but related concepts. Automation helps make your business more efficient by reducing or replacing human interaction with IT systems and instead using software to perform tasks in order to reduce cost, complexity, and errors.
In general, automation refers to automating a single task. This is different from orchestration, which is how you can automate a process or workflow that involves many steps across multiple disparate systems. When you start by building automation into your processes, you can then orchestrate them to run automatically.
In other words, Kubernetes makes it easier to manage complex solutions that would be hard to maintain without a proper orchestration system. While you can implement DevOps engineering practices on your own, it’s not scalable if you go from dozens to hundreds of services.
Kubernetes is Complex
In order to take advantage of its features, developers and IT operators must have knowledge of containers, network, security, portability, resiliency, and Kubernetes itself. To make proper use of its workloads, you should understand how each component works. To manage a cluster, you should understand its architecture, storage, API, and administrative system, which is a lot different from traditional virtualized environments. In order to expand the solution, you should learn how to integrate tools to deploy, monitor, and trace services, like Helm and Istio, for instance. A lot of new concepts are added there, so your team has to be ready for this challenge.
Kubernetes is Expensive for Small Solutions
To understand why, let’s reinforce one of the key concepts of Kubernetes — resiliency. To take advantage of that, you need additional nodes — above the minimum amount required to run your applications. If a node is down, the requested pods will be relocated to the available nodes. For production workloads, at least three nodes are recommended for resiliency.
It’s easy to imagine that it’s not worth it if you have a single application to host. But even if you have ten or more, you have to consider whether the costs of the cluster is worth the effort of its maintenance.
The cost of maintaining the environment also includes operational support. The more complex the platform, the more specialized people should be involved. It can imply in hiring a third party specialized company to provide support or a solution with support services included, like Openshift.
When to Choose Kubernetes
Depending on the architecture you use, the number of applications and how much they depend on each other, and the operational capacity of your team, it’s possible to check whether Kubernetes is the appropriate choice among all the technologies available.
With Web Apps for Containers, you get a fully production-ready enviromment. With standard plans, SSL features and application insights, you can have a secure, scalable and monitored environment with little operational effort.
If you only deal with isolated applications, or a small number of connected applications, maybe a combination of Azure Web Apps and Containers Instances running in the same virtual network would be enough.
On the other hand, if you have a growing number of containerized applications, hosting them in Kubernetes is interesting. Youll be able to host several types of applications, like web apps, APIs and recurring jobs, in a single, centralized environment. Your team will be able to focus on Kubernetes instead of several cloud-native solutions.
If you deal with distributed scenarios, like microservices, then go for it. Distributed architecture is complex, and Kubernetes was designed to make it easier. I cannot think of any other platform as complete and extensible for distributed applications than Kubernetes.
When you deal with a small number of containerized applications, isolated or with few dependencies among themselves, other host options like Azure Web Apps for Containers or Azure Container Instances — or a combination of them — may be simpler and even cheaper.
If your team is comfortable with Kubernetes and you have a growing number of containerized applications, it may be worth centralizing hosting in a single Kubernetes Platform, like Azure Kubernetes Service.
Kubernetes is a platform designed to boost performance and reduce the operational effort of distributed systems. It basically makes a complex scenario, like microservices, less operationally complex.
If you're not dealing with many applications, don’t use distributed architecture, or don’t have available specialists working in your staff, you won’t be able to avail of the advantages Kubernetes offers — because it was not made for you. You’ll end up adding an accidental and unwanted complexity to your solution.
If you want to understand the hosting options for containerized applications better and when to choose each one, please check the article below: