Dapr is an open source, portable, event-driven runtime that makes it easy for developers to build resilient, microservice, stateless and stateful applications that run on the cloud and edge. Dapr enables developers to focus on writing business logic and not solving distributed system challenges, thereby significantly improving their productivity, and reducing development time. Dapr lowers the bar for entry to build modern cloud native applications based on a microservices architecture and with this v1.0 release, Dapr applications can be deployed to self-hosted infrastructure or Kubernetes clusters in production scenarios.
Here you find an E-book about Dapr for .NET Developers
Foreword by Mark Russinovich Azure CTO and Technical Fellow Microsoft
With the wave of cloud adoption well underway, there is a major shift happening towards “cloud native” development, often built with microservice-architectures. These microservices are both stateless and stateful, and run on the cloud and edge, embracing the diversity of languages and frameworks available today. This enterprise shift is driven by both the market forces of faster time to market, as well as the scale and efficiencies of building services for the cloud. Even before COVID-19, cloud adoption was accelerating for enterprises and developers were being asked to do even more to deliver on building these distributed system applications, and that has only accelerated since. Developers in enterprises seek to focus on business logic, while leaning on platforms to imbue their applications with scale, resiliency, maintainability, elasticity, and the other attributes of cloud-native architectures, which is why there is also shift towards serverless platforms that hide the underlying infrastructure. Developers should not be expected to become distributed systems experts. This is where Dapr steps in to help you, whether you are building on infrastructure such as Kubernetes, or on a serverless platform.
Dapr is designed as an enterprise, developer-focused, microservices programming model platform with the mantra “any language, any framework, run anywhere”. It makes building distributed applications easy and portable across any infrastructure, from public-cloud, through hierarchical edge, and even down to single node IoT devices. It emerged from both our experiences building services in Azure as well as time spent working with customers building applications on Azure Kubernetes Service and Azure Service Fabric. Over and over, we saw common problems that they had to address. It became clear that there was a need to provide a “library” of common microservice best practices that developers could use, not only in new greenfield applications, but also to aid in the modernization of existing applications. In the containerized, distributed, and networked cloud native world, the sidecar model has emerged as the preferred approach, in the same way DLLs are preferred in the client/server generation. Using Dapr’s sidecar and APIs give you, as a developer, all the power of distributed systems functionality, with the ease of a single HTTP or gRPC local call.
To address the wide range of scenarios that developers face, Dapr provides features such as state management, service to service invocation, pub/sub and integration to external systems with I/O bindings, which are based on the triggers and bindings of Azure Functions. These in turn take advantage of Dapr’s component model which allows you to “swap out”, say different underlying state stores, without having to change any code, making code more portable, more flexible and allowing for experimentation of what best suits your needs. Developers don’t need to learn and incorporate service SDKs into their code, worry about authentication, secret management, retries or conditional code that targets specific deployment environments.
This book shows how Dapr reduces your development time and overall code maintenance by incrementally “Daperizing” the canonical .NET reference application, eShop. For example, in the original eShop implementation, significant amounts of code were written to abstract between Azure Service Bus and RabbitMQ for publishing events between services. All this code can be discarded and simply replaced with Dapr’s pub/sub API and component model which had an even wider range of pub/sub brokers, rather than just two. Dapr’s actor model, when used in the reworked eShop application, shows the ease of building long running, stateful, event driven, workflow applications with all the difficulties of concurrency and multi-threading removed. By the end of this book, you will see the drastic simplification that Dapr brings to your application development, and I firmly believe all developers embarking on a cloud native app building journey should leverage Dapr.
We publicly announced Dapr with the v0.1 release in Oct 2019 and now, a year and half later, I am thrilled to say that Dapr is ready for production usage with the v1.0 release. Getting Dapr to v1.0 has truly been a community effort. It has been amazing to see the open-source community coalesce around Dapr and grow since it was first announced – from 114 contributors in October 2019 to over 700 in early 2021 – a six-fold increase in 16 months! Contributions to the project have gone to every Dapr repo and have ranged from opening issues, commenting on feature proposals, providing samples, and of course contributing code. The parts of the project community members have contributed to the most include the Dapr runtime, docs, CLI, SDKs and the creation of a rich ecosystem of components. Maintaining this openness is critical to Dapr’s future.
Dapr is really just getting started, though, and you should expect to see more Dapr capabilities and more support for Dapr in Azure services. I hope that you will take advantage of Dapr to enable you to focus on your core business logic and accelerate your microservices development. I am are excited to have you join us in the Dapr community on this journey at https://github.com/dapr/ and on Discord https://aka.ms/dapr-discord.
Modern distributed systems are complex. You start with small, loosely coupled, independently deployable services. These services cross process and server boundaries. They then consume different kinds of infrastructure backing services (databases, message brokers, key vaults). Finally, these disparate pieces compose together to form an application.
Mark Russinovich Azure CTO and Technical Fellow Microsoft
Thank you Author; Rob Vettor, Sander Molenkamp and Edwin van Wijk for this Awesome E-book 😉
