[Learn microservices from scratch] 08. When to introduce microservice architecture

Hello everyone, welcome to Wanmao Academy, learn with me, and you can also become a microservice expert .

Before understanding the timing of introducing the microservice architecture, there are generally three principles that need to be followed in architecture design.

Three principles of architecture design

Architecture design generally needs to follow the following three principles:

  • Appropriate principle: Appropriate is better than industry-leading.
  • Simplicity Principle: Simple is better than complex.
  • Evolution principle: Evolution is better than one step.

Appropriate principle

We generally have a strong technical plot. When making an architectural solution, we always want to challenge ourselves and make a great architecture, but if the idea exceeds the reality, it is likely to fail in the end.

Even if our design is good and can lay a good foundation for the company, what is the actual environment of the company? Can it land well? If there are not so many people, but you want to do so much work, you will definitely fail.

Excellent architectures are actually forced out. When business development reaches a certain stage, quantitative changes lead to qualitative changes. Without such a strong business scenario support, the probability of failure is very high.

simple principle

When many people evaluate the level of a design plan, they like to look at the complexity. The more complex the system, the higher the probability of failure.

The principle of KISS (Keep It Simple, Stupid) should be kept in mind. The design of most systems should be kept simple and simple without adding unnecessary complexity. Such systems will achieve optimal performance.

evolutionary principle

For architecture, eternity is the theme, and for software, change is the theme.

When designing the architecture, you should always remind yourself not to be greedy for everything, or to blindly copy the practices of large companies. You should carefully analyze the characteristics of the current business, clarify the main problems of the current business, design a reasonable plan, and quickly implement it to meet the needs of the business. During the operation process, the structure is continuously improved, and the structure is constantly evolving with the business.

When to introduce microservices

Although the microservice architecture looks very beautiful, it also has a lot of additional costs.

As can be seen from the figure above, the horizontal axis is complexity and the vertical axis is productivity. When the complexity of the software is very low, the productivity under the monolithic architecture is higher than that of the microservice architecture, but as the complexity continues to increase, the productivity of both the monolithic application and the microservice application will decrease. The decline of the service architecture will be relatively slow.

Because in the microservice architecture, our system is composed of many small services, each service is small, relatively simple, and the technology stack is also very independent. It will also be easier to make local changes in this way. As the complexity of the system continues to increase, the advantages of microservices will gradually be reflected.

How to introduce microservices

In the right project and the right team, the benefits of adopting the microservice architecture will outweigh the costs. Microservice architecture has many attractions, but before embracing microservices, you also need to recognize the challenges it brings. "Microservices" for the sake of "microservices" needs to be avoided.

Martin Fowler (Martin Fowler) proposed the Monolith First (Monolith First) idea, we can understand:

It is not recommended to use the microservice architecture directly from the beginning, because microservices require investment in infrastructure in the early stage, and the complexity is very high. If you do not understand the problem domain very well, it is difficult to divide the boundaries of services when using microservices at the beginning. On the contrary, the productivity will be relatively low, and a lot of effort has been spent on development. The product has not been verified by the market and may fail. Therefore, the risk of this choice will be relatively high, so the single architecture is recommended first.

Start with the application of a single architecture, which has low cost and fewer team members. Without too much R&D investment, you can quickly iterate and deliver some basic functions, which can also win more time to explore the complexity of the business field. , and have a deeper understanding of the boundaries of the business domain. You can consider introducing some suitable microservice architectures. The principle is to transform existing systems in small areas with clear boundaries, or to gradually explore and accumulate experience in microservice architectures, rather than fully implementing microservice architectures.

As the application becomes more successful, the number of users increases, and the complexity of the system increases, there will be a contradiction between the application of the single architecture and the size of the team, and the productivity will gradually decrease with the complexity of the business. The effect of gradually splitting into microservices will be better.

Finally, thank you for being so handsome and giving me a thumbs up .


"Learning Microservices from Scratch" General Catalog

Guess you like

Origin blog.csdn.net/heihaozi/article/details/128405596