Summary: Starting today, we are launching a new column: 36 Ways to Improve R&D Performance — Continuous Delivery. The column will be a 10-20 article system to share the cloud native era, enterprises how to land sustainable delivery.

Editor’s note: Starting today, we’re launching a new column: 36 Ways to Improve R&D Performance — Continuous Delivery. This is the first of 10-20 articles on how systems share the cloud native era and how enterprises can land and deliver.

Dora’s annual DevOps 2018 report provides a set of metrics for software delivery effectiveness to measure the level of software delivery in an enterprise.

• Deployment frequency. Refers to how often an application deploys changes to production. If you deploy every day, 10 times a day, once a day, or only once a month.
• Change the lead time. This is the time from code submission until deployment is up and running in production.
• Service recovery time. It is the time between service interruption and the next time the service can be resumed.
• Change failure rate. This is the ratio of failed changes to the production environment, how many total changes were made, and how many of them were failed.

As you can see, “elite” teams deploy almost as often as they want — they can post whenever they want. By comparing “inefficient” with “elite” and comparing our own teams, we can see which quadrant we belong to, elite, inefficient, efficient, or medium effective.

Of course, when it comes to change failure rates, some students will say, “I’ve been successful every time I’ve released, I’m 100 percent.” In fact, it is difficult to complete the release process in one go without any intervention, repair or rollback afterwards.

When communicating with many business teams, including students from outside companies, we found that no matter CTO, CIO, or front-line R&D personnel, everyone was faced with a problem: “I want to change”, “I want to do well”, “I want to be elite”, but actually it was difficult to do so. Why is that?

Because:

1. Management costs are getting higher and higher. More people, more administrative costs, more complex collaboration, more time spent in meetings than in work.

2. Technology debt is also getting higher. In real production, businesses often don’t give you a lot of time to get it right from the start. Hence “I’ll get the business going anyway.” But maybe after a year or two, you’ll find it can’t run anymore. This situation is called rough and fast in Internet entrepreneurship. When technical debt gets higher and higher, you have to pay it back with interest if you want to do something else.

3. It is very difficult to introduce new technologies. There are some good technology because of the cost of personnel problem, can not find very good people. In addition, some technologies have high barriers to entry and require complex skills.

Moreover, the change of software delivery form also poses a challenge to software delivery efficiency.

1. Continuous product delivery requires a higher software development model

There used to be milestones in software delivery, but now we want something new to come out every day, not to hit a few milestones, or to come out in three months or two years. We want software delivery to happen continuously and incrementally.

Take telecom equipment as an example. The delivery, development and production environments of telecom equipment are disconnected. In other words, the cost of doing a release and implementation is extremely high.

At this point, continuous delivery puts forward higher requirements for software development model. It is impossible to plan for a long time and then wait six months or two years for an integration to be delivered and implemented. It requires that you have something coming out of each iteration.

2. Continuously upgraded services put forward higher requirements on availability

When the software can be continuously released and upgraded, the usability of the software will be correspondingly put forward higher requirements, and can not be broken easily. To the customer, what he sees is one of your services, he feels the service you provide, so your service needs to be very high availability.

3. Continuous delivery requires efficient assurance of product quality

Quality is very important to continuous delivery. When the product is released online, if there is a quality problem, it is easy to lead to failure, and even cause the company to come out to do public relations. There have been many examples of this in recent years.

As the saying goes, where there is challenge, there is opportunity. Specifically, in the cloud native era, we face two major opportunities to improve software delivery efficiency.

Opportunity 1: Technology is driving the evolution of application and deployment architectures

(1) Evolution of application architecture

We will find that technology is actually driving the evolution of our application architecture and deployment architecture. From a resource perspective, we used to do cloud hosting, then cloud optimization, and now cloud native. We’ll see some changes in resources, but also in application architecture — from monolithic applications to Severless. That is to say, from getting closer and closer together, to gradually becoming more and more apart, smaller and smaller.

(2) Evolution of deployment architecture

From a deployment architecture point of view, we can also see some changes from physical machines to BaaS/FaaS.

This evolution has also made our overall delivery more flexible and decoupled, allowing us to deliver on demand, even allowing engineers to focus more on business logic.

Opportunity 2: The rise of cloud infrastructure and cloud native technologies

(1) The cloud infrastructure is getting higher and higher

Cloud infrastructure is becoming increasingly abstract. Back in ’13, all we knew about cloud infrastructure was infrastructure. But with the rise of containers, we saw container platforms, and then we had PaaS, and we didn’t have to worry about message queues, storage, monitoring, etc. Now, with Serverless, we almost don’t have to write the back end, the entire application back end is in the cloud. All you have to do is write the business logic, almost the front-end business logic. I only have to pay for the usage of back-end services.

(2) K8S becomes the de facto standard and cloud native becomes the trend

From K8S to the present CNCF, we will find that K8S is now a de facto standard. People are no longer debating whether to do cloud native, the question is how.

(3) In the context of microservitization, the demand for service governance is increasing

Everyone is talking about micro-services, but micro-services bring a lot of problems that they didn’t have before. One of the typical problems is service governance. Too many services, how to conduct service governance, how to do service discovery, load balancing, capacity scheduling and so on, all kinds of problems come. So everybody’s appeal to service governance becomes more and more big.

At the same time, the greater the number of services, the greater the complexity. For example, if the availability of a service is 99.9%, 10 nines add up to 99.9% to the power of 10. In addition, its own complexity will increase. For example, the communication between two people is very simple, but when three people communicate, I have more links. Coupled with network communication between distributed services, all kinds of exceptions can occur. These are very real problems and they cost us a lot.

In summary, software delivery is very different today than it was before.

In the cloud native era, we need a continuous delivery model to achieve faster and higher quality software delivery.

Most of the time, however, the concept is beautiful and the landing is painful in all sorts of ways.

In cloud native era, how should we land and deliver continuously? Next, through a series of articles, we will comb through a series of practices for continuous delivery in the cloud native era. Stay tuned.

The original link

This article is the original content of Aliyun and shall not be reproduced without permission.