The author | juven xu Ali cloud senior technical experts

Introduction: How to improve delivery speed with cloud native technology? Under the background of cloud native era, what changes will the focus of R&D be? Through this article, Xu Xiaobin, senior technical expert of AliYun, shares the evolution direction of application architecture from the cloud era on IaaS to the cloud era on PaaS, and the relationship between cloud native technology and application architecture evolution.

Cloud native has entered the cloud-dominated phase on PaaS

Alibaba has gone through the phase of IaaS on cloud and entered the era of PaaS on cloud. In last year’s “Double 11”, Alibaba has realized the full cloud of e-commerce core system, the cloud here is mainly in the IaaS layer. The so-called IaaS is mainly the virtualization of computing, network and storage. After this stage, Alibaba has entered the stage of cloud on PaaS. In the PaaS cloud phase, more cloud products are needed, including middleware, storage, caching and even application hosting platforms.

There is a big difference between IaaS phase and PaaS phase. In IaaS, for application development, the focus is often on infrastructure and resources, generally speaking, virtual machines or containers, etc., with little or no intrusion into the application architecture. However, in the PaaS cloud phase, when you use cloud products such as Cloud Redis, cloud RDS, cloud OSS, cloud RabbitMQ, etc., there will be a strong intrusion into the application architecture. What impact this intrusion will have on application architecture is a question for all r&d architects to ponder.

Cloud native technology

If you try to search for Cloud native technology, you’ll see Google Cloud’s definition, CNCF’s definition, and many other Cloud vendors’ and open source software definitions, all of which have different opinions. It can be divided into several categories as shown in the figure below. Vertically, it can be divided into four dimensions: application architecture, life cycle management, traffic management, and infrastructure and dependency. Horizontally, it is divided into microservices, 12 Factor Apps, containers, BaaS, GitOps/IaC, and Service Mesh.

Today, everyone talks about doing cloud native based on microservices architecture, not based on Boulder application architecture or simple CS architecture. Quarkus put forward 12 Factor Apps, which means that if you want to run an application on Quarkus and other application hosting platforms today, there are certain requirements for the application, about 12 principles, such as configuration and code separation, of course, there are many extensions in the future. Many of these principles mean that as long as you follow these principles, the application hosting platform can provide you with more capabilities, such as operation free. The core of the container is a standard interaction that allows the platform to manage the application lifecycle, including release, expansion, and self-healing.

BaaS — Backend as a Service can build applications using existing services as much as possible. The essence of a Service Mesh is to manage traffic. Today’s applications receive traffic and need to export traffic when providing services. In this process, Service Mesh technology is required to manage Service discovery and traffic routing rules. Finally, GitOps and IaC (Infrastructure as Code) are highlighted. These technologies are getting more and more attention in the industry today. Although there is no de facto standard, many cloud computing companies are working on it. The implication is that when you use infrastructure today, you can use code to declare the requirements of that infrastructure. To sum up, the above content is all around the four dimensions of application architecture, lifecycle management, traffic management, and infrastructure and dependency.

The business cares about speed of delivery

For the business, the primary concern is often speed of delivery. If you talk to a business director or a CTO, they’ll ask you, what’s the benefit of having so much technology for the business? Cost advantages and management advantages may be discussed, but for almost all businesses, the core is the improvement of R&D efficiency. So we should think about how cloud native technologies can help achieve faster delivery.

Leveraging cloud native technologies to speed up service delivery can be roughly divided into three steps.

1. Standardize protocols for platforms/services and applications

Standardize protocols between platforms/services and applications. If IaaS layer uses cloud, the protocol is machine, such as virtual machine, container, etc. For business applications, it is an operating system. In this way, applications can use various resources on the operating system. The advantage of this method is that they do not need to worry about the faults of physical machines and machines.

2. Business-independent capabilities are further decoupled to the platform

For business applications, see, it is not an operating system, will give to a more upper protocol, to help the application platform to achieve automatic scaling and self-healing, etc., can also help the application of automatic crag, failure occurs when the underlying infrastructure, application can be migrated from one machine to another machine, also is the life cycle management. With these protocols, many of the capabilities of the platform can be sunk. For example, things that would otherwise need to be managed manually can be done with code declarations. With these protocols, business applications can host the related lifecycle management to the platform.

3. Upgrade the application architecture

In addition to the above two points, the third step is to make the application architecture need to be upgraded to accommodate so that the relevant capabilities can sink to the cloud platform.

IaaS on-cloud phase to cloud native phase

Further refinement shows that in the original Cloud phase of IaaS, besides business logic, life cycle management and flow management of business applications need to be concerned, and middleware needs to be set up and configured, such as Redis and Kafka in the cloud environment. That means spending a lot of time on application dependency management and not getting the cloud platform to manage it. Today, in the phase of cloud on PaaS or cloud on cloud native, what we want to do is to try to use the capabilities provided by the cloud platform, focus more on the business itself, and leave the general technical capabilities irrelevant to the business to the cloud to manage.

Core issues:

How are business-independent capabilities decoupled to the platform?
How is the protocol between the platform and the business (application) defined?
How does the application architecture fit in?

In the cloud phase of IaaS, where there was a standard protocol for applications to interact with the operating system, what that protocol should be today in the cloud phase of PaaS needs to be redefined. In addition, how to achieve capacity sinking based on such protocols is also what many cloud vendors, including Ali Cloud, do. For example, Ali Cloud makes RocketMQ Service based on RocketMQ, and provides container services based on some container protocols. Of course, this is just the beginning, and this section will be much richer and more complete in the future.

Example 1: Service Mesh separates Service discovery and traffic from the business

At the same time, the application architecture needs to adapt. Here we take Service Mesh as an example. Previously, the traffic within an application was in the form of SDK. In the process of evolution, how to separate Service discovery and traffic from the Service SDK into Sidecar and hand it over to the cloud platform for processing is an example of application architecture evolution.

Service registration & discovery
Flow routing
Traffic replay
Traffic control during publication

Example 2: Lightweight container takes log collection out of business

Before collecting logs, you need to enable a log collection process on each VM and send the collected logs to the log collection platform for analysis on a visual interface. Today, in the cloud native era, it is better to have the container service fetch logs from STdout or configure it to fetch log data from a specific log directory. However, the collection needs to be moved to Sidecar to upgrade the Agent. So the lightweight container taking log collection out of the business is also an example of architectural evolution.

Resource isolation
Independent upgrade

Example 3: The business provides probes that enable the platform to implement lifecycle management

The requirements of lifecycle management for application architecture are that whether the original application is healthy or unhealthy after startup is the responsibility and concern of application operation and maintenance or r&d. However, in the cloud native era, it is hoped that the protocol can be fixed and the business can provide probes to determine whether the application is healthy or unhealthy. In this way, the health information needs to be provided inside the application through HTTP protocol or Shell, so that the application lifecycle management can fall into the platform.

Automatic elastic
Automatic bottle cap
Automatic restart (self-healing)

Contract =API+Configuration

Overall, the protocol is API+ configuration. In terms of apis, if people use caching, they will basically treat open source protocols as apis, and such protocols are usually more friendly than closed source protocols. For RPC protocols, the open source GRPC and DUBBO are superior to the proprietary HSF. In addition, there are protocols for infrastructure, such as Terraform and Pulumi. These are actually defining an open source configuration language, which can help declare the required infrastructure, such as containers, disks, networks, storage, etc. Although there are many configuration languages nowadays, But in the future there will eventually be one or two languages, just like the SDK for Java, there will inevitably be an SDK for cloud resources in the future, and this SDK will inevitably be built on a set of configuration coding languages. Further, GitOps et al. have defined the publishing process and publishing strategy as a language that will be the standard protocol between applications and the cloud in the future.

Docker (& OCI) is a standard software delivery API;
As an RPC protocol, the open source GRPC/DUBBO is superior to the proprietary HSF;
As a caching protocol, open source Redis is superior to proprietary Tair;
Microsoft’s Dapr attempts to standardize apis on the HTTP/GRPC layer based on the Sidecar architecture to go to the SDK, and supports multiple languages;
IaC products such as Terraform and Pulumi declare infrastructure through configuration languages;
GitOps further uses code to declare the environment, release process, and release policy content.

A shift in r&d focus

There are so many things that applications need to care about, such as SDKS and operations events, but these things can actually be abstracted into a model and defined in a new language, which is what the cloud industry is all about.

The emphasis is always on new languages and protocols because that is all the application needs to care about once a new language or protocol is defined. For developers, the most important thing is code, and if you can use code to describe your application’s infrastructure, operations, and hosting requirements, it’s very application-friendly. The application only needs to be able to connect to this protocol, so it can run on the private cloud, the public cloud, and ali Cloud simultaneously.

conclusion

In the future, there will be more and more resources on the cloud. On top of the infrastructure, the cloud platform provides more PaaS capabilities, just like the operating system provides processes on top of these capabilities, as well as many SDKS. However, the use of these capabilities is still very inefficient and non-standard, and the use process is more troublesome. Today we use the cloud in assembling-like form, and cloud native is redefining the contract between applications and the cloud platform, and building higher-level programming languages and tools around it. This is a very important direction of application architecture evolution in the cloud native era.

Click to view the cloud native architecture white paper: developer.aliyun.com/topic/cn-ar…

“Alibaba Cloud originator focuses on micro-service, Serverless, container, Service Mesh and other technical fields, focuses on the trend of cloud native popular technology, large-scale implementation of cloud native practice, and becomes the public account that most understands cloud native developers.”

How will application architectures evolve in the cloud native era?