I was recently reading a book called Microservices Patterns. There is a section in the first chapter called “Above Microservices: Processes and Organizations.” I changed the position of organization and process here.

Microservices are more than just architecture

In today’s world of microservices, it is often the best solution for large or complex applications to adopt a microservice architecture. However, when we usually talk about micro services, we hear more about what technology to use, how to split services, how to solve the problems caused by the split, etc. In a word, more stay in the technical category.

But are microservices really just a matter of technical architecture? At least I don’t think so now!

Successful software development also requires some work on organizational, development, and delivery processes.

Why do we microserve

In my opinion, the original purpose of microservices is to solve various problems caused by the increasing number of single applications. The disadvantages of single applications are the advantages of microservices. Include:

  • Enables continuous delivery and deployment of large and complex applications
  • Each service is relatively small and easy to maintain
  • Services can be deployed independently
  • Services can be independently extended
  • Microservices architecture enables team autonomy
  • Easier to experiment and adopt new technologies
  • Better fault tolerance

With the rise of agile development and DevOps, it happens to coincide with many ideas in micro-service architecture, which increasingly shows the superiority of micro-service architecture. However, it is not easy to practice micro-service well.

Organizational dilemma

Most enterprises should continue to have a functional organizational structure, also known as a U-shaped organization, in which different functional personnel belong to different teams. For example, product, development, testing, operation and maintenance teams are independent of each other. To me, now the team due to the nature of the project, a greater use of r&d resource pool sharing method, the team’s early days, only the development and testing personnel, research and development efficiency is very high, but with the increase of functional teams, product, the PMO, r&d efficiency plummeted, project related people more and more, do not have a unified process chaos, Endless meetings, pointless discussions and so on all at once.

Butt determines head

Due to the different functions, goals and even performance standards of each functional post, they will consider and do things from their own standpoint, which is commonly known as butt decides head.

Butt head is often regarded as a derogatory term, to describe the vision is not open enough, the way of thinking is relatively single. Personally, I don’t think so completely. Sometimes you do something in a certain position, which doesn’t mean you have a small vision or poor ability, but you only have so much right to speak at present.

But because of the diversity of functions and the increasing size of organizations, the head of the ass does have a negative impact on the r&d process.

  • Product: the business doesn’t even know what it wants. R&d is always bargaining. That’s what the business needs.
  • Research and development: the requirements of products are technically difficult and the business process is unreasonable. Testing requirements do not understand, opinionated put forward a lot of improvement advice, in the end is a product or testing.
  • Test: r & D development of things is the use of people, but also do not cooperate with the test, raised a bug along while did not respond.
  • Operation and maintenance: frequent version releases have affected the stability of the online environment, and there will be problems with each version release, and I don’t know how to measure the test.

The above scenario happens all the time at work, wrong? I don’t think so, but different functions, KPI orientation and interests lead to different goals.

Even within r&d, there are conflicts between the front and back end teams because of the gray area of division of labor, such as who should design the interface, whether a certain verification should be done on the front end or the back end, etc., which I have experienced personally.

High communication costs

When a requirement needs to be addressed, people are drawn from various departments to form temporary project teams. When the project is completed, people are returned to their respective organizations. There is one major problem with such an organizational structure: high communication and coordination costs.

Such as:

  • Project team members need to be familiar with each other and coordinate;
  • When encountering problems, it is difficult to communicate. If point-to-point communication, it will bring a lot of problems. It would be too costly to organize everyone in everything.

The feedback link is long

Communication costs are too high and demand moves slowly. Requirements go through layers of hoops from the product team to the operations team. On the other hand, when production problems occur, the process of feed-back from operations to products is also slow. If this is compounded by the fact that the boundaries between departments are not clear, it is worse to pass the buck to each other.

Divide and conquer

There’s a famous law in organizational division, Conway’s Law:

Organizations that design systems are often limited by the structure of the organization, and the result of the final design is a copy of the communication structure of those organizations. — Melvin Conway

The structure of an application often reflects the structure of the development organization behind it, so apply Conway’s law in reverse and design the enterprise organization so that its structure corresponds to the architecture of microservices. By doing so, you ensure that the development team is as loosely coupled as the service.

According to Fred Brooks in his book The Myth of the Man-Month, communication costs rise O(N ^ 2) with the size of the team. If the team is too large, the efficiency of the team will be reduced due to the high communication cost. Imagine if there were 20 people standing every morning.

The problems arising from the continuous expansion of single application and traditional functional organizational structure are basically the same. The solution to the problems of single application is micro-service, while the solution to the problems of functional organizational structure is still divide and rule, dividing large teams into multiple small teams.

There are no specific requirements for the size of the team, the most famous of which is Amazon’s two pizza teams principle. Each team has a clear responsibility: to develop and operate one or more services that implement one or more business capabilities.

The most important is that these teams are cross-functional, including product, RESEARCH and development, testing personnel and so on, and can handle user interaction UI design, background service development, database management, service operation and maintenance. They do analysis, development, testing, deployment, and other tasks independently without having to constantly communicate and coordinate with other teams.

Borrow the image below:

Small team internal staff can achieve the same goal, there is no butt not together to cause the ideological disunity, because the staff is basically fixed, can cultivate the tacit understanding between the team, the efficiency of internal communication can also achieve the highest. Well-run teams can even achieve a degree of “autonomy” without external coordination intervention.

Of course, there is no perfect “silver bullet” to solve the problem, and we have to face some emerging problems:

  • Management and coordination problems after too many teams
  • The problem of unbalanced team load
  • There used to be only one portal for connecting services, but now there may be more
  • Teamwork issues

Each of the above questions may have different answers in different enterprise environments and different team atmospheres, or even cannot be completely solved. But I don’t think it’s wrong to split small teams to improve efficiency and flexibility. More importantly, we need to explore the answer according to local conditions.

Process dilemma

Imagine a microservices architecture with traditional waterfall development. Here’s how the book describes it:

With a microservices architecture, continuing with a waterfall development process is no different than using a Horse-drawn Ferrari — we need to take advantage of the convenience of microservices.

Imagine a cascade of development processes: requirements analysis, software design, programming, software testing, operations and maintenance.

  • The division of the phases is completely fixed, and the amount of documentation generated between the phases can greatly increase the workload.
  • Since development is linear, users will only see the results at the end of development, increasing the risk.
  • Early mistakes can have serious consequences when they are found in final testing.

The whole process is also interspersed with a variety of cross-functional meetings organized by the project manager, project approval meeting, requirements meeting, review meeting and so on; Each communication is a large group of people in the debate can not reach a result; Even a week’s demand is there to discuss procedures and norms with you. Teams and individuals are stuck in a bog and can be summed up as inefficient teams.

Microservices break up business modules and teams break up small cross-functional teams for quick feedback and output, and the waterfall process, as its name suggests, is Niagara Falls in front of you when you’re ready to pack light.

Agile development

Adopting agile development and deployment practices such as Scrum or Kanban is essential if you want to develop an application using a microservices architecture.

The core idea of agile development is to iterate gradually and quickly, focusing more on people and the team. The values of Agile development are:

  • The subjective initiative of programmers, and the interaction between programmers, is superior to established processes and tools.
  • Software works better than detailed documentation.
  • Close collaboration with clients is better than contract and negotiation.
  • Able to respond to change, better than following a plan.

Now that microservices are popular, I think Agile is more suitable for it.

Microservices, processes, and organizations

Here’s a diagram of the three from the book:

Fast, frequent, and reliable software delivery for large and complex applications requires several key DevOps capabilities, including continuous delivery and continuous deployment, small autonomous teams, and microservices architectures

Microservices architecture is technically easy to implement, but the process and organizational support behind it needs to be constantly explored and practiced. In this respect, all the books are theoretical foundations that must be adapted to the circumstances, and this is not an easy task. But anyway, I’m willing to go with the flow.