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

author| Sun Jianbo (Tianyuan) Alibaba Technical Expert

OAM is a standard specification for building and delivering cloud-native applications launched by Alibaba and Microsoft in the community. It aims to push application management technology towards "light operation and maintenance" through a new application definition, operation and maintenance, distribution and delivery model, and fully open up the technological revolution of the next generation of cloud-native DevOps.

background

OAM is a standard specification for building and delivering cloud native applications launched by Alibaba and Microsoft in the community. We have published a series of introduction articles before. For your convenience, the links and introductions are as follows:

"4 concepts, 1 action, make application management simpler": specific and detailed introduction of all aspects of OAM details;"doing subtraction for K8s API ": challenges and practices of Alibaba Cloud native application management ": introduced some of our practice background before exploring OAM and why we naturally designed such application models as OAM; Kubernetes PaaS application management practice under OAM blessing: Focusing on the various solutions of building PaaS based on Kubernetes, this paper introduces how OAM organically combines and finally unifies these solutions, and then further exerts the ecological power through standardized modular organization, making it possible for mutual cooperation and mutual benefit; Open Application Model Operation Guide (I): Cloud Service "One-Click Access" OAM System: Taking cloud resources as an example, this paper introduces the methods and practices of how to intervene in OAM system.

In the previous articles, we explained why cloud-native applications require standard definitions and what the OAM model actually looks like. Today, we will introduce what value OAM itself has, that is, answer why OAM is used as an application standard model.

AWS Development Principles for Building ECS CLI v2

Earlier this month (December 2019), AWS released ECS CLI v2, the first major release update in four years since v1 was released in 2015, with v2 command-line tools that focus more on the end-to-end application experience, managing the full application delivery process from source code development to application deployment. They summarized four CLI development principles based on user feedback received over the years:

Create modern apps by default. Modern applications created by default meet these characteristics: serverless, infrastructure as code, observable, secure;

Users should think about architecture, not infrastructure. Developers building microservices should not specify VPC, Load Balancer configurations, or complex Pipeline flow configurations. Developers may know nothing about cloud services, but they should specify what type of application exactly belongs to, that is, what architecture the application should adapt to, and the infrastructure should automatically match resources according to the architecture specified by the application;

Operations should also be part of the workflow. Building, developing, and deploying applications is only one part of the application lifecycle that application developers are responsible for. The whole lifecycle of an application should also include operation and maintenance, i.e. problem troubleshooting and resolution;

Application delivery is continuous. Upgrade changes applied should also be easily integrated into the CI/CD system.

These principles are not so much ECS CLI development principles, but rather user demands, users want their applications to be modern (or cloud-native); users want them to specify architecture, not specific infrastructure resources; users want operational capabilities to be centrally managed throughout the application lifecycle; users want application change delivery to be continuous, transparent, and easily managed by CI/CD systems.

Value of OAM model

In response to the demands of the above users, we will look at how OAM is satisfied one by one, and we can also see the value of OAM in it.

The cloud original biochemical OAM application definition is declarative, i.e., end-state oriented. Its format is consistent with the API of K8s, and it can be seamlessly connected with CRD of K8s and directly deployed to K8s as Object of Custom Resource. The OAM application definition is self-contained, and all information in all aspects of an application life cycle can be found through the description of OAM definition.

As shown in the figure below, you can see an application configuration running OAM, using K8s API spec, complete with all aspects of an application's resources.

Platform independent, runtime independent

The OAM application definition does not limit your underlying platform and actual runtime. You can run on platforms other than K8s, whether it is ECS, Docker, or FaaS (Serverless). Naturally, there is no vendor lock-in problem. If your application satisfies the Serverless condition, then the OAM description for that application can naturally run at Serverless runtime that supports the OAM specification.

In different environments that support OAM, you can use a unified application description to create undifferentiated application delivery. As shown in the figure below, corresponding users can achieve a consistent application experience in different environments as long as they describe a uniform application configuration.

infrastructure as code

The popularity of cloud nativity has largely promoted the implementation of infrastructure i.e. code. As an infrastructure platform, K8s makes users accustomed to describing the resources needed through Yaml files through declarative APIs, which is actually the implementation of infrastructure i.e. code. The OAM goes further and defines infrastructure resources that are not included in the native K8s in a unified way, and uses the infrastructure by configuring the yaml (code) of the OAM specification.

Today, the OAM implementation of ROS, a resource orchestration product on Alibaba Cloud, is such a model. You can pull up infrastructure resources on a cloud through OAM configuration.

Let's actually look at an example of pulling up a NAS persistent storage that contains two ROS resources, NAS FileSystem and NAS MountTarget.

apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata: name: nasFileSystem annotations: version: v1.0.0 description: > component schematic that describes the nas filesystem.spec: workloadType: ros.aliyun.com/v1alpha1.NAS_FileSystem workloadSettings: ProtocolType: NFS StorageType: Performance Description: xxx expose: - name: fileSystemOut---apiVersion: core.oam.dev/v1alpha1kind: ComponentSchematicmetadata: name: nasMountTarget annotations: version: v1.0.0 description: > component schematic that describes the nas filesystem.spec: workloadType: ros.aliyun.com/v1alpha1.NAS_MountTarget workloadSettings: NetworkType: VPC AccessGroupName: xxx FileSystemId: ${fileSystemOut.FileSystemId} consume: - name: fileSystemOut expose: - name: moutTargetOut ---apiVersion: core.oam.dev/v1alpha1kind: ApplicationConfigurationmetadata: name: nas-demospec: components: - componentName: nasMountTarget traits: - name: DeletionPolicy properties: "Retain" - componentName: nasFileSystem traits: - name: DeletionPolicy properties: "Retain"

In the definition, you can see that NAS MountTarget uses the FileSystemId output by NAS FileSystem. Eventually, this yaml will be translated by ROS OAM Controller into ROS resource stack template file, and finally pull up resources on the cloud.

Care about architecture rather than infrastructure

The user's appeal is actually the application architecture, not the specific infrastructure resources used. OAM solves this requirement through "WorkloadType", which defines the architecture of an application by describing the WorkloadType of an application. This WorkloadType can be a simple stateless application "Server", indicating that the application can be replicated, accessible, and run as a daemon for a long time; it can also be a database type application "RDS", corresponding to starting an RDS instance on the cloud.

The component "Component" of the user selects a specific architecture template by specifying "WorkloadType", and multiple Components constitute a complete architecture.

Using OAM application definitions allows users to really care about architecture rather than specific infrastructure.

As shown in the following figure, an application description of OAM, the user specifies that its application requires an external network access capability, rather than specifying an SLB, the user specifies that its component is a database.

Operation and maintenance capability management

Users expect OPS capabilities to be part of the application lifecycle, and OAM is exactly that. By binding Trait, OPS capabilities used by a Component are defined, so that OPS capabilities are also added to the application description, facilitating unified management of the underlying infrastructure.

As shown in the figure below, an application consists of two components, a web service and a database. The database component should have the ability to backup data, while the web service can be accessed and elastically scaled. These capabilities are managed uniformly by the OAM interpreter (i.e., the OAM implementation layer), and conflicts arising from this O & M capability binding are no longer annoying.

Transparent integration

Just as Docker images solve long-standing inconsistencies in development, test, and production environments, unified and standardized OAM application descriptions make integration between different systems transparent and standardized.

Different roles, separation of concerns.

OAM also decouples the complex API of the original K8s All-in-one to a certain level, and divides it into three roles: application R & D (managing Components), application operation and maintenance (combining Components and binding Trait into AppConfig), and infrastructure provider (providing OAM interpretation capability to map to actual infrastructure). Different roles work together to simplify the content concerned by a single role as a whole. So that different roles can focus more professionally on doing the work of this role.

elastically scalable

OAM application definitions are flexible and extensible. You can define different types of workloads by extending Workload, and you can describe your O & M capabilities by customizing Trait, which can be perfectly integrated with the CRD+Operator extension method in the existing K8s architecture.

Modular collaboration

OAM divides applications into three levels: R & D, O & M and infrastructure through the idea of separation of concerns, and provides modular collaboration capabilities for R & D Workload and O & M Trait, greatly improving reuse capabilities.

As modular Workloads and Traits become more and more available, a marketplace for these components will be formed, where users can quickly find the appropriate architecture for their applications (Workload) and the operational capabilities (Trait) they need to use in registries such as CRD Registry. Building apps is getting easier.

future

It is believed that the construction of applications will become simpler and simpler, the choice of infrastructure will automatically match according to the architectural needs of users, users can truly enjoy the dividends of cloud platform, quickly reuse existing modular capabilities, and OAM will also become the inevitable choice for cloud nativity.

At present, Alibaba team is contributing and maintaining this set of technology upstream. If you have any questions or feedback, you are welcome to contact us upstream or nail.

Participation:

Nail scanning code enters OAM project Chinese discussion group

Direct participation in OAM open source implementation discussions via Gitter

"Alibaba Cloud focuses on microservices, Serverless, containers, Service Mesh and other technical fields, focuses on cloud native popular technology trends, cloud native large-scale landing practices, and is the technical circle that understands cloud native developers best. "

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.