Everyone talks about microservice application architecture. What is she good and how to switch to her?

The rapid development and spread of network cloud services by the early 2010s led to disappointment in the classic, so-called monolithic version of the application architecture. Due to the complexity of individual modules, which are often entire software systems, as well as the need to ensure compatibility between them through standard protocols, the introduction of any changes and additions has become a non-trivial task that takes too much time.

As an answer to this call, the microservice architecture was proposed as a distributed system of simplest and easily replaceable modules that perform the only elementary function possible. At the same time, the microservice system has a symmetric, peer-to-peer, and not a hierarchical organization, which eliminates the need for complex organization of relationships. Services communicate with each other and with clients using easy protocols, for example, through HTTP or text messages. As a result, a system is created that is easy to deploy and upgrade with automatic development and update functions.

By 2021, microservice architecture is in the spotlight, and not only specialists: they write about it on blogs, on social networks, discuss it in the press and at various conferences. Representatives of Amazon, Google, Netflix and Twitter declare the successful implementation of microservices. In Russia, the experience of switching to microservices was reported by large banks, as well as, for example, M.Video-Eldorado and MegaFon^[1]

At the same time, in the community of programmers, the voices of skeptics who do not consider microservices to be something fundamentally new are increasingly heard. In their opinion, this is simply the implementation of service-oriented architecture (SOA) at a lower level. Be that as it may, the microservice architecture has obvious advantages, especially in the field of Agile-development and deployment of complex enterprise-level applications.

Microservices as a Natural Cloud Application Architecture

As of 2021, microservice architecture is considered the most natural approach to developing cloud applications. These consist of many weakly connected and independently developed small modules - services. These services typically have three properties:

• they have their own stack, which includes a database and a data model;
• they interact with each other through a combination of REST APIs, event streams, and a message broker;
• application modules are selected based on the specific needs of^[2] business].

From the point of view of business and purely organizational tasks, the benefits of microservices are reduced to three main ones:

• ease of updating code;
• Different commands can use different stacks for different modules
• components can scale independently of each other, which reduces the cost and cost of scaling the entire application in cases where only one function acts as a bottleneck.

Microservices, monolithic architecture and SOA

To specify differences of microservices from other architecture, they are compared most often to monolithic architecture and service - the focused architecture (service-oriented architecture SOA). A microservice application consists of many small independent and weakly interconnected services, while in a monolith all its components are closely interconnected and work as a single service. Among other things, this means that if any one process in an application with a monolithic architecture becomes more popular, you have to scale the entire application as a whole. A failure in one process can compromise the entire system. Finally, this complexity limits the possibilities of modernization and makes it difficult to introduce new ideas.

The differences between microservices and SOA are not so obvious. You can follow a complex path and list many technical details, including those related to the Enterprise Service Bus (ESB) role, but you can do it easier and evaluate the levels to which these architectures apply. If SOA is an enterprise architecture designed to standardize the interaction of all services, then microservices belong to one particular application.

Microservices, managers and developers

A rare case: microservice architecture is almost as popular among project managers as among the developers themselves. The reason is that microservices fit perfectly into the schemes by which many managers structure tasks and manage development teams. Simply put, microservice architecture best reflects familiar management processes.

Individual services are extremely simple and can be deployed independently of each other, which means that in order to change some line in the code, decision-making at the highest level is not required. Thus, making minor changes no longer takes extra time. Small teams working independently on individual services can also be combined into multi-functional teams according to the Agile methodology.

When developing applications on a monolithic architecture, a large relational database is usually used, one for the entire application, even if there are simpler and more convenient solutions for some individual processes. This makes the entire architecture less efficient and cumbersome. In the case of microservices, each can have its own stack, model, and database optimized for a particular process.

Microservices and DevOps

DevOps methodology (from English development and operations; a set of practices aimed at actively interacting development specialists with information technology service specialists and integrating their workflows into each other) is often considered one of the most important and indispensable advantages of microservices, which is not surprising, since we are talking about the frequent deployment of small services. Moreover, it is following the principles of DevOps that makes microservices a successful architecture. Unlike monolithic architecture, microservice is a complex distributed system with many independent elements, which requires operational interaction between developers and users, frequent updating and maximum level of automation. And this is exactly what the essence of the concept of DevOps is.

Key technologies and tools

Modules in microservice architecture can be implemented on the basis of almost any modern programming language or tool, but there is a set of key tools that have become mandatory and defining for it.

First of all, we are talking about Docker^[3] - software for deploying and managing applications based on containers - a calculation model that is most closely associated with microservices. Since individual application containers do not have all the attributes of a full-fledged operating system, they are smaller and lighter in volume than ordinary virtual machines. Thanks to this, they start and disconnect faster, and thereby are ideal for small and light microservices.

With the advent of many services based on restaurerization, automation tools for managing large sets of containers have become extremely popular. One of the most popular technologies in the world for "orchestrating" containers, that is, automatic deployment, control, scaling and network connection today is Kubernetes^[4].

Microservices often interact through APIs, especially when initially establishing relationships. Although clients and services can communicate directly, API gateways act as a useful intermediate element with an increase in the number of services in the application. In addition to the reverse proxy and router features, they provide an additional layer of security for applications.

However, API communication is not an efficient and practical way of real-time operational interaction, so in addition to it, messaging or event flows are used. Message brokers and event flow platforms such as Apache Kafka^[5] do the best].

Server-free computing is a strategy that brings to a logical conclusion some of the key features of cloud and microservice technologies. When it is implemented, the execution unit is not even just a small service, but only a function, which is often expressed in several lines of code. The facet separating the server-free function from the microservice is rather conditional, so the function is usually considered as an even smaller process than the microservice.

Microservices and Cloud Services

Microservice architecture is not necessarily exclusively related to cloud computing, but is often associated with it for one simple reason: microservices are a popular architecture for new applications, and the cloud is a popular hosting for these new applications.

Disadvantages of Microservice Architecture

Of course, there are no ideal solutions, and microservices also have weaknesses. The main drawback of microservices lies in their very nature: a distributed system with many independent elements is more complicated both organizationally and architecturally. The management of development and deployment teams is becoming more difficult, and there are no methodologies Agile and. DevOps Distributed access to services means an increase in network delays and potential failures, which can be overcome by asynchronism and reducing the number of calls.

Do not forget the need to ensure application consistency: due to decentralization and modularity, non-consistency of data may arise, which also leads to failures and inaccessibility of the application as a whole. In this case, it is worth looking for trade-offs between service availability and consistency.

Due to these and other similar restrictions, experts do not recommend^[6] to switch to microservices simply in pursuit of fashion: the business should have a competent and trained development team and administrators, as well as sufficient infrastructure. In addition, experts do not advise using this architecture without cloud technologies, as well as Agile and DevOps practices.

Notes

You look also

• Check list: How to minimize risks when migrating to a microservice architecture
• SOA Architectural Features and Practices
• SOA 2.0
• SOA (Russian market)
• SOA (Global Market)