Q&A

Q&A: Dapr for Building Distributed .NET Applications

• By David Ramel
• 05/03/2022

Modern distributed applications require much more than just application logic. Features such as state management for services, communication using publish/subscribe messaging and event-driven binding to cloud resources might be needed. Dapr introduces a runtime to offer such building blocks, and is less invasive in your application, allowing you to pick-and-choose what you need.

Dapr has become so instrumental in the .NET space for distributed applications that it's the subject of an upcoming advanced-level workshop to be conducted by Alex Thissen at the Visual Studio Live! conference set for June 13-17 in Austin, Texas.

Thissen, an architect, lead developer and mentor at large enterprises and small companies, will conduct the workshop titled Dapr for Building Distributed .NET Applications on June 17.

The workshop will look at the approach that the Dapr runtime takes with a sidecar architecture, separating application logic from the Dapr runtime components while showing attendees how to develop distributed applications in .NET using Dapr's features and how to bind to messaging infrastructure, cloud resources and use the actor programming model and client proxies. Coders will also learn to combine Dapr in ASP.NET Core applications using routing, controllers and middleware.

In advance of the workshop, we caught up with Thissen to learn more in a short Q&A.

VisualStudioMagazine: Microsoft says Dapr addresses a large challenge inherent in modern distributed applications: complexity. How so?
Thissen: Distributed applications in a modern architecture and cloud environment are inherently complex. Dapr provides an abstraction at the application level and takes away a considerable portion of this complexity.

The challenges of service communication and discovery, pub/sub messaging patterns, storage and multithreading and high levels of concurrency are made easy by the building blocks of Dapr. The languages help combine application logic with the use of the building blocks in native constructs. Developers can concentrate on the logic instead of having to learn and use the low-level details of the cloud services being used.

What are some examples of those building blocks?
The building blocks cover storage, secret management, service-to-service communication, pub/sub patterns, actor programming model, configuration, observability and bindings to cloud services. There is a long list of specific blocks for each of these. These include many services from Microsoft Azure, Google Cloud Provider and Amazon Web Services. The application logic is agnostic of the specific block being used, so changing block is relatively easy.

Can you briefly describe what a sidecar architecture is?
A sidecar architecture leverages the ability of a container orchestrator to host container instances with additional accompanying containers tightly connected to each other. These extra containers are sidecars and help the main container in providing extra functionality. Dapr uses sidecars to provide secure mutual TLS communication to other services, service discovery, distributed tracing and the binding to the various cloud services.

What's the biggest pain point developers typically find in learning to use Dapr?
Dapr uses Kubernetes as its production hosting environment. Dapr itself is quite approachable, but learning Kubernetes is daunting and challenging. Developers will need to get acquainted with container technology in general and Kubernetes as container orchestrator in particular.

Dapr is described as an open source project sponsored by Microsoft. What benefits does that sponsorship provide to .NET-centric developers?
.NET is a first-class citizen for Dapr to implement applications using the application runtime. So are other languages such as Go and C++. The benefits for .NET developers are the long-time support implied by the involvement of Microsoft. Also, .NET will often be one of the first to get support for new features in Dapr.