Dapr is "An event-driven, portable runtime for building microservices on cloud and edge." Being an exciting open source project, it attracts a lot of developers and with them, lots of questions :)
I thought it might be helpful to answer (or provide pointers) to some of them here. I have seen/heard these (in different forms) at various places including conferences/webinars, Dapr Gitter, Twitter DMs or one-one conversations (oh yes those exist too!) etc.
Is Dapr a Service mesh, what's the difference ?
Or sometimes, this is phrased as, "Can I use Dapr with Service mesh?"
Good news is that this has already being covered in one of the Dapr community calls - "Introduction to Dapr and Service Meshes. How they relate, when to use one verses the other...."
TL;DR
- Service meshes are closer to infrastructure layer and operator concerns
- Dapr is closer to applications layer which developers are reponsible for
- There is an overlap between Dapr and Service meshes ...
- ... but, you can use them together as well - see a demo of Dapr and Linkerd working together
Dapr is a "runtime" - what does that mean?
I thought about this as well, when I first started exploring Dapr. In my specific case (Java middleware background), "runtime" was an application server which provided a "managed environment" (concurrency, security etc.) to my code (WAR, EAR etc.)
That's not the case with Dapr. It is a "Runtime" that operates along with your application using a sidecar architecture - your application does not run "inside it". In standalone mode, Dapr simply runs as a different process and in Kubernetes, it runs as a (sidecar) container in the same Pod as your application
(Myth) Dapr depends on Docker
Guess what, this was also covered in one of the community calls, which showcased Dapr working in standalone mode on an AWS EC2 instance
TL;DR
- "Dapr needs docker" == false
- In standalone mode, Dapr runs as a process
- In Kubernetes, there is some magic going on - one of them being the sidecar injection which is taken care of by the
dapr-sidecar-injectorPod (check out the implementation here)
Use this link if you want to jump straight to the demo
What about Docker Compose support?
Right now, with the Dapr CLI, dapr init will start Dapr (using Docker) and you can then start your app along with Dapr using dapr run. But a common use case is to run treat these as a single unit, and Docker Compose helps with that
The answer? Of course it is!
Check out:
- Docker Compose sample - https://github.com/dapr/samples/tree/master/10.hello-docker-compose
- and this Extend mDNS to support custom host enhancement which made this possible
... and this demo on yet another awesome Dapr community calls!
Use this link if you want to jump straight to the demo
Pub/sub and Bindings - what's the difference?
With Bindings, you can interact with external systems:
- Input bindings: trigger your app with events coming in from external systems
- Output bindings: invoke external systems
Pub/Sub on the other hand is for Dapr apps to communicate amongst themselves (inter-app messaging) in a decoupled and asynchronous manner.
That's it.. for now!
But I do want to leave you with a few handy resources:
- You're most welcome to join the community call which I referred to so many times! https://github.com/dapr/dapr#community-call
- Get started https://github.com/dapr/docs/tree/master/getting-started
- Try out the sample apps https://github.com/dapr/samples
- Connect, follow, ask questions! https://github.com/dapr/dapr#contact-us
- Contribute! https://github.com/dapr/dapr/blob/master/docs/development
Until next time!
Top comments (0)