Kubernetes: Monolithic vs Microservice

Kubernetes is the industry standard for the container orchestration platform for the modern microservice. The word Kubernetes comes Greek language which represents the pilot or the person steering the wheel of the ship.

Kubernetes as software provides developers the ability to deploy their numerous applications as microservice containers and automate the overall lifecycle of these deployed containers.

It creates an abstraction over the underlying hardware infrastructure consisting of many commodity hardware and exposes them as a single highly reliable and scalable computational resource. Kubernetes shifts the responsibility of managing individual applications and nodes to managing the Kubernetes cluster as a whole.

Thus, it abstracts the configurations for
individual applications into simple configuration files that can be specified in yaml or JSON format. This makes it an ideal tool for managing configurations as code. Another advantage of using Kubernetes is that all the configurations can be represented as yaml files making it easier to read and consistent throughout the application.

To understand why the requirement for a system like Kubernetes came to be, we need to understand monolith and microservices.

Monolith vs Microservice

The need for a system like Kubernetes arises from the gradual change in the software development and deployment processes in the last few decades. The ever-increasing size and complexity of modern software have forced modern developers to split their big monolithic applications into smaller microservices. Similarly, the deployment practices of the companies have migrated from making occasional large changes to gradually smaller changes. Thus, modern software requires to be dynamic at the same time highly available to the users.

These kinds of requirements are extremely hard to be fulfilled in large monolithic applications, where only a few experienced developers have a working understanding of the system and, it appears to be a black box for most developers in the team.

In such a system, making even a small change in a part of the system requires the developer to consider all other parts of the monolithic application as these parts are tightly coupled with one another.

Microservices address these pain points by splitting the large application into smaller loosely coupled components, each of which communicates with each other through the implementation of general API contracts.

This allows the developers of a component to make update the implementation of the microservice without worrying about the other parts of the system as long as it complies with the API contracts defined beforehand. Also, individual microservices can be deployed independently with little impact and friction compared to its monolithic counterpart.

Additionally, having loosely coupled services comes in very useful handful when the system needs to be scaled up. Unlike most monolithic applications which can only be scaled vertically i.e. by increasing the RAM and the number of processers which has a higher limit to it, individual microservices can be scaled horizontally by replicating them in another machines.

Monolithic Applications VS Microservices Applications

Monolithic Application	Microservices Applications
Consists of complex and highly coupled services.	Consists of several smaller and loosely coupled applications
Components within the monolith are deeply integrated and dependent on each other.	Microservices are independent of each other.
Components within the monolith can directly access and utilize the services of each other.	Microservices communicate with other microservices through a simple, well-defined interface called APIs.
Monolith applications require to be scaled vertically by adding more RAM and higher CPU counts which has an upper bound and are generally expensive in cost.	Microservices can be scaled horizontally on commodity hardware by increasing the replica count of individual services which make it highly scalable and cheaper in larger scale.
Individual changes are difficult and can propagate to cause the failure of whole system.	The effects of individual changes are much more predictable as the failures is bounded within the microservice.
Monolith are better for highly coupled applications which require very low latency.	Microservices are suitable for highly diverse and complicated applications which can handle little latency.
Properly implemented monolithic applications can offer high performance and very low latency for applications like databases, online games, trading websites.	Microservices though highly scalable and flexible have greater latency and require complex deployment strategies. They are useful for applications like e-commerce websites, batch processing sites, and highly loaded applications.

Conclusion

In conclusion, the choice between microservices and monolithic implementation is a matter of subjective decision that requires thorough requirements analysis and identification of priority. If the requirements of the problem can be solved by the monolithic approach then a lot of time can be saved in optimizing the application that could have been wasted in deciding the interfaces between the microservices. However, if the problem is too complicated to be implemented in a microservice then microservices would be the suitable choice.