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 Жыл бұрын
Yes please a video talking about differences between service meshes vs dapr using tls or other protocols.
@KingoOoVideos4 ай бұрын
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
@trocomerlo2 жыл бұрын
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!
@kevinyu99342 жыл бұрын
I love Dapr!!! Like its architecture and functionalities.
@nitinkansal2 жыл бұрын
Complex microservice architecture explained nicely and concisely ! I will wait for all other aspects of dapr and service mesh vs dapr. Thanks Victor !
@jurkinss12 жыл бұрын
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.
@DevOpsToolkit2 жыл бұрын
Thanks for that. I was afraid that the new "style" might not be received well.
@azharhaque42172 жыл бұрын
Stumbled upon an absolute gem of a video
@Peter12152 жыл бұрын
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.
@soubinan2 жыл бұрын
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!!
@gorgegorgara21862 жыл бұрын
Would love to see more about daor! Awesome work, you videos are excellent
@faysoufox2 жыл бұрын
great video, thank you, yes looking forward to your suggestion at the end, dapr vs service mesh usages
@DevOpsToolkit2 жыл бұрын
I just moved it close to the top of my TODO list.
@backwoodsfab2 жыл бұрын
Well done! I see use cases where we would be able to leverage some of this right away.
@DaljeetSingh1 Жыл бұрын
please make more videos on Dapr explaining all its features.
@DevOpsToolkit Жыл бұрын
It's ready on my list but I cannot yet say when it'll come.
@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 Жыл бұрын
Unfortunately, i haven't used Camunda so i can't comment on it 😟
@giovanibrioninunes6932 жыл бұрын
I would like to see a video comparing dapr and service mesh.
@DevOpsToolkit2 жыл бұрын
Great! I'll bump it towards the top of my TODO list.
@punasusi67912 жыл бұрын
@@DevOpsToolkit One more vote for a bump up :)
@ParkerLouisDE2 жыл бұрын
I really like the new style! 👍
@DevOpsToolkit2 жыл бұрын
Thanks
@javisartdesign2 жыл бұрын
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...
@scottamolinari2 жыл бұрын
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.
@DevOpsToolkit2 жыл бұрын
Yeah. It supports both direct and pub/sub communication (among other things).
@farzadmf2 жыл бұрын
Great video, thanks!
@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 Жыл бұрын
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...
@DevOpsToolkit11 ай бұрын
It took me a while: kzbin.info/www/bejne/i3jcpIKObZmpaMU
@evgenygrinfeld14182 жыл бұрын
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!
@DevOpsToolkit2 жыл бұрын
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.
@betorvs2 жыл бұрын
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!
@DevOpsToolkit2 жыл бұрын
I'm ahead of you :) kzbin.info/www/bejne/h6uYioeMeap9o5I
@betorvs2 жыл бұрын
@@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)?
@DevOpsToolkit2 жыл бұрын
@@betorvs I still haven't used Replicated so I cannot compare it with others. Let me dig into it first...
@kevinyu99342 жыл бұрын
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?
@DevOpsToolkit2 жыл бұрын
I'll do that (more videos on the subject).
@kevinyu99342 жыл бұрын
@@DevOpsToolkit Thanks for the consideration! Look forward to it!!!! And you know Falco is also in your list xDDD
@Yrez12342 жыл бұрын
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!
@DevOpsToolkit2 жыл бұрын
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.
@Yrez12342 жыл бұрын
@@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)
@sushilprusty27663 ай бұрын
Love you Bro Captain Jack sparrow
@holgerwinkelmann62192 жыл бұрын
Can you make a difference between dapr and knative eventing.
@DevOpsToolkit2 жыл бұрын
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).
@fpvclub72562 жыл бұрын
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.
@DevOpsToolkit2 жыл бұрын
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-bv5fd2 жыл бұрын
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?
@DevOpsToolkit2 жыл бұрын
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-bv5fd2 жыл бұрын
@@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 Жыл бұрын
Is mtls just a overhead and complexity if your cloud provider encrypt the vnc traffic?
@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 Жыл бұрын
i was trying NATS io ... what do you think of it, i still feels like gRPC is the best to connect services
@DevOpsToolkit Жыл бұрын
NATS is awesome.
@rezanaipospos33202 жыл бұрын
Always love your video, what is different with apache kafka? i'm using it right now
@DevOpsToolkit2 жыл бұрын
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.
@rezanaipospos33202 жыл бұрын
@@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
@DevOpsToolkit2 жыл бұрын
@@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.
@rezanaipospos33202 жыл бұрын
@@DevOpsToolkit istio or dapr? what's your recommend?
@DevOpsToolkit2 жыл бұрын
@@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.Norris2 жыл бұрын
Can you do a video on Rudder, I am really looking for a Ansible replacement.
@DevOpsToolkit2 жыл бұрын
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.Norris2 жыл бұрын
@@DevOpsToolkit thank you I like to stick to the free and open source anyway. Keep up the great work
@DevOpsToolkit2 жыл бұрын
@@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).
@whitehatcomua2 жыл бұрын
Thanks!
@DevOpsToolkit2 жыл бұрын
Thanks a ton!
@andrejab742 жыл бұрын
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.
@DevOpsToolkit2 жыл бұрын
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 Жыл бұрын
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 Жыл бұрын
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.
@wolfymaster2 жыл бұрын
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)
@DevOpsToolkit2 жыл бұрын
I did not trash it. Quite the opposite :)
@wolfymaster2 жыл бұрын
@@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.
@jemag2 жыл бұрын
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..
@DevOpsToolkit2 жыл бұрын
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.
@Keloran2 жыл бұрын
I assume its ironic (but just in case) you put SKDs rather than SDKs on the list of integrations
@DevOpsToolkit2 жыл бұрын
Nope. It wasn't ironic but a typo :(
@grahamferguson32402 жыл бұрын
Doesn't K8S services do about the same thing?
@DevOpsToolkit2 жыл бұрын
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.
@christianibiri2 жыл бұрын
Great
@agarbanzo3602 жыл бұрын
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)
@DevOpsToolkit2 жыл бұрын
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.
@agarbanzo3602 жыл бұрын
@@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.
@DevOpsToolkit2 жыл бұрын
@@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.
@vn70572 жыл бұрын
As always if i need learn something news to me , here is my first place to go