DEV Community

Sardar Mudassar Ali Khan
Sardar Mudassar Ali Khan

Posted on • Updated on

Distributed App Runtime (Dapr), Open App Model (OAM), Open Service Mesh (OSM)

Microservices have become a well-liked architectural design paradigm in recent years for creating sophisticated applications. But as the quantity of microservices increases, so does the difficulty of controlling them. Numerous open-source initiatives that seek to make managing distributed applications simpler have emerged in response to this problem. We'll examine three of these initiatives in more detail in this article: Distributed App Runtime (Dapr), Open App Model (OAM), and Open Service Mesh (OSM).

Distributed App Runtime (Dapr):

Dapr is an open-source runtime that makes it easier to create apps with a microservices architecture. Developers don't have to write boilerplate code because it provides a collection of building blocks that may be utilized to create durable and scalable applications. These fundamental components include pub/sub messaging, state management, and service invocation. Any infrastructure, including Kubernetes, virtual machines, and serverless platforms, can be used with Dapr.
The fact that Dapr abstracts away the underlying infrastructure makes it simpler for developers to concentrate on creating business logic rather than worrying about the underlying technology. This is one of the main advantages of Dapr. Additionally, it gives users a standard programming model for interfacing with other services, which can make the development process easier.

Open App Model (OAM):

A specification called Open App Model (OAM) is used to create cloud-native, platform-independent applications. Specifying how an application should be deployed and managed is made simpler by the declarative approach it offers to define application components. Because OAM separates the application logic from the supporting infrastructure, developers can concentrate on creating and deploying applications without being concerned about the particulars of the supporting platform.
The fact that OAM enables developers to define application components only once and then deploy them across several platforms without the need for modifications is one of its main advantages. In a multi-cloud context, this can aid in reducing the time and effort needed to deploy and manage applications.

Open Service Mesh (OSM):

For microservices-based systems, Open Service Mesh (OSM) offers traffic management, security, and observability. It is a compact, cloud-native service mesh. It is made with an emphasis on simplicity and use and is created to be simple to deploy and manage.
OSM, regardless of the underlying architecture, offers a uniform mechanism to manage traffic across microservices, which is one of its main advantages. This can facilitate the management of microservices-based applications and enhance the overall performance and dependability of the applications.


Implementing Dapr, OAM, and OSM in your application can be done in several steps:

Choose your infrastructure:

Choose the infrastructure that your application will utilise. Kubernetes, virtual machines, and serverless platforms can all be used with Dapr. OSM was created expressly to work with Kubernetes, but OAM is platform-neutral and can be used with any cloud-native platform.

Install the necessary components:

Install the OAM controller, the Dapr runtime, and the OSM control plane in the infrastructure of your choice. The runtime environments and management tools your programme needs will be made available as a result.
Define your application components:
Your application's components, along with their dependencies and configuration settings, should be defined using the OAM specification. This will give you a declarative way to describe your application, which will make it simpler to deploy and administer.

Implement your business logic:

State management, service invocation, and pub/sub messaging are just a few examples of the business logic you may implement using the Dapr building blocks. For interacting with external services, this will offer a consistent programming model regardless of the underlying infrastructure.

Configure your service mesh:

Configure your service mesh using the OSM control plane, considering observability, security, and traffic management. Your application's performance and dependability will both be enhanced as a result.

Test and deploy your application:

Once you are happy with the performance and dependability of your application, test it in a staging environment before deploying it to a live environment. To administer and monitor your application in production, use the management tools offered by Dapr, OAM, and OSM.
Implementing Dapr, OAM, and OSM can help to streamline the creation and administration of distributed applications, making it simpler to create durable and scalable applications without having to write boilerplate code or worry about the underlying infrastructure.

Advantages and disadvantages

Advantages of Dapr, OAM, and OSM:
Application development is made easier thanks to these projects' consistent programming style and declarative approach to application description, which allows developers to concentrate more on creating business logic and providing value to consumers.


Since OAM is platform-neutral, applications can be deployed across various cloud-native platforms without requiring any modifications. OSM is specifically made to function with Kubernetes, but Dapr may be used with any infrastructure.

Improve application performance and reliability:

OSM offers observability, security, and traffic management for microservices-based applications, which can enhance their overall performance and dependability.

Open source and community-driven:

Because they are open source and have vibrant communities, these projects are frequently updated and enhanced by a large team of developers.

Disadvantages of Dapr, OAM, and OSM:


Even though these initiatives seek to make distributed application development and management simpler, their implementation and administration can be challenging, particularly for smaller teams with fewer resources.

Learning curve:

To use these projects effectively, developers may need to take the time and effort to master new technologies and programming patterns.

Limited adoption:

These initiatives are still in the early stages of acceptance compared to more well-established technologies and frameworks because they are relatively new.

Integration challenges:

Especially if there are dependencies on other technologies or frameworks, integrating these projects into current infrastructure or applications may be difficult.
Dapr, OAM, and OSM are better than they are, especially for companies creating sophisticated distributed applications. Before deciding to use these projects, it's crucial to carefully assess your organization's needs as well as their capabilities.


Open-source initiatives like Dapr, OAM, and OSM seek to streamline the creation and administration of distributed applications. They offer administration tools for microservices-based applications, a consistent programming architecture, and a declarative method of describing programs. These platform-neutral initiatives can enhance the dependability and performance of applications. Although there may be certain limitations, such as complexity and integration difficulties, using Dapr, OAM, and OSM has more advantages, especially for businesses creating sophisticated, dispersed systems.
These initiatives have the potential to develop into crucial building blocks for scalable and resilient applications in the cloud-native age as they develop and become more widely used. Three open-source initiatives, Dapr, OAM, and open-source management (OSM), are intended to make managing distributed applications simpler. Depending on the requirements of your application, each of these projects offers a different set of features and advantages, and they can be used jointly or alone. By utilizing these initiatives, developers can put their attention on creating business logic and providing value to their users without having to worry about the supporting infrastructure.

Top comments (0)