Hey Habr. Today I continue a series of publications that I wrote specifically for the start of a new course stream. .
Introduction
The choice of architectural style is one of the fundamental technical decisions when building an information system. In this series of articles, I propose to analyze the most popular architectural styles for building applications and answer the question of when which architectural style is most preferred. In the process of presentation, I will try to draw a logical chain that explains the development of architectural styles from monoliths to microservices.
Last time we talked about the different kinds of monoliths and the use of components to build them, both build components and deployment components. We have dealt with service-oriented architecture.
We will now finally define the main characteristics of a microservice architecture.
Relation of architectures
You need to understand that based on the data in the previous definition articles, any service is a component, but not any service is a microservice.
Characteristics of microservice architecture
The main characteristics of a microservice architecture are:
- Organization in accordance with business capabilities (Organized around Business Capabilities)
- Products, not projects (Products not Projects)
- Smart endpoints and dumb pipes
- Decentralized Governance
- Decentralized Data Management
- Infrastructure Automation
- Insurance against failures (Design for failure)
- Architecture with evolutionary development (Evolutionary Design)
The 1st point comes from Service Oriented Architecture because microservices are a special case of services. Other points deserve separate consideration.
Organization in accordance with business capabilities (Organized around Business Capabilities)
Now it is necessary to recall Conway's law: organizations that create systems organize its architecture, replicating the structure of interaction within these organizations. As an example, we can recall the case of creating a compiler: a team of seven people developed a seven-pass compiler, and a team of five developed a five-pass compiler.
If we are talking about monoliths and microservices, then if the development is organized by functional departments (backend, frontend, database administrators), then we get a classic monolith.
To receive microservices, teams need to be organized by business opportunities (team of orders, shipments, catalog). This organization allows teams to focus on building specific parts of the application.
Products, not projects (Products not Projects)
The project approach in which the team transfers the developed functionality to other teams in the case of a microservice architecture is completely unsuitable. The team must support the system throughout its life cycle. Amazon, one of the leaders in the implementation of microservices, said: “you create a product, and you run it” (“you build, you run it”). The product approach allows the team to feel the needs of the business.
Smart endpoints and dumb pipes
SOA architecture paid great attention to communication channels, in particular the Enterprise Service Bus (enterprise service bus). Which often leads to the Erroneous Spaghetti Box, that is, the complexity of the monolith turns into the complexity of communications between services. In microservice architecture, only simple ways of interaction are used.
Decentralized Governance
Key decisions about microservices should be made by the people who actually develop the microservices. Here, key decisions mean the choice
programming languages, deployment methodology, 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 particular service. MSA involves decentralized data management, up to the use of various technologies.
Infrastructure Automation
MSA supports continuous deployment and delivery processes. This can only be done by automating processes. At the same time, the deployment of a large number of services no longer looks like something terrible. The deployment process should get boring. The second aspect is related to the management of services in the production environment. Without automation, managing processes running in different operating environments becomes impossible.
Insurance against failures (Design for failure)
Numerous MSA services are prone to failures. At the same time, error handling in a distributed system is not a very trivial task. Application architecture must be resilient to such failures. Rebecca Parsons thinks it's very important that we no longer even use in-process communication between services, instead we use HTTP for communication, which is nowhere near as reliable.
Architecture with evolutionary development (Evolutionary Design)
The architecture of an MSA system must evolve in an evolutionary way. It is desirable to limit the necessary changes to the boundaries of one service. The impact on other services must also be considered. The traditional approach is to try to solve this problem with version control, but MSA suggests using version control in
as a last resort.
Conclusion
After all of the above, we can formulate what microservices are. A microservice architecture is an approach to developing a single application as a set of small services, each running in its own process and interacting through lightweight mechanisms, often an HTTP resource API. These services are built on business capabilities and can be deployed independently using a fully
automated deployment mechanism. There is a minimum level of centralized management of these services, which can be written in different programming languages and use different storage technologies.
Source: habr.com