Running Event-Driven Pub/Sub Microservices In Kubernetes With Dapr

  Рет қаралды 19,771

DevOps Toolkit

DevOps Toolkit

Күн бұрын

Пікірлер: 86
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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), KZbin tends to delete comments that contain links. Please do not use them in your comments.
@emonymph6911
@emonymph6911 Жыл бұрын
Yes please a video talking about differences between service meshes vs dapr using tls or other protocols.
@KingoOoVideos
@KingoOoVideos 4 ай бұрын
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
@trocomerlo
@trocomerlo 2 жыл бұрын
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!
@kevinyu9934
@kevinyu9934 2 жыл бұрын
I love Dapr!!! Like its architecture and functionalities.
@nitinkansal
@nitinkansal 2 жыл бұрын
Complex microservice architecture explained nicely and concisely ! I will wait for all other aspects of dapr and service mesh vs dapr. Thanks Victor !
@jurkinss1
@jurkinss1 2 жыл бұрын
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.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
Thanks for that. I was afraid that the new "style" might not be received well.
@azharhaque4217
@azharhaque4217 2 жыл бұрын
Stumbled upon an absolute gem of a video
@Peter1215
@Peter1215 2 жыл бұрын
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.
@soubinan
@soubinan 2 жыл бұрын
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!!
@gorgegorgara2186
@gorgegorgara2186 2 жыл бұрын
Would love to see more about daor! Awesome work, you videos are excellent
@faysoufox
@faysoufox 2 жыл бұрын
great video, thank you, yes looking forward to your suggestion at the end, dapr vs service mesh usages
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
I just moved it close to the top of my TODO list.
@backwoodsfab
@backwoodsfab 2 жыл бұрын
Well done! I see use cases where we would be able to leverage some of this right away.
@DaljeetSingh1
@DaljeetSingh1 Жыл бұрын
please make more videos on Dapr explaining all its features.
@DevOpsToolkit
@DevOpsToolkit Жыл бұрын
It's ready on my list but I cannot yet say when it'll come.
@DaljeetSingh1
@DaljeetSingh1 Жыл бұрын
@@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 ? )
@DevOpsToolkit
@DevOpsToolkit Жыл бұрын
Unfortunately, i haven't used Camunda so i can't comment on it 😟
@giovanibrioninunes693
@giovanibrioninunes693 2 жыл бұрын
I would like to see a video comparing dapr and service mesh.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
Great! I'll bump it towards the top of my TODO list.
@punasusi6791
@punasusi6791 2 жыл бұрын
@@DevOpsToolkit One more vote for a bump up :)
@ParkerLouisDE
@ParkerLouisDE 2 жыл бұрын
I really like the new style! 👍
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
Thanks
@javisartdesign
@javisartdesign 2 жыл бұрын
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...
@scottamolinari
@scottamolinari 2 жыл бұрын
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.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
Yeah. It supports both direct and pub/sub communication (among other things).
@farzadmf
@farzadmf 2 жыл бұрын
Great video, thanks!
@thomasaugsbourger7057
@thomasaugsbourger7057 Жыл бұрын
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.
@DevOpsToolkit
@DevOpsToolkit Жыл бұрын
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...
@DevOpsToolkit
@DevOpsToolkit 11 ай бұрын
It took me a while: kzbin.info/www/bejne/i3jcpIKObZmpaMU
@evgenygrinfeld1418
@evgenygrinfeld1418 2 жыл бұрын
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!
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@betorvs
@betorvs 2 жыл бұрын
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!
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
I'm ahead of you :) kzbin.info/www/bejne/h6uYioeMeap9o5I
@betorvs
@betorvs 2 жыл бұрын
@@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)?
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
@@betorvs I still haven't used Replicated so I cannot compare it with others. Let me dig into it first...
@kevinyu9934
@kevinyu9934 2 жыл бұрын
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?
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
I'll do that (more videos on the subject).
@kevinyu9934
@kevinyu9934 2 жыл бұрын
@@DevOpsToolkit Thanks for the consideration! Look forward to it!!!! And you know Falco is also in your list xDDD
@Yrez1234
@Yrez1234 2 жыл бұрын
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!
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@Yrez1234
@Yrez1234 2 жыл бұрын
@@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)
@sushilprusty2766
@sushilprusty2766 3 ай бұрын
Love you Bro Captain Jack sparrow
@holgerwinkelmann6219
@holgerwinkelmann6219 2 жыл бұрын
Can you make a difference between dapr and knative eventing.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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).
@fpvclub7256
@fpvclub7256 2 жыл бұрын
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.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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).
@sr-bv5fd
@sr-bv5fd 2 жыл бұрын
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?
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@sr-bv5fd
@sr-bv5fd 2 жыл бұрын
@@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!
@gsilva877
@gsilva877 Жыл бұрын
Is mtls just a overhead and complexity if your cloud provider encrypt the vnc traffic?
@DevOpsToolkit
@DevOpsToolkit Жыл бұрын
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).
@Babbili
@Babbili Жыл бұрын
i was trying NATS io ... what do you think of it, i still feels like gRPC is the best to connect services
@DevOpsToolkit
@DevOpsToolkit Жыл бұрын
NATS is awesome.
@rezanaipospos3320
@rezanaipospos3320 2 жыл бұрын
Always love your video, what is different with apache kafka? i'm using it right now
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@rezanaipospos3320
@rezanaipospos3320 2 жыл бұрын
@@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
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
@@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.
@rezanaipospos3320
@rezanaipospos3320 2 жыл бұрын
@@DevOpsToolkit istio or dapr? what's your recommend?
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
​@@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.
@Earl.Norris
@Earl.Norris 2 жыл бұрын
Can you do a video on Rudder, I am really looking for a Ansible replacement.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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?
@Earl.Norris
@Earl.Norris 2 жыл бұрын
@@DevOpsToolkit thank you I like to stick to the free and open source anyway. Keep up the great work
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
@@Earl.Norris 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).
@whitehatcomua
@whitehatcomua 2 жыл бұрын
Thanks!
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
Thanks a ton!
@andrejab74
@andrejab74 2 жыл бұрын
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.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@maertscisum
@maertscisum Жыл бұрын
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?
@DevOpsToolkit
@DevOpsToolkit Жыл бұрын
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.
@wolfymaster
@wolfymaster 2 жыл бұрын
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)
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
I did not trash it. Quite the opposite :)
@wolfymaster
@wolfymaster 2 жыл бұрын
@@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.
@jemag
@jemag 2 жыл бұрын
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..
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@Keloran
@Keloran 2 жыл бұрын
I assume its ironic (but just in case) you put SKDs rather than SDKs on the list of integrations
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
Nope. It wasn't ironic but a typo :(
@grahamferguson3240
@grahamferguson3240 2 жыл бұрын
Doesn't K8S services do about the same thing?
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@christianibiri
@christianibiri 2 жыл бұрын
Great
@agarbanzo360
@agarbanzo360 2 жыл бұрын
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)
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
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.
@agarbanzo360
@agarbanzo360 2 жыл бұрын
​@@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.
@DevOpsToolkit
@DevOpsToolkit 2 жыл бұрын
@@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.
@vn7057
@vn7057 2 жыл бұрын
As always if i need learn something news to me , here is my first place to go
Cloud-Native Applications And NOT Infrastructure Code - Klotho
24:13
OpenFunction: The Best Way to Run Serverless Functions on Kubernetes?
36:54
Trapped by the Machine, Saved by Kind Strangers! #shorts
00:21
Fabiosa Best Lifehacks
Рет қаралды 39 МЛН
How Autoscaling Works In Kubernetes (And Beyond)? Kubernetes Tutorial
30:55
DevOps MUST Build Internal Developer Platform (IDP)
36:22
DevOps Toolkit
Рет қаралды 56 М.
KEDA: Kubernetes Event-Driven Autoscaling
16:02
DevOps Toolkit
Рет қаралды 28 М.
Should We Run Databases In Kubernetes? CloudNativePG (CNPG) PostgreSQL
19:10
Running Dapr in Production | DaprCon
28:48
Dapr
Рет қаралды 8 М.
Dapr in Practice - Marc Klefter - NDC Oslo 2024
54:17
NDC Conferences
Рет қаралды 2,1 М.
The Death of Microservices?
24:20
Cloud Computing Insider
Рет қаралды 64 М.
How To Auto-Scale Kubernetes Clusters With Karpenter
26:58
DevOps Toolkit
Рет қаралды 24 М.
Event-Driven Architecture (EDA) vs Request/Response (RR)
12:00
Confluent
Рет қаралды 169 М.
Trapped by the Machine, Saved by Kind Strangers! #shorts
00:21
Fabiosa Best Lifehacks
Рет қаралды 39 МЛН