The author | Andy Shi (ali cloud senior technical experts), tian yuan (ali cloud experts)
In May this year, Ali cloud and Microsoft cloud jointly announced that Open Application Model (OAM) community and well-known hybrid cloud management project Crossplane community, jointly released OAM in Kubernetes platform standard implementation and core dependency library. With this collaboration, the OAM community has successfully unified standard application definitions with standardized cloud service management capabilities, taking a key step towards truly undifferentiated cloud application delivery.
In October last year, AliYun and Microsoft jointly launched the OAM project, which aims to build cloud-native application specifications around Kubernetes. OAM describes a model in which developers can define application components; The application operator is responsible for creating instances of these components and assigning application configuration to them; The infrastructure operator is responsible for defining, installing, and maintaining the underlying services available on the platform.
This cooperation is a tripartite technical cooperation between Aliyun, Microsoft and Crossplane community, which mainly focuses on the implementation of OAM standard on Kubernetes and the oAMization of Crossplane project. Because Kubernetes community in the implementation of OAM model in the process, put forward the demand for OAM standard implementation. Therefore, one of the key points of this cooperation is that the engineers of the three parties developed an OAM Kubernetes core dependency library using Go language. The name of this project is OAM-Kubernetes-Runtime. The OAM Kubernetes Runtime will be the foundation component of official maintenance by the OAM community, with the goal of providing a stable and unified OAM core plug-in on Kubernetes.
In order to further understand the details of this cooperation and the status quo of THE OAM project, Ali Cloud senior technical expert Andy Shi and Ali Cloud technical expert Sun Jianbo (name: Tianyuan) accepted an exclusive interview with Open Source China and jointly discussed the significance of the existence of THE OAM project.
Stamp for details: www.oschina.net/question/44…
Where the OAM came from
As we know, application container technology has quickly conquered almost all cloud vendors and data centers with its charm of “revolutionizing the way software is packaged and distributed” since its birth. However, the innovation of software packaging and distribution has not changed the definition and description of software itself, and the application management experience based on K8s has not made the work of business development and operation easier.
In fact, the cloud native technology revolution brought by Kubernetes is to realize the standardization and abstraction of the infrastructure layer, but this layer of abstraction is too far away from business R&D and operation and maintenance. The most typical example is that Kubernetes, to this day, does not have the concept of “application”. Instead, it provides finer grained “workload” primitives such as Deployment or DaemonSet.
In the real world, an application is often composed of a series of independent components, such as a “PHP application container” and a “database instance” consisting of an e-commerce site. A machine learning training task composed of a “parameter service node” and a “work node”; A microservice application consisting of “Deployment + StatefulSet + HPA + Service + Ingress”.
The absence of the concept of “application” in the Kubernetes project is a deliberate design that has resulted in the extreme fragmentation and high learning threshold of today’s cloud native application management ecosystem. How to solve the problem of “what is an application in Kubernetes” in a standardized way is the initial motivation for the release of OAM project.
What’s the point?
Before THE release of OAM, there was no such thing as an “application” in the cloud native ecosystem. Today, even in the world in almost every in the ground cloud native team, have an own definition of the concept of “application”, their degree of abstraction levels not neat, define the way also rich variety, that has made all around the “apply” to build out of the system, has become a one big chimney.
For the entire cloud ecosystem, the fragmentation and smokestack of the application layer is actually very detrimental to the entire ecological evolution. Today, as Kubernetes standardizes access to infrastructure capabilities, the application management, which is closer to the user and more important, has barely evolved and has not come up with any innovative ideas in recent years.
As a result of application management stagnation, business R&D and operations around the world have been forced to become “container experts” overnight, learning concepts in various Infrastructure as Data domains that shouldn’t be their concern (e.g. Declarative apis, controllers, etc.), teasing Kubernetes about how complex and bizarre the design is.
In short, Kubernetes is a system-level project for infrastructure engineers that provides loosely-coupled infrastructure semantics, which makes learning and manipulating Kubernetes YAML files feel very low-level and difficult.
In fact, the real end users of Kubernetes, such as business developers and operations people, do not want to configure such low-level resource information, but rather higher dimensional abstraction. This requires a real end-user-oriented application definition, and application definition primitives that can provide business r&d and application o&M personnel with their own perspectives. So the first change that OAM brings is to provide a standardized way to define higher-level application level abstractions that everyone can follow, with separation of concerns at the heart of the definition model.
** The second change that OAM brings to the Kubernetes project is the definition of the application, or more specifically, the standard open source specification that defines and describes the application itself and its required operational capabilities. ** From the perspective of Kubernetes project, OAM is a Kubernetes native standard “application definition” project, but also a focus on packaging, organization and management of Kubernetes various “operation and maintenance capabilities”, as well as the connection of “operation and maintenance capabilities” and “application” platform layer framework.
Specifically, OAM standardizes the specification of application definitions based on the Kubernetes API Resource Model, which emphasizes that a modern application is a collection of components rather than a simple workload or K8s Operator. So in the context of OAM, a PHP container and the database it depends on, as well as the various cloud services it needs to use, are all part of an “e-commerce site” application. Furthermore, OAM considers the “operations policy” required by the application as part of an application, such as the HPA (horizontal automatic scaling Policy) required by the PHP container:
Take the Crossplane project for example. How has it changed since the OAM upgrade in this collaboration?
“As a leader in hybrid cloud management, The OAMization of Crossplane ensures that today any oAM-compliant application, operation and maintenance capabilities, and cloud services on which it depends, can seamlessly drift together in a hybrid cloud environment.”
This platform-independent application definition paradigm allows application developers to describe their applications only through the OAM specification, and the applications can run on any Kubernetes cluster or Serverless application platform or even edge environment without any changes to the application description. With the release of Crossplane OAM, the OAM community is unifying standard application definitions with standardized cloud service management capabilities to achieve true “cloud application delivery.”
How does OAM work?
So how does OAM work in a project?
According to the introduction, OAM runs in Kubernetes as a native plug-in. OAM emphasizes separation of concerns throughout the model. That is, business developers define and maintain components to describe service units, while operations people define traits that they attach to previous components to form the OAM deliverables, ApplicationConfiguration.
This design is an important basis for OAM to provide the best use experience and minimum mental burden to business r&d and operations personnel while providing unlimited access to Kubernetes capabilities. At the same time, infrastructure engineers can always add more workloads (such as FaaS) to Kubernetes to run serverless functionality, or add operational features (such as CronHPA) to define CRONJob-type HPA policies. OAM manages application delivery capabilities and processes across the platform in a standard declarative manner, and provides API primitives for each role to express their respective demands, which are finally implemented through Kubernetes.
What kind of project requires OAM?
In fact, almost all kubernetes-based application management platforms have a clear desire to build their application models in a standardized way through OAM. On the other hand, because OAM is a native Kubernetes API resource model, the migration process here is very difficult, can gradually complete the migration operation through the GRAYscale management of API objects (through OAM objects gradually take over the existing Kubernetes objects).
Compared with traditional PaaS, which is closed and cannot connect with “operator-based cloud native ecology”, modern cloud native application management platform constructed based on OAM and Kubernetes is essentially an “application-centered” Kubernetes. This ensures that the application platform can seamlessly access the entire cloud ecosystem. At the same time, OAM can further shield the complexity and diversity of container infrastructure, and provide users of the platform with a low mental burden, standardized, consistent application management and delivery experience. This enables a Kubernetes application platform built on OAM to initially hide the details of the underlying infrastructure (for example, whether it is the cloud or the Internet of Things), focus on application-layer abstraction, and provide an application-centric resource model.
Second, OAM separates the development, operations, and infrastructure roles along the application delivery path, separating concerns and making the process clearer and easier to manage.
Third, OAM stands on the shoulders of the K8s API resource model, providing portable application and infrastructure abstractions that allow an application description to be delivered and run in any environment, cloud, side, or end, completely unchanged.
In addition, OAM defines a set of core workloads/operations characteristics/application categories as the cornerstones of the application delivery platform. Platform developers can also add more workloads (such as FaaS or any cloud service), or add o&M features (such as CronHPA) to define CRONJob-type HPA policies. OAM manages application delivery capabilities and processes across the platform in a standard declarative manner. As modularity’s Workload and traits grow, the component market will emerge. OAM is like the manager of the component market, dealing with the relationship between components, integrating many components into a product to deliver to the user. The Kubernetes application management platform, powered by OAM, can assemble underlying capabilities, operational characteristics, and development components as flexibly as Lego bricks. Makes the application management become unified, the function is more powerful.
OAM community status
Talk about the current state of the OAM project community. “As a neutral open source community not tied to commercial demands, OAM Ecology has maintained a high degree of activity and participation since its establishment. A large number of community Issue/PR contributions come from teams outside Alibaba and Microsoft, such as AWS, Tencent, Bytedance, Harmonyun, Qingyun, Haoyuyun, fourth Paradigm and other ecological participants. In addition to unifying and standardizing the internal application management architecture of Alibaba and Microsoft itself and based on OAM, many cloud services based on OAM, such as Ali Cloud EDAS, have also been launched.”
At the same time, THE OAM technology system has begun to be implemented in many large community users (such as MasterCard MasterCard), and there are also product and commercialization practices (such as visual OAM implementation of harmonic cloud), and even open source project integration and docking from other cloud vendors, such as AWS. As you can see, the OAM community is growing and expanding rapidly.
How the open source community works has always been something of a curiosity. The OAM project is completely community driven and is maintained and managed by Maintainer teams of each sub-project. The community has biweekly community meetings (one in the US and one in Beijing) to discuss and make decisions on major issues and to synchronize the progress of the project. The entire community workflow is supported by a Maintainer seat voting mechanism, with end user voting rights. Maintainer, the core of the OAM community, comes from original members of Ali Cloud, Microsoft and Crossplane projects. In terms of promotion strategy, the OAM project maintained by a number of international big factory teams has been fully oriented to the operation mode of international open source community since its birth. It drives the whole project to evolve continuously in the right direction by relying on ali and Microsoft’s own scenes, as well as the high-quality input of the whole cloud native community and contributors. Encourage contribution and community development in an atmosphere of communication, sharing and collaboration. In this mode, once the early ice-breaking stage is broken, the subsequent community communication and promotion will bring viral effects.
The current VERSION of OAM is V1alpha2. The version of OAM will continue to iterate and evolve according to the actual scene. At the same time, of course, the spec itself guarantees the stability and compatibility of the specification. The speed at which the standard will be updated depends on user acceptance and feedback, and a Beta version will be released this year. In this collaboration, OAM has released the Kubernetes standard implementation and core dependency libraries, which means that in the future the entire open source ecosystem can directly support the OAM standard through Crossplane or OAM-Kubernetes-Runtime. So there will be more and more of these programs soon.
If you have any questions: Nail scan code into OAM project Chinese discussion group
- Participate directly in the discussion via Gitter
- OAM open source implementation address
- I’m gonna hit star
Author’s brief introduction
Andy Shi is a senior technical expert of Alibaba Cloud and a developer evangelist of Alibaba Group. He has been engaged in the promotion of open source technology in Silicon Valley all year round and has rich experience in the use of cloud platform and network infrastructure.
Sun Jianbo (name: Tianyuan) ali Cloud technology expert, is one of the main makers of THE OAM specification, is committed to promoting the standardization of cloud native applications. At the same time, I also participated in large-scale cloud native application delivery and application management in Alibaba.
Course recommended
In order for more developers to enjoy the dividends brought by Serverless, this time, we gathered 10+ Technical experts in the field of Serverless from Alibaba to create the most suitable Serverless open course for developers to learn and use immediately. Easily embrace the new paradigm of cloud computing – Serverless.
Click to free courses: developer.aliyun.com/learning/ro…
“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.”