What Are Microservices?

Objective

The objective of this chapter is to describe Kubernetes and its needs in the clearest way possible without putting you to sleep. At its core, Kubernetes is an orchestrator of cloud native microservices applications. That’s a lot of jargon, so let’s explain the following:

• What are microservices?

• What is cloud native?

• What is orchestration?

Before we understand what microservices are, let’s look at the traditional way of building applications.

Monolithic applications

In the past, we have built and deployed monolithic applications. That’s jargon for complex applications where every feature is developed, deployed, and managed as a single large object.

If we look at the illustration below, we’ll see a monolithic app with the following six features:

• The web frontend

• The authentication

• The middleware

• The logging

• The data store

• The reporting

These are built, deployed, and managed as a single large application, meaning if we need to change any part, we need to change it all.

As a quick example, if we need to update the reporting feature, we need to take the entire app down and update it. This leads to high-risk updates we must plan months in advance and execute over long weekends. However, the pain of monolithic applications doesn’t stop there. If we want to scale a single feature, we must scale the whole thing.

Conversely, microservices applications take the same set of features and treat each one as its own small application. Another word for “small” is “micro,” and another word for “application” is “service.” Hence, the term microservice.

Microservices

If we look closely at the following figure, we’ll see it’s the exact same application as the above figure. The difference is that each feature is developed independently, each is deployed independently, and each can be updated and scaled independently. However, they work together to create the exact same application experience.

The most common pattern is developing and deploying each microservice as its own container. If we need to scale the reporting service, we add more reporting containers. If we need to update the reporting service, deploy a new reporting container and delete the old one.

Microservices are loosely coupled by design, and each one exposes an API that others use to consume it. These are fundamental to the ability to change one without affecting others.

The following car analogy might help if you’re new to the concept of APIs.

Cars come in all shapes and sizes—sports cars, SUVs, trucks, petrol, diesel, electric, hybrid, hydrogen fuel cell, etc. However, these differences are hidden from drivers behind a standard set of controls, including a steering wheel and foot pedals. In this analogy, the steering wheel and foot pedals are the car’s API—how we consume its capabilities. This means a driver can get into any car in the world and be able to drive it. For example, If someone learned to drive in a front-wheel-drive petrol-engine car with the steering wheel on the right. However, they can step into an all-wheel drive electric car with the steering wheel on the left and be able to drive it without learning any new skills.

Well, it’s the same with microservices applications. As long as you don’t change the API for a microservice, you can patch or update it without impacting consumers.

In addition to the ability to update and scale individual features, microservices lend themselves to smaller and more agile development teams that can deliver faster. It’s common to apply the two-pizza team rule, which states that the team is too big if you can’t feed a development team on two pizzas.

However, microservices introduce their own challenges. They can become very complex, with many moving parts owned and managed by different teams. This requires good processes and good communication.

Finally, both of these—monolithic and microservices—are called design patterns. The microservices design pattern is the most common pattern in the current cloud era.