In Data Engineer’s Lunch #39 Dapr Cloud, we will discuss getting started with Dapr. The live recording of the Data Engineer’s Lunch, which includes a more in-depth discussion, is also embedded below in case you were not able to attend live. If you would like to attend a Data Engineer’s Lunch live, it is hosted every Monday at noon EST. Register here now!
Today we are experiencing a wave of cloud adoption. Developers are comfortable with web + database application architectures (for example classic 3-tier designs) but not with microservice application architectures which are inherently distributed. It’s hard to become a distributed systems expert, nor should you have to. Developers want to focus on business logic while leaning on the platforms to imbue their applications with scale, resiliency, maintainability, elasticity, and the other attributes of cloud-native architectures.
This is where Dapr comes in. Dapr codifies the best practices for building microservice applications into open, independent building blocks that enable you to build portable applications with the language and framework of your choice. Each building block is completely independent and you can use one, some, or all of them in your application.
In addition, Dapr is platform-agnostic, meaning you can run your applications locally, on any Kubernetes cluster, and in other hosting environments that Dapr integrates with. This enables you to build microservice applications that can run on the cloud and edge.
Using Dapr you can easily build microservice applications using any language and any framework, and run them anywhere.
Microservice building blocks for cloud and edge
Sidecar architecture
Dapr exposes its HTTP and gRPC APIs as a sidecar architecture, either as a container or as a process, not requiring the application code to include any Dapr runtime code. This makes integration with Dapr easy from other runtimes, as well as providing separation of the application logic for improved supportability.
Self-hosted
In self-hosted mode Dapr runs as a separate sidecar process which your service code can call via HTTP or gRPC. Each running service has a Dapr runtime process (or sidecar) which is configured to use state stores, pub/sub, binding components and the other building blocks.
You can use the Dapr CLI to run a Dapr-enabled application on your local machine. Try this out with the getting started samples.
Kubernetes hosted
In container hosting environments such as Kubernetes, Dapr runs as a sidecar container with the application container in the same pod.
The dapr-sidecar-injector and dapr-operator services provide first-class integration to launch Dapr as a sidecar container in the same pod as the service container and provide notifications of Dapr component updates provisioned in the cluster.
The dapr-sentry service is a certificate authority that enables mutual TLS between Dapr sidecar instances for secure data encryption. For more information on the Sentry service, read the security overview
Deploying and running a Dapr-enabled application into your Kubernetes cluster is as simple as adding a few annotations to the deployment schemes. Visit the Dapr on Kubernetes docs
