This is the third day of my participation in the August More text Challenge. For details, see:August is more challenging

Once the decision has been made to introduce a microservice architecture into the development practice, the challenge is to smooth the transition from the accumulated giant systems to microservice architecture.

The parts that architects most want to replace with microservitization are often the core of a company’s profitability, and are as difficult to retrofit as replacing an engine in flight. According to the public information of the industry, no one has achieved the perfect upgrade, but more likely there are two:

  • The first kind of reform after the survival, research and development is exhausted;
  • The other is the transformation of the direct shock.

Therefore, in order to enable the smooth application of microservices, the architect should never dream of an overnight success. There are three steps that can be taken.

Training first

Technical people are good at turning a problem into a technical problem and solving it in their own area of expertise. This creates a paradox: problems that can be solved by technology are not problems, real problems cannot be solved by technology alone in constrained scenarios, and the biggest obstacle to implementing microservices is not technology itself. From the experience of the same process microservices team, the biggest problem is not how to do microservices well, but how to reach a consensus on what microservices should be. Therefore, prior to implementation, a consensus can be reached through large discussions or training involving a large number of people. This is similar to naming conventions in coding conventions, where it doesn’t matter which naming method you use, as long as everyone uses the same naming method.

2. Strangler mode

The strangler mode refers to the system that cannot be improved by the fixer mode. The system is gradually stripped and refactoring by rebuilding new functions outside the system, and the function services are strangled one by one. The advantage is not to affect the original environment, once the conditions are ripe can quickly switch. The disadvantage is that it may take some time to maintain both systems and pay additional development and maintenance costs.



This pattern helps minimize the risk of migration and spreads the development effort over a period of time. Because the outer layer securely routes users to the right application, you can add functionality to the new system at your own pace while ensuring that the old application continues to run. Over time, functionality migrates to the new system, and the old system eventually gets suppressed and doesn’t need to exist. Once this process is complete, you can safely disable the older version of the system.

3. Proxy mode

Some systems that cannot be changed in the short term are allowed to access the micro-service platform through MicroProxy and entrust the Proxy to expose it as micro-service. The single architecture often has a huge service interface comb and often needs to open multiple Proxy Windows. Each proxy window is packaged and divided into microservices, which can be easily replaced with native microservices when conditions are ripe, called unbroker.