One, foreword

The previous article briefly examined the benefits of microservices, as well as the problems they can bring.

Encountering problems is not terrible, terrible is that we do not face it, do not think of a way to solve it, escape the problem is impossible to make any progress. So actively find ways to deal with the problem and solve the problem, in order to continue to progress.

As mentioned above, microservices generally evolve from a single unit, and few businesses start microservice development from zero. It’s a good thing to start microservice development from zero, as long as you really think about how microservice development fits your current business and the needs of your business.

So the question is, when will companies introduce microservices?

Second, when will enterprises introduce micro-services?

Reason for introduction:

Single application can not meet the needs of business growth, business delivery, business reliability, stability requirements, as time goes by, problems will be more and more. — that is, some of the previous problems

But also some people, not from the company business development, development costs, development efficiency to consider the problem, but what development conference saw many companies micro service of speech, or hear a lot of companies in the service, from these aspects to consider, which is going with the flow, this way of thinking is clearly not correct ways of thinking. Don’t microservice for microservice’s sake. The benefits of using a microservice must be greater than that of a single application, and it must be able to solve the problems encountered.

To upgrade from a monolithic architecture to a micro-service architecture is to improve research and development efficiency, shorten the construction period, and speed up product delivery.

What’s the difference between them in terms of specific productivity?

According to this article by Martin FowlerThe article”Reveals the relationship between productivity and complexity.

When complexity is low, individual applications are more productive, and microservice architectures reduce productivity. However, when complexity reaches a certain scale, the productivity of the system can be reduced, whether using monolithic applications or micro-service architectures. The difference is that the productivity of individual applications starts to decline sharply, while the micro service architecture can mitigate the productivity decline. The diagram below:

The X axis is system complexity, and the Y axis is development productivity

  • Green represents single application
  • Blue represents the micro-service architecture

There is a point where monolithic applications and microservices intersect, where productivity of monolithic applications declines sharply and productivity of microservices declines gently, and their productivity starts to diverge.

This point is the point at which a monolithic application switches to a microservice.

But the problem is that this point in time, the article does not specify when it will occur, how to measure this point in time. Therefore, it can only be analyzed on a company-by-company basis, and the technical leader should consider and judge this point in time. It’s also a time to think about technical leadership. But there are some elements to consider:

  • Business perspective

    • Whether business requirements development is often delayed
    • Is product delivery keeping pace with business development

  • Research and development of quality

    • Whether the code is often buggy due to changes
    • The code is bloated and bulky

  • Technical personnel

    • You have the skills, you have the will

    • The number of team

      And so on some considerations, in addition to the previous single application of some problems.

After thinking it through and deciding to introduce microservices, what are the problems?

III. How will the organizational structure change?

Conway’s law

Conway’s Law is
Marvin ConwayProposed in 1967:


The architecture of the design system is constrained by the communication structure of the organization that produces these designs.

Conway’s Law tells us that if we implement a microservice, then the change in the organization structure must be adjusted accordingly. In this way, it is possible to adapt to the development of micro-services.

Single architecture and micro-service architecture

Let’s take a look at the traditional monolithic architecture and micro-service architecture, as shown below:

Image from:
https://martinfowler.com/arti…

Single architecture diagram in the left half: Single application to put all the functionality in a process: Scaling by copying the entire application to a polymorphic server

Micro-service architecture diagram in the right half: Micro-service architecture separates functions into multiple different processes and scales them by distributing different services across different servers and replicating them as needed

Organizational structure

  • Organizational structure of individual applications:

Image from:
https://martinfowler.com/arti…

It is an integrated application team, and each team is divided by function (left half of image), such as UI team, middleware team, and DBA team.

People with different functions belong to different teams. When you’re working on a project, select people from different functional departments to be responsible for the project. One problem with such an organizational structure is the problem of cross-functional communication and coordination. This form of team organization does not fit the characteristics of a microservice architecture.

  • Microservice application organization architecture

Image from:
https://martinfowler.com/arti…

Microservice architecture features: each microservice is independent, the team can develop independently, test independently, deploy independently, and the service is autonomous. Corresponding team members also have products, technologies and tests. Team members can develop various functions of micro-services completely within themselves.

This is to break the traditional form of organizing a team by function, and to organize people with different functions in a team to form a cross-functional product organization structure. In this way, a microservice function can be architected, designed, developed, tested, deployed, and put online within an organization to form a complete closed loop of business, development, and delivery.

Changes in team organization

A picture is worth a thousand words:

Image from:
https://insights.thoughtworks…

What had been a functional team became a small cross-functional team that aligned itself with the microservice architecture.

How many members are appropriate for each team? Amazon’s “two pizza teams” are 6-10 people in size. This is just a reference, after all, each company is different in size, business, industry, members, etc., so finding a suitable team composition is the best team organization.

Note: the above picture invasion delete, please contact the home page mailbox!

Fourth, infrastructure construction

The infrastructure construction here refers to the automated delivery pipeline based on CI/CD, and finally the goal of building DevOps to automate the entire R&D process from development, testing, pre-release, online, operation and maintenance.

With the gradual construction of micro-service, the number of services increases, and the number of online services will inevitably increase. Frequent delivery will lead to more failures. Therefore, we must build an automated tool chain to help us deliver services quickly and correctly and implement micro-service projects well.

How do you build your first microservice project

  • The first is that you have a new project and you can design the microservice architecture from scratch.

  • The second kind: the reconstruction of the old project, which can also be divided into 2 categories:

    1. Start to test the water from a small scope of the project, and carry out renovation.
    2. Completely refactor the project – This is not generally recommended. Because not only the old project needs to be maintained, but also the new demand what to do? Should old projects stop demand development, or should new and old projects be added together, which will waste manpower and fail to keep up with business development without adding technology? These are risks that need to be weighed.
  • Third: Start with small projects that are marginal. This kind of project demand development is generally not urgent, the project is small, relatively independent, less coupled with the existing system, and can be completely restructured. Implement microservices from such small projects and build step by step to reduce risk. After rich experience, I will gradually transform other projects. This is a compromise, not a “shock treatment”.

Six, reference

  • https://martinfowler.com/articles/microservices.html Microservices
  • https://martinfowler.com/bliki/MicroservicePremium.html
  • https://insights.thoughtworks.cn/management-of-microservices-team/ micro organization and management of a small team of service clusters