Choosing an architectural style (part 3)

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 disassemble the most popular architectural styles for building applications and answer the question of when is the most preferred architectural style. In the course of this 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 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, 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:

• Organization according to business opportunity
(Organized around Business Capabilities)
• Products, not projects (Products not Projects)
• Smart endpoints and stupid channels (Smart endpoints and
dumb pipes)
• Decentralized Governance
• Decentralized data management (Decentralized
Data Management)
• Infrastructure Automation
• Insurance against failures (Design for failure)
• Architecture with evolutionary development (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 it is necessary to recall Conway’s law: organizations that create systems organize its architecture, copying 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 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 given 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
programming languages, deployment methodologies, 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, the management of 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 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 architecture of the MSA system 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 in
as a last resort.

Conclusion

After all of the above, we can formulate what microservices are. Microservice architecture is an approach to developing a single 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 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.

Read part 2