Running Event-Driven Pub/Sub Microservices In Kubernetes With Dapr
HTML-код
- Опубликовано: 31 июл 2024
- Dapr simplifies microservice communication through direct or event-based pub/sub messaging and helps us develop resilient and secured microservices. It performs service discovery, message broker integration, encryption, observability, secret management, and many other tasks.
In this video, we are focusing on pub/sub events.
#Dapr #Microservices #Events
Consider joining the channel: / devopstoolkit
▬▬▬▬▬▬ 🔗 Additional Info 🔗 ▬▬▬▬▬▬
➡ Gist with the commands: gist.github.com/8d941690a087b...
🔗 Dapr: dapr.io
🎬 What is microservices architecture?: • What is microservices ...
🎬 How Microservices Communicate? Sync vs Async. Direct vs Brokers And Event Busses: • How Microservices Comm...
▬▬▬▬▬▬ 💰 Sponsoships 💰 ▬▬▬▬▬▬
If you are interested in sponsoring this channel, please use calendly.com/vfarcic/meet to book a timeslot that suits you, and we'll go over the details. Or feel free to contact me over Twitter or LinkedIn (see below).
▬▬▬▬▬▬ 👋 Contact me 👋 ▬▬▬▬▬▬
➡ Twitter: / vfarcic
➡ LinkedIn: / viktorfarcic
▬▬▬▬▬▬ 🚀 Courses, books, and podcasts 🚀 ▬▬▬▬▬▬
📚 Books and courses: www.devopstoolkitseries.com
🎤 Podcast: www.devopsparadox.com/
💬 Live streams: / devopsparadox
▬▬▬▬▬▬ ⏱ Timecodes ⏱ ▬▬▬▬▬▬
00:00 Introduction
02:26 Deploying (Real) Microservices
09:34 What Is Dapr?
12:49 Microservices Communication With Pub/Sub Events Through Dapr
20:37 Dapr Pros And Cons 
Развлечения
Are you using pub/sub messaging? If you are, how do you orchestrate communication?
IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), RUclips tends to delete comments that contain links. Please do not use them in your comments.
Yes please a video talking about differences between service meshes vs dapr using tls or other protocols.
I really loved the idea of using event-driven approach instead of synchronous communication thank you victor for this amazing video I can't wait for the next video comparing service mesh to Daper
I love Dapr!!! Like its architecture and functionalities.
I've been following dapr for sometime now. I had the same reaction when I understood the problems it's solving, it blew my mind. Would be awesome if you do a video series about it. Thanks for your videos!
Greaaaattt!!!
I was waiting for this one ^^
Thanks a lot!!!
One thing I love with Dapr is this abstraction it adds for example by using the sdk we can decide to replace redis by kafka or another pub/sub hub without change nothing in the code. and this is fantastic!!! :)
Now a combo knative serving + dapr should permit something beautiful... :)
Actually I consider Dapr as a service mesh alternative for decoupled communication with all service mesh benefits!!
Stumbled upon an absolute gem of a video
Great video! I've been advocating DAPR since its inception and find it equally fascinating. Unfortunatelly I've encountered a lot of pushback, probably because I dodn't have such positive energy like you on this vid ;). For me DAPR fills the gap that's left in serverless space. Serverless doesn't offer enough knobs and buttons for my taste, it doesn't address stateful workloads well, and that's why I think that having DARP combined with Azure Container Apps is an extremely powerful solution.
Would love to see more about daor! Awesome work, you videos are excellent
Yeah would be interesting to see comparison of service mesh and daper. Thanks for video great approach to show yaml and keep video on background looks nice.
Thanks for that. I was afraid that the new "style" might not be received well.
Complex microservice architecture explained nicely and concisely ! I will wait for all other aspects of dapr and service mesh vs dapr. Thanks Victor !
Great video, thanks!
Well done! I see use cases where we would be able to leverage some of this right away.
I really like the new style! 👍
Thanks
great video, thank you, yes looking forward to your suggestion at the end, dapr vs service mesh usages
I just moved it close to the top of my TODO list.
Thanks. Really awesome video and example!! I started to get more interested when they joined CNCF last year. It would be nice to see the ecosystem and tooling used to monitor, tracing and debuging appllications usnig Dapr. Also if it integrates with defacto standard such as Prometheus, Jaeger, etc...
Thanks!
Thanks a ton!
Great
Yes. Please do explore the other capabilities. Can Dapr also support direct communication between services? Like is it possible to hit a service directly with a request to also get a direct response? Edit: Ok. Reading the Dapr docs, I think what I'm asking for is "service invocation". Correct me if I am wrong. :) Edit2, just read the video description and it says through direct or event-based pub/sub. Cool. Looking more into Dapr as this question in my quest for a comms system to back up the platform of apps I want to build hasn't yet been answered.
Yeah. It supports both direct and pub/sub communication (among other things).
please make more videos on Dapr explaining all its features.
It's ready on my list but I cannot yet say when it'll come.
@@DevOpsToolkit can you help me understand when to use Camunda Workflow automation, and how does it relate to microservices ? (if thats in your list, would you recommend using Camunda or you have some other preferences ? )
Unfortunately, i haven't used Camunda so i can't comment on it 😟
I would like to see a video comparing dapr and service mesh.
Great! I'll bump it towards the top of my TODO list.
@@DevOpsToolkit One more vote for a bump up :)
Thank you a lot for that video! Again! :)
Can you please elaborate about running tests with Dapr? Especially for component testing that will run locally and as part of CI pipeline?
Thank you!
Setting up Dapr in a dev/test environment should not be a problem. What might be a bit challenging is to check Event Store (e.g., Reddis) for messages. Think of it in the same way as if you're testing an app that reads or writes to a DB. You can use a "real" store or mocks/stubs.
Thanks Victor again! Really amazing video. I will test dapr soon. I'm already waiting for dapr and service mesh video comparison. Did you know something about troubleshoot dot sh? Maybe one video about it. Just a suggestion. Thanks again!
I'm ahead of you :)
ruclips.net/video/Qz5YTVDEJm0/видео.html
@@DevOpsToolkit thanks again. I will watch it. Do you know anything open source tool that makes similar work as replicated (same guys that creates troubleshoot)?
@@betorvs I still haven't used Replicated so I cannot compare it with others. Let me dig into it first...
Can you make a difference between dapr and knative eventing.
There is overlap in terms that both can help to manage pub/sub events. The major difference is that Dapr has many other potentially useful features (e.g., direct service invocation, state management, actors, etc.). Also, KNative is more of a low-level solution (a building block).
In essense, Dapr injects side-car container along with the main application container. The logics are quite similar to Kafka and Pulsar, but much more light-wright and moden. However, my concern is it will essentially bring in more resource consumption as a running pod. Same problem as Istios. Would you like to do a video to expand the discussion of how we can leverage Dapr in serverless application?
I'll do that (more videos on the subject).
@@DevOpsToolkit Thanks for the consideration! Look forward to it!!!! And you know Falco is also in your list xDDD
Thanks very much for the video, Viktor! Dapr sounds amazing. I have a question about services meshes: are they still relevant in case of events based architecture where all microservices communicate with each other asynchronously using an event hub? From what I understood, services meshes are suitable for synchronous communication, but what about asynchronous communication? Thanks a lot!
Service mesh is indeed more focused on direct communication so if you're using Dapr and all your services are using pub/sub, you might not need a service mesh. However, that is almost never the case. While pub/sub is great, it almost never replaces direct communication. Frontends with corresponding backends are a common example of something that often needs direct communicaiton.
@@DevOpsToolkit Very clear answer. My thought is that, Pub/sub with async call should be used for internal services communication, while sync (with service meshe) will be used for front-end/backend communication (backend for front-end design pattern)
Thanks for this video (and all others too) your chan is amazingly interesting !
And yes, it would be nice to have your point of view and your thoughts about a comparison between Service Meshes (ie. Istio) and Dapr !
While watching your video I was asking myself exactly what you said at the end in the "CONS" part. For the networking but also for the observability.
From which tool to use these kind of "duplicated" features? What's the differrence between both implementations? How making them working together? etc...
It would be nice also to have a quick difference between Darp and Argo Events.
Because if I remember well OpenFunction has been inspired by Argo Events.
A kind of comparison (and a tutorial) of all CNCF projects (including Dapr and Istio) is coming very soon. It's a new project I'm starting with a few other people around the end of January and will take at least a year to complete (there's over 200 projects in CNCF). I can't say more at this moment. Stay tuned...
It took me a while: ruclips.net/video/UGysOX84v2c/видео.html
Dapr says this is not a replacement for Istio and other service mesh options, but it seems to offer, mTLS + Certificate Management, Service Discovery, Monitoring, Tracing, Secret Integration of of course more.. The only thing it does not seem to have that Istio does is advanced routing options for A/B testing and similar. Do you think it really still makes sense to run both together? If you run both sidecars, would you disable mTLS on Dapr and just use Istio mTLS? Would love a bit more of your thoughts on this.
Advanced routing is indeed the main thing why one might want to combine Dapr with service mesh. Whether it makes sense to use both or not depends on whether you need advanced routing. If, for example, you do want to use canary deployments, you will need service mesh (even though it can be done without it).
When I do run both, I'm using mTLS from service mesh mostly because some services might not use Dapr.
Come to next week's AMA session (it'll be announced soon) and we can go into more depth on that subject (even though service mesh is not going to be the main theme).
As always if i need learn something news to me , here is my first place to go
good video, thanks for the rundown! Suppose you had to scale your speech-to-text service to run two instances. How would you make sure that when you post a new video, both instances of the speech-to-text service don't do the work to the same video?
The answer to that question depends on whether you're processing messages in the idempotent way or not. I'm guessing that it's not idempotent. Is that correct? If it is, you can set brokers to allow only one subscriber to receive a message.
@@DevOpsToolkit not idempotent (for example, your speech-to-text service could drop the transcript in an S3 bucket, we wouldn't want two copies of the same video transcript!). I see, so that would be a configuration of Kafka/RabbitMQ/Redis/(whatever else) and not something that Dapr would handle. Thanks for the reply!
Great tool. I really like it. There is a zillion things that dapr supports but I am wondering if it supports canary deployment. That would be awesome. I would like that I deploy new version of my app and that with help of dapr I can control how many messages this new version of my app can process. So, as dapr is becoming the standard then flagger should support dapr and vice versa.
Today, you would need to use service mesh for that since dapr does not support weighted traffic (requirement for canary deployments). Whether it will is yet to be seen.
I don't think dapr will ever get all the features of a service mesh, and I don't know how I feel about having to run 2 sidecars for each pod. Starting to add significant overhead..
I guess it all depends on whether you need features from one of those or both. Some do not need service mesh, while others do not need dapr. There are those who need both. The important thing to note is that dapr will probably never get all the features of a service mesh. Its intention is not to be a service mesh.
How would it look to return a response to the client? For example if you needed to return to them a link to the tweet (which presumably would be generated when the Twitter service talks to Twitter)
The Twitter service would create yet another event expecting that whoever needs to do something with it would listen for a specific topic.
To be clear, I'm not advocating that everything should be event-based. Direct messaging is still useful. We just need to see which model serves better a specific scenario and requirements.
@@DevOpsToolkit makes sense, would the publisher service then wait (blocking the response) for that event and include it in it's response? I guess ya the other option is for everything to be event based, meaning the client would have to be event based (i.e. it needs to poll for new events), but like you say that doesn't always make sense.
To me the general architecture of synchronous communication at the system boundary (clients and many human interactions are synchronous) but event driven internally makes sense. But it's the rough edges that get me, like the publisher service waiting for an event to send back a response is a bit tricky.
@@agarbanzo360 I guess it depends on how you define "waiting". Listening for events is a sort of waiting, but not for a specific request.
I can't say right away what would be better for your use-case (I don't know details). What I will say is that you do not have to use only sync or only async communication nor that it always have to be direct or always through pub/sub. You can combine them.
As a side note, most of human communication is async (not sync). When you send an email, a message on Slack, a comment (like here), etc. you are effectively doing async communication. Even when you are face-to-face with friends at, let's say, a party, you are most of the time doing async communication. You might start listening to a conversation of one group of people and then move to a different group. Unless someone is addressing you directly, you might choose to say something, just to listen, or to respond to a message on your phone while that group is talking. An example of direct sync communication is when someone asks you a direct question (e.g., "what's your name") and is waiting for you to respond before moving to a different question or choosing to ask something someone else.
Is mtls just a overhead and complexity if your cloud provider encrypt the vnc traffic?
Whether mTLS is overhead depends on whether you mean human or performance overhead. In the case of the former, it depends on whether you are using service mesh for other reasons. If you are, mTLS comes for free (in terms of maintenance). If it's the latter, performance is not impacted much. There is certainly an impact, but it's noticeable only for cases when a tiny difference in latency is considered unacceptable (e.g., micro trading).
What if I don't want to use kubernetes/docker hosting but I want to use edge servers? Can DAPR be made running in webassembly runtime?
I never tried it without containers so I'm not sure. My best guess is that it wouldn't work, but don't take my word for it.
You must be reading my mind cuz I've had dapr pinned for a year or so now and just yesterday decided I should try building something on it.. THIS IS A SIGN.. (unless you trash it.. I haven't watched the vid yet =P)
I did not trash it. Quite the opposite :)
@@DevOpsToolkit Oh yeah! Having now watched the video, I'm def doing to check out dapr. Also, I would def :thumbsup: a video on dapr/service mesh mashup. I'd love to hear your thoughts.
Can you do a video on Rudder, I am really looking for a Ansible replacement.
I haven't tried it (yet). I just had a quick look at rudder.io and it seems that you cannot try it without contacting sales. Is that the case?
@@DevOpsToolkit thank you I like to stick to the free and open source anyway. Keep up the great work
@@chuckstrut I do think that there is value in paying for commercial software and services. I almost never consider exploring something that is not free. Later on, after I adopt that something, I might opt for a commercial version on top of it. What I don't do is get involved with sales from the start (while I'm still exploring something).
Always love your video, what is different with apache kafka? i'm using it right now
There's no difference from Dapr's perspective. The only reason I used Redis for the demo is that it's lightweight and easy to set up. I might do a separate video about the differences of using Redis, Kafka, and a few others for pub/sub. But, that would be unrelated to Dapr since it does not care much which one you're using.
@@DevOpsToolkit i’m still confusing, it’s i need using Dapr? Currently pubsub using kafka. What the reason i will using dapr on my kubernetes
@@rezanaipospos3320 Mostly for the reasons of simplification and, more importantly, decoupling application code from pub/sub backend. Application code should not be aware of external dependencies and focus only on it's own business logic.
@@DevOpsToolkit istio or dapr? what's your recommend?
@@rezanaipospos3320 There are some overlaps (e.g., TLS) but, if I ignore those, they serve different purposes so it's hard to say which one to use (apart from saying "use both"). For example, Dapr does not give you weighted traffic making canary deployment very hard (if not impossible). On the other hand, service meshes in general (including Istio) do not offer pub/sub.
i was trying NATS io ... what do you think of it, i still feels like gRPC is the best to connect services
NATS is awesome.
Doesn't K8S services do about the same thing?
It doesn't. K8s Service is, intentionally, very basic. All it does is service discovery and routing to a random (round-robin, more or less) Pod associated with it.
I assume its ironic (but just in case) you put SKDs rather than SDKs on the list of integrations
Nope. It wasn't ironic but a typo :(