Today, the market environment is complex and changing rapidly. In order to survive better, modern enterprises need to have strong adaptability. Quickly and easily meeting changes has become one of the characteristics of a high-quality enterprise. At the same time, enterprises also require technical teams to build a more scientific architecture and build a lower-cost platform, which makes these teams more and more inclined to use the microservice architecture. to meet the above requirements.
The microservices approach favors the decentralization of software components and data, breaking a whole into smaller, easier-to-change parts. Decentralization only helps teams speed up engineering without sacrificing system security. For this architecture to work well, a change in the way it works needs to be done.
The microservice architecture is actually designed to enable teams to distribute decision-making power among the people who perform the work, directly imposing decision-making power on more members, allowing them to produce in a freer way. When used correctly, a microservices architecture will result in better and faster changes. But if your architecture is wrong, a series of bad decisions can reduce conversion rates or even hurt your business.
1.jpg
We talk about the distribution of decision-making power, which means that the splitting of the microservice architecture is actually seeking the right decentralization strategy. This is an evolutionary process that requires constant analysis and adjustment. And how to correctly split the microservice architecture, I think we can focus on the following three aspects:
1. What decisions should we make?
Designing a microservice system is not just about changing the size of components, all areas of architecture that involve creating and changing services have a role. The following nine aspects are summarized here as a reference for decisions made when splitting a microservices architecture:
• Lifecycle: When is a service created or stopped? When do we need to separate them?
• Service implementation: What tools, languages, and architectures should we use in each service?
• System Architecture: How does the service guide others? How do developers know?
• Data Architecture: How will data be shared between services?
• Change Process: When can a service change? Tools and processes for deployment and QA?
• Team management: who serves on which team? What is each team responsible for? What did the team members do?
• Personnel management: How are people hired and fired? How are employees motivated and rewarded?
• Safety management: How do we reduce the risk of safety incidents? What needs to be done to improve the security of the entire system?
• Procurement process: What software can be purchased? What protections are required to use open source software?
2. Who are involved?
Admittedly, some of the decisions an employee makes can be very impactful for their company. A typical phenomenon is that companies try to increase control over internal decision makers in order to minimize risk, resulting in centralization of decision-making power. For example, over the past few years, Apple has been known for having a highly centralized design team, with a small number of people making most of the decisions about product design.
Concentration happens because the right people need to make the most important decisions. Often, the "right people" are those with the combination of talent, expertise, and experience that we can trust to make the best decisions, and we can call these people our "star decision-makers." But in fact, the company has a limited number of "star decision makers", and most teams have only a few "stars".
Microservices change this phenomenon of few people exercising decision-making power, while making it easier to deal with bad decisions. If a team makes the wrong decision when working on microservices, the scope of the error will be small and the fault tolerance rate will be high. When changes to the system become cheap and easy, teams can quickly improve on previous decisions, allowing them to arrive at the best decisions faster.
2.png
3. Who owns which part?
Decisions are based on choices, which in turn are based on domain knowledge. Decisions should not be carried out immediately, it requires a process that requires highly specialized skills or knowledge to achieve.
Management expert Henry Mintzberg provides us with a good model outlining the steps of the decision-making process:
research and information gathering ,
generating choices
, making choices
, empowering choices,
executing and implementing
The key to all of this is that when adopting decision decentralization, there is no need for absolutes. Each step can be independently centralized or decentralized, allowing for greater flexibility when balancing efficiency and security. Today, the combination of centralized selection and non-centralized selection is also a common model for many large companies today.
When people talk about microservices architecture, the selection, delegation, and enforcement parts of the decentralization process work together, move quickly, and at scale, all of which reduce the negative impact on the overall system when changes come. It's an effective way to increase the speed of change, but don't forget that your membership, team alignment, and all of your systems, tools, and work environments are just as important.
You have to understand how to make decisions, how to improve processes, and that's a good way to embrace change.
If you want to get a high salary, want to study, want good employment prospects, want to gain an advantage in competition with others, want to enter Ali for an interview but are worried that the interview will fail, you can come. The group number is: 454377428