The background

We provided a practical definition for microservices in the first chapter. In this chapter, let's define microservices a bit more.

To fully appreciate microservices, let's start by telling the story of their rise. Before the idea of microservices became popular, most applications used to be monolithic. A monolithic application is a single application that tries to get numerous tasks accomplished at once. Then, as new features are needed, the application will get bigger and bulkier. This, in effect, produced unmaintainable applications in the long run. With the emergence of cloud computing, and distributed applications with massive loads, the need for a more flexible application architecture became obvious.

In Chapter 1, Modern Microservice Architectures, we provided an introduction to the MyEvents application, which we will be expecting to build in this book. The MyEvents application is used to manage event bookings for concerts, plays, and so on. The main tasks for the application include the following:

• Process bookings: For example, a user makes a booking for a concert next month. We will need to store this reservation, ensure that there are seats available for this event, and confirm no prior reservations were made with the same name, among other things.
• Handle events: Our application needs to be aware of all the concerts, plays, and other types of events that we're expecting to support. We need to know the event addresses, the total number of seats, their duration, and so on.
• Handle search: Our application needs to be capable of performing efficient searches to retrieve our bookings and events.

The following image shows how a monolithic application design for MyEvents would look like:

Monolithic application

We'll build multiple software layers within the application to handle each distinct task needed. Our application will become a program with a large code base. Since the code is all connected, there will always be a risk of change in one layer affecting code on the other layers.

Since it's a single program, it won't be easy to write some of the software layers in different programming languages. This is typically a very good option to have when you know there is a really good library in language X to support feature Y, however, language X is not good for feature Z.

Also, as you add new features or layers, your single program will keep growing with no good scalability options. Wouldn't it be better to be able to run different software layers on different servers so that you can control your application load without throwing more hardware on one or two servers?

Software engineers have tried to solve the monolithic application's dilemma for a long time. Microservices is one approach to address the issues that come with monolithic applications. Before the term microservices became popular, there was the concept of SOA, which was similar in principle to microservices.

Before we pe more into microservices, it is worth mentioning that monolithic applications are not always bad. It all depends on what you are trying to achieve. If you are trying to build an application that is expected to have a limited set of tasks, and not expected to grow by much, then a single well-built application might be all you need. If on the other hand, you are looking to build a complex application that is expected to perform numerous independent tasks, being maintained by multiple people, while handling massive data loads, then the microservices architecture is your friend.