Hello, Habr. Today, I continue the series of publications written specifically for the launch of the new stream of the course. .
Introduction
Choosing an architectural style is one of the fundamental technical decisions when building an information system. In this series of articles, I propose to explore the most popular architectural styles for building applications and answer the question of when each architectural style is the most preferable. Throughout the discussion, I will try to establish a logical chain that explains the evolution of architectural styles from monoliths to microservices.
Last time, we discussed various types of monoliths and the use of components for their construction, including both assembly components and deployment components. We delved into service-oriented architecture.
Now, we will finally define the key characteristics of microservices architecture.
Architectural Relationships
It is essential to understand that based on the definitions provided in previous articles, any service is a component, but not every service is a microservice.
Characteristics of Microservices Architecture
The primary characteristics of microservices architecture are:
- Organized Around Business Capabilities
- Products Not Projects
- Smart Endpoints and Dumb Pipes
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Design for Failure
- Evolutionary Design
The first point comes from service-oriented architecture because microservices are a specific case of services. The other points deserve separate consideration.
Organized Around Business Capabilities
Now, it is necessary to recall Conway's Law: organizations that create systems will design their architecture to reflect the communication structures within those organizations. For instance, a team of seven people developed a seven-pass compiler, while a team of five created a five-pass compiler.
When discussing monoliths and microservices, if development is organized by functional departments (backend, frontend, database administrators), then you end up with a classic monolith.
To achieve microservices, teams need to be organized around business capabilities (order team, shipping team, catalog team). This organization will allow teams to focus on creating specific parts of the application.
Products Not Projects
The project approach where a team hands over developed functionality to other teams in the case of microservices architecture is completely unsuitable. The team must maintain the system throughout its entire lifecycle. Amazon, one of the leaders in implementing microservices, stated: "you build a product, and you run it." This product-oriented approach allows the team to feel the needs of the business.
Smart Endpoints and Dumb Pipes
SOA architecture paid great attention to communication channels, particularly the Enterprise Service Bus. This often leads to what is known as the Erroneous Spaghetti Box, where the complexity of a monolith shifts to the complexity of interactions between services. Microservices architecture solely uses simple methods of interaction.
Decentralized Governance
Key decisions regarding microservices should be made by the people who actually develop the microservices. Key decisions refer to the selection of
programming languages, deployment methodologies, public interface contracts, etc.
Decentralized Data Management
The standard approach, in which the application relies on a single database, cannot take into account the specifics of each individual service. MSA assumes decentralized data management, even to the extent of using different technologies.
Infrastructure Automation
MSA supports continuous deployment and delivery processes. This can only be achieved through process automation. Deploying a large number of services no longer seems daunting. The deployment process should become mundane. The second aspect is related to service management in a production environment. Without automation, managing processes running in different operational environments becomes impossible.
Design for Failure
Numerous services in MSA are prone to failures. At the same time, error handling in a distributed system is quite a non-trivial task. The application architecture must be resilient to such failures. Rebecca Parsons emphasizes that we no longer rely on even inter-process interaction between services; instead, we turn to HTTP for communication, which is not nearly as reliable.
Evolutionary Design
The architecture of an MSA system should evolve gradually. It is preferable to limit necessary changes to the boundaries of a single service. The impact on other services must also be taken into account. The traditional approach is to try to solve this issue through version management, but MSA proposes using version management as
a last resort.
Conclusion
After all that has been said, we can define what microservices are. Microservices architecture is an approach to developing a single application as a set of small services, each running in its own process and communicating through lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and can be deployed independently using a fully
automated deployment mechanism. There is minimal centralized management of these services, which can be written in different programming languages and use various data storage technologies.
Source: habr.com
