A discussion of architectural organization, and advice on the architect's path

Architect group exchange meeting: Choose one of the most popular technical topics in each issue to share practical experience.
The second issue: This article is a continuation of "Practical Sharing on High Availability Architecture from Didi, Weibo, Meizu, Vipshop, and Comments".
Participants in this issue: Peng Lingpeng, technical director of Didi, He Wei, system architect of Meizu, Zhang Guangping, application architecture director of Vipshop, Nie Yong, technical expert of Sina Weibo, Chen Yifang, technical director of Dianping trading platform, and chief executive of Qiniuyun Architect Li Daobing.
This article is a compilation of this exchange, welcome to discuss.

The second round: topic exchange
Moderator : Do you think there is a need for a unified technical architecture department, or does it not need a unified technical architecture department, and each business department develops independently?

Zhang Guangping from Vipshop: If we have a common infrastructure, the learning cost of such development is relatively low. After learning one set, he can continue to develop. If there are multiple sets of frameworks, the learning cost for developers is relatively high, and the other is the cost of operation and maintenance. In fact, any system is not an independent thing. If you want to go online, you also need to do operation and maintenance. As a simple example, we have developed a log monitoring framework called Mercury, which seems to have similar technology to some of the more popular existing ones. For example, a series of jobs using kafka, etc. If you want to operate and maintain, you need hundreds of machines to play this system. If we use different frameworks, the cost for the company is very high. After the operation and maintenance, each framework must build an operation and maintenance team to operate and maintain. At the beginning, there was this problem. It was difficult to launch the developed things. When the basic components were just developed, there was a little problem, and then it was enlarged infinitely, and no one used it. I just mentioned the refactoring. We recruited a team ourselves, but also because of the support of our CTO, we were given a team to do this refactoring. When our core services were connected little by little, we found that the effect was very good, and more and more teams were connected later. We certainly can't force pressure, because each team has KPIs. We were taking a gradual approach, picking up modules one by one.

Didi Peng Lingpeng: I still prefer the business architecture to follow the business technology department. Because whether it is from Baidu's experience or from Didi's feeling, we definitely need some of the most basic architectures, such as message queues, storage, and computing, which can be handed over to the infrastructure. However, when it comes to business architecture, I think it is still very close to the business. Personally, I have met many students who have done infrastructure before. The architecture they do is actually different from the business, such as delay or other requirements. It's still big, and it's not that easy to use.

Meizu He Wei: Because the basic architecture is actually recognized by everyone, the business architecture must be related to the business group. Because of business scenarios, such as the original technical architecture to develop the MQ framework, its framework may be normal MQ, and the technical architecture team can make it. The possibility is that the basic characteristics of the message can be sent and received, the business requirement is the timing of the message arrival, the message arrival has a delay, it sometimes requires a delay, and sometimes the message must be continuous before the message. Like this, the architecture team doesn't understand it, and it has to be done again.

Didi Peng Lingpeng: I think from the perspective of the whole team, it may be feasible to do this in the early stage of formation. But with the development of the business, the team will definitely recruit some new people, but the new people will actually know less and less about the business. The elderly may gradually prefer to do top-level design. When it is implemented, the new classmates will not implement it well in the end, which basically cannot meet the business needs. For example, Baidu Web Search Department and other departments used to have their own infrastructure. In 2011, a special infrastructure department was jointly established. At first, the business department and the architecture department were willing to cooperate, but after 2013, basically No longer in contact.

Zhang Guangping of Vipshop: We set up an architecture review committee at that time. While pushing, we also made some mandatory requirements through the committee. For example, we will review each project. If you do not use some standard things, or do not To solve it according to some better methods, we will not let him go online.

Qi Niu Yun Qi Dao Bing: If there is an infrastructure, in fact, the most worrying thing is that the things of the infrastructure cannot be sold, that is, the business department does not buy the account of the infrastructure department. If you do it separately, you are more worried about efficiency. It is more about the early and late strategies of some companies.

Public comment Chen Yifang: The technical structure actually follows the organizational structure or the business structure. The infrastructure is actually related to the organizational structure.

The third round: Suggestions for improving the ability of architects
Moderator : There are three questions here, everyone will choose one to express their views.
1. Many architects are transferred from programmers, so what advice do you have for a programmer who wants to become an architect?
2. Different architects have different practices in selecting models. Some are conservative, some are radical, what is your point of view? Why would you make this choice?
3. What are you most afraid of when doing architectural design? Why?

Didi Peng Lingpeng: I choose programmers to transform. Because I do a lot of frontline work. It's important that we don't just write code, but leave plenty of time for thinking and abstraction. Because I found that many first-line engineers who have worked for five or six years, changed companies, or stayed in a company for a long time are always writing similar business codes. If he doesn't think about it, I don't think his ability will go up. The second is that we need to break the boundary when we do some things. Many programmers will feel that this thing does not belong to me, I will not touch it, or that this thing is C++, I am not familiar with it, and I don't care, etc. narrow. Third, after becoming an architect, I still have to stay close to the business. And for an architect who has turned from a programmer, it is necessary to pay attention not to look only at technology, but more importantly, to be close to the business. Fourth, we do something, such as service governance. Your strategy can be very big, and there is an ideal goal there, but when it is implemented, each tactic you have to do is very detailed before it can be achieved. The whole is a spiral iterative process.

Meizu He Wei: I just asked the second question. In fact, I agree with the previous one. One is to lay a good foundation, and then to learn some experience in industry architecture. Let me add that as a programmer, you need to find opportunities to exercise yourself, instead of doing what you have arranged for you, you need to think more and dare to PK with others. The second question about architecture selection, I don't think it is necessarily conservative or radical, there is no absolute. For key businesses, I tend to be conservative. After all, stability comes first. I only dare to use things that have been verified in the business environment. For some businesses that are not very important, and new businesses that are growing, you can try some new technologies, and make some radical attempts appropriately.

Weibo Nie Yong: The first question is, I don't think it's important to be an architect or not. Don't make architecture for architecture's sake. You should combine reality and think with your heart. When thinking, you should think more comprehensively, and then put your whole heart into it. In the built system, it is natural to be able to do deep technology. The second question, about conservative or radical? In fact, I may be conservative. When we are building architecture or systems, we should rely on external dependencies as little as possible, because once you add a dependency, in the subsequent practice process, every link may be A problem occurs, which increases the difficulty of operation and maintenance. The third problem, when doing the architecture, the most feared problem is that you introduce each dependent component, you do not seriously understand it deeply, so it will be very troublesome when there is a problem later.

Vipshop Zhang Guangping: I am addressing the second question. Whether it is conservative or radical depends on some specific scenarios. If architects are involved in time-constrained projects or key projects, changes to these projects will have a greater impact on the production environment, and the plan must be measured carefully at this time. Should we make some changes and what are the rewards for these changes? Well for new projects, it's similar to refactoring. If you just stay put, you may not get some rewards. Therefore, we need to exert our subjective initiative, such as using some abstract thinking, do some sufficient research on the existing system, and boldly propose some of our own solutions. Of course, this plan needs to interact with each team and then verify it.

The public commented on Chen Yifang: I am actually more practical, neither conservative nor radical. Just like the idea of ​​a product, less is beautiful. Now a system is very complex. If everyone adopts different strategies or different technical warfare, it is actually difficult to manage. The requirements here are simple, and everyone should try to be unified. Then after the introduction of this module and this technology, it is maintainable. We must also be responsible for this system. Whoever brings it in will have to control this technological war. This strategy is generally called pragmatic. It is also possible to iterate, process, and adjust, and a very good system will not come out all at once, all of which are gradually added to the technical war. The pros and cons of a technology station should be selected according to your user scenario and the traffic scale of your business, because the long-term traffic scale will determine how much impact your system will have and what will be the bottleneck in the future.

Qiniuyun Li Daobing: Regarding the first question, I think the first is to improve your vision, and the second is to practice deliberately. To improve your vision is to read more books, attend more conferences, learn more about some emerging ideas, and how to integrate these ideas into your current knowledge system. Deliberate practice is mainly divided into two parts, how to solve the problem and how to evaluate the pros and cons of the solution. For example, when watching a speech, try to read only the problem part, not the solution part, try to solve the problem by yourself, and then talk to the speaker. Compare the plans and evaluate the pros and cons.