From Monolith to Microservice Architecture on Kubernetes

Emmanuel Eliason-Armstrong
4 min readJan 19, 2020
Kubernetes comes to fill this gap and provides plenty of benefits to both developers and ITOPS teams.

With more and more big companies accepting the Kubernetes model as the best way to run applications, it’s becoming the standard way of running distributed apps both in the cloud, as well as on local on-premises infrastructure.

To give you a better understanding of the reason behind the adoption, this article will go through the transition from Monolithic to Microservice architecture and then highlight some of the key important benefits of Kubernetes for organizations as well as Software and DevOps Engineers.

From Monolith to Microservice.

Add alt text

In the Early days, most big companies, as well as startups, used to build their systems using a Monolithic Architecture, running either as a single process or as a small number of processes spread over a bunch of servers. These legacy systems are still widespread today. They have slow release cycles and are updated relatively infrequently. At the end of every release cycle, developers package up the whole system and hand, it over to the ITOPS guys, who then deploy and monitors it. And in the case of system failures, the ITOPS team manually migrates the applications to the remaining healthy servers. And as the architecture and the applications get more complex, more resources are required to maintain it at the same time, we lose speed, flexibility, and agility which makes it harder to react to the market’s needs.

For those reasons, today these big monolithic legacy applications are slowly being broken down into smaller, independently running components called Microservices. Because microservices are decoupled from each other, they can be developed, deployed, updated, and scaled individually. This enables you to change components quickly and as often as necessary to keep up with today’s rapidly changing business requirements. However, with bigger numbers of deployable components and increasingly larger datacenters, it becomes increasingly difficult to configure, manage, and keep the whole system running smoothly. It’s much harder to figure out where to put each of those components to achieve high resource utilization and thereby keep the infrastructure costs down. Doing all this manually is time-consuming and obviously requires a lot of effort. We, therefore, need Automation which includes automatic scheduling of those components to our servers, automatic configuration, supervision, and failure-handling. This is where Kubernetes comes in.

Do Kubernetes come to fill the gap?

Add alt text

Oh Yes!!!! with Kubernetes, developers are now able to deploy their applications themselves quite easily, while ITOPS engineers can now monitor and reschedule these applications in the event of a hardware failure. It could be stated then that the focus for DevOps engineers and Sysadmins shifts from supervising individual apps to mostly supervising and managing Kubernetes and the rest of the infrastructure, while Kubernetes itself takes care of the applications themselves. More precisely, Kubernetes is an open-source container orchestration platform developed by Google for managing microservices or containerized applications across a distributed cluster of nodes. Kubernetes is highly resilient and supports zero downtime, rollback, scaling, and self-healing of containers. As such, the main objective of Kubernetes is to hide the complexity of managing a fleet of containers. It can run on bare metal machines or on public or private cloud platforms such as AWS, GCP, Azure, and OpenStack. In any case, it abstracts away the hardware infrastructure and exposes the whole datacenter as a single enormous computational resource. It eases the deployment and bootstrap of software components without having to know about the actual servers underneath. But where Kubernetes really starts shine in, is that it alleviates the burdens of manually managing a lot of containers in a large scale production environment. If set up properly, it could save the company time and money by automating infrastructure resource management. For example, when an instance fails, Kubernetes automatically re-creates it. The end result is a smoother user experience and less downtime for applications in the cloud.

Key Takeaway

As we have reached the end of this article, it is important to highlight that Kubernetes marks a breakthrough for DevOps because it allows teams to keep pace with the requirements of modern software development. In the absence of Kubernetes, teams have often been forced to script their own software deployment, scaling, and update workflows. Some organizations employ large teams to handle those tasks alone. Kubernetes allows us to derive maximum utility from containers and build cloud-native applications that can run anywhere, independent of cloud-specific requirements.

Please share this article if you find it useful :)

REFERENCE:

  • Kubernetes. Production-Grade Container Orchestration
  • Marko Luksa. Kubernetes in Action.
  • Code.Hub. Docker & Kubernetes
  • Sirish Raghuram . 4 reasons you should use Kubernetes

--

--

Emmanuel Eliason-Armstrong

Cloud DevOps Engineer | AWS Certified Solutions Architect | AWS Certified Developer