This document provides an overview of Dapr, an open source runtime that makes it easier to build distributed applications. It discusses key Dapr concepts like building blocks, sidecars, and SDKs. It demonstrates Dapr capabilities for service invocation, pub/sub, state management, actors, secrets, and observability. The document concludes that Dapr is suitable for most teams by helping develop faster with portability and a focus on application logic rather than infrastructure.
8. CNCF cloud native definition
Cloud native technologies empower organizations to build and run
scalable applications in modern, dynamic environments such as public,
private, and hybrid clouds. Containers, service meshes, microservices,
immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient,
manageable, and observable. Combined with robust automation, they
allow engineers to make high-impact changes frequently and predictably
with minimal toil.
The Cloud Native Computing Foundation seeks to drive adoption of this
paradigm by fostering and sustaining an ecosystem of open source,
vendor-neutral projects. We democratize state-of-the-art patterns to
make these innovations accessible for everyone.
Source: https://github.com/cncf/toc/blob/main/DEFINITION.md
13. Challenges with Distributed Apps
▪ Lots of components / services
▪ Service-to-service communication
▪ Decoupling by using events
▪ Handling state across multiple instances
▪ Stateful services / actors
▪ Local dev environment vs. cloud
environment
19. Dapr
▪ dapr.io
▪ Open source
▪ Originated at Microsoft
▪ Cloud Native Computing Foundation
(CNCF)
20. Dapr – High Level Definition
▪ Any language or framework
▪ Portable APIs
▪ Building blocks applying best practices
▪ Use the blocks you need
▪ No big bang framework
▪ Platform agnostic
▪ Extensible and pluggable components
35. Service Invocation
▪ HTTP and gRPC
▪ mTLS (with Dapr Sentry)
▪ Resiliency including retries
▪ Tracing and metrics with
observability
▪ Access control (policies)
▪ Namespace scoping
▪ Load balancing (round robin
with mDNS)
▪ Pluggable service discovery
https://docs.dapr.io/developing-applications/building-blocks/service-invocation/service-invocation-overview/
38. Publish & Subscribe
▪ Platform-agnostic API to
send and receive messages
▪ At-least-once message
delivery guarantee
▪ Integration with various
message brokers
▪ CloudEvents 1.0 specification
▪ Message content type
▪ Content-based Routing
▪ Dead letter topics
▪ Namespace consumer groups
▪ Scoping topics
https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview/
39. Competing consumers pattern
▪ Multiple application instances
using a single consumer
group
▪ Same app id = same
consumer group
▪ Dapr delivers each message
to only one instance of that
application
https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview/
42. State Management
▪ Configurable state store
behavior (default eventually
consistent, last-write-wins
concurrency pattern)
▪ Optimistic concurrency with
ETag
▪ Time to live (TTL)
▪ State encryption
▪ Querying state
https://docs.dapr.io/developing-applications/building-blocks/state-management/state-management-overview/
46. Actors
▪ Virtual Actor pattern
▪ Stateful, long running
objects with identity
▪ Encapsulate state and
behavior within a distributed
system
▪ Actor state store
▪ Actor timers and reminders
https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/
52. Input/Output Binding
▪ Trigger your app with events
coming from external
systems
▪ Handle retries and failure
recovery
▪ Portable app with
environment-specific
bindings
https://docs.dapr.io/developing-applications/building-blocks/bindings/bindings-overview/
56. Observability
▪ Distributed tracing
▪ Open Telemetry (OTEL) and
Zipkin protocols
▪ Used with service invocation
and pub/sub APIs
▪ Sidecar health
▪ App health checks
▪ Unsubscribing Pub/Sub
▪ Stop input binings
▪ Short-circuiting all service-invocation
requests
https://docs.dapr.io/developing-applications/building-blocks/observability/tracing-overview/
59. Pros / Cons
Advantages
▪ Develop faster
▪ Best practices
▪ Portability
▪ Focus on your logic
Disadvantages
▪ Additional hop /
network overhead
▪ Common API – less
features
60. Conclusion
▪ Suitable for most teams and applications
▪ Base your development on proven best
practices
▪ Ideal, if portability is key (different
environments / clouds, local, etc.)
62. Thank you for your attention!
If you have any questions do not hesitate to contact us:
4tecture GmbH Marc Müller
Industriestrasse 25 Principal Consultant
CH-8604 Volketswil
+41 44 508 37 00 marc.mueller@4tecture.ch
info@4tecture.ch @muellermarc
www.4tecture.ch www.powerofdevops.com