Introduction: What is the difference between IaaS on the cloud and PaaS on the cloud? How to use cloud native technology to increase the speed of delivery? Under the background of the cloud native era, what changes will the focus of research and development be? Alibaba Cloud senior technical expert Xu Xiaobin uses this article to share the evolution direction of application architecture from IaaS to the cloud era to PaaS, and the relationship between cloud native technology and application architecture evolution.
Cloud native has entered the stage of PaaS cloud-based
Alibaba has gone through the stage of IaaS going to the cloud and entering the era of PaaS going to the cloud. In last year's "Double 11", Alibaba has realized the full cloud access of its e-commerce core system, where cloud access is mainly at the IaaS layer. The so-called IaaS mainly refers to the virtualization of computing, network, and storage. After this stage, Alibaba has entered the stage of PaaS to the cloud. At the stage of PaaS going to the cloud, more cloud products need to be used, including middleware, storage, caching and even application hosting platforms.
There is actually a big difference between the IaaS phase and the PaaS phase. In the IaaS stage, for application research and development, the concerns are often infrastructure and resources, generally speaking, virtual machines or containers, which have almost no intrusion into application architecture. But in the PaaS cloud phase, when you use cloud products, such as cloud Redis, cloud RDS, cloud OSS, cloud RabbitMQ, etc., it will have a relatively strong intrusion into the application architecture. Then, what kind of impact such an intrusion will have on the application architecture is a question that all R&D architects need to think about.
Cloud native technology
If you try to search for cloud native technologies, you will see the definition of Google Cloud, the definition of CNCF, and the definition of many other cloud vendors and open source software, and these definitions have different views. A simple summary can be divided into the following categories as shown in the figure below. From a vertical perspective, it is divided into four dimensions: application architecture, lifecycle management, traffic management, and infrastructure and dependencies; horizontally, it is divided into microservices and 12 Factors. Apps, containers, BaaS, GitOps/IaC and Service Mesh dimensions.
Today, everyone will talk about cloud native based on microservice architecture, rather than based on Jushi application architecture or simple CS architecture. Quarkus proposed 12 Factor Apps, which means that if you want to run applications on Quarkus and other application hosting platforms today, there are certain requirements for applications, probably 12 principles, such as configuration and code separation, of course, follow-up There are many extensions. Many items in these principles mean that as long as you meet these principles, the application hosting platform can provide you with more capabilities, such as free operation and maintenance. The core of the container is to use a standard interaction method to allow the platform to manage the life cycle of the application, including release, expansion, and self-healing.
BaaS-Backend as a Service, able to use existing services as much as possible to build applications. The essence of Service Mesh is to manage traffic. Today's applications are receiving traffic, and traffic needs to go out when providing services. In this process, how to manage service discovery and traffic routing rules requires Service Mesh technology. The last thing that needs to be highlighted is GitOps and IaC (Infrastructure as Code). These technologies are now getting more and more attention in the industry. Although there is no de facto standard, many cloud computing companies are constantly working hard. The meaning is that when using infrastructure today, you can use code to declare the needs of these infrastructures. All in all, the above-mentioned content revolves around the four dimensions of application architecture, life cycle management, traffic management, and infrastructure and dependencies.
The business cares about delivery speed
For business, the most concerned thing is often the speed of delivery. If you talk to a business director or CTO, they will ask you, what are the benefits of having so much technology for the business? It may talk about cost advantages and management advantages, but for almost all businesses, the most important thing is the improvement of research and development efficiency. So we should think about how cloud native technology can help achieve faster delivery.
Using cloud native technology to improve the speed of service delivery can be roughly divided into three steps.
Standardized platform/service and application protocol
Standardize the agreement between the platform/service and the application. If the IaaS layer uses the cloud, the protocol is the machine, that is, the virtual machine, container, etc. For business applications, what you see is an operating system, so that the application can use various resources on the operating system. The advantage of this is that it does not Need to care about physical machines and machine failures.
Further decoupling of business-independent capabilities to the platform
For business applications, what you see is not an operating system. A higher-level protocol will be given, allowing the platform to help the application realize automatic scaling and self-healing, etc. It can also help the application realize automatic move, when the underlying infrastructure occurs When a failure occurs, the application can be migrated from one machine to another, which is life cycle management. Based on the above agreements, many capabilities of the platform can be sunk. For example, things that originally need to be manually managed can be implemented well only through code declarations. With these agreements, business applications can manage related life cycle management Give the platform.
Application architecture upgrade
In addition to the above two points, the third step is to allow the application architecture to adapt through upgrades, so that related capabilities can sink to the cloud platform.
IaaS transition from the cloud phase to the cloud native phase
Further refinement will find that in the original IaaS cloud phase, in addition to the business logic, you also need to care about the life cycle management and traffic management of the business application. You also need to build and configure middleware yourself, such as in the cloud environment. Redis, kafka, etc. are built in the middle, which means that a lot of time is spent on application dependency management, and the cloud platform cannot be managed. Today, in the stage of PaaS or cloud-native migration, what I want to do is to use the capabilities provided by the cloud platform as much as possible, focus more on the business itself, and hand over the general technical capabilities that are not business-related to the cloud To manage.
the core issue:
- How to decouple business-independent capabilities to the platform?
- How to define the agreement between platform and business (application)?
- How does the application architecture need to adapt?
In the IaaS cloud phase, there was a standard protocol for the interaction between applications and operating systems, but today, in the PaaS cloud phase, what such a protocol should be needs to be redefined. In addition, how to achieve capacity sinking based on such a protocol is also what many cloud vendors, including Alibaba Cloud, do. For example, Alibaba Cloud has built RocketMQ Service based on RocketMQ, and provided container services based on some protocols based on containers. Of course, now is just the beginning, and this part of the content will be richer and more complete in the future.
Example 1: Service Mesh separates service discovery and traffic from business
At the same time, application architecture also needs to adapt. Take Service Mesh as an example. The traffic inside the application was in the form of SDK, so how to separate service discovery and traffic from the business SDK and put it in Sidecar during the evolution process, and then hand it over to the cloud platform for processing. This is an example of application architecture evolution.
- Service registration & discovery
- Traffic routing
- Traffic playback
- Flow control during publishing
Example 2: Lightweight container strips log collection from business
In the past, when doing log collection, it was necessary to start a log collection process in each virtual machine, and transfer the collected logs to the log collection platform, and analyze it through the visual interface. Today, in the cloud-native era, it is better to let the container service grab logs from stdout, or to get log data from a specific log directory through configuration. But the collection thing needs to be moved to Sidecar to realize the agent upgrade. Therefore, the separation of log collection from the business by lightweight containers is also an example of architecture evolution.
- Resource isolation
- Independent upgrade
Example 3: Business provides probes to enable the platform to realize life cycle management
The requirements of life cycle management for application architecture are whether the original application is healthy or unhealthy after it is started. It is the responsibility and concern of application operation and maintenance or research and development. In the cloud-native era, it is hoped to fix this protocol and provide probes through the business to determine whether the application is healthy or unhealthy. This requires that health information be provided within the application through the HTTP protocol or Shell. Application lifecycle management falls into the platform.
- Automatic flexibility
- Auto move
- Automatic restart (self-healing)
Agreement (Contract)=API+Configuration
Overall, the protocol is API + configuration. For APIs, if you use caching, you will basically use open source protocols as APIs. Such protocols are usually more friendly than closed-source protocols. For the RPC protocol, the open source GRPC and DUBBO will be better than the private HSF. In addition, there are protocols for infrastructure, such as Terraform and Pulumi, which are actually defining an open source configuration language. These configuration languages can help declare the required infrastructure, such as containers, disks, networks, storage, etc., although the current There are many types of configuration languages, but one or two languages will eventually be formed in the future, just like the SDK of Java. The use of cloud resources in the future will inevitably present a set of SDKs, which must be based on a set of configuration coding languages. Constructed. Furthermore, GitOps, etc. have also defined the release process and release strategy as a set of language, which will be a standard agreement 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 better than the private HSF.
- As a caching protocol, the open source Redis is better than the private Tair.
- Microsoft's Dapr attempts to standardize the API to the HTTP/GRPC layer based on the sidecar architecture to remove the SDK and support multiple languages.
- IaC products such as Terraform and Pulumi declare infrastructure through configuration language.
- GitOps further uses code to declare the environment, release process, and release strategy content.
Shift in R&D focus
Originally, there were too many things that the application needed to care about, such as various SDKs and various operation and maintenance events, but these things can actually be abstracted into a model and defined in a new language. Things that the entire cloud industry cares about.
The reason why new languages and new protocols have always been emphasized is that after defining new languages or protocols, applications need to care about these. For developers, the most concern is the code, so if the code can be used to describe the application's requirements for infrastructure, operation and maintenance, and hosting, it will be very friendly to the application. The application only needs to be able to connect to this protocol, then it can run on the proprietary cloud, public cloud, and Alibaba Cloud at the same time.
to sum up
In the future, the resources on the cloud will become more and more abundant. On top of the infrastructure, the cloud platform provides more PaaS capabilities, just like the operating system provides the capabilities of processes, and there are many SDKs. However, these capabilities are currently very inefficient and non-standard in use, and the use process is also troublesome. Today we are using the cloud in a similar assembly form, and cloud native is redefining the contract between the application and the cloud platform and building more advanced programming languages and tools around this contract. This is a very important direction for application architecture evolution in the context of the cloud native era.
Original link: https://developer.aliyun.com/article/776095?
Copyright statement: The content of this article is contributed spontaneously by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud developer community does not own its copyright and does not assume corresponding legal responsibilities. Please refer to the "Alibaba Cloud Developer Community User Service Agreement" and "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines" for specific rules. If you find that there is suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.