Introduction
The choice of an architectural style is one of the fundamental technical solutions in 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 is the most preferred architectural style. In the process, 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 how to use components to build them, both assembly components and deployment components. We've dealt with service-oriented architecture.
Now we will finally define the main characteristics of a microservice architecture.
Relationship of architectures
It should be understood that, based on the data in the previous definitions articles, any service is a component, but not every service is a microservice.
Characteristics of a microservice architecture
The main characteristics of a microservice 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 special case of services. Other points deserve separate consideration.
Organized around Business Capabilities
Now we need to recall Conway's law: organizations that create systems organize its architecture, copying the structure of interaction within these organizations. As an example, consider the case of creating a compiler: a team of seven 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 get microservices, teams need to be organized by business opportunity (order, shipment, catalog team). This organization allows teams to focus on creating specific parts of the application.
Products not Projects
A 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 entire life cycle. Amazon, one of the flagships of microservices adoption, stated: “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 has paid a lot of 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 the connections between services. The microsevice architecture uses only simple communication methods.
Decentralized Governance
The key decisions for microservices must be made by the people who actually develop microservices. Here, key decisions mean the choice
of programming languages, deployment methodology, public interface contracts, etc.
Decentralized Data Management
The standard approach, in which an application relies on a single database, cannot take into account the specifics of each specific service. MSA assumes 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 scary. The deployment process should get boring. The second aspect is related to service management in the product environment. Without automation, managing processes running in different operating environments becomes impossible.
Design for failure
Numerous MSA services are prone to failure. 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 is very important that we no longer even use in-process communication between services, instead we use HTTP for communication, which is not nearly as reliable.
Evolutionary Design
The MSA system architecture must evolve. It is desirable to limit the required changes to the boundaries of one service. It is also necessary to consider the impact on other services. The traditional approach is to try and fix this problem with version control, but MSA suggests using version control as
a last resort.
Conclusion
After all of the above, we can formulate what microservices are. Microservice architecture is an approach to developing an individual application as a collection of small services, each of which runs in its own process and interacts 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 engine. There is a minimum level of centralized management of these services, which can be written in different programming languages and use different storage technologies. Read part 2
