Kubernetes

Kubernetes (or K8s) is a buzz word that has taken the world by a storm. K8s is being considered and will be considered by organizations who welcomes Microservice architecture. Why are they considering it? (as simple as that, but do read on to find out why they need it). You can find plenty of articles on the internet and you can also find each organization’s take on K8s and how they are using it (or intend to use it) in their architecture. We do not want to re-invent the wheel with this article, we would like to explain why K8s is being considered and most importantly – Do you need it in reality?

We at cimt provide consultancy and advise on microservice architecture (among other things) and can assist you with including and implementing K8s in your architecture (if using K8s is beneficial to you).

Evolution

Technology is also evolving at a rapid pace; Because of this, new processes, concepts, programming languages, etc. started to emerge more frequently now. K8s is no different and it surfaced due to a problem/scenario that could not be avoided.

Monolithic applications (or very large and tightly coupled applications) became difficult to maintain and enhance over a course of time, increasing the time/ difficulties maintaining them even more. This gave way to Microservices wherein the big monolithic application is split into smaller ones with each application poses as a self-contained business function. This made the applications independent and loosely coupled.

Microservice architecture has its own benefits, among which:

• Technology agnostic
• Fault isolation
• Easy to build and easily scalable
• Easy integration across domains
• Better Data security
• Faster deployment

and more…

Microservice architecture has been beneficial for a lot of organizations who have adapted it but, this also introduced to some complexities which over a point in time became unavoidable. What kind of complexities are they and how do we solve them?

Enter K8s (the WHAT and the WHY)

Microservice architecture goes hand-in-hand with containerization. Not all Microservice architecture involves containerization, but you should wonder whether having your applications containerized would work out for the best. Microservices introduces redundancy in terms of resource usage; Managing the usage becomes difficult. The complexity increases with increase in number of applications (Microservices). This led to the introduction of containerization which involves budling or packaging applications along with its dependencies into a container.

For better understanding, lets introduce an example so that it can guide you for the rest of the article.

Let us say that you have an invoice application in your organization which has been in-use for a long period of time and that this application is a Monolith.

The Invoice application makes use of the following:

• Customer base (CRM system)
• Employee base
• Project Information
• Pricing (Rate card)

The invoice application has been built in a way that it makes use of all the above applications and the architecture is such that these applications are tightly coupled, which makes it less scalable and means that a change/enhancement to one of the applications impacts the other.

We had a face-lift of the application, and the monolith has been transformed into a microservice based architecture (as shown below)

As you can see in the diagram above, the large monolithic application (Invoice application) has been split into smaller (4) microservices with each microservice capable of independently carry out a viable business function. Each microservice can communicate with other microservices or carry out operations on its own and communicate back to the calling application.

The applications (microservices) are now independent, loosely coupled and it doesn’t look too difficult to maintain.

Since cimt has started adapting microservice architecture in the IT landscape, we want to make this as a norm within the complete organization (so that there is a and encourages the team to become cross functional). We identify the other departments within the organization, prioritize the ones which has some dependencies with the Invoice application and then start transforming them to bring them inside our microservice architecture.

During this journey it became clear that containerizing applications (or containerization) is the best strategy to adhere to.

What is Containerization?

Assume that you have multiple applications (front-end, back-end, etc.) in your IT landscape with each application having its own dependencies. Dependencies could be the libraries, framework, environment, configuration, etc. needed for the application to function properly. If you deploy 1 front-end application (PHP based) and 1 back-end application (Java or Python based) in a single server; the resources, infrastructure are shared and, an error encountered by 1 application also impacts the other.

Containerization is the concept of bundling applications along with its dependencies together in a container (or a box). This helps decouple application and infrastructure thereby aiding in resource isolation as well. Containerization has many benefits, for example/ among other things:

• Improves Efficiency
• Portable – You can bundle your desired application once and use it anywhere
• Security
• Maintainability
• Faster deployment

Containerization seemed to be a very good approach and the right way to go, but it also introduced more complexities:

• Resource Utilization in an optimal way
• Workload management as the applications are split as microservices
• Applications must be resilient
• Applications must be highly available with no downtime
• Scheduling
• Rollouts after upgrade of applications
• Networking (Containers on Node A should be able to communicate to those on Node B)
• Load balancing

These are points that need to be considered for normal non-containerized applications as well but since we now have applications split into microservices, these points show up front and center.

This is where Kubernetes comes into play.

What is Kubernetes?

Deploying a large microservice setup of containerized applications into a multi-cluster production environment is not difficult, but the things to consider such as replication, load balancing, networking, etc. for the containers makes it complex. This is where Kubernetes comes in. Kubernetes in short is a container orchestration platform. It is a platform used by organizations to schedule, automate deployments, take care of scaling, availability, management of containerized applications.

“Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem.” – source: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

Why do you need it?

K8s runs anywhere. It eliminates the need for direct manual orchestration in a cluster, and automates the orchestration process, so that the applications are highly available and compute resources are optimally utilized. You can also use K8s for:

• Automating deployment
• Scaling up or down containers without any downtime. Also, auto-scales containerized applications as per workload
• Management of containerized applications
• Simplifies deployment process
• Self-heal containerized applications (resiliency)
• and more…

In short, it addresses all complexities mentioned in the previous section. Below is a sample image after incorporating Kubernetes into your microservice landscape (the image is only displayed at a very high-level and not all components of K8s are visualized here)

Is K8s necessary for you?

This is the golden question, isn’t it? A lot of organizations have adapted K8s but, do you need it? And: does it do justice to your current architecture landscape?

If you have a large containerized microservice environment/landscape then, you should consider Kubernetes for orchestrating your containerized landscape.

As mentioned in the previous section, K8s runs anywhere; This means that you can set it up on-premise on multiple environments (for example DTAP) or if you are on the cloud, you could opt for managed Kubernetes hosting provided by AWS, Azure, etc.

Conclusion

In this article, we mentioned in detail on what complexities K8s can help overcome. We also mentioned that K8s is helpful only if you have a large containerized microservice landscape. There are pros and cons to any technology/software/application/tool available. For instance, good foundation of K8s along with expert level knowledge is required to configure K8s in large environments. It is not easy to learn K8s without dedicated time and effort, but the ROI is big as well.

How do you decide? Whether to opt for K8s or not? This is where we, cimt come in. We have good experience with containerization (Docker for example) and can also help incorporate K8s in your microservice landscape.
If you are interested in containerization of your microservices or having a thought about incorporating K8s in your landscape, please reach out to us at [email protected] or use our contact form. One of our colleagues is more than happy to look into the possibilities of Kubernetes for your organization.