This is the sixth and the final article in the Dapr series. The previous one can be found here. If you missed it, please check it out.
In this case, we'll be wrapping things up and talking about what else we can learn. Believe me or not, there is still much to discover.
Hosting options
We should review what has been accomplished so far. We began by discussing what the Dapr is and how it is constructed, and the hands-on installation and configuration was the next stage. We also mentioned that Dapr has hosting options. We have used the self-hosted one. But there are two more, and trying them out is an excellent idea for new Dapr challenges.
First, there is an option for Dapr to run on the Kubernetes cluster. In this scenario, four Dapr parts are executing on Kubernetes: operators, sidecar injectors, locations, and sentries.
The last option is to run in serverless mode. You can choose a serverless cloud offering if you want to run your Dapr applications without managing any underlying infrastructures such as VMs or Kubernetes. These platforms integrate with Dapr to make deploying and managing your applications easy. At the time of writing this article, the sole option for operating Dapr in serverless mode was to use the Azure Container Apps serverless platform.
Azure Container Apps is a serverless application hosting service where users do not see nor manage any underlying VMs, orchestrators, or other cloud infrastructure. Azure Container Apps enables you to run your application code in multiple containers and is unopinionated about runtimes or programming models used.
Dapr is built-in to Container Apps, enabling you to use the Dapr API building blocks without any manual deployment of the Dapr runtime. You simply deploy your services with their Dapr components.
Services invocation
This is another area covered by Dapr and is an excellent place to the extent of your knowledge. This is a prevalent issue, and the one present is most of the microservices-based solutions. The challenge is to make a call from one service to another and manage the addresses of the environments that the microservices are running on. There is a set of common challenges in this process. The first is no call service discovery to track the URL and IP address of the given microservice - this is challenging, though, because we know the code we like to address service by name rather than by an IP. The second challenge lies in communication security: we need to prevent calls from external sources if the service is to be used only internally in the solution. We also have to ensure that the communication is encrypted so no one can listen. Third, observability can be challenging in the microservices infrastructure.Dapr also handles that with Open telemetry tracing.
Last but not least, there is a challenge of retries in case of a mistake. We always have to be ready for an error in network communication. At the time of writing this article, the sole option for operating Dapr in serverless mode was to use the Azure Container Apps serverless platform.
This is how Dapr addresses this case. With the Service invocation block. Service invocation block provides several features to make it easy to call methods between applications. First of all, we have an mTLS authentication to keep the communication secure. In the event of call failures and transient errors, service invocation provides a resiliency feature that performs automatic retries with backoff periods. By default, all calls between applications are traced, and metrics are gathered to provide insights and diagnostics for applications. This is especially important in production scenarios, providing call graphs and metrics on the calls between your services.
Pub/Sub Messaging
Direct calls aren’t the only type of possible service-to-service communication.There is also pub/sub messaging. In this approach, the messages aren’t being sent directly. Instead, the sender sends them to a message broker and, in due time, receives them from the receiver. The example solution with this Dapr block can look like this.
But why should we use Dapr pub/sub API? Good question. The block provides us with a platform-agnostic API to send and receive messages and offers an at-least-once message delivery guarantee. It also integrates with various message brokers and queuing systems. This point is essential because the specific message broker used by your service is pluggable and configured as a Dapr pub/sub-component at runtime - this removes the dependency from your service and makes your service more portable and flexible to changes.
The application often works like this when we go with the pub/sub. Your service makes a network call to a Dapr pub/sub-building block API. The pub/sub building block makes calls into a Dapr pub/sub component that encapsulates a specific message broker.To receive messages on a topic, Dapr subscribes to the pub/sub-component on behalf of your service with a topicand delivers the messages to an endpoint on your service when they arrive.
As shown in the diagram above, the pub/sub approach has one huge benefit over the direct API call. In the graph below, a “shipping” service and an “email” service have both subscribed to topics published by a “cart” service. Each service loads pub/sub-component configuration files that point to the same pub/sub message broker component. So one message is received by the recipients, which is highly convenient when designing internal application communication.
So the Pub/Sub Dapr Messaging should be another point on the Dapr roadmap.
Monitoring
It is going to be the last roadmap item we are going to discuss. There are many more, of course, but we must draw a line somewhere. So in my honest opinion, the last item to look at should be the monitoring block. In the case of the Dapr solution, it is called observability and comprises three areas: tracing, view metrics and logging.
This diagram shows the introduction of observability to our Dapr infrastructure - as we can see the Dapr sidecars are using the collector. The advantage of it is that the approach to internal communication is consistent. Always sidecar based. Once the data is collected, we can freely monitor and visualize it as we like. This is huge because it blends perfectly into Dapr infrastructure and, as always withDapr doesn’t restrict us to a predefined set of tools.
Summary
That is it when it comes to Dapr series. I hope you will find it enjoyable and educative. Please remember that the work we did was only for one block. The series' goal was to show its approach to using Dapr and the design decision made by its creators. I believe we met this goal and encourage you to keep using and exploring Dapr usage in your day-to-day work.
If you have any questions, please drop me a line at karol.rogowski@softwarehut.com.
Till next time. Keep coding.
