Let's imagine we have one huge plastic block with a solid structure. Next to it is a block of the same size and shape, but consisting of a cluster of several smaller blocks. Which of the blocks will it be easier for us to change in any way? This is how you can depict monolith and microservices.
Change of business scale and microservices
Microservices are the answer, among others, to the problem of keeping up with business growth, where the existing IT architecture is no longer enough. But scaling such an architecture is not the simplest - it is a complicated process that requires us to change the amount of data, the number of interactions, and the functionalities.
Increasingly, the data we collect and process is huge and the amount is constantly increasing. For some time there has even been - somewhat ridiculously - the concept of an "information diet", referring to escaping from the sheer volume of information. But when you run a business, all data (information) is valuable.
Let's use an online store order register as an example. Although after some time it loses its validity, its storage is important from the point of view of doing business: the register may prove useful in performing subsequent analysis that will help improve sales.
The obvious answer would be to move the outdated collection of orders to another place. However, when using a monolith, it’s not easy. Because the monolith is a compact structure that has integrity bonds. They make introducing modifications difficult, as well as testing or scaling a separate part of the application.
The solution is to divide the monolith into parts, i.e. to create microservices, but this means a change in the whole architecture - obviously, there are high costs and risks.
Microservices - architecture
Problems can begin when a company creates new products or services within a monolith - or adds new features or modifications to existing services. Work with the code then turns out to be time consuming. Therefore, instead of creating a monolith, it seems more practical to divide the application into smaller elements.
To this end, we assign each team work on a specific, relatively small, part of the application. It's like creating a huge structure from Lego blocks, during which children or adults in small groups prepare each of its elements separately.
What are microservices?
We will call a microservice a small application that performs only one task well. It’s a small component that can be easily replaced, independently developed and installed. A microservice is part of a larger system, launched and working together with other microservices to achieve what would otherwise be served by one large, stand-alone application.
Definition based on the book "Microservices" by Susan J. Fowler.
Giants prefer microservices
It’s no wonder Amazon, Twitter, Netflix, eBay and Uber have abandoned the monolithic applications. The listed companies focused on microservice architecture because they noticed it helps them avoid major obstacles, which Susan J. Fowler mentions in her book:
- Insufficient system efficiency.
- Slow pace of development.
- Difficulties in adopting new technologies.
Susan J. Fowler warns that problems arise when we try to implement complex software systems in a large monolithic application. She advises that - despite the aforementioned risk - in this situation, adopt the microservices architecture.
Today, it is common to divide an application into three separate elements: frontend, i.e. the client side, backend, and database. Susan J. Fowler describes the collaboration between each of these elements as three-tier architecture:
"Requests are directed to the application via the client's site, the backend code does the main work, and the necessary data that must be stored or shared (regardless of whether it is temporarily in memory or permanently in the database) is sent or obtained from places in which data is stored. We call this three-tier architecture. "
Susan J. Fowler, Microservices
An example of programming challenges and microservices at a software house
To further illustrate how helpful microservices are, let’s use the example of a young software house, which initially employs a few employees and creates simple applications, and the number of orders overlaps with the human resources at the company's disposal.
However, after just a few years of business activity, the software house is growing significantly and gaining more and more customers. New employees join the team and applications gain additional functionalities. There are new challenges associated with this.
Susan J. Fowler first mentions the increased load associated with starting and maintaining the application. This is usually followed by the need to hire extra people e.g. system administrators who take on most of the hardware and support calls. Another obvious element is that as you add new features to your application, its complexity and number of lines of code increases.
The third element refers to the increase in traffic, which forces increased scalability and performance of applications - this is followed by the need to use more servers, which is why the cloud is such a good solution, where our information is divided into smaller parts each stored on a different server.
Along with new features and other changes in an application, its code is growing enormously. Susan J. Fowler warns this means having to write hundreds or thousands of tests to check the changes made don’t compromise the integrity of the existing thousands of lines of code. This is always the case, even if the changes just rely on one or two lines of code.
Microservices and monolith
When creating a microservice architecture, our task is to create a collection of small applications, each of which will be responsible for performing one function.
The basic difference between a monolithic application and a microservice is that a monolithic application contains all the features and functions in one application and one code base. What's more, they are installed at the same time, and each server is the host for a complete copy of the application. In turn, the microservice contains only one function or feature and functions in the microservice ecosystem along with other microservices, each of which performs one function or functional feature.
Microservices - advantages
Finally, let's look at the positives associated with microservices:
- Reduction of technical debt.
- Improving programmers' work efficiency.
- Better testing performance.
- Increased scalability and ease of implementation.
- Coping with scalability challenges and organizational problems.
Main photo: FonsoSac / Flickr.com