Comparing Open Application Model (OAM) with Other Application Deployment Models

This blog will delve into the technical aspects of OAM and compare it with other prominent application deployment strategies, highlighting their differences, advantages, and potential consequences.

Open Application Model (OAM)

OAM is a specification designed to create cloud-native, platform-independent applications. It uses a declarative approach to define application components, which simplifies the process of specifying how an application should be deployed and managed. OAM separates the application logic from the underlying infrastructure, allowing developers to focus on creating and deploying applications without worrying about the specifics of the supporting platform.

Key Components

• Components: These correspond to workloads or resources within the application.

• Traits: These define additional capabilities or configurations for the components, such as scaling or monitoring.

• Policies: These specify the rules and constraints for the application deployment.

• Deployment Workflows: These outline the steps involved in deploying the application.

OAM allows developers to define multiple workloads in a single specification, although best practices suggest limiting the number of components within an application to maintain manageability.

Platform Neutrality

One of the significant advantages of OAM is its platform neutrality. Applications defined using OAM can be deployed across various cloud-native platforms without requiring modifications. This is particularly useful in multi-cloud environments, where the ability to deploy applications consistently across different platforms can reduce deployment and management complexities.

Blue/Green Deployment

The Blue/Green deployment strategy involves running two versions of the application simultaneously: the current version (blue) and the new version (green). This approach allows for testing the new version in a live environment while keeping the old version available for immediate rollback if necessary.

Key Aspects

• Traffic Management: Load balancers are used to redirect traffic between the blue and green environments.

• Database Compatibility: Both environments must use compatible data formats and schema to ensure seamless data sharing.

• Rollback Capability: The ability to quickly switch back to the previous version if issues arise with the new version.

Comparison with OAM

Unlike OAM, which focuses on defining and deploying application components in a declarative manner, Blue/Green deployment is more about managing the transition between different versions of an application. While OAM does not inherently support versioning and rollback mechanisms, it can be integrated with service meshes like Open Service Mesh (OSM) to achieve similar traffic management and rollback capabilities.

Continuous Deployment (CD)

Continuous Deployment is a strategy where new versions of the application are released to production automatically after passing through automated testing and validation. This approach eliminates the need for manual testing or approval processes, allowing for rapid deployment of new features

Key Aspects

• Automated Testing: New code changes are deployed to production only after passing automated tests.

• No Manual Gates: Unlike Continuous Delivery, CD does not include manual approval steps before deployment to production.

Comparison with OAM

OAM and Continuous Deployment share the goal of streamlining the deployment process, but they approach it differently. OAM focuses on the declarative definition of application components and their deployment workflows, whereas Continuous Deployment is about automating the release process. OAM can be used in conjunction with CD pipelines to ensure that the application components are defined and deployed consistently across different environments.

Recreate Deployment

In the Recreate deployment strategy, the old version of the application is completely shut down before the new version is deployed. This results in downtime for the application until the new version is fully deployed and operational.

Key Aspects

• Downtime: The application is unavailable during the transition from the old to the new version.

• Cost-Effectiveness: This strategy is cheaper as it does not require load balancers or complex traffic management.

Comparison with OAM

OAM does not inherently support recreate deployment strategies, as it is designed to manage and deploy application components without downtime. However, if an application defined using OAM needs to undergo a complete overhaul, the recreate strategy could be manually implemented, though it would not align with OAM's principles of platform neutrality and minimal downtime.

Shadow Deployment

Shadow deployment involves running both the old and new versions of the application simultaneously, but the new version receives traffic indirectly through the old version. This approach helps in testing the new version in a live environment without directly impacting users.

Key Aspects

• Indirect Traffic: The new version receives traffic from the old version, reducing the risk of direct user impact.

• Response Time: The response time may be prolonged due to the indirect traffic routing.

Comparison with OAM

Similar to Blue/Green deployment, Shadow deployment is more about managing the transition and testing of new application versions. OAM, with its focus on declarative application definitions, does not natively support shadow deployment. However, integrating OAM with service meshes could facilitate similar traffic management and testing scenarios.

Conclusion 

OAM, while offering significant flexibility and platform neutrality, presents several technical considerations. Its declarative nature, while powerful, can introduce complexity, particularly for smaller teams or those new to this deployment model. Grasping OAM's components, traits, and policies requires a deeper understanding. Integrating OAM with other deployment strategies, such as Blue/Green or Continuous Deployment, can enhance its capabilities but also adds layers of complexity that must be effectively managed. Furthermore, while OAM's ability to define multiple workloads within a single specification can improve scalability, it necessitates careful management to prevent system overload.

Operationalizing OAM can have significant consequences. Strategies like Recreate deployments, if not carefully managed, can lead to significant downtime, negatively impacting user experience and disrupting business operations. Techniques like Blue/Green and Shadow deployments require running multiple application versions concurrently, which can increase resource consumption, including storage, computing power, and hardware costs. Continuous Deployment, while enabling rapid deployments, heavily relies on robust automated testing and validation. Any deficiencies in these processes can result in deploying faulty code to production, potentially causing service disruptions.

Selecting the appropriate deployment strategy is critical. For instance, OAM is well-suited for intricate, cloud-native applications, whereas Blue/Green deployments might be more suitable for applications requiring frequent version updates. Irrespective of the chosen strategy, meticulous monitoring and testing are paramount to guarantee the application functions as intended in production. Continuously reviewing and refining deployment processes is essential to accommodate evolving requirements and mitigate potential risks.