Developing Multicloud Ready Microservices with DAPR

We all know how fast you can write a cloud native web application and deploy it to any public cloud. With a few clicks you’ve created an empty .NET Core project, implemented dependency injection, hooked up some APIs and deployed it to your compute service. But what if you want to go the Microservice route? Well then you’d have to setup your container cluster first and setup a Service Bus or Message Queue for service-to-service communication and then you haven’t even started coding yet. Have you considered the dependencies of your software architecture on your infrastructure yet? Most of the times your container setup will be specific for the cloud provider you use at this moment and your microservices will have a tight coupling with cloud provider specific endpoints or other PaaS offerings from this specific provider. But what if you want or need to switch cloud providers? What if you need a new service that only a competitor offers? Then you’ll need an software architecture that is multicloud ready!

Well that undertaking of making your architecture multicloud ready can now be massively simplified by using DAPR. A middleware layer and application runtime designed to make your Microservice development and deployment cloud agnostic. With no more tight coupling between your application code and your cloud infrastructure.

As said DAPR is a middleware layer and application runtime, therefore it’s abbreviation stands for “Distributed Application Runtime”. Distributed meaning it runs de-centralized and is perfect for a microservices architecture. It’s main aim was to bring support for cloud native and serverless cloud services to microservice architectures.

Au contraire popular belief, DAPR is not developed nor maintained by Microsoft. It is a fully open-source project maintained under MIT license. However Microsoft has gathered quite some press for DAPR and is also financially backing the project. Maintainers on the project also include some Microsoft staff and developers that have worked for Microsoft in the past. This involvement from Microsoft has led to good support for DAPR in the Microsoft ecosystem from the beginning. There are specific SDKs for .NET Core, full support in Visual Studio and documentation is up to Microsoft standards. But DAPR is not Microsoft specific, the runtime itself is written in Go and is platform agnostic.

This applies for both the infrastructure layer that DAPR talks to as well as the application layer sitting on top of DAPR. Next to .NET Core there is also support for Node.js, Java, Python C++ and Go itself. On the infrastructure layer there is out of the box support for of course Microsoft Azure but also for AWS, Google Cloud Platform and even newcomers such as Alibaba Cloud and Camunda Cloud.

DAPR acts as an interface between your application code and your containerized infrastructure. On a sidenote, using containers is a prerequisite to for using DAPR although the underlying orchestrator used doesn’t matter. This can be Kubernetes but also Docker Swarm and the infrastructure provider is also free of choice. The key benefit of DAPR from the developers point of view is that it provides a single-contract interface to interact with any cloud infrastructure, any other microservice in your application or interactions with other applications or APIs on the internet, outside of your cluster. You don’t have to worry about any breaking changes on the infrastructure or cluster layer. As long as you respect your contract with the DAPR interface you’ll be fine.

The DAPR runtime is setup to be modular. Which means that you can pick what services in your software life cycle you want DAPR to handle and which ones you want to control yourself. This way DAPR stays lightweight and doesn’t slow your microservice down nor takes up loads of resources in your Kubernetes cluster.

Modules for DAPR include: State Management, Service-to-Service Invocation, Pub-Sub, Resource Bindings, Observables and Secrets. Because of the open-source nature of DAPR you can also use one of the many extension modules that have been developed by the community.

DAPR uses the sidecar pattern to make itself available to your microservice. This is the same pattern that Service Meshes like Istio use within the Java Ecosystem. However DAPR it not a Service Mesh because it doesn’t offer Network layer features or controls, instead it is a true application runtime.

When you are injecting a DAPR resource into your Microservice a sidecar is spun up in a separate pod or container in your cluster that is then hooked onto the pod that is running your microservice in a similar fashion as multiple carts on a rollercoaster train. Depending on the number of DAPR services your microservice can use more than one sidecar hooked on to your service pod. The cars itself communicate with each other over mTLS.

The DAPR component as shown above contains relevant metadata about the type of component and infrastructure behind it. In this case we have a component demosecrets of type secretstores which reads from a local file so obviously a file name and path is required.

The DAPR client is injected as a singleton and then a SecretStore is added to the client. The DAPR interface only knows that it’s talking to the demosecrets secret store, it doesn’t care about its physical location or specific implementation. It only knows to retrieve secrets from this specific DAPR endpoint which would be something like http://localhost:<daprPort>/v1.0/secrets/demosecrets/. This means that you can change the content of the DAPR component at any time without breaking the contract with the interface for your application. So say I want to move my secrets from a local file to Azure Key Vault I can do so just by updating my DAPR component.

My ASP.NET Core application will still be talking to the demosecrets secret store. It doesn’t know that the secrets no longer live in the local file system but have moved to Azure Key Vault. It doesn’t know it has to fetch the secret now over the public internet and authenticate with Azure first, DAPR is taking care of that. This means that you can move around your resources or switch public clouds without your application knowing and without the need to change your application’s configuration or make any code changes. This makes your microservices much easier to maintain without having to change anything on your service code.

DAPR has a lot of off-the-shelve components for all supported public cloud platforms. For a better insight the graph below will show the different native components that you can use on every cloud platform. Some components can be used regardless of the cloud provider as long as you use the standardized wire protocols for these components.

Because DAPR itself is cloud agnostic, i.e. for each module they have components for almost all of the Public Clouds (Azure, AWS, GCP, Alibaba Cloud, Camunda Cloud) and it makes your service code cloud unaware it is ideal for using in a multicloud environment or a must in a multicloud architecture. With DAPR you can independently change your infrastructure layer, move to a different public cloud or mix different public clouds without your service knowing or needing to know about it. This makes your cloud architecture much more flexible and you have no more vendor lock-in as it is much easier to move to a different Public Cloud provider when desired or to mix public clouds or even to setup a hybrid cloud solution with some resources still living on-premises.

The Public Cloud landscape is ever changing and as a consumer you don’t want to be suffering from vendor lock-in. At IT management level committing to a single vendor for infrastructure can be quite challenging. Not only you lose flexibility but also have to engage in a long term commitment with a specific vendor, especially if your software architecture only caters for one cloud platform. So you have a hard dependency on this vendor, you might not be happy with the level of support this vendor provides, there might be future services this vendor doesn’t offer yet or they might simply increase their prices by more than a fair bit.

In these cases you want to be able to (partly) move to a new cloud provider without jeopardizing business continuity of your applications. Having a multicloud architecture makes this possible because you decouple your application from your cloud infrastructure. This will no longer leave you at the mercy of the single cloud provider you committed to and will make it possible to try and use new cool services that are introduced by a new cloud provider. Also it will make sure your CTO has no more sleepless nights over the mammoth contract with that single cloud provider that would otherwise be a single point of failure in your IT strategy. If you are considering moving to Public Cloud, you have to also consider making your software architecture Multicloud ready! Do this before it’s to late and you find yourself trapped in the golden cage of your cloud provider that you can’t live with but also no longer can go without.

Related posts:

Down a little on last weeks but still very high — and with the App not closing again this means that support are on top of the numbers. An additional 300 reviews from last week is quite a jump —…

I went through a particular season of extremely vivid dreams that I felt were messages to me from the Lord speaking into my heart. In this dream, I took my young son to the doctor’s office in the…

Un desarrollador de Full Stack es una “raza distinta” y los buenos desarrolladores de Full Stack son invaluables. Son la entidad más importante que puede sellar el destino de su aplicación. Pero al…