From the course: Kubernetes: Microservices

Monolithic vs. microservices architecture - Kubernetes Tutorial

From the course: Kubernetes: Microservices

Monolithic vs. microservices architecture

- [Instructor] Kubernetes is a container orchestration system built to run applications as containers in the cloud and enable communication between those containers. Kubernetes was developed in response to issues that arose when people deployed applications using physical servers and virtual machines, and it's helpful to understand some of this history in order to appreciate Kubernetes. The first part of understanding this history is to learn about the difference between monolithic and microservices architecture. A monolithic architecture is when an application is developed in a single code base and deployed all at once. Microservices architecture, often shortened to the term microservices, is when different parts of an application are developed and run independently as containers. Cloud native applications are synonymous with microservices architecture. The benefits of a monolithic app are that they are easier for a team of software engineers to develop and test because all of the code is in one repository. Another benefit of monoliths is that they have only a few points of entry, so they are easier to secure and they do not need complex networking enabled, so your company may not need a DevOps or platform team. The downside of a monolithic app is that it is difficult to keep up to date with all the application's dependencies and libraries. Every time you and your team deploy, you have to deploy the entire app instead of just the part you updated, and when one part of the application breaks, the entire thing can go down and they do not scale well. In contrast, the benefits of microservices include how fast you can deploy a service. When a change is made to the code of one microservice, you deploy the update on its own quickly and without impacting the other services. In the same vein, it's easier to update the software versions of your dependencies and libraries because you are only concerned with what it is in one small container, not a giant application. Another benefit is increased fault tolerance. When one service breaks, it doesn't automatically take down the entire app. Finally, microservices are easier to scale than monoliths because you can create more replicas of any service, but not necessarily all of them. This ultimately saves you or your company money. Monoliths were the most popular application architecture in the 2000s and early 2010s, when most companies owned the physical servers that hosted their websites and applications, and it made sense to have all their application code in one place and on one server. Microservices started to become popular in the mid 2010s when Docker, one of the first container technologies, was widely available to developers. At the same time, cloud services that offered virtual machines like AWS's EC2 and Google's Compute Engine became available. Once containers were mainstream and companies were migrating to the cloud, people began looking for ways to put as many containers as possible on one virtual machine to make the best use of computing resources and to save money. Kubernetes was in part, designed to solve that problem. Now that you know why microservices led to the development of Kubernetes, in the next video, let's go in depth about the ways people have used servers to deploy applications and how Kubernetes fits into that history.

Contents