When Not To Use Kubernetes?

Kubernetes is the most widely used orchestration system for large-scale containerized software. Amidst the maturity of cloud computing and the technologies it introduced, many developers and organizations believe their tech stack is not complete without Kubernetes.  If you engage in technology discussion forums or pay attention to technology news, it feels like everybody is running on Kubernetes or, at least, talking about how they want to move all their workloads to Kubernetes; that they can't efficiently manage their applications without it. This is a misconception that many people have and can be used to determine whether or not an individual truly understands what these technologies are about or simply following the crowd.

While Kubernetes is a great tool, it is still so much in its hype stage. Because it seems like everybody is moving that way, it might cease you from understanding the fundamental idea behind the technology and if it's indeed required for your system.

Engineers developed Kubernetes at Google to provide an efficient orchestration solution for their large-scale production workloads by applying proven techniques and experience from Google's Borg orchestration system.

Before going for Kubernetes, you must understand what problem you're solving and the tools for solving it. Because, lack of proper understanding of the problem makes the majority stick with Kubernetes as the famous, holy grail solution to their problemㅡwhich it necessarily isn’t.

Kubernetes is a complex system designed for orchestrating complex, large-scale containers.

The increasing number of providers offering "easy Kubernetes" is enough to prove this. If you want to adopt it, you must be ready for the complexity it brings into your workflow.

As a developer who's just starting with a personal project, writing your first thousand lines of code, you most likely do not need Kubernetes. You don't want to dive into the complexities of Kubernetes when there are other more straightforward and efficient ways such as FTP to deploy your single or multiple-page monolithic software.

Unless you have a service-oriented application with an architecture that requires multiple services to communicate with one another-say an e-commerce project, with one service that handles the products, another that handles the cart, and another that handles payments. They will be required to communicate with one another based on different networking policies to make the application fully operationalㅡthen you can look into adopting Kubernetes.

However, even for such applications, there are other more straightforward, less complex, and equally effective solutions other than Kubernetes.

Using Kubernetes involves a steepㅡvery steepㅡlearning curve. To efficiently use Kubernetes, you need to learn about containers, network, security, kubernetes specific policies and concepts, and a whole bunch of things that will help you leverage its capabilities.

Organizations adopt Kubernetes for various reasons, the common ones being effective container management, efficient load balancing, and autoscaling, many of which are not native features of Kubernetes.

For Kubernetes to be fully functional, you need to learn how to integrate and configure many other tools like Docker, Prometheus, Grafana, and many others to enable autoscaling, visibility, monitoring, and other required services.

Kubernetes also requires significant expertise for effective management and maintenance. To avoid these complexities, you need to understand your use case and check if other alternatives require less effort than Kubernetes. Take a distributed application that has three layers: frontal load balancing, core application, and a database layer, for example.

A typical cloud native professional would suggest that you use Kubernetes to handle such applications since the application layers have multiple services in today's world.

Setting up Kubernetes and configuring it for such an application will require knowledge of multiple tools, including Prometheus for autoscaling based on custom metrics and regular maintenance of Kubernetes worker nodes and control planes. Kubernetes will also need to interface with your cloud platform to provision virtual machines, storage, load balancing, and so on, which may expose your application to recent vulnerability types such as cryptojacking and cryptomining attacks. Kubernetes is also built to handle stateful workloads. This might be a bit challenging if you run a stateless database layer.

Other than using Kubernetes, however, other less complicated platforms can effectively cater to such applications like the one in view.

Say you use AWS as your cloud provider. AWS offers an array of feature-rich services that can help you manage your multi-service applications efficiently.

AWS' Elastic Load Balancing service can manage the load balancing layer of the application with high availability, built-in autoscaling, and zero maintenance efforts as the trump cards.

Using Amazon ECS, you can orchestrate your application containers similarly to Kubernetes. Even though it has fewer features than Kubernetes, it is easier to configure and works well with other AWS services.

RDS is also an Amazon-managed service that can efficiently handle the database layer effectively. You can configure it for frequent backups, read replicas, and standby instances across different availability zones to make the database resilient to data losses.

AWS Lambda and AWS Batch are also effective alternatives to Kubernetes in serverless applications and batch jobs.

When you think you prefer Kubernetes to all of these less complicated alternatives, there are procedures, assessments, and questions you need to ask before adopting K8s.

As soon as you choose a cloud computing provider as the preferred infrastructure for your applications, you need first to understand the fundamental services offered by your cloud provider, the pricing models, and all. Then you need to adopt a cloud-native structure in your teams by adopting practices such as DevOps and automation to make your workflow effectively operational.

Only after adopting a DevOps culture should you adopt microservices to simplify your application management further if required for your application type. Then to make your microservices platform-agnostic, you containerize them.

Finally, you weigh out options that will help you efficiently orchestrate your containerized microservices. And if Kubernetes is the best solution for you, you can go ahead and implement it.

You shouldn't use Kubernetes just because everyone is using it. You should, in fact, because of its complexities, avoid Kubernetes and only use it if it is the best solution for your use case.

Kubernetes is great when you have all the right things in place to run and manage it effectively. When done at the wrong time, the consequences might be more harmful than not using an orchestration system at all.