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

This article mainly explains "how to understand the standard definition and architecture model of the world's first cloud native application". The explanation in this article is simple, clear and easy to learn and understand. let's study and learn how to understand the standard definition and architecture model of the world's first cloud native application.

As a de facto standard in the field of container orchestration, the Kubernetes project has successfully promoted the rapid growth of cloud native services such as Aliyun Kubernetes (ACK). But at the same time, we are also concerned that the core API resources of Kubernetes, such as Service, Deployment, etc., are actually different components of the application and can not represent the whole of an application. Maybe we can try to express a deployable application in a way like Helm charts, but once deployed, there is still a lack of application-centric constraint model in the actual running application. These problems reflect that Kubernetes and cloud native technology stack need an application-centric API resource to provide a standard, highly consistent model focused on application management. This API resource can represent the fully running application itself, not just an application template or several components of an application. That's why Aliyun and Microsoft jointly announced the launch of the open application model Open Application Model (OAM) today.

Cdn.com/6c51226594a494c5047be3c46b02989c5267d6aa.png ">

The OAM project currently consists of two parts: specification and implementation.

What is Open Application Model?

OAM is a standard specification that focuses on describing applications. With this specification, the application description can be completely separated from the details of infrastructure deployment and management applications. The design benefits of this separation of concerns (Seperation of Conerns) are obvious. For example, in the actual production environment, whether it is Ingress, CNI, or Service Mesh, these seemingly consistent concepts of operation and maintenance vary greatly in different Kubernetes clusters. By separating the definition of the application from the operation and maintenance capabilities of the cluster, we can enable application developers to focus more on the value of the application itself, rather than on operation and maintenance details such as "where the application is deployed". In addition, the separation of concerns allows platform architects to easily encapsulate the operation and maintenance capabilities of the platform into reusable components, so that application developers can focus on integrating these operation and maintenance components with the code. in order to quickly and easily build reliable applications. The goal of Open Application Model is to make simple application management easier and complex application delivery more controllable.

1. Application component (Components)

In OAM, "application" is a combination of multiple concepts. The first concept is: application component (Components), which is an important part of the whole application. Therefore, the application component can include not only the services on which the application runs, such as the MySQL database, but also the application service itself: such as the PHP server with multiple replicas. Developers can "package" the code they write into an application component, and then write configuration files to describe the relationship between the component and other services. The concept of application components enables platform architects to decompose applications into reusable modules. This idea of modular encapsulation of application components represents a best practice for building secure and highly scalable applications: it realizes the decoupling of application component description and implementation through a fully distributed architecture model.

II. Application deployment configuration file (Application Configuration)

In order to turn the description of these application components into a real running application, the application operation and maintenance staff will instantiate the running application through a special deployment configuration file that contains all the application component information. This configuration file itself is also a declarative API in the OAM specification, which is used to enable application operators to instantiate the corresponding running application according to the application description submitted by the developer or platform.

3. Apply operation and maintenance features (Traits)

The last concept is a set of application operation and maintenance characteristics (Traits), which describe the operation and maintenance characteristics of the application in the specific deployment environment, such as the horizontal scaling strategy and Ingress rules of the application. These characteristics are very important to the operation and maintenance of the application, but they are often implemented in different deployment environments. To take a simple example, also Ingress, its implementation on the public cloud may be completely different from that of the local data center: the former is generally a cloud service such as SLB, while the latter may be a specialized hardware. This means that the Ingress operation and maintenance work for these two environments will be very different. But at the same time, no matter in which environment, this Ingress rule may be exactly the same for application developers. The design of application features makes this separation of concerns possible: as long as the two environments provide the implementation of Ingress as an application operation and maintenance feature under the OAM model, then your application can use unified Ingress rules to describe running in these two places without difference. At the same time, infrastructure vendors of these two environments can continue to configure the implementation of these application features to meet their respective operation and maintenance requirements (for example, differences in compliance and security of Ingress implementations in different environments)

OAM: platform-independent, highly scalable application description capability

Compared with the PaaS application model, OAM has many unique features, the most important of which is platform independence. Although our currently released OAM implementation (rudr) is based on Kubernetes, there is no strong coupling between Open Application Model and Kubernetes. In fact, OAM can be implemented on any platform or running environment, which of course includes scenarios of edge computing and the Internet of things. We also agree that Kubernetes may not be the best choice in many operating environments, or where users like Serverless don't need to care about infrastructure complexity. In these scenarios, OAM can provide a completely consistent application management experience.

The second important feature is that OAM's specification (OAM specification) is inherently extensible in design. OAM is not a closed system like PaaS, nor will it shield the features of the underlying platform through some unique application management environment (such as "putting a big hat on top of Kubernetes"). On the contrary, OAM enables the platform layer to reflect the characteristics and differences of the platform through the application of feature system (Trait system). In other words, as long as different platforms can provide some application features (Trait) required by the application, developers can easily develop cross-platform applications. Similarly, even the lowest-level hardware providers can reflect their platform characteristics by applying feature systems. The overall design of OAM is to avoid the "lowest common denominator" locking problem that often occurs in platform portability. Instead, OAM not only provides portability, it also ensures that each platform has the ability to reveal unique features and uses. OAM gives developers the freedom to strike a balance between portability and differentiated capabilities in a standard way for different platforms.

Open Community and the Future

Today, we are very excited about the initial results of the open application model and the corresponding Kubernetes implementation. The OAM specification is developed based on the Open Web Foundation protocol. Our goal from the beginning is to make the open application model Open Application Model a neutral foundation project in order to achieve open governance and broad cooperation. For more information, go to the GitHub repository of the Open Application Model project: OAM specification, and the OAM standard implementation Rudr based on Kubernetes.

Today's release of the OAM project is just a small step. We look forward to hearing from you and working closely with you to create a simple, portable and reusable application model for Kubernetes and any cloud environment.

Thank you for your reading. the above is the content of "how to understand the standard definition and architecture model of the world's first cloud native application". After the study of this article, I believe you have a deeper understanding of how to understand the standard definition and architecture model of the world's first cloud native application, and the specific usage needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.