Shulou(Shulou.com)06/02 Report--

Introduction: the most important benefit of micro-service architecture is that it can achieve the continuous delivery and deployment of large and complex applications. Continuous delivery and deployment are part of DevOps, a set of fast, frequent, and reliable software delivery practices. High-performance DevOps organizations often face fewer problems and failures when deploying software to a production environment.

For large and complex applications, micro-service architecture is often the best choice. However, in addition to having the right architecture, successful software development requires some work in terms of organization, development, and delivery processes.

Figure 1 shows the relationship between architecture, process, and organization:

Figure 1. Rapid, frequent and reliable delivery of software for large and complex applications requires several key DevOps capabilities, including continuous delivery and deployment, small autonomous teams, and micro-service architecture

1. Organization for software development and delivery

Success often means the expansion of the R & D team. On the one hand, this is a good thing, because there are many people and great strength. But when the team gets bigger, as Fred Brooks mentioned in the Myth of Man and Moon, the cost of communication increases at an O (N ^ 2) rate with the size of the team. If the team is too large, the efficiency of the team will often be reduced due to the high cost of communication. Think about it. What would happen if the size of the station reached 20 people every morning?

The solution is to split the large team into a series of small teams. Each team is small enough, with a staff size of 812 people. Each team has a clear responsibility: to develop and may also be responsible for the operation and maintenance of one or more services that implement one or more business capabilities. These teams are cross-functional. They can perform development, testing, and deployment tasks independently without frequent communication or coordination with other teams.

Inverse Conway's law

In order to deliver software effectively when using a micro-service architecture, you need to consider Conway's law, which states the following:

The organization that designs the system. It is often limited by the organization's structure, and the end result of the design is a copy of the communication structure of these organizations.

(Melvin Conway)

In other words, the architecture of an application often reflects the structure of the organization that developed it. Therefore, apply Conway's law in reverse and design your enterprise organization so that its structure corresponds to the architecture of micro-services. By doing so, you can ensure that your development team is as loosely coupled as the service.

Several small teams are obviously more efficient than a single large team. The micro-service architecture allows the team to achieve some degree of "autonomy". Each team can develop, deploy, and operate to extend the services they are responsible for without having to coordinate with other teams. Furthermore, when there is a service failure or does not meet requirements such as SLA, the corresponding responsible person (team) is also very clear.

Moreover, the development organization is more extensible. You can expand your organization by adding teams. If a single team becomes too large, break it up and associate it with the services for which they are responsible. Because teams are loosely coupled, you can avoid the communication overhead of large teams. Therefore, you can add people without affecting your productivity.

2 the process of software development and delivery

After adopting the micro-service architecture, if we still follow the waterfall development process, it will be no different from using a horse to pull a Ferrari sports car-we need to make full use of the convenience of micro-services. If you want to develop an application through a micro-service architecture, it is essential to adopt agile development and deployment practices such as Scrum or Kanban. At the same time, it also needs to actively practice continuous delivery and continuous deployment, which is a key part of DevOps.

Jez Humble defines continuous delivery as:

Continuous delivery enables safe and rapid delivery of all types of changes, including new features, configuration changes, bug fixes, and labs, to the production environment or users in a sustainable manner.

A key feature of continuous delivery is that software is always deliverable. It relies on a high level of automation, including automated testing. Continuous deployment takes continuous delivery to a new level in the process of automatically deploying code to a production environment. High-performance organizations that implement continuous deployment deploy to the production environment multiple times a day with much fewer production disruptions and can recover quickly from anything that happens. The microservices architecture directly supports continuous delivery and deployment.

Move fast without screwing things up.

The goal of continuous delivery and deployment (and more generally, DevOps) is to deliver software quickly and reliably. Four useful indicators for evaluating software development are as follows:

Deployment frequency: how often the software is deployed to the production environment.

Delivery time: the time from when the developer commits the change to when the change is deployed.

Average recovery time: the time it takes to recover from production environmental problems.

Change failure rate: the percentage of changes committed that caused production environmental problems.

In traditional organizations, deployment frequency is low and delivery time is long. In particular, developers and operators usually stay up until the last minute during the maintenance window. By contrast, DevOps organizations often release software, usually several times a day, with much fewer production environment problems. For example, Amazon deployed code changes to a production environment every 11.6 seconds in 2014, and a software component of Netflix took 16 minutes to deliver.

3 Human factors in the adoption of micro-service architecture

After the adoption of micro-service architecture, not only the technical architecture has been changed, but also the organizational structure and development process have been changed. In the final analysis, this is a series of changes to people in the work environment (as mentioned earlier, emotional creatures). If you ignore people's emotions, then the adoption of micro-service architecture will be a very complicated and troublesome process. Mary, FTGO's chief technology officer, and other management are facing the challenge of how to change the way FTGO software is developed.

The best-selling book Managing Transitions introduces the concept of transition, which explains how people react emotionally to change. It includes the following three stages.

1. End, lose and give up: when people are told of a change that pulls them out of their comfort zone, such emotions begin to breed and spread. People will talk about the benefits of losing them. For example, when reorganized into a new cross-functional team, people miss their former colleagues. For example, for the team responsible for global data modeling, each service team is responsible for its own data modeling, which is a threat to them.

two。 Neutral zone: in the process of dealing with the transition between the old and the new, people are generally at a loss about the new way of working. People begin to struggle and have to learn how to deal with new jobs.

3. New beginnings: in the final stage, people begin to enthusiastically embrace new ways of working from the bottom of their hearts and begin to experience the benefits of new ways of working.

Summary

The single architecture pattern builds the application as a single deployable unit.

The micro-service architecture pattern decomposes the system into a set of services that can be deployed independently, each with its own database.

Single architecture is a good choice for simple applications, while micro-service architecture is usually a better choice for large and complex applications.

The micro-service architecture enables small autonomous teams to work in parallel, thus speeding up software development.

Microservice architecture is not a silver bullet: it has many drawbacks, including complexity.

The microservice architecture pattern language is a set of patterns that can help you build applications using the microservice architecture. It can help you decide whether to use a micro-service architecture, and if you choose a micro-service architecture, the pattern language can help you apply it effectively.

You need more than just a micro-service architecture to accelerate software delivery. Successful software development also requires DevOps and small, autonomous teams.

Don't forget the human aspect of adopting microservices. You need to consider the emotions of your employees in order to successfully switch to a micro-service architecture.

This article is extracted from "Micro Services Architecture Design pattern" and published under the authorization of the publisher.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.