Let's imagine we have one huge plastic block with a homogeneous structure. Next to it is a block of the same size and shape but consisting of several smaller blocks.
In which of the blocks will it be easier for us to make changes? This is how we can describe a 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 easy — it is a complicated process that requires us to change the amount of data, the number of interactions, and the functionalities.
All the more so since the data we collect and process are huge, and the amount is constantly increasing. For some time now, the concept of an "information diet" has been circulating, which is a bit stupid concept, referring to escaping from huge amounts of information. But when you run a business, all data (information) is valuable.
Let's use an example of an order registry of an online store. Although it loses its relevance after some time, storing it is important from the perspective of running a business: the register may prove useful for performing subsequent analyses that will help improve sales.
The simple solution would be to move the outdated collection of orders to a different place. However, when using a monolith, it's not easy. Because the monolith is a homogeneous structure that has integrity constraints, they make introducing modifications difficult, as well as testing or scaling a separate part of an application.
The solution is to divide the monolith into parts, i.e., to create microservices, but this means changing the whole architecture — obviously, high costs and risks are involved.
Microservices — architecture
Problems begin when a company creates new products or services within a monolith — or adds new features or modifications to existing services.
Working with the code turns out to be time-consuming. Therefore, dividing the application into smaller elements seems more practical instead of creating a monolith.
To do that, we assign each team to work on a specific, relatively small part of the application. It's like creating a huge structure from Lego, during which children or adults in small groups prepare each of its elements separately.
We Audit. We Research. We Design.
What are microservices?
A microservice is 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 handled by one large, stand-alone application.
Definition based on the book "Microservices" by Susan J. Fowler.
Giants prefer microservices
It's no wonder that Amazon, Twitter, Netflix, eBay, and Uber have abandoned monolithic applications. These mentioned companies focused on microservices architecture because they noticed it helps them avoid major obstacles, which Susan J. Fowler mentions in her book:
- Insufficient system efficiency.
- Slow-pace 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. Despite the risk mentioned above, she advises adopting 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 cooperation between each of these elements as three-tier architecture:
"Requests are made to the application through the client-side piece, the backend code does all the heavy lifting, and any relevant data that needs to be stored or accessed (whether temporarily in memory or permanently in a database) is sent to or retrieved from wherever the data is stored. We’ll call this the three-tier architecture."
Susan J. Fowler, Microservices
An example of programming challenges and microservices at a web development company
To further illustrate how helpful microservices are, let's use the example of a young web development company, which initially employs a few employees and creates simple applications, and the number of orders overlaps with human resources at the company's disposal.
However, after just a few years of business activity, the web development company 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 an application. This is usually followed by the need to hire additional people, e.g., system administrators who take on most of the hardware and support calls. Another obvious element is that as new features are added to an application, the complexity and number of lines of code increase.
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 that this means writing hundreds or thousands of tests to check that the changes made didn't compromise the integrity of the existing thousands of lines of code, even if the changes were made only in one or two lines of code.
Microservices and monolith
When creating a microservices 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 microservices is that a monolithic application contains all the features and functions in one application and one code base.
Moreover, they are installed simultaneously, and each server is the host for a complete copy of the application. In turn, microservices contain only one function or a feature and function in the microservices ecosystem along with other microservices, each of which performs one function or functional feature.
Microservices — advantages
Finally, let's look at the positives of 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.
Hero shot: FonsoSac / Flickr.com
