What Are Microservices?

Objective

The objective of this chapter is to describe Kubernetes and its need in the clearest way possible, without putting you to sleep.

At its core, Kubernetes is an orchestrator of cloud-native microservices applications.

But that is a painful number of buzzwords in such a short sentence. So, you can take a step back while you are given answers to the following questions:

• What are microservices?
• What is cloud-native?
• What is an orchestrator?

Before you can understand what microservices are, you will need to look at the traditional way of building applications.

Monolithic applications

Back in the day, monolithic applications were built and used. That is just a fancy way of saying that all of the application features were bundled together into a single package.

If you look at the illustration below, you will see the following bundled as a single ugly application:

• The web frontend
• The authentication
• The logging
• The datastore
• The reporting

They are also tightly coupled, which means that if you want to change one part, you will have to change everything.

As a quick example, if you want to patch or update the reporting feature of the application in the illustration above, you have to take the entire application down, and patch/upgrade the whole thing. Talk about a nightmare. Work like this requires painful amounts of planning, carries enormous risk and complexity, and is usually carried out over long boring weekends in the office consuming too much pizza and coffee.

But the hassle of working with monolithic applications does not stop there. You’ll encounter similar challenges regardless of what part you want to scale. ;Scaling any single part of the application means scaling the whole thing

Every application feature is bundled, deployed, upgraded, and scaled as a single unit. Needless to say, this is not ideal.

Note: This is an extreme example. Not all applications were shipped like this. However, it was the prevalent model for building, deploying, and managing applications.

Microservices applications

If you look closely at the illustration below, you’ll see that it is the same set of application features, namely:

• The web frontend
• The authentication
• The logging
• The datastore
• The reporting

But, it splits each one out into its own mini-application. This is where the term “microservice” comes from.

The difference is that each microservice is developed independently, deployed independently, and can be updated and scaled independently. But they work together to create the same application experience. This means that clients and other application users get the same experience.

Each feature/microservice is usually developed and deployed as its own container. For example, there will be a container image for the web front end, a different container image for the authentication microservice, a different one for reporting, and so on.

As shown in the illustration above, each microservice is more loosely coupled. Technically speaking, each microservice normally exposes an API over an IP network that the other microservices use to connect to it. That is a lot of jargon that explains how each microservice is allowed to work independently from the group.

As well as the ability to update and scale microservices independently, the microservices design pattern lends itself to smaller, more agile, and specialized development teams that can develop and iterate on features faster. This is based on the “two-pizza team” rule coined by Jeff Bezos, which states that if you can not feed a development team on two pizzas, the team is too big. Generally speaking, teams of 2–8 people can communicate and work together with fewer politics and more agility than bigger teams.

There are other advantages to the microservices design pattern. Still, you get the picture. Developing features as independent microservices allows them to be developed, deployed, updated, scaled, and more without impacting any other part of the application. This is what we call fault isolation.

Microservices aren’t all cupcakes and rainbows, though. They can become complex with lots of moving parts being managed by different teams. This needs careful management.

These two ways of designing applications,monolithic and microservices, are called design patterns. The microservices design pattern is the prevalent design pattern with containers.

To summarize, a microservices application is composed of several small, specialized parts that are loosely coupled to create a useful application.