Microservices with Dapr
The term microservices refers to an architectural pattern which divides a complex application into individual microservices. Each microservice fulfils a specific task and can be individually developed, tested and deployed. A software architecture structured in this way makes it easy to replace and expand individual microservices and offers advantages in terms of flexibility, scalability and resilience. However, these advantages bring with them greater complexity, such as during deployment, communication between services, data storage and troubleshooting. The building blocks used by Dapr can help with many of these additional complexities.
Dapr stands for “Distributed Application Runtime” and is a Cloud Native Computing Foundation (CNCF) project.
We can think of Dapr as a “framework” for microservices and one which is implemented as a sidecar pattern. It offers building blocks for many common challenges.
There is an SDK for GO, Node, .Net, Python, Java, C++, PHP and Rust, but it can be used with any language that supports HTTP or gRPC.
We have already been able to use Dapr successfully as part of several projects. As an example, I would like to highlight the “Coinless MVP” project, which we discussed in a previous blog post. Coinless is a technology demonstrator project that enables existing coin-operated machines to be converted into cashless systems supporting payment by mobile phone.
Beside is a simplified overview of the microservices and applications involved. In this C4 container diagram, the microservices are represented by the hexagons, whilst the third-party systems have been omitted for simplicity.
Dapr provides “building blocks” for many common problems faced when dealing with microservice architectures.
For the Coinless MVP project, we used the following Dapr building blocks:
Service-to-service invocation
“Service-to-service invocation” enables reliable and secure communication between the endpoints of the microservices (HTTP or gRPC). If several instances of the microservice are running, round robin load balancing is performed. Metrics and traces are recorded for observability. Retries and access control can be configured.
We used this building block to connect to the individual microservices at the API gateway and aggregator.
State management
The state management building block (state store) offers a key/value store to give microservices a simple option for safely storing and using states across multiple instances. The building block can be easily configured to meet different requirements:
- Concurrency (ETags)
- Consistency (strong, eventual)
- TTL (Time to Live)
- Access restrictions and much more…
The building block supports several stores. We chose Redis as the store for the Coinless project. We use it in our application for various reasons, including to manage the different states of the tickets.
Publish and subscribe
The pub/sub building block enables microservices to communicate via messages.
This is used in our application to enable people to buy tickets, for example. The message will be required in a future version in order to carry out evaluations of ticket sales.
Dapr supports common providers such as RabittMQ, Kafka, etc.
Observability
When it comes to distributed applications, observability is important for finding problems and errors, as an action usually involves several components. The image below shows the distributed traces that were created for the ticket buying process. If an action takes longer than expected, or an error occurs, the cause can be quickly identified.
Secrets
Dapr provides a secrets building block that can be integrated into all common secret stores such as AWS Secrets Manager or Kubernetes. Microservices can now use the building block to request access data for database access, for example.
Conclusion
From our experience, Dapr is a solid, helpful framework for implementing microservice solutions. It provides reliable building blocks to reduce the complexity and additional effort associated with microservices.
The distributed traces generated by Dapr are a considerable help when trying to locate problems.
Another advantage is the great flexibility of use. Dapr runs with Docker locally, with Kubernetes via any cloud provider or on-premises, as well as serverless in Azure container apps. The building blocks can be configured accordingly, so that, for example, Redis can be used as a store at the beginning of development and, if necessary, the switch to an alternative implementation of the building block can be made with little effort at a later date.
Dapr is being developed very actively, new functionalities (building blocks) are being added to the framework on an ongoing basis, as well as extensions/optimisations of the existing building blocks.
The following points must be observed when using Dapr:
- Dapr is a sidecar pattern, meaning additional communication takes place. The delay is almost indiscernibly small and is irrelevant in most cases, but is there all the same.
- Dapr's building blocks place great importance on the interchangeability of the implementations, so if a very specific feature of Redis is required, for example, it may not be available via Dapr. This should be checked in good time in the Dapr documentation.