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

Author: Deng Hongchao Alibaba Application delivery expert

Preface

With K8s, users can customize the infrastructure and replace or modify the existing functions of the platform in parallel, rather than being limited to the capabilities provided by the platform. But it is this "white box" experience that is bringing "too complex" trouble to more and more R & D and operation and maintenance.

From Kubernetes to an "application-centric" future, PaaS engineers around the world are actually looking forward to a new technology to bridge the gap. The approach of Aliyun's native application platform team is to solve this problem by "modeling" applications, which is an important purpose for the creation of Open Application Model (OAM) open source projects.

Alibaba's containerization Journey

Alibaba's containerization journey began in 2013. Before the birth of Docker, Alibaba developed container technology T4 based on lxc container engine, which is used to deploy and manage applications on bare metal.

In 2017, Alibaba internally incubated the container orchestration engine Sigma similar to K8s as a unified resource layer to manage the internal machine pool, with an average utilization of 40%.

In 2018, Sigma was redesigned and migrated to be compatible with K8s API. Alibaba rewrote the custom controller and scheduling algorithm and tried it out on the exposed declarative API.

At the end of 2019, most of the applications in Alibaba ran on K8s, and dozens of native frameworks were built on K8s to build the K8s ecosystem. The Singles' Day event in 2019 is not only a commercial success, but also strong proof that the K8s infrastructure can support such a large scale.

After solving the problem of scale and stability in K8s, we began to face a new challenge: K8s API is too complex for developers to learn.

Three reasons for the complexity of K8s API

There are three main reasons for the complexity of K8s API:

1. K8s lacks an "application"-centric resource model.

There is no concept of "application" in K8s, only loosely coupled infrastructure resources. Deploying applications requires writing Pod and setting up infrastructure resources such as network and storage, which are very low-level. However, for developers, they do not want to configure these complex underlying resource information, they want to specify application deployment specifications from the development level, such as stateless service components with automatic expansion, monitoring, Ingress and other functions. We need to provide a higher level of application-level abstraction and an application-centric resource model to bridge the gap between deployment and configuration.

2. There is no separation of development and operation and maintenance concerns in K8s API

Secondly, there is no separation of development and operation concerns in K8s API. As you can see from the figure above, K8s encapsulates all fields belonging to different roles in an API. For example, the developer only needs to specify the container image, port, and health check, while the operator is responsible for configuring the copy size, rolling update policy, storage volume access mode, and so on.

There is no problem with such a statement for K8s API. K8s is intended to expose infrastructure functionality and to build other platforms. Therefore, it needs to include everything and provide an all-in-one API. However, we found that all-in-one API is not suitable for end users who write applications. On top of K8s API, we need to distinguish roles and separate the concerns of development and operation and maintenance.

3. There is no portable application abstract definition on K8s

K8s defines a standard way to use underlying resources. But as mentioned above, deploying applications requires network access, monitoring, logging, and so on. We need to standardize those application operation interfaces to implement portable application layer abstractions.

OAM starts the next Generation Cloud Native DevOps Technology Revolution

In view of the above problems that K8s API is too complex and difficult for developers to learn, here is an introduction to the open application model OAM (Open Application Model), a standard specification for building and delivering cloud native applications, launched by Alibaba and Microsoft in the community.

In October 2019, Alibaba announced that he and Microsoft would jointly launch the Open Application Model Project (Open Application Model-OAM).

The so-called "application model" is actually a standard open source specification used to define and describe the cloud native application itself and its required operation and maintenance capabilities. So for Kubernetes, OAM is not only a standard "application definition" project (analogy is no longer active Kubernetes Application CRD project), but also a platform-level project focusing on encapsulating, organizing and managing various "operation and maintenance capabilities" in Kubernetes, as well as connecting "operation and maintenance capabilities" and "applications".

In OAM, an application contains three core ideas:

The first core idea is the service component (Component) that makes up the application, which includes micro-services, databases, cloud services, etc.

The second core idea is to describe a collection of application operation and maintenance features (Trait), such as auto scaling and Ingress. They are critical to the operation of the application, but they are implemented differently in different environments

Finally, in order to translate these descriptions into specific application examples, operators use application configuration (Application Configuration) to combine components and corresponding features to build deployable application delivery instances.

As shown in the figure above, we can see that the developer defines a Component to describe the service unit. Then the operation and maintenance staff defines the operation and maintenance characteristics (Trait) and appends them to the previous components, resulting in an OAM deliverable-ApplicationConfiguration. At the bottom of the figure, the underlying infrastructure resources will be presented through the OAM platform.

So how does OAM solve the above three Kuberntes API problems? First, OAM hides the underlying infrastructure details (for example, the cloud or the Internet of things), focusing on the application layer abstraction, providing an application-centric resource model. Secondly, OAM divides the three roles of development, operation and maintenance and infrastructure on the application delivery path, which separates the concerns and makes the process clearer and easier to manage. Third, K8s defines the portable abstraction of the infrastructure, while OAM stands on the shoulder of K8s and provides a portable application layer abstraction that allows the same application to run across platforms.

OAM also defines a set of core workload / operations characteristics / application categories as the cornerstone of the application delivery platform. Also, these core specifications have an open source implementation-Crossplane. Crossplane provides a mechanism for users to extend their functionality. For example, ContainerizedWorkload provided by Crossplane core runs the application in a container and manages the application's life cycle.

In addition, we can add more workloads (such as FaaS) to run serverless functions, or add operations features (such as CronHPA) to define HPA policies of type CronJob. OAM manages application delivery capabilities and processes in a single platform in a standard declarative manner. As there are more and more modular Workload and Trait, there will be a component market. OAM is like the manager of this component market, dealing with the relationship between components, integrating many components into a product and delivering it to users. PaaS with the blessing of OAM can assemble underlying capabilities, operation and maintenance features, and development components as flexibly as Lego bricks. Make the application management become unified, but the function is more powerful!

Conclusion

Above we discussed the background, motivation, and architectural details of OAM. It is worth noting that the OAM project is open source neutral and community driven. The specification and implementation are supported by open communities including Alibaba, Microsoft, and Upbound. We welcome more people to participate in defining the future of cloud native application delivery.

You can contribute to github repos: https://github.com/oam-dev/spec

Join the mailing list: https://groups.google.com/forum/#!forum/oam-dev

Join the weekly community meeting: Bi-weekly, Tuesdays 10:30AM PST

Join the nailing discussion group:

"Alibaba Cloud Native focus on micro-services, Serverless, containers, Service Mesh and other technology areas, focus on cloud native popular technology trends, cloud native large-scale landing practice, to be the best understanding of cloud native developers of the technology circle."

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.