Every once in a while a new piece of software based technology emerges that just make you smile thinking on the amount of work that perviously was needed to accomplish similar results. Dapr is one such technology.
The sales pitch (but its free!) states - ‘Dapr is a portable, serverless, event-driven runtime that makes it easy for developers to build resilient, stateless and stateful microservices that run on the cloud and edge and embraces the diversity of languages and developer frameworks.’
Starting out as a Microsoft incubator project in 2019 it has matured and since November 2021 it is part of Cloud Native Computing Foundation. System Internals founder, novel writer, Azure CTO and Microsoft Technical Fellow, Mark Russinovich was involved which is enough to catch my interest!
It is open source and the runtime and building blocks are written in Go which is really popular for cloud infrastructure including greats such as Kubernetes and Traefik. It uses a sidecar pattern and communication between your application and the Dapr sidecar uses Http and Grpc. You can use ANY programming stack leveraging Dapr using its APIs directly or using an SDK.
Dapr is a cloud native microservice runtime which is running in a sidecar right next to your application. It asbtracts external dependencies and complex patterns allowing for a loosely coupled and component (think lego-blocks) approach to microservices development.
But why?
The power is in the building blocks. Service invocation, State management, Publish & subscribe, Actors, Secrets management, Configuration to mention the most common ones. All supporting a large number of different ‘stores’.
Take Dapr for a spin
While it is possible to run Dapr completely standalone without Docker the default installation uses Docker and it is the most convinient way.
After a deafult local installation we have a few containers running.
Redis is the default state-store and is great to get going which is why it is installed in the first place. Without ANY configuration we can use out-of-the-box state store with the exciting name ‘statestore’. There is something like 30 different stores supported including Postgres, SQL-server, Google Firestore and Azure Table Storage.
During development we can start the runtime process manually without docker:
dapr run --app-id statetest --dapr-http-port 3500
Let´s give it a go. After staring the runtime we can interact with the default state store component (running in the Redis container)
Dapr is really fun to work with and shines when used together with Kubernetes or Azure Container Apps. More on that in a later post!