About the Author
顾宇ThoughtWorks Senior Consultant
Before the official start, do a survey. When you hear about microservices, are you happy, questioning, or painful?
My sharing today is the reflection and efficient landing of microservices. I will tell you in advance. This is for the team. If you see microservices videos and tutorials on the Internet, you can implement the microservices technology yourself on the cloud. . When you encounter a team that wants to implement microservices, it will have some problems. These contents are mainly for this part.
1. Reflections brought about by three microservice cases
1.1 Decoupling of Java legacy systems
This service project was the first year I joined ThoughtWorks. In September 2013, I didn't know that it was a microservice project. The concept of microservice only appeared in 2014. At that time, I was doing Java decoupling. This was a foreign client who was doing a vertical search engine.
The company chose a very good time and entry point, and soon became the number one in this industry in Australia. The old technology they used could not beat their competitors. They had new competitors competing with it with newer, faster, and cheaper technologies almost every month, so they wanted to decouple.
How to split the application reasonably in this situation? We started with the old Spring 2.5, using Java ESB as the bus, and hanging a lot of services on it, the old SOL model. Later, we used Restful's API to decouple the model and dismantled it from the entire Java outsourcing into an independent service. We can allow the disassembled applications to be deployed independently. This was the problem we encountered at the time. Our understanding at the time was very simple. To do microservices is to do continuous deployment of Restful API.
It took me seven months to complete the project. After that, we began to copy this experience.
1.2 A telecom operator
This project is an Australian operator. The problem with the project at that time was like this. At that time, it acquired a company to become a mobile operator and acquired a broadband operator. Its user base is rapidly expanding, so it needs to change its online application. The problem we faced was how to deploy applications quickly and stably, how to improve the productivity of the team, especially the level of automation, and how to remove process bottlenecks and cross-departmental collaboration.
At that time, our Ops team had only 4 people, and we wanted to improve the productivity of the team. Improvements other than the bottleneck are false. We have done DevOps consultation and improvement, and we have increased the development efficiency by 300%, but in fact it is less than 300%. For the upper level, the effect of the improvement is the same, or the version is deployed once a month.
The team that connects with me deploys the version once every three months. If something goes wrong, I can only wait for the next month. What I thought was that even if you did DevOps, you still did not accelerate. Our solution at the time was to separate a part of it related to our partner and turn it into a separate service. Our part uses our method so that everyone becomes asynchronous. DevOps achieves the ultimate and gets microservices.
When you have a single application that continuously improves the speed and quality of the continuous delivery pipeline, you can only remove it to improve it. You can expand the application on demand, and you can get a smaller risk point, because each deployment is a point, and the production impact is very small. Therefore, I think the ultimate in DevOps is to get microservices.
1.3 Cloud computing products of a large IT group
This is a domestic customer, headquartered in Shenzhen, and it is also a cloud computing product. After I finished my last microservice project, I discovered the routine of microservices. You have to find the bottleneck that really solves the problem. At that time, the bottleneck of the project was how to shorten the release time, how to release independently, and the microservices were delayed.
It takes eight weeks for this project to be released. We think it is very difficult for such a large cloud computing platform system to send a whole package, so we split a part. But there is a problem. This microservice splitting plan has been delayed.
The week before Christmas in 2015, I said that I would do this. I joined the project one week before April 1, 2016. When I learned about this, I found that they had already passed about three months, except for a bunch of reports and meeting minutes. , And the evaluation plans of the consultants from all parties, none of them are in place. I was thinking that microservices is a very simple matter through my previous experience, why is it so difficult to land?
Your bottleneck often comes from the organization, and it is effective to make microservices from the adjustment of the organizational structure. We want to do microservices, draw the system architecture, we will split and design, and the results will be slow and not good. When new problems arise later, we will need to modify the original plan.
1.4 Common points of the three cases
-
All development teams and applications need to maintain high-efficiency deployment of the team when the scale grows;
-
To practice continuous delivery and DevOps on the team;
- Let the application be released without conflict in space and time;
If you have a single application, you will definitely build a pair of branches, and you need to deal with conflicts when merging, and it may not be feasible to go online after testing. So, to do this, we need to make some huge adjustments.
1.5 How to face growth
This is the growth model we encounter when demand and scale grow. When you encounter SCALE UP, resource growth needs to be managed, which brings additional costs.
There is a law called the law of diminishing marginal returns, so we will do another kind of expansion, that is, SCALE OUT, which is a linear expansion, but we need a strong system. We can take the success of a team and the success of an application along with the scale The growth of the company continues to expand. This is the basic idea of doing microservices. The problem you are facing is to solve the conflict of development and deployment in time and space in the case of rapid growth or large scale.
After we encountered the scale problem, there was a cost turning point.
The X axis is the cost, the Y axis is the scale, the black line is the single application, and the green line is the microservice application. Microservice applications start as a distributed system, and the initial cost will be a little higher than that of a single application. After a while, they will reach point X. At this point, there is no difference between a monolithic application and a microservice application. However, when the application grows, if it is a single application, it will meet the cost limit. When the cost limit is reached, the expansion of scale cannot be supported, so there is a growth limit, which is called X'. When the application complexity grows in scale and cost to a certain extent, it is transformed into a microservice application.
The fact is very cruel. Most companies do not hit Nantou and do not look back. This is ideal. The concept of separation of duties has been around for a long time. Microservices use new technologies and new bottles of old wine. Microservices have not brought new methodological breakthroughs.
Therefore, consider the transformation of microservices as an investment, an investment in the growth limit of the enterprise. After you obtain a higher expansion capability, you will get a farther limit, because you can copy your advantages.
1.6 Problems Solved by Microservices
What problems are microservices essentially solving?
-
The team and application are in high growth;
-
Improve overall delivery efficiency through independent deployment and independent release;
- Resolve conflicting access to a single code base in time and space;
If you are doing microservices, first check if you have such a problem.
2. Difficulties in landing microservices
Let's take a look at the difficulties of microservices landing. These are common problems in the microservice projects I have participated in in the past. The difficulty is that these problems require more time to think and discuss, and provide a basis for microservice architecture decisions.
-
Don't know how to split;
-
Difficulty in the implementation of the structure;
-
Management is becoming more and more complex;
-
The technology stack does not know how to choose;
-
The team does not know how to organize;
- How to manage microservices;
2.1 Technical vs. non-technical issues
Are microservices technical or non-technical? In fact, it is both. I highly recommend the book "Humanware". There are two sentences in its preface: "The important problem of software systems lies not in technology, but in social factors." "If the problems we face are inherently sociological, then Good technology may not provide much help."
Microservices is a management problem that is hidden under technical problems. If your technology stack lacks management, if you use a good refactoring solution to continuously optimize the code at the beginning, it is good for you to do microservices and do a single responsibility later. , You can migrate in one step. Our code base is actually isolated. When we merge the code, we have automated testing, so we make a one-click switch to copy the code base and change it to API calls, which can ensure that the microservices are not too big after they go online. The problem.
Did not realize that microservices is an organizational transformation problem.
This picture is from Netflix. Netflix has its own experience of doing microservices on the Internet. This picture also comes from there. It says that microservices is an organizational change, and organizational changes are difficult.
Microservices are not all smooth sailing, but management is something you can't see. We have to let many teams see management problems. Seeing is the beginning of change. Only when we can see the problems, we know how to change.
There is a Satya change model in Humanware. When you have an existing architecture, the introduction of microservices will cause confusion. After intervention and coaching, practice and integrate, feedback and strengthen to form a microservice architecture. If you are happy doing microservices, it means that you have reached the stage of microservice architecture. The difficulty is the chaotic part in the middle, and chaos is an insurmountable process. When you encounter new things, you have to spur your new habits, and you must experience unaccustomed things.
2.2 What is efficient?
When it comes to the steps of efficient implementation of microservices, how can they be considered efficient?
-
Starting from the result, find the shortest distance. Through the original development model, after analyzing and then landing, you are farther and farther away from microservices. It does not make you faster or simpler;
-
The most difficult things are solved first. Technological changes are often the easiest part, and the most difficult part is the technical implementation part;
- Low cost, low risk, absolutely no waste;
Three. Five steps to efficiently implement microservices
3.1 Start with the end and build a team
Don't think about technology first, first set up a microservice team. If you do microservices in the traditional way, you will only repeat the same mistakes. An autonomous full-function team is a team that can independently publish microservices. It requires 1 microservice manager to solve process dependencies and interference; 2-4 development/testing, focusing on microservice development and testing; 1-2 operation and maintenance , Used to provide the fastest release and deployment. If your organization is a separate DevOps team, it is recommended to have 1-2 operations and maintenance.
An independent small team is to avoid dependence. You are used to one development method in the original development process and environment. After you switch to another method, you always think about the previous method of development.
However, we want to emphasize that everything in a team is done by the team. On the one hand, it is to improve the ability of the personnel. On the other hand, it is to make everyone feel that they can have more control, and the mood is better than before. Press the correct one. Way to make the right choice. There are also special affairs, if you follow the original way, the efficiency will not improve. To put microservices at the highest priority, there must be a sense of ritual.
This is technical advice-a microservice, a code base, and a pipeline.
There are two kinds of organizations. One is a loose and flat organization. It has a strong management protocol. If a software system is applied, it will quickly adapt to the architecture of the software system. If it is another type, the software architecture will be changed to an organizational structure. This is the so-called Conway's law, that is, your organizational structure and system architecture are basically equivalent.
In different organizations, it is possible that the system structure changes the organization structure, and it is possible that the organization structure changes your system structure. If the team size exceeds 200 people, changing the way of managing the organization through technical means will generally not succeed, unless it is very powerful. To do this.
3.2 Building a microservice elevator speech
The elevator speech comes from McKinsey, which is to keep the concept of microservices simple. It should be simple at the beginning, and the borders can be easily cut apart. The most important thing is not to 15 seconds, finish the microservice within 15 seconds.
This is the title of our company-without mobile phones and computers, the meeting communication effect is good, so it must be hung on the wall to form a sense of ritual and continuously form hints. The elevator speech of the microservice team must reach a consensus and then realize it quickly.
3.3 Get a quick victory
Release the first microservice with minimal cost, which will bring a lot of morale to the team. The goal should not be too high. Showcase drives development. You can develop whatever you want to demonstrate, and there will be effective output every day. Set a goal on the first day, show this tomorrow, and make sure to show it tomorrow.
What is the release of the first microservice with the least cost? The smallest cost is the team size of 2-8 people, the time is 2-4 weeks, and the less expensive technology stack should be selected.
There is a feature switch when you do online segmentation of microservices. You must use this instead of branches. Moreover, it is important to emphasize single-trunk development. If you use branches, it means that there are branches and your code is coupled. Coupling proves that you can disassemble it. The worst thing is to give yourself an interface that does not do continuous delivery. You must go online quickly, quickly deploy to the production environment, rather than high in the test environment.
3.4 The code moves slightly, DevOps first!
It is easy for engineers to see the code and lead the code details, which is difficult and impossible to do. When you hear an excuse, there is no direction to the destination. If your organization is a separate organization between Dev and Ops, consult the Ops engineer first. It is best to have an Ops engineer in the microservice team. If you do not have the conditions to implement DevOps, the microservice architecture must start from the operation and maintenance side, not the development side.
To do DevOps is to do CLAMS. There must be measurement, there is no improvement without measurement. Automation means to automate everything except code submission and release. This is a requirement for the team. If the quality control is done well, the release can also be automated. There is no need for anyone to do any verification in the middle, and any verification can be solved by automation.
The key automations are listed. The first is automated testing, with functional and non-functional automated testing.
The second is automated infrastructure management, mainly infrastructure and code. If the infrastructure needs to be manually built, the speed of microservices will not meet the standard.
The third is automated deployment, not release. The deployment of microservices to the production environment still requires manual verification steps, because it is not very accustomed, and it is necessary to do this at the beginning.
Deployment is a technical action. You deploy the application on the production environment, while release is a business action, which is to determine which part of the user can see your microservice.
The fourth is automated monitoring and alarming. The automated monitoring and alarming of microservices is different from the previous monitoring and alarming. It is necessary to figure out how to bury the problem in advance.
Use Lean to find problems through visualization, and find various existing problems through Kanban. I won't say much about this, you can find relevant reference materials. To find problems through visualization, this problem is not an architectural problem, but a management problem. In the team, when there is a problem, it is everyone's. Build the concept of sharing and sharing, and don't blame others.
To create a complete DevOps culture, DevOps makes sense to say that it is a culture. There are four cultures: flexibility, communication, learning, and atmosphere.
DevOps has several core practices, the first is continuous delivery,
The second is infrastructure as code, which is used for resource allocation and resource orchestration.
The third is that the infrastructure is transparent to microservices.
I have encountered some situations where microservices and infrastructure code are placed in one code base. Each microservice has different infrastructure requirements. If changes are made, too many actions are involved. Don't put the entire infrastructure in one code base.
3.5 Continuous improvement, copy successful experience
What is the curse of knowledge? After you learn a piece of knowledge, you can no longer imagine your state as a beginner. After you finish the microservices, you go to teach beginners, the effect will not be very good. Therefore, at the beginning of microservices, it is better to keep a record of the various problems of microservices and give part of the successful experience to newcomers than to find someone who has experience in microservices to teach newcomers. Because if a very experienced person teaches a new person, he will be cursed with knowledge, and he will forget how he started as a beginner.
The key output that needs to be summarized to replicate successful experience, to achieve the end-to-end process specification from microservice development to release, it is best to be automated, and automation itself is a management system. The specification of the technical quality of the microservice development, the adherence to the best practices of cooperation in the team, and the summary of some problems should be continuously improved through retrospective meetings.
Finally, we need to cross-rotate the team. After there is a microservice team, some people will be removed from the middle to add newcomers, and we must adapt to the microservice culture. The microservice itself requires a relatively small team to simplify the entire deployment.
I want to meet and communicate with more colleagues, and I want to listen to more technical interpretations of experts
The DevOps International Summit is a brainstorming event
Let DevOps return to a more essential place, and further understand the spirit of DevOps