<\/p>\n
Dapr \u2013 The Future of Cloud-Native development is here<\/p>\n
<\/h1><\/div>
Dapr v1.0.0 is here! To be precise, it was released tonight<\/a> and is now considered ready for use in production workloads. In fact, there are already companies that are successfully using Dapr in production. So why is this exciting? Read on to find out how Dapr can help you be more productive when developing distributed systems such as microservices.<\/p>\n\n\n\n .<\/mark><\/p>\n\n\n\n It is a novel application runtime, which does not limit developers to using a particular programming language, framework, or environment. This allows cloud-native developers to truly embrace the polyglot nature of microservices<\/a>. Furthermore, it is specifically aimed at simplifying developing distributed applications. A task that is commonly described as hard and error-prone. With Dapr this task becomes a lot easier. Possible use cases for Dapr are:<\/p>\n\n\n\n .<\/mark><\/p>\n\n\n\n Dapr, the Distributed Application Runtime, is a project initiated and announced by Microsoft on October 16, 2019. However, Dapr is not owned by Microsoft and is being transitioned to an open governance model. Hence, it is an open-source project that is publicly developed on GitHub<\/a>.<\/p>\n\n\n\n Dapr helps developers build event-driven, resilient distributed applications. Whether on-premises, in the cloud, or on an edge device, Dapr helps you tackle the challenges that come with building microservices and keeps your code platform agnostic.<\/p>\nDapr – portable, event-driven, serverless runtime.<\/a><\/cite><\/blockquote>\n\n\n\n To achieve this, Dapr is built on the sidecar pattern<\/a> using HTTP or gRPC APIs to communicate with the application code. The general idea is to encode industry best practices in building blocks to simplify distributed application development. Instead of a programming language-specific SDK or library to work with a third-party component, developers use a programming language agnostic Dapr building block. This decouples application code from third-party services and therefore simplifies using different programming languages.<\/p>\n\n\n .<\/mark><\/p>\n\n\n\n As already mentioned, Dapr consists of various building blocks that run as a sidecar alongside the application. Each building block specifies a behaviour and API that is implemented by Dapr components. Therefore, building blocks are the specification, whereas components are the actual implementation. This allows it to have several implementations for each building block, which can be swapped out without affecting the application. This is possible because the application only sees and implements the Dapr API, without knowing of the actual implementation of the building block. As a result, swapping out third-party dependencies can be done in a declarative way. The only thing that changes is the YAML file that specifies the third-party components behaviour.<\/p>\n\n\n In Kubernetes, the sidecar providing the Dapr functionality runs a separate Container in a Kubernetes Pod. For those, that are familiar with Service Meshes<\/a>, this should sound familiar. The general concept of using a sidecar to extend the functionality of an application is similar between Dapr and Service Meshes. However, in contrast to Service Mesh sidecars, which are transparent to the application, Dapr sidecars are meant to be explicitly invoked by the application via HTTP or gRPC.<\/p>\n\n\n .<\/mark><\/p>\n\n\n\n Dapr building blocks are pluggable and opt-in, so cloud-native developers can choose only the functionality they need. They provide the functionality to build resilient, event-driven and stateful distributed applications without the complexity of implementing it yourself.<\/p>\n\n\n .<\/mark><\/p>\n\n\n\n The service-to-service invocation<\/a><\/em> building block provides distributed applications with service discovery and service invocation. As can be seen in the following example, the python app<\/em> can invoke a service by simply calling an HTTP endpoint via POST with the data to invoke the method in the node app<\/em>. In this example, Dapr takes care of service discovery, service invocation, security, handling of retries, dealing with transient errors and even distributed tracing, all without adding a single line of code to the python or node app. In short, Dapr provides developers with an endpoint that acts as a reverse proxy with built-in service discovery and additionally offers distributed tracing, metrics, and error handling.<\/p>\n\n\n .<\/mark><\/p>\n\n\n\n The state management<\/a><\/em> building block offers Key\/Value storage APIs to communicate with third-party state stores. To store data in a state store component, the myApp<\/em> application only needs to send a POST request to the Dapr sidecar with the name of the state store, myStateStore<\/em> in the example below, and the data in a key\/value format in JSON. Retrieving data is done in an equivalent way by sending a GET request to the Dapr sidecar. Again, the state store must be specified, and in this case additionally the key to the data, which is planets.<\/em> This sounds trivial at first, but Dapr additionally handles distributed concurrency, data consistency, retry policies and even bulk CRUD operations. All this is provided via an easy-to-use to use API without the need to add or learn a third-party SDK to the application.<\/p>\n\n\n The publish and subscribe<\/a><\/em> building block enables distributed applications to communicate asynchronously via Messages. This pattern is particularly useful for decoupling microservices from each other. Traditionally, however, this creates a dependency on a message broker or queuing system that manages topics<\/em> where applications publish messages or subscribe to receive messages. In addition, there is a dependency on a specific third-party component and code in each application to interact with it. With Dapr, this coupling to a specific pubsub<\/em> component is removed, making the application more portable. Furthermore, Dapr offers an at-least-once delivery guarantee, consumer groups with multiple application instances and topic scoping. Again, this is provided without adding code or new SDKs to the application.<\/p>\n\n\n A complete overview over all building blocks and their technical details can be found in the Dapr Docs building blocks<\/a> section.<\/p>\n\n\n\n .<\/mark><\/p>\n\n\n\n To start developing with Dapr you should head over to the Dapr Docs getting started section<\/a>. Dapr provides you with an easy-to-use CLI and can be run in self-hosted mode or in Docker containers. Thus, setting up a development environment is simple and done in minutes. To set up Dapr you only need to run a simple:<\/p>\n\n\n\n This gives you a Redis container instance<\/em> for state management and publish and subscribe, a Zipkin container instance for observability, a default components folder holding component definitions for the Redis and Zipkin containers and a Dapr placement service container instance for actor support. So, with a single command, you are ready to go. Now starting an application with a Dapr sidecar is as simple as running the following line of code. In detail, it says to run a Dapr sidecar on port 3500<\/em> alongside the application myapp<\/em>, which must be defined in a components YAML file in advance.<\/p>\n\n\n\n Furthermore, Dapr provides developers with several SDKs<\/a> to simplify interaction with Dapr in the respective language. However, the SDKs are completely optional and only a convenience layer above the HTTP or gRPC API.<\/p>\n\n\n\n Now to see how this works in practice, check out our Dapr-demo on GitHub<\/a>. It demonstrates the use of the service invocation<\/em>, state management<\/em> and publish & subscribe<\/em> building blocks in a polyglot microservice architecture.<\/p>\n<\/blockquote>\n\n\n\n .<\/mark><\/p>\n\n\n\n We think Dapr is an exciting technology and the next evolutionary step for cloud-native development after Service Meshes. It has the potential to simplify the development of distributed applications and finally make polyglot microservice architectures a viable choice. So, in conclusion, if you are a distributed application developer, you should check out Dapr!<\/p>\n\n\n\n Many thanks to all contributors<\/a> who make this open source project possible at all!<\/p>\n","protected":false},"excerpt":{"rendered":"Why is Dapr relevant to you?<\/h2>\n\n\n\n
\n
What is Dapr?<\/h2>\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/dapr-logo.png\"){kind=logo}
<\/figure>\n<\/div>\n\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/image-23-1024x486.png\")
<\/figure>\n<\/div>\n\n\nHow does it work?<\/h2>\n\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/overview_kubernetes-1024x542.png\")
<\/figure>\n<\/div>\n\n\n![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/overview-sidecar-kubernetes-1024x450.png\")
<\/figure>\n<\/div>\n\n\nBuilding Blocks Overview<\/h2>\n\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/building_blocks-1024x416.png\")
<\/figure>\n<\/div>\n\n\nService-to-Service Invocation<\/h3>\n\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/service-invocation-overview-example-1024x472.png\")
<\/figure>\n<\/div>\n\n\nState Management<\/h3>\n\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/state-management-overview-1024x491.png\")
<\/figure>\n<\/div>\n\n\nPublish and Subscribe<\/h3>\n\n\n\n
![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/pubsub-publish-subscribe-example-1024x421.png\")
<\/figure>\n<\/div>\n\n\nMore<\/h3>\n\n\n\n
Developing with Dapr<\/h2>\n\n\n\n
dapr init<\/code><\/pre>\n\n\n\ndapr run --app-id myapp --dapr-http-port 3500<\/code><\/pre>\n\n\n\n\n
Conclusion<\/h2>\n\n\n\n