In this series of blog posts, we will get to know everything there is to know about Distributed Application Runtime, also known as the Dapr. The plan is to start with an introduction of a solution, as well as a theory. After that, we will take a deep dive into the technical aspects of the solution. So, without further ado, join me on this Dapr learning adventure, let’s start.
What is it?
To find out what Dapr, is we need to start somewhere. And the best place to start is at the beginning. That’s cheesy, I know – but hey! So, it all begins at https://dapr.io/. On that website, there is a graphic that puts us on the right track when it comes to understanding what Dapr is.
Dapr focusses on common problems that we can face while creating microservice base applications. It provides us with a set of solutions to help solve these problems. These solutions come in the form of building blocks.
Each of these building blocks focus on a different part of the solution. But don’t worry, we’ll get to those in a moment. What we need to know for now is that they all are APIs and can be called by any application that can send a HTTP request.
The great thing about this approach is that it is modular, and that we are not forced to use all the blocks in our solution. We are free to pick and choose based on what we currently need. For example, I can decide to only apply the State Management block and Secrets block in my application. That course of action would be perfectly valid. So, if you are eager to find out more about Dapr, feel free to read up on the Dapr official documentation at https://docs.dapr.io/.
Why would I want to use it?
As is the case with such a versatile solution, there are many reasons for using it. I will focus on the one that, in my case, was the key selling point.
In solving standard issues, as we will see along the way, Dapr’s main purpose is to solve common problems in an organized way. This cause stood out for me, as well as for many other users.
As it’s easy for testing – thanks to Dapr being modular and configurable – you’re able to test against it, or against a portion of it. By being highly configurable, it also helps throughout the testing process tremendously.
Being vendor agnostic and interchangeable – as we can see on two graphics below that Dapr is an API layer operating over infrastructure elements. The observability block can be configured to use Jaeger, AppInsights, ZIPKIN or other, while the Pub or Sub block can be configured to use kafka, RabbitMQ or any other Cloud based Pub and Sub solution. This agnostic approach makes our application agile on an infrastructural level. If we want, we can swap the AWS based infrastructure to an Azure one, without affecting the Dapr API layer.
Problems
A good question to ask at this point will be: What problems can I solve thanks to Dapr? To be honest, people creating microservice-based applications usually face the same issues. Here are some most common instances that Dapr will help us with.
Discovering services
“Hey John! Where was that API hosted?!” Hands up if you never had this conversation. This is an intensely recurring issue. I’m of course talking about service’s location, aka. service discovery. Dapr makes it that much easier because we can work using a dictionary-like approach. So, this problem effectively comes off the table.
Securing communication
Since microservices can be build using many different technologies and frameworks, securing lines of communication can be an immense challenge. Dapr helps us with that. By standardizing communication security. All service-to-service communication can be secured with mutual TLS. We can also define an ‘allow’ list for improved access control.
Monitoring system health
As just as it is important to address errors, it is essential to engage in system health monitoring. The layer provided by Dapr allows us to monitor pain points and performance more intuitively. The monitoring is carried out by metrics, tracing, and logs. What’s more, is to make it super easy, Dapr uses industry-standard such as OpenTelemetry.
Summary
As promised, I have given you a short introduction to Dapr, as well as the overall look of this project. What’s more, was that I was also mindful to not share any lines of code in this blog post. Doing so, would’ve changed the tone of this entire post. So, I hope I kept things simple.
I can promise that in the next instalment, there will however be a lot of code. We will demonstrate the process step-by-step, to show our work on microservice solutions, while of course, applying Dapr to improve it.
If you have any questions, please drop me a line at karol.rogowski@softwarehut.com.
Until next time. Keep coding!
