Shulou(Shulou.com)06/03 Report--

The concept of micro-services has always been popular, but now the concept of ServiceMesh is even more popular, and many of the projects I have worked on recently have been developed in the form of micro-services. However, practice has found that when a RD develops more than two microservices at the same time, the probability of bug or failure will increase.

When I look at the project now, I will unconsciously pay attention to the ratio of the number of engineering services split to the number of R & D personnel. Although I did so, I could not say why, nor did I find a theoretical basis.

I. introduction

Recently, I read an interview by Ji Wang (Peng Wenjie), a member of Spring Cloud Alibaba, which solved some of my doubts. The original text is here.

Https://mp.weixin.qq.com/s/jArp9LUnLv9jveh9qTndfA

I took an excerpt from the more important part.

The essential problem solved by micro-service is the division of labor among teams.

Whether SOA or micro-service, the fundamental problem to be solved is the division of labor among teams, as detailed in Conway's Law, which is the necessity of the development of large-scale software and does not change because of people's preferences. When you understand Conway's law, you will find that "service split granularity is difficult to accurately grasp" is not an essential problem at all.

How many 2 pizza teams you have, it's best to break it down into a few microservices. To take a realistic example: when there is only one developer, try to do a single application, do not look for stimulation to split into 10 micro-services, and eventually the developer will synthesize him. Micro services require vertical 2 pizza teams (numerous small teams, including development, testing, and operation and maintenance). Of course, we have also implemented some traditional large enterprises, but the team is still in the scenario of horizontal structure (development, operation and maintenance, and testing are each a team), so it is very painful for them to split micro services, especially the operation and maintenance team.

There are two concepts in this passage: pizza team and Conway's law.

2 pizza team

The two pizza principles mean that there should be no more participants than two pizzas are enough for them to eat. Amazon CEO Jeff Bezos (JeffBezos) believes that the truth is not that the more participants in corporate meetings, the better. He believes that meetings with more people will not be conducive to decision-making, but will lead to the following of the attendees, called the two pizza principles. 2 A pizza team can be simply understood as a small team that does something.

Conway's law

To the surprise of many people, many core concepts of microservices were expounded in the article "How Do Committees Invent?" half a century ago (1968). Many of the arguments in this article have been verified again and again in the half-century of rapid development of software development, which is the Conway's Law Law.

Interestingly, this argument remained unknown after it was put forward for many years, and then Brooks Law's famous man-month myth quoted it, and Conway's Law entered the public eye.

Second, Conway's law

Wikipedia shows that the most famous sentence of Conway's Law (http://www.melconway.com/Home/Committees_Paper.html) is this

"organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

The general meaning is: system design (product structure) is equivalent to organizational form, the organization of each design system, the resulting design is equivalent to the communication structure between organizations (to put it simply, the design of the system is limited by the personnel structure of the organization of the design system. We often say that micro-service is not only a technical problem, but also a R & D organization problem.

Think about the products you have used. Take a look at the following picture, which may deepen your understanding of Conway's law.

Mike Amundsen (author of Design RESTful API), summed up some other core ideas in this paper ("How Do Committees Invent?") from his point of view in a technology sharing of "Conway's Law at a long distance-team Building in a distributed World".

1. Communication dictates design (organizational communication will be expressed through system design)

2. There is never enough time to do something right, but there is always enough time to do it over (one more thing cannot be done perfectly, but there is always time to finish one thing)

3. There is a homomorphism from the linear graph of a system to the linear graph of its design organization (potential heterohomomorphism between linetype system and linetype organization structure)

4. The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems (large system organizations are always more likely to decompose than small systems)

More details of Mike Amundsen will not be expanded. If you are interested, you can search on your own.

III. Evidence supporting Conway's Law

Wikipedia is described below in the Supporting evidence section of the Conway Law entry.

The MIT and Harvard Business School research teams published evidence to support Conway's law, using the "mirror hypothesis" as the equivalent term for Conway's law. They found strong evidence that "supports the mirror hypothesis", "significant differences in [product] modularity" and "distributed teams tend to develop more modular products".

The case studies of Nagappan, Murphy and Basili of the University of Maryland working with Microsoft and Syeed and Hammouda of Tampere University of Technology in Finland also support Conway's law.

Fourth, how does Conway's law explain the rationality of micro-service?

Knowing what Conway's Law is, let's take a look at how he laid the theoretical foundation for micro-service architecture half a century ago.

The communication between people is very complex, and a person's communication energy is limited, so when the problem is too complex and needs to be solved by many people, we need to split the organization to achieve the management of communication efficiency.

The way of communication between people in the organization determines the system design in which they participate. Managers can bring different ways of communication between teams through different split ways, thus affecting the system design.

If the subsystem is cohesive and the communication boundary with the outside is clear, the communication cost can be reduced, and the corresponding design will be more reasonable and efficient.

Complex systems need to be continuously optimized through fault-tolerant flexibility. Don't expect a large and comprehensive design or architecture. Good architectures and designs are iterated slowly.

The specific practical suggestions are as follows

We should use all means to improve the efficiency of communication, such as slack,github,wiki. If you can explain things clearly by two people, don't pull more people. Everyone has a clear division of labor in each system. If something goes wrong, you will know who to look for immediately and avoid playing the ball.

Through the MVP way to design the system, through continuous iteration to verify the optimization, the system should be flexible design.

What kind of system design you want, build what kind of team, flat can be flattened. It is best to divide the team by business, so that the team can naturally self-unite, a clear business boundary will reduce the cost of communication with the outside, each small team is responsible for the entire life cycle of its own module, no unclear boundaries, no invalid wrangling, inter-operate, not integrate.

To be a small and beautiful team, a large number of people will bring the cost of communication and reduce efficiency. Amazon's Bezos has a funny metaphor: if two pizzas are not enough for a team, then the team is too big. In fact, in general, the team of small products of an Internet company is about 8 people.

The organizational structure at the company level seems to be at a high level, so back to the original question, how much is appropriate for your small team micro-service?

"How Do Committees Invent?" it is mentioned in the article that tasks can be nested, meaning that the split will first be split vigorously, and the split will continue to be split at a finer granularity until it is not needed.

Combined with Ali Ji Wang and my personal experience. If you are still a novice, it will not be a big problem if you expect several people to develop the project into several parts; if you are more experienced, you can give full play to the governance capabilities of the company's micro-services.

In short, as long as it is clear and the ability of operation and maintenance can keep up with it, it is generally reasonable!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.