Cloud-native architecture anti-patterns

Typical cloud native architecture anti-patterns

Technology is often like a double-edged sword . Alibaba will fully consider choosing different technologies according to different scenarios when helping itself and customers to evolve cloud-native architectures. The following are some typical cloud -native architecture anti-patterns that we have summarized.

1 : Huge monolithic application

The biggest problem of huge monolithic applications is the lack of dependency isolation, including unclear responsibilities caused by code coupling, lack of governance of interfaces between modules and the diffusion of change impacts, difficulty in coordinating development progress and release time requirements between different modules, and a sub-module . Instability causes the entire application to slow down. When expanding the capacity, it can only be expanded as a whole instead of the modules that have reached the bottleneck individually... Therefore, when the business module may be developed by multiple people, it is necessary to consider a certain degree of splitting through service. Sort out the aggregate roots, determine the main service modules and the boundaries of these modules through business relationships, clearly define the interfaces between modules, and match the organizational relationship with the architectural relationship.

Taobao business , Alibaba encountered hundreds of people maintaining a core single application, which caused serious problems of source code conflict and high cost of collaboration between multiple teams. To support the ever-increasing traffic, the application needed to keep adding machines, and the backend database connections quickly hit the limit. In 2008, when there was no "microservice" concept, Alibaba decided to split the service-oriented architecture. At that time, the idea was the micro-service architecture. The first service started from the user center, and the subsequent transactions, categories, stores, products, and evaluations Services such as the center are gradually separated from the monomer, and the services communicate through remote calls. Each center is specially maintained by an independent team, which solves the problem of R&D collaboration and the problem of continuous horizontal expansion according to scale.

2 : "Hard dismantling" of monolithic applications into microservices

The splitting of services needs to be moderate. Excessive service splitting will lead to a mismatch between the new architecture and the organizational capabilities, so that the architecture upgrade will not receive technical dividends. Typical examples include:

Service splitting of small-scale software: The software scale is not large and the number of team members is small, but for microservices and microservices, the modules with high coupling degree and small amount of code are forcibly split into services, and the one-time release needs to be split Separate releases and maintenance for multiple modules;
Data dependency: Although services are split into multiple services, the data of these services are tightly coupled, so these services share the database, resulting in data changes often being fanned out to multiple services, resulting in data dependencies between services;
Reduced performance: When a highly coupled module is split into multiple microservices , the original local call becomes a distributed call, which increases the response time thousands of times and leads to a sharp drop in the performance of the entire service link .

3 : Microservices that lack automation capabilities

A very important dimension in software architecture is to deal with the problem of software complexity. Once the scale of the problem has increased a lot, it must be reconsidered to adapt to the new solution. In many software organizations, the work unit of development, testing and operation and maintenance is based on the process . For example, the entire user management is packaged, released and run as a separate module; after the microservice is split, the user The management module may be divided into multiple modules such as user information management, basic information management, point management, order management, etc. Since each module is still packaged, released and run separately, the number of modules that the development, testing, and operation and maintenance personnel are responsible for per capita is limited. The linear increase has resulted in an increase in the per capita workload, which has also increased the cost of software development.

In fact, when the scale of the software becomes larger, the lack of automation will bring more harm. Due to the increase of interfaces, the number of test cases will increase, and more software modules will be queued for testing and release. If there is a lack of automation, the software release time will be longer. In multi- environment release or remote release, experts are needed to deal with environmental differences. impact. At the same time, more processes run in one environment, and the lack of automated manual operation and maintenance can easily bring irreproducible effects to the environment, and once a human operation and maintenance error occurs, it is not easy to "quickly stop the bleeding", resulting in longer troubleshooting time. , and make day-to-day operation and maintenance operations, require experts to complete. The consequences of all these problems are longer software delivery times, increased risk, and increased operational and maintenance costs .