当前位置:网站首页>How will the application architecture evolve in the cloud native era?

How will the application architecture evolve in the cloud native era?

2020-12-07 19:19:07 Aliyun yunqi

brief introduction :  How to use cloud native technology to improve delivery speed ? Under the background of the original cloud , What changes will the focus of R & D change ? Ali cloud senior technical expert Xu Xiaobin shares the information from IaaS It's the cloud age PaaS The evolution direction of application architecture in the cloud era , And the relationship between cloud native technology and application architecture evolution .

1.png

author |  Xu Xiaobin   Alibaba cloud senior technical expert

Reading guide : How to use cloud native technology to improve delivery speed ? Under the background of the original cloud , What changes will the focus of R & D change ? Ali cloud senior technical expert Xu Xiaobin shares the information from IaaS It's the cloud age PaaS The evolution direction of application architecture in the cloud era , And the relationship between cloud native technology and application architecture evolution .

Cloud primitives have entered PaaS The cloud based stage

Alibaba has experienced IaaS The cloud stage , We're moving forward PaaS The age of the cloud . In last year's “ double 11”, Alibaba has already realized the comprehensive cloud of e-commerce core system , The cloud here is mainly in IaaS layer . So-called IaaS It's mainly about calculation 、 The Internet 、 Storage virtualization , After this stage , Alibaba entered PaaS The cloud stage . stay PaaS More cloud products need to be used in the cloud phase , Including middleware 、 Storage 、 Cache and even application hosting platform .

2.png

IaaS Phase and PaaS There's a big difference between stages . stay IaaS Stage , For application development , It's often about infrastructure and resources , Generally speaking, it is virtual machine or container , There is almost no intrusion into the application architecture . But in PaaS The cloud stage , When you use cloud products , Such as cloud Redis、 cloud RDS、 cloud OSS、 cloud RabbitMQ When waiting , Will have a strong intrusion on the application architecture . that , What kind of impact will this intrusion have on the application architecture , It's a question that all R & D architects need to think about .

Cloud native technology

If you try to search for cloud native technology , You will see Google Cloud The definition of 、CNCF And many other cloud vendors and open source software definitions , And these definitions have different views . Simple induction can be divided into several categories as shown in the figure below , Vertically , It is divided into Application Architecture 、 Life cycle management 、 Traffic management , And four dimensions of infrastructure and dependence ; Horizontally , It is also divided into micro services 、12 Factor Apps、 Containers 、BaaS、GitOps/IaC as well as Service Mesh Several dimensions .

3.png

today , Everyone will talk about cloud native based on microservice architecture , Not based on Jushi application architecture or simple CS framework .Quarkus Put forward 12 Factor Apps, That is to say, if you want to make the app run in Quarkus And so on these application hosting platforms , There are certain requirements for the application , Probably 12 Article principle , Such as configuration and code separation , Of course, there are many extensions to follow . Many of these principles mean that as long as you follow these principles , Then the application hosting platform can provide you with more capabilities , For example, free operation and maintenance . The core of the container is to use a standard way of interaction so that the platform can manage the life cycle of the application , Including publishing 、 Expansion and self-healing .

BaaS——Backend as a Service, Be able to use existing services as much as possible to build applications .Service Mesh The essence of is managing traffic , Today's applications are receiving traffic , When providing services, the traffic needs to go out , How to manage service discovery in the process 、 Traffic routing rules, etc Service Mesh technology . Finally, what needs to be highlighted is GitOps and IaC(Infrastructure as Code), These technologies are getting more and more attention in the industry , Although there is no de facto standard , But a lot of cloud computing companies are trying to . What it means is that when you use infrastructure today , These infrastructure requirements can be stated in code . To make a long story short , These are all around the application architecture 、 Life cycle management 、 Traffic management , And the four dimensions of infrastructure and dependence .

Business is concerned with delivery speed

For business , The most important concern is delivery speed . If you and the business director or CTO Go talk , They'll ask you , What's good for the business to have so many technologies ? Maybe talk about the cost advantage 、 The advantages of Management , But for almost all businesses , The core is the improvement of R & D 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 .

1. Standardized platform / Protocols for services and Applications

Put the platform / Standardization of protocols between services and Applications . If IaaS If the layer uses cloud, the protocol is the machine , It's virtual machines 、 Container, etc , For business applications , What you see is an operating system , In this way, the application can use various resources on the operating system , The advantage of this is that you don't have to worry about the physical machine and the problems of the machine .

2. Business independent capabilities are further decoupled to the platform

For business applications , It's not an operating system , It's going to give you a higher level agreement , Let the platform help the application to achieve automatic scaling and self-healing , It can also help the application to automatically move , When the underlying infrastructure fails , Applications can be moved from one machine to another , Life cycle management . Based on the above agreement , A lot of the power of the platform can sink , For example, things that originally need to be managed manually can be well implemented through code declaration , With these agreements , Business applications can host the relevant lifecycle management to the platform .

3. Application architecture upgrade

In addition to the above two points , The third step is to make the application architecture need to be upgraded to adapt to , Only in this way can the relevant capabilities sink to the cloud platform .

IaaS  The transition from cloud to cloud

Further refinement will reveal , In the original IaaS The cloud stage , In addition to the need to care about business logic , You also need to care about the lifecycle management of business applications 、 Traffic management , You also need to build and configure the middleware yourself , For example, build in the cloud environment Redis、kafka etc. , In other words, a lot of time has been spent on the application of dependency management , You can't manage the cloud platform . today , stay PaaS On the cloud or cloud on the original cloud stage , What you want to do is try to use the capabilities provided by the cloud platform , Focus more on the business itself , And leave the business independent common technology capabilities to the cloud to manage .

4.png

Core issues :

  • How business independent capabilities are decoupled to the platform ?
  • Platform and business ( application ) How to define the agreement between ?
  • How the application architecture needs to adapt to ?

before IaaS The cloud stage , There are standard protocols for interaction between applications and operating systems , And today in PaaS The cloud stage , What should such an agreement be , Need to be redefined . Besides , How to achieve capacity sink based on such a protocol , It is also what many cloud manufacturers, including Alibaba cloud, have done , For example, Alibaba cloud is based on RocketMQ Did RocketMQ Service, Some protocols based on containers provide container services and so on . Of course , Now it's just the beginning , In the future, this part will be more abundant and complete .

Example 1:Service Mesh Separate service discovery and traffic from the business

meanwhile , Application architecture also needs to adapt to . Here we use Service Mesh For example , The traffic in the application before was SDK In the form of , So in the process of evolution, how to make service discovery and traffic from the business SDK Split it out and put it in Sidecar Go inside , And then leave it to the cloud platform , This is an example of application architecture evolution .

5.png

  • Service registration & Find out
  • Traffic routing
  • Traffic playback
  • Flow control in the release process

Example 2: Lightweight container separates log collection from business

In the past, when I was doing log collection , You need to start a log collection process in each virtual machine , And transfer the collected logs to the log collection platform , And through the visual interface to analyze . Today, , In the age of cloud Nativity , It's better to have container services from stdout To grab logs , You can also get log data from a specific log directory through configuration . But collecting this thing needs to be moved to Sidecar Inside to realize Agent The upgrade . So lightweight container separates log collection from business is also an example of architecture evolution .

6.png

  • Resource isolation
  • Independent upgrade

Example 3: Business provides probes , Let the platform realize life cycle management

The requirement of life cycle management for application architecture is whether the original application is healthy or unhealthy after startup , It's all about the operation and maintenance or R & D of applications . And in the age of cloud Nativity , Hope to fix this Agreement , Providing probes through the business , To determine whether the application is healthy or unhealthy , This needs to be done inside the application through HTTP Agreement or Shell To provide health information , In this way, life cycle management can be applied to the platform .

7.png

  • Auto elastic
  • Automatic move
  • Automatic restart ( self-healing )

agreement (Contract)=API+Configuration

As a whole , The agreement is API+ To configure . about API for , If you use caching , Then the open source protocol will be treated as API, Such a protocol is usually more friendly than a closed source protocol . about RPC agreement , Open source GRPC and DUBBO Will be better than private HSF. And then there's the agreement on infrastructure , such as Terraform、Pulumi These are actually defining an open source configuration language , These configuration languages can help to declare the required infrastructure , Such as the container 、 disk 、 The Internet 、 Storage, etc , Although there are many kinds of configuration languages now , But the future will eventually form 1 To 2 Languages , like Java Of SDK equally , The future use of cloud resources will inevitably present a set of SDK Come on , This SDK It must be built on a set of configuration coding languages . further ,GitOps The process will be released 、 The release strategy is also defined as a language , And this will be the standard protocol between applications and the cloud in the future .

  • Docker (& OCI) It's standard software delivery API;
  • As RPC agreement , Open source GRPC/DUBBO Better than private HSF;
  • As a Caching Protocol , Open source Redis Better than private Tair;
  • Microsoft Dapr Try based on sidecar The architecture will API Standardize to HTTP/GRPC layer , To go SDK, And support multilingualism ;
  • Terraform,Pulumi etc. IaC product , Declare infrastructure through configuration language ;
  • GitOps Further, use code to declare the environment 、 Publishing process 、 Release strategy content .

A shift in R & D focus

The original time , There are so many things an application needs to care about , Such as a variety of SDK、 Various operation and maintenance events , But these things can actually be abstracted into a model , And use a new language to define , This is what the whole cloud industry is concerned about .

8.png

The reason why we always emphasize new language and new agreement , Because after defining a new language or protocol , That's all the application needs to care about . For developers , The main concern is the code , So if you can use code to describe the application to the infrastructure 、 Operation and maintenance 、 The need for hosting , Then it will be very app friendly . The application just needs to be able to dock with this protocol , Then it can be in the proprietary cloud 、 Public cloud 、 Running on alicloud at the same time .

9.png

summary

future , The resources on the cloud will be more and more abundant , On top of the infrastructure , Cloud platform provides more PaaS Ability , It's like the operating system provides these capabilities for processes , There's a lot more SDK. however , These capabilities are currently very inefficient and nonstandard in use , The use process is also more troublesome . Today we're using the cloud in an assembly like fashion , Cloud native is redefining the contract between application and cloud platform , And build more advanced programming languages and tools around this contract . This is in the context of the original cloud era , Application architecture evolution is a very important direction .

 

 

 

Link to the original text
This article is the original content of Alibaba cloud , No reprint without permission .

版权声明
本文为[Aliyun yunqi]所创,转载请带上原文链接,感谢
https://chowdera.com/2020/11/202011122210167532.html