Many teams are excited to start using Kubernetes as soon as possible, for the most diverse reasons. Some are interested in all the resilience, elasticity, portability, reliability and other compelling advantages that made Kubernetes famous. Others are technology enthusiasts who would like to have the opportunity to work with this platform to learn more about it. Finally, some wish to gain experience with it to improve their resumé.
In some scenarios, adopting Kubernetes is the right thing to do. However, there are some facts that we need to consider to avoid headaches.
#1 – It is tailored 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.
Kubernetes was not designed exclusively for distributed systems, but containerized applications. Still, it provides many features that make it easy to manage and scale distributed applications, such as those with microservice architectures. Besides, it is considered a system for orchestration.
What is Orchestration?
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.
#2 – It is complex
To take advantage of its features, developers and IT operators have to have good knowledge about containers, network, security, portability, resiliency and… Kubernetes itself. To correctly manage a cluster, a professional needs to understand its architecture, storage, API and administrative systems, which is quite different from traditional virtualization environments.
To expand a solution, you need to 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.
#3 – It 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’ll have to have extra nodes besides the minimum amount required to run your applications— in case 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 applications or more, you have to consider if the costs of the cluster worths the effort of its maintenance.
The cost of maintaining the environment also includes operational support. The more complex the platform, more specialized people should be involved, and it can imply in hiring a third party specialized company to provide support or a solution with support services included, like Openshift.
So, 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 a more appropriate choice than other technologies available in the market.
With Web Apps for Containers, you get a fully production-ready environment. Within Standard plans, SSL features and application insights, you can have a secure, scalable and monitored environment with little operational effort involved.
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 can be enough.
On the other hand, if you have a growing amount of containerized applications, hosting them in Kubernetes can be exciting. You will 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.
Conclusion
When you deal with a small amount of containerized applications, isolated or with few dependencies among themselves, maybe other host options like Azure Web Apps for Containers or Azure Container Instances — or a combination of it — can be more straightforward and even cheaper.
If your team is very comfortable with Kubernetes and you have a growing amount of containerized applications, it can be worth it to centralize 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 makes a complex scenario, like microservices, operationally less complicated.
[tweet]If you aren’t dealing with many applications, distributed architecture or don’t have available specialists working in your staff, you won’t be able to avail the advantages Kubernetes offers, basically because it was not made for you.[/tweet] You’ll end up adding an accidental and unwanted complexity to your solution.
