Introducing Dapr : cloud-native applications at speed
Dapr stands for Distributed Application Runtime. Its mission is to simplify the life of developers working on microservices and distributed applications. The runtime is fundamentally event-driven since it embraces pub/sub async communication and many other communication mechanisms to support many scenarios.
Where it helps?
Microservices, cloud-native or distributed applications share some pain points. Before getting the benefits of those kind of architectures, you have to manage the added complexity. Here’s a short list of some examples you could think of:
- Increasing inter-process calls relying on network
- Transient faults of the underlying infrastructure
- Integrations with multiple dependencies implies a lot of learning (SDKs, APIs, …)
- Local development with many cloud services
- Distributed tracing
Dapr could help a lot by encapsulating many solutions to these problems in a sidecar component.
Architecture
Dapr’s architecture is based on the sidecar pattern. Basically, you’ll have to run a small process next to your application to execute some cross-cutting concern logic and to interact with your external dependencies.
This pattern is well known in the Kubernetes’ world because it’s easy to implement within a pod. Even though Kubernetes is the preferred scenario for production applications with Dapr, it’s not a hard requirement.
This architecture is interesting because it permits to have a lot of possible scenarios while deploying your application. You’ll find lot more information on hosting and architecture here :
https://docs.dapr.io/operations/hosting/
Performance
You may think that it could be a performance issue to have a separate process by which all the traffic is going, but Dapr have a very small performance hit in terms of latency. (1-2ms)
Building blocks
There’s many building-blocks already available with the 1.0 release of Dapr. Here is a high-level list :
All those building-blocks can be consumed in an opt-in model depending on your needs. All you have to do is to make an HTTP or gRPC call to the sidecar. Depending on the url you use, you’ll hit the right building-block.
To get an idea of the potential of Dapr, let’s describe what some building-blocks can do for you.
Service-to-Service invocation
In a microservice world, when calling another API or service, you have to deal with small network faults or with transient fault from the remote service. For example, the orchestrator (K8s) may need to reschedule a pod to free some space on a node which may cause some connections to be dropped if the remote container doesn’t handle this carefully. Using the Service-to-Service building-block, you’ll get automatic retries to manage some of those use cases.
You’ll also get free service discovery. It’s built-in in Kubernetes, but you’ll have the same behavior while running locally on your computer. Also, you can leverage the default mTLS feature which helps to do end-to-end packet encryption.
Observability
Some standards are emerging at the moment in the observability OSS space. Many tools will require your application to add some code to send traces and metrics. With Dapr, since the sidecar sees all the communications, it can send information to your favorite distributed tracing tools like Zipkin, Jeager or Application Insights.
Others
Going deeper on all of these building-blocks is out of scope of this post, but you’ll find all the information on the docs :
https://docs.dapr.io/concepts/building-blocks-concept/
Caveats
Dapr is a very promising project and it will be very interesting to see where the maintainers and the community will go. Nevertheless, here are some limitations that you’ll have to overcome if you want to start using it.
- Custom traces:
- While you get free observability, you can’t send your custom traces to this tooling. It’s coming soon.
- Pub/sub:
- The only pub-sub pattern supported is the at-least once delivery guarantee.
- State Store:
- Partial updates, complex queries, batching
I think it’s not a big problem to have some limitations right now. You can use Dapr where it fits and use other tools when you face limitations. When new features become available, you’ll have the choice to remove your implementation and leverage the Dapr building-blocks and components.
Future
What’s super exciting about Dapr is its potential. The team is looking at supporting other hosting models like Web Assembly and Edge computing.
Web Assembly could ultimately be a way to make SPA applications part of a Dapr-Mesh. If the sidecar could be compiled and run on the browser, it will allow developers to build terrific applications.
Considering Edge computing, Dapr could be a great way to support partially connected devices. With his abstraction level for many building-blocks, you could use local components when you lose the connection or when you have to leverage local compute capacities.
The future of Dapr is very interesting!
Resources
Finally, you’ll find more resources on Dapr following these links :
https://dapr.io/
https://docs.dapr.io/
https://discord.com/invite/ptHhX6jc34
https://github.com/karoldeland/daprShowcase (my samples)
https://www.oreilly.com/library/view/learning-dapr/9781492072416/
https://www.amazon.ca/Practical-Microservices-Dapr-NET-cloud-native/dp/1800568371
https://docs.microsoft.com/en-us/dotnet/architecture/dapr-for-net-developers/
https://github.com/dotnet-architecture/eshopondapr
https://github.com/vietnam-devs/coolstore-microservices
Conclusion
Dapr is only on its starting block and it’s gaining a lot of popularity. I hope it will achieve his goal of simplifying the cloud-native/microservices developers’ lives.
I hope you’ll enjoy this project as much as I do ! 🙂
Recent Comments