Jointly launched by Alibaba Cloud and Microsoft, Open Application Model (OAM) is the world's first project for defining cloud-native application standards and architecture modeling. Jiang Jiangwei, an Alibaba partner and the general manager of the Alibaba Cloud's smart infrastructure product division, made this announcement in Shanghai on October 17. The vision of OAM is to communicate and connect application developers, operators, and application infrastructure in a standardized approach, making cloud-native application management and delivery simpler and more efficient.
At 9:15 on October 17, 2019, Jiang Jiangwei, an Alibaba partner and the general manager of Alibaba Cloud's smart infrastructure product division, officially announced the following in a keynote speech named "Evolution of the R&D Model Based on Cloud Architecture" in Shanghai: "Today, together with Microsoft, we are launching a new project called Open Application Model (OAM)."
The Project homepage: https://openappmodel.io
In the announcement, Jiang Jiangwei said: "OAM is the first project for cloud-native application standards and architecture modeling in the industry. With this architecture model, we hope to connect application developers, operators, and end users in an efficient way, allowing them to enjoy a seamless and easy application management experience."
At the same time, Redan Burns, a Distinguished Engineer at Microsoft and the founder of the Kubernetes project, also announced this important joint release on Microsoft's official website.
You can read this article here: https://cloudblogs.microsoft.com/opensource/2019/10/16/announcing-open-application-model/
So, what is OAM? And what brought the world's two top technology companies together to want to take this project for defining application standard definitions and architecture modeling towards this direction? Well, the answer to this question can be traced back to the story of the earliest cloud application delivery in the world.
On March 14, 2006, Amazon released the cloud storage service called Simple Storage Service (S3). Shortly after the service was released, a Microsoft technician developed an application by using this particular service as the underlying storage service.
According to the developer, "it took several days" from decision-making to writing, delivering, and running the application". He was very excited about this, and later wrote in his blog: "the S3 announcement was game changing." The developer's name was James Hamilton. He was an architect of IBM Db2 in earlier days, and he later became one of the leaders of Microsoft's SQL Server. And then, in just two years after developing this magic application, he moved to Amazon. Today, James Hamilton has become the vice president and a key figure at AWS.
From 2006 to now, cloud computing has undergone several waves of change. Today's cloud is no longer the strange thing that the public first saw 13 years ago, which needed to be "tried out". Rather, with the extreme optimization of cost and resource efficiency of cloud, today's cloud services have undergone changes so dramatic that Moore's law no longer applies.
Now, this timeline still continues. Not too long ago, in August 2019, Alibaba announced that "the next turning point of cloud computing has arrived." Migration to cloud is quickly becoming the default choice for enterprises that are planning their application architecture and infrastructure. In 2019, if a developer wants to launch a Java website on a cloud platform like James did in his era, what would the experience be like?
Before answering the question asked in the previous section, consider this: What does it feel like to install an app in a smart phone today? What about updating that app? In smart phones like Apple's iPhone for example, the app management experience is absolutely seamless. It's as smooth as silk.
But now consider cloud. Of course, you could say that an application on the cloud is much more sophisticated than a simple executable file, but nevertheless, it's a far cry away from being the seamless and smooth experience you would have with installing an App on a smart phone. Consider a Java website as an example. Before end users can use this application on the cloud platform, a large amount of external dependencies must to be processed. All of this complexity is exactly what cloud application developers are concerned about. And simply put, it is not simple at all:
Above is a rough road path for how to deliver an application on the cloud. Here, also, are some examples to consider alongside this, too. As cloud developers, you need to first spend a lot of time designing the overall application deployment architecture to figure out which cloud services need to be activated for this application. However, problems like this still could happen:
In general, these situations happen because the process of cloud application management was actually done discretely-something that causes the whole process to be disorganized and difficult to control. As a result, mistakes and the whole process of trying to rework things to fix those mistakes is inevitable.
Also, consider this. In addition to the complexity of the entire process, one huge problem with the current cloud application management systems used nowadays is developers have to constantly activate and configure various cloud services while still also spending loads of time to develop the code for activating and connecting various cloud products. And what's worse, all of these processes, the activation, configuration, and the connection operations of cloud services are one-off things, which means you have to go through this entire process over and over again when launching different application components. Sometimes, even just connecting to a new cloud service means that you'll need to re-develop the entire application.
Again, with all of this said, the root cause of all of these problems is that the activation and configuration processes of cloud services that an application depends on are completely one-offs. They cannot be used more than once. So, a large amount of work needs to be repeated over and over and over again in the application management process.
These kinds of situations, as annoying as they sound, are the typical "symptoms" that limit and bother cloud application developers and operators on a day to day with how cloud is currently set up. These issues, of course though, also highlight the two root causes behind the time-consuming, inefficient, and laborious cloud application management we now know and don't really "love".
Ans again, all of it really boils down to two challenges, two issues. First, the relationships or connections between applications and cloud resources cannot be defined in a unified and custom manner. And second, there is no unified, standard, or even efficient means of delivering services to an application.
Now, after anyone experiences the smooth, silky and simple application management systems of smart phones, the broken and complex application management of cloud is one sad and painful reality. It makes one stop to think. With the rapid development of cloud computing technologies, why can't it be possible to receive the same application management experience on the cloud as we do nowadays with modern smart phones?
In fact, if we dive deeper into the application management systems in smart phones and on the cloud, we will find that both of smart phones and cloud share more things in common than you may first expect.
First of all, based on the standard hardware language used, or at least the "standardized infrastructure" used in smart phones nowadays, smart phones do provide a "standardized access layer" for users. In Apple's iPhone, for instance, this standardized access layer is iOS, which is a layer that shields the details of underlying resources by exposing UNIX-style interfaces upwards. Analogously, on the cloud, this layer is the OpenAPIs of Kubernetes and various other cloud services. However, there's more to this.
Application developers and end users of smart phones do not directly interact with the UNIX interfaces. This is because, in addition to the "standardized access layer", iPhone, like other major smart phones nowadays, also provides users with a complete "standardized application architecture and management system". This system includes both the library encapsulation of the operating system interfaces (that is, the modular SDK) and the delivery specifications for organizing and packaging applications. On this basis, it also serves to provide a series of development tools such as the IDE and even some programming languages. All these make the app management experience in the iOS system "as smooth as silk".
Now, let's look back at cloud computing. We will find that there are no cloud capabilities analogous to "standardized application architecture and management system" you see in Smart Phones like the iPhone.
That is, there is no unified or standard way for cloud applications to describe the relationships they share with cloud resources, nor is there a unified or standard framework for describing and defining cloud computing infrastructure services.
This is why it took only a few days for a developer to launch the world's earliest S3 application back in 2006, whereas, now, 13 years later, with cloud computing being as powerful as it is, it may still take several hours or even longer for us to deliver and upgrade a Java website on the cloud. Not much of an improvement, eh?
Open Application Model (OAM) is an application standard definition and architecture model for cloud-native applications. The OAM provides specifications for describing applications to cloud application managers. By complying with these specifications, application managers can compile a self-contained and self-described "application definition file". Specifically, this Application Definition file consists of two parts: the Application Components and the Application Traits.
For application components, application developers use a declarative description to define what kind of application they want to deploy and manage. For example, they can define whether a component is a Java website, a container, or a function, or define whether this application can run on Kubernetes or ECS. Or, they could define whether or not it should be noted that this application description describes the application development and operations from the perspective of a developer.
Next, for application traits, application operators use an additional declarative description to define the "operational traits" of an application. For example, they can define how the security group policy should be set, or what the routing access policy or scale-out policy is. So, as you can see, these application traits are actually the description of the operational details of application and infrastructure capabilities.
Based on all of this, you can probably figure out that, under the OAM specification, the management of cloud applications is implemented through these two types of declarative descriptions. In the real world, application developers only need to submit the application description they have written, and then operators are responsible for defining and managing various application traits. Next, cloud platform or application architects are responsible for attaching the appropriate application traits to it according to the requirements in the application description.
What is special about the OAM specification is that it does not simply combine application configuration with external dependencies, but it also creates two "decouplings" that are critical to cloud application management in the application definition specification.
One of these is role decoupling during application management. This so-called decoupling allows developers and operators to focus only on what they are responsible for, which can help improve developer productivity. Meanwhile, the cloud platform or application architects are given the necessary flexibility to choose appropriate traits for cloud applications without affecting the experience of developers by combining application traits with application descriptions.
This design can be referred to as a sort of separation of concerns. It allows for the application definition in the OAM model to not only clearly define responsibilities, but also clearly describes all the cloud infrastructure capabilities that an application depends on, which happen to be traits. Also, this design provides the basis for the systematic management of their relationships.
Next, there is the decoupling of the application definition and implementation layer. This decoupling effort enables a complete separation of user application definitions from cloud infrastructure capabilities. That is, an application no longer needs to be limited to running a specific platform or cloud service. Rather, the runtime option for an application is merely a configurable parameter in the application description.
Following this, the operational traits of an application, at the implementation layer, are essentially the modular implementation of each cloud infrastructure capability. Therefore, once an application description is attached to an application trait, the cloud platform can automatically connect corresponding cloud services to the application runtime, freeing users from repeatedly activating and configuring cloud services. However, the OAM provides far greater values for cloud application management than just a better user experience.
With the OAM, application managers can flexibly combine application descriptions and traits to provide different cloud infrastructure capabilities to applications. These infrastructure capabilities, after exposure to users through the OAM, can differentially represent the infrastructure capabilities that different running environments can provide for applications. For example, a developer defines an application description named "car" and makes the following description: "safety", "control", "driving power".
Then he submits this application description to the cloud platform, which then also attaches a set of basic "application traits" to the application according to the description like the following:
The application, as a result, appears to be a "family car" to its end users. However, after a while, the developer decides to upgrade the "car". But, what should he do now? Well, he does have to do much. All he will need to do is ask the application operator to attach a set of more "powerful" application traits to the previous "car" description, such as these ones:
Once these "more powerful" application traits are attached to the "car" description, the "family car" can be immediately upgraded to a powerful "sports car". Within this whole process, the only thing left for application developers and operators to do is to flexibly arrange and assemble different application traits like building Lego blocks.
So like the example way, OAM is a tool set that helps to make things simpler. It is primarily designed to provide a standard cloud application management experience, smoothing out the differences between different running environments so that applications can be defined once, but ran everywhere. With the application trait system provided by the OAM, users are still able to accurately select the running environment for their applications through comparing application traits in different running environments after the cloud platform exposes its capabilities in a standardized manner. The application trait system is an important innovation in the design of OAM as it balances both portability and differentiation.
The OAM open-source project mainly includes two parts, which are the OAM Spec and the Rudr product. Let's discuss exactly what they are in detail.
-The OAM Spec, or to get a bit more technical the Open Application Model Specification, can be defined as the official specifications and standards library project of the OAM model. This repository describes and defines all the core concepts of the OAM model as well as things like API specifications. At the same time, the OAM Spec also provides native extension specifications, which afford the model the flexibility to access any runtime, modularize any cloud infrastructure, and describe any operational trait in a standardize manner. To put things another way, this repository can be thought of as the official bible for OAM users and implementers.
You can access the OAM Spec project on GitHub by clicking here.
You can find the Rudr project on GitHub here.
Currently, although the OAM Spec and Rudr projects are jointly initiated and maintained by Alibaba Cloud and Microsoft Azure engineers, both projects have operated on a neutral foundation from the very beginning, using a completely neutral and open-source contributor agreement, without any binding relationship to any particular company or organization, including Alibaba Group and Microsoft.
The reasons for this are obvious: As a fundamental model for the future managing any or all applications on the cloud, Open Application Model has relied on the cooperation of the whole community in a completely neutral and open manner from the beginning, and it is planned to be transferred to a neutral foundation for hosting when the project becomes stable.
As of now, OAM has been implemented in multiple Alibaba Cloud projects for several months already. Through OAM is a unified and standard application definition system, it enables the efficient management of multiple cloud application management projects and empowers a stronger relationship between product applications and external resources, bringing the cloud-native application management experience to different application management processes based on different runtime environments whether they be FunctionCompute, ECS, or Kubernetes. Moreover, it also modularizes multiple capabilities exclusive to Alibaba Cloud to greatly improve the delivery efficiency of Alibaba Cloud's infrastructure capabilities.
And, at the same time, as a start-up participant of OAM, the Microsoft Service Fabric team has begun to "build Lego blocks" for the powerful application infrastructure capabilities of Service Fabric through the OAM to seamlessly integrate with the cloud-native technology system and build the "Mesh programming model" on this basis.
In its future development, OAM will be committed to bringing a smart phone-like experience to any and all developers working with developing and managing applications on the cloud. The goal is to ensure the efficient and quality delivery of applications in a standardized way to anywhere and everywhere in the world with a maximum level of portability and scalability.
At Alibaba, we look forward to bringing every developer in the cloud computing space together to take part in the development of this new application architecture model, building standards models and basic dependencies that support a prosperous cloud application ecosystem.
How Does Alibaba Ensure the Performance of System Components in a 10,000-node Kubernetes Cluster?
508 posts | 48 followers
FollowAlibaba Developer - March 3, 2020
Alibaba Clouder - August 18, 2020
Alibaba Cloud_Academy - May 26, 2022
Alibaba Developer - July 13, 2021
Alibaba Developer - December 27, 2019
Alibaba Clouder - November 22, 2019
508 posts | 48 followers
Follow
YiDA Low-code Development Platform
A low-code development platform to make work easier
Learn More
mPaaS
Help enterprises build high-quality, stable mobile apps
Learn More
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn More
Global Application Acceleration Solution
This solution helps you improve and secure network and application access performance.
Learn MoreMore Posts by Alibaba Cloud Native Community
