Unleashing the Power of OAM: Open Application Model

Hackathon Journey with Shivraj Nakum exploring OAM

✍️Introduction

Imagine yourself as a developer, brimming with excitement over a groundbreaking idea for a new cloud-native application. As a developer, cloud engineer or DevOps engineer or anyone interested in the cloud or passionate about the cloud then you might agree that deploying a cloud-native application involves headaches regarding:

Requirements of ongoing operations, such as monitoring, logging, scaling, and updating
Manual configuration and managing the application's behavior and requirements.
Creation of vendor lock as applications may become tightly coupled to a specific cloud provider's APIs, services, and proprietary features.
Challenging to keep track of application metadata, metrics, logs, and traces.
Difficult to monitor, debug and troubleshoot cloud-native applications.

🤔Is there a way to solve this problem under one umbrella?

The answer is yes!! This is where the Open Application Model (OAM) comes in, offering a unified, vendor-neutral approach to describe and manage cloud-native applications. You might be wondering what is OAM. So let's dive in and get started on an exciting journey into the world of OAM!

🙋‍♀️What is OAM?

The Open Application Model (OAM) is a set of standards that simplifies the development and deployment of cloud-native applications by providing a consistent way to describe, package, and manage them across different cloud platforms.

OAM can be likened to a blueprint that provides a clear roadmap for developers to build highly scalable, portable, and adaptable cloud-native applications. Just as an architect uses a blueprint to design a building, developers can rely on OAM to design and deploy their applications with confidence, knowing that they are following industry best practices and standards.

😵Still didn’t understand OAM clearly?

Let us understand OAM with an example of the MARVEL SERIES:

OAM is like a set of instructions for managing the Marvel Cinematic Universe (MCU) as a cloud-native application. Each movie or TV show in the MCU is a component, and OAM helps define how these components behave.
It allows the producers of the MCU to easily deploy, manage, and update components like movies or TV shows. OAM helps define relationships and dependencies between components, ensuring consistent behavior.
For example, "Avengers: New Battle" can be defined as a component with its own set of instructions. These instructions might include details on how the movie should be deployed, how it should communicate with other movies or TV shows, and what resources it needs.
OAM makes it easy to change the behavior of "Avengers: New Battle" without affecting other components of the MCU. It enables consistent behavior across the entire MCU, just like how other movies and TV shows in the MCU behave.
OAM helps manage resources like actors, sets, and special effects needed for each component. It provides a scalable and manageable way to create, deploy, and manage cloud-native applications.
The producers can use OAM to ensure that "Avengers: New Battle" is released after "Avengers: Endgame" and reuses special effects from "WandaVision". OAM makes it easier to create and manage cloud-native applications with consistency and efficiency.
It allows the producers to update "Avengers: New Battle" without affecting the overall behavior of the MCU. OAM provides a framework for defining and managing components within a larger cloud-native application, like the Marvel series.
In summary, OAM is like a set of instructions that help manage the behavior of components within a cloud-native application, similar to how the producers of the Marvel series use instructions to manage the movies and TV shows in the MCU.

💪Capabilities of OAM

Now the question occurs: What makes the Open Application Model (OAM) stand out?

Today's complex deployment environments, make delivering applications without proper application context challenging:

Developers may find themselves spending valuable time on infrastructure details, such as clusters, ingresses, labels, and DNS, learning how these are implemented in different environments.
Upper-layer platforms may be introduced, but the needs of the application will likely outgrow the capabilities of those platforms quickly.

However, OAM proposes an app-centric approach instead:

Application-first approach: OAM enables developers to define app deployments with a self-contained model, including operational behaviors, without being tied to infrastructure details.
Clarity and extensibility: OAM provides an open standard for modular app delivery, allowing for the self-service assembly of reusable pieces, promoting clarity and extensibility.
Vendor-neutral: OAM offers a consistent abstraction for app delivery across different environments without vendor lock-in, allowing flexibility in choosing cloud platforms or edge devices based on app requirements.

📦Key Components of OAM

OAM is composed of several key components, including:

Components - Components are the building blocks of an OAM application. They define the application's logic, including its inputs, outputs, and behavior.
Traits - Traits are additional features that can be added to a component to modify its behavior, such as scaling, logging, or monitoring.
Configuration - The configuration is the set of parameters that define how the components and traits should be deployed and managed.
Deployment - The deployment is the instantiation of the configuration, resulting in the actual deployment of the application.

🤔You might be wondering, are OAM and Kubernetes the same?

OAM (Open Application Model) is a specification for defining cloud-native applications. It is designed to work with Kubernetes, but it is not a replacement for Kubernetes.

Kubernetes is an orchestration platform for containerized workloads. It provides a framework for deploying, scaling, and managing containers. OAM, on the other hand, is a higher-level abstraction that provides a way to define and manage cloud-native applications, including their infrastructure, configuration, and deployment.

One of the key differences between OAM and Kubernetes is that OAM focuses on the application, while Kubernetes focuses on the infrastructure. With OAM, developers can define their applications using a declarative model that abstracts away the underlying infrastructure. This makes it easier to manage and deploy applications across different cloud environments.

Another difference is that OAM provides a standard way to define and manage applications, while Kubernetes relies on custom YAML files. This can make it challenging to manage complex applications with multiple components and dependencies.

Overall, OAM provides a higher-level abstraction for defining cloud-native applications that complements Kubernetes' infrastructure-focused approach.

🔮Future of OAM

What potential developments can we anticipate for OAM in the future?

OAM has a dynamic community that actively works on improving the standard and accommodating new use cases. The goal of OAM is to enable developers to focus more on their applications and reduce the challenges related to the underlying infrastructure.

This aligns with the objectives of Napptive, where OAM is seen as rapidly evolving to offer a vendor-agnostic approach to application deployment, independent of cluster management or orchestration systems.

This approach has the potential to revolutionize how enterprise applications are operationalized, allowing for functionalities such as seamless migration between cloud vendors or complex multi-cloud multi-vendor deployments.

🫡All this Technical Stuff is cool, but let's see some Real World 🌎 Use-Cases.

NAPPTIVE is a fictitious company that specializes in developing cloud-native applications. One of their use cases involves deploying a new application to multiple cloud environments, each with different infrastructure and configuration requirements.

By using OAM, NAPPTIVE can define its application and its components once, and then deploy it to different cloud environments without having to modify the underlying infrastructure. This saves time and reduces the complexity of managing multiple configurations.

Recently, NAPPTIVE has been expanding its use of OAM to include more complex applications with multiple components and dependencies. They have found that OAM's standard way of defining and managing applications has made it much easier to manage and deploy these more complex applications.

Additionally, NAPPTIVE is exploring the use of OAM in conjunction with other cloud-native technologies, such as Istio and Knative, to further streamline their application development and deployment processes.

Overall, NAPPTIVE continues to leverage OAM to develop and deploy cloud-native applications more efficiently and effectively and is exploring new ways to incorporate OAM into its technology stack.

👩‍💻Interesting, Right? Here are some more Real-Life Implementations of OAM !! 😎

CNCF OpenEBS (Open Elastic Block Storage) is an open-source cloud-native storage platform for Kubernetes that provides persistent storage for containerized applications. OpenEBS has integrated the Open Application Model (OAM) to enhance its storage capabilities and enable a more composable and scalable approach to managing storage resources in Kubernetes clusters.
Azure Service Fabric, a distributed systems platform by Microsoft, has incorporated the Open Application Model (OAM). By leveraging OAM, Azure Service Fabric simplifies the deployment and management of containerized applications, providing a declarative, composable, portable, and extensible approach to building and managing distributed systems. OAM enables developers to define applications in a more modular and flexible way, allowing for efficient updates, portability, and extensibility, while abstracting the complexities of managing containerized applications in Service Fabric clusters.

📝Lessons Learned

Migrating an open-source application to the Open Application Model (OAM) can provide valuable learning experiences, like:

Understanding OAM concepts, principles, and components, such as application definition, traits, and scopes, for declarative cloud-native application deployment.
Testing and troubleshooting to ensure proper functionality in the OAM environment, including validating application definitions, configurations, and traits.
Collaborating with the OAM community, seeking guidance and sharing insights, to contribute to the knowledge base and foster community innovation.

🏁Conclusion

The Open Application Model is a promising development in the world of cloud-native applications. Its benefits include the ability to define applications independently of the underlying infrastructure, clear separation of concerns between application logic and infrastructure, and easy management and maintenance of applications.

With its key components of traits, components, configuration, and deployment, OAM provides a powerful framework for building and deploying modern cloud-native applications.

🔥Pro-Tip:

It is super easy to get started with Napptive, you just have to sign up and boom 💥 you are ready for deploying your first cloud-native application.

Don’t worry if you are new to this field check out my another blog on how to get started with Napptive ! ⚡