Microservices architectures – still a revolution or already standard in IT projects?

Dawid Wieczorek | Software Development | 10.11.2021

The popularity of microservices architecture is growing

The concept of microservices architecture first appeared in IT around 2013. Since then, its popularity seems to have been moving in one direction – up! We can find confirmation of this in the 2020 O’Reilly report “Microservices adoption”, which shows that 77% of respondents use microservices architecture. At the same time, as many as 92% of respondents described the use of microservices as a success from the perspective of the expected payoffs that this approach brings.

In another survey by IBM Market Development & Insights, over 1,200 people from the IT industry were asked to share their opinions, including technical directors, managers and programmers working in companies that use or plan to use microservices.

The results are clear:

• 87% of users agree that the effort and costs related to implementing microservices architecture have paid off.
• 84% of users agree that the use of microservices architecture facilitates the work of employees and allows them to attract new ones.
• 77% of users agree that microservices are a proven and reliable application development model.

Although this is obviously a very uncertain measure, from the developers’ own perspective – judging by the project descriptions in job postings – I could say that in practice most projects are currently created using microservices architecture. Despite the fact that we have to look at such descriptions with an element of uncertainty, we can see that microservices are quickly becoming standard in the IT world.

Microservices architecture

One of the biggest challenges of microservices architecture is a strong dependence on infrastructure (server side, network, etc.), and thus an increased need to invest in development. A few years ago, however, it was a much greater challenge than today. In response to the needs of the new model, a wide range of tools have been developed to improve work in a distributed environment.

What are microservices tools?

• Containers – solutions for the management, automation and scaling of container applications were created for the purposes of service orchestration. Today we can choose from a wide variety of tools, from simple and undemanding like Docker Swarm, to the largest-scale enterprise solutions, of which Kubernetes or Openshift are perhaps the most popular. There are also cloud solutions such as AWS Fargate or Google Cloud Run. Each of the cloud platforms also offers self-managed Kubernetes services such as AWS EKS or Google GKE. All these tools significantly reduce the threshold of entry into microservices-based projects in terms of server infrastructure. However, you should take the costs of maintenance into account.
• Service Mesh – in response to the challenges related to the strong dependence on network infrastructure, many solutions have been created, of which the most popular is now the Service Mesh model. Here again we have a choice between lightweight solutions like Linkerd, Kuma or Maesh; more demanding ones like Istio; and cloud solutions, such as AWS App Mesh. As you can see, creating a network infrastructure for your microservice application is not as great a challenge as it used to be, although network dependence still is and will always be a challenge.
• Monitoring tools – to quote Lyft’s chief engineer Matt Klein, who was involved in the company’s transition from monolith to microservices:

Another significant change that occurs with the development of microservices is the presence of the network as an unstable element that cannot be avoided. Every developer eventually has to deal with networking problems, both in terms of transport and the much more complex tools required for debugging.

There is also a boom in demand for the above-mentioned tools supporting work and for debugging of the container application, and today we can take advantage of many monitoring, logging and tracing solutions.

Solutions such as Prometheus, ELK or AWS CloudWatch address the challenges related to maintaining or debugging applications in a distributed environment.

The cons of monolithic application

The emergence and ultimate success of microservices, of course, did not come out of nowhere. It is rather a response to the difficulties associated with the classical approach, which in many cases outweigh the advantages of the monolithic approach.

From the perspective of business and users

From a business perspective, we can list many issues that may affect the user experience, and thus – the final success of the application:

• Making even the smallest change requires the reinstallation of the entire application, which leads to the temporary inaccessibility of the application, which nowadays is essentially unacceptable for commercial solutions.
• The individual components of the system are closely related, which means that even a small change in the code may have a negative impact on the entire application, and thus affect 100% of its users.
• It is difficult to scale the application in response to fluctuating traffic. We do not have the option to scale individual elements of the system (as in the case of microservices) which is why the entire application needs to be scaled. In the event of overload, the application may become inaccessible to some users.
• Lack of scalability may translate to higher application maintenance costs.
• Slowing down the speed of development and release of new functionalities.

The possibility of using new technologies, the introduction of which would be too costly and require more time for developers (or even the necessity of hiring new ones), is significantly reduced.

From a developer’s perspective

Looking at this from the perspective of the developer working on the monolith, we can additionally mention a few more disadvantages:

• The big code base is difficult to understand, which means it takes a new developer a long time to learn and start working on the project. It also slows down the daily cycle of introducing changes and testing them (bear in mind that every change, even a small one, can affect the entire application).
• Dispersed responsibility and a lack of code ownership can demotivate a programmer, in contrast to having complete ownership of a part of the system, when you take ownership or when building and maintaining specific microservices.
• Difficulty in implementing new and interesting technologies, because each such initiative means changes to the entire code base of the application.
• Fewer opportunities for personal development – in the dynamically changing IT world, a developer is constantly broadening their skills and their knowledge is up-to-date. Working on a monolithic application may not be the best measure, as they do not deal with the extensive knowledge required in the world of microservices.

Advantages of using microservices architecture

Now let’s move on to the capabilities made available through the use of microservices.

From the perspective of business and users

• Easy redundancy of elements (i.e. duplication of individual components to ensure business continuity in the event of a failure) and scaling, in accordance with the current need, and thus greater system availability. Thus, the risk that the user will not be able to use our application is reduced.
• The loose connection of individual websites allows for the independent development of functionalities and their faster implementation.
• Deployments of each service can take place independently and do not affect the availability of the entire system for users in practice.
• Microservices applications are ideally suited to serverless architecture which, if applied correctly, will allow us to save on infrastructure costs.
• Easier testing of small services (components) allows users to avoid bothersome bugs.
• The introduction of new technologies which the user can benefit from is much easier and can take place at the level of individual websites.

From the development team’s perspective

• The use of microservices-based architecture has also several advantages for developers:
• Particular services are easier to understand and their code base is suitably smaller. This makes it easier to work on new functionalities and test them, but also has a positive impact on assigning a new person to the project.
• Each of the developers of a given microservice feels responsible for it and knows the business domain of the part entrusted to him well.
• The possibility of experimenting and expanding one’s knowledge of new technologies while creating new features.
• Better knowledge sharing among programmers, which allows us to avoid a situation in which the lack of a key person may turn into a serious problem.
• Responsibility for individual components is divided amongst separate teams, which allows for effective reaction by the right people in order to solve a given problem.

Disadvantages of microservices

From a business perspective

• The initial cost of implementing an application using distributed architecture may be higher than for a monolithic one. The increased primary cost includes the costs of infrastructure and the involvement of suitable DevOps specialists, who are responsible for its maintenance.
• The risk of difficulties or even application failure is greater due to the integral complexity of such an architecture.
• Building microservices calls for a change in the approach of the entire team working on the application. Decision-making shifts from managers and architects to individual teams. With such autonomy comes a greater need for effective communication and collaboration between teams.

From a development team’s perspective

• A functionality that requires absolute data consistency (banking transactions etc.) is more difficult to implement because it requires additional coordination of the entire process, which can be carried out in several services. In a monolithic application, such a problem would be solved with database-level transactions.
• Debugging can become difficult because the logic is spread across many services, the logs of which may contain error hints. Communication points between individual services may be additional sources of error.
• Integration testing of new features becomes more complicated as it is not possible to test entire distributed systems.

Microservices and the DDD approach

Most of the benefits of building distributed systems are the result of creating a proper division of responsibilities for given microservices and determining the ways of communicating between them. The goal is to create a strong consistency amongst websites and at the same time a loose connection between them. In other words, things that usually need to be changed together should belong to one site.

Without adequate division, instead of benefiting from microservices (services can be deployed independently and are scalable) we can end up with a project which is inefficient or difficult to maintain. In practice, it is obviously easier said than done – initial assumptions or requirements may change later. For this reason, being able to easily make changes is another crucial aspect in the design of any application.

Domain-driven design (DDD) is a key approach when designing microservice architecture, both while carrying out monolithic service decomposition and creating a system from scratch.

What is DDD?

DDD, introduced in Eric Evans’ book, is a set of principles and patterns aimed at supporting the development of distributed systems based on the business domain model as the subject of the developed software. A team of developers, together with business domain experts, create a business model in a common language (so-called ubiquitous language). Then the created model is translated into particular services, communication protocols between them are established and teams responsible for given services are formed. Using event storming can also be helpful throughout the process. DDD patterns are designed to help you to comprehend the domain and its dependencies. From here it is not far to delineate the boundaries in the domain, and split it into services.

Example of microservices in use

In an e-commerce platform which has been available for many years now, a new business requirement has emerged for the mass creation of new file-based offerings. The tool was to be mainly used by sellers offering a wide range of products, who could use the tool to improve and automate the interaction with the platform in terms of creating and editing their offers.

This platform, although created as a monolithic one, has been divided and developed using microservice architecture. The duty entrusted to one of the JCommerce development teams was therefore to create a new microservice (several of them were eventually created) responsible for this functionality. Work on the solution was carried out without interfering with the rest of the application’s multiple services, the development of which could proceed independently. The only point of contact with the rest of the platform was another microservice, and communication and implementation details were agreed between the teams responsible for both services.

Also, the majority of decisions about the technology stack (such as a database or even using different programming languages) were left to the team. After production deployment, the JCommerce team is able to dynamically scale the number of service instances according to the number of inquiries from users. Such autonomy is crucial to the development of applications that even hundreds of teams are working on collectively. It is hard to imagine the effective implementation of such functionalities in the case of monolithic applications.

Microservices vs monolith: which architectural style will work best for my project?

Unfortunately, the answer to this question must be evasive – it depends. When deciding on a given model, we have to compromise, i.e. we agree to take it together with its strengths and weaknesses.

When we want to divide the monolith into different services

If we are considering dividing an existing monolithic application, the decision may be simpler, motivated by all the issues that the monolith can cause. In this case, one of the proven approaches is cutting off smaller components from the main block, until finally new functionalities can be created in complete isolation and the smaller central monolithic application is gradually extended.

When we create an application from scratch 

However, if we start building an application from scratch, one of the key factors is the size of the target application. When creating an MVP of an application, the most important thing is the speed of functionality delivery, at the expense of other priorities. According to the YAGNI rule (You Ain’t Gonna Need It) it makes no sense to invest in using excessively sophisticated tools, if we are not sure that the application will attract the required level of interest.

Such a situation speaks in favor of using a monolith, which will be divided at a later stage – an interesting solution may be the use of the architecture of the so-called modular monolith, in which the functionalities are divided into individual modules created within one application.

However, if we know that the size of the target application justifies the initial investment, microservices architecture is the most suitable choice.