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. 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 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 will see a monolithic app with the following six features.

• The web frontend

• The authentication

• The middleware

• The logging

• The datastore

• 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 the whole thing. This leads to high-risk updates that we have to 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 have to scale the whole thing.

On the flip side, microservices applications take the same set of features and treats 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. But they work together to create the exact same application experience.

The most common pattern is developing and deploying each microservice as its own container. This way, if we need to scale the reporting service, we just 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, I learned to drive in a front-wheel-drive petrol-engine car with the steering wheel on the right. However, I can step into an all-wheel drive electric car with the steering wheel on the left and be able to drive it without having to learn 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.

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

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.