1 00:00:00,000 --> 00:00:00,779 Welcome everyone. 2 00:00:00,960 --> 00:00:04,170 Unfortunately, Laura could not join us today. 3 00:00:04,560 --> 00:00:06,810 Again, what does she even do? 4 00:00:07,680 --> 00:00:09,060 Geez, sorry. 5 00:00:09,560 --> 00:00:14,909 In today's episode, I'm joined by Mark, the co-founder and CEO of Dapr. 6 00:00:15,170 --> 00:00:19,470 A CNCF project that helps make microservice development almost possible. 7 00:00:19,920 --> 00:00:21,510 Let's go dig in without me. 8 00:00:22,010 --> 00:00:22,970 Enjoy the episode. 9 00:00:23,490 --> 00:00:24,030 hi Mark. 10 00:00:24,060 --> 00:00:25,530 Welcome to Cloud Native Compass. 11 00:00:25,530 --> 00:00:28,770 Could you please take a few moments to introduce yourself to our audience? 12 00:00:29,415 --> 00:00:30,015 Thank you, David. 13 00:00:30,015 --> 00:00:31,185 It's fantastic to be here. 14 00:00:31,185 --> 00:00:31,515 Yeah. 15 00:00:31,515 --> 00:00:32,605 My name's Mark Fussell. 16 00:00:32,955 --> 00:00:34,125 I'm the CEO of Diagrid. 17 00:00:34,208 --> 00:00:38,393 Diagrid is a company where we build on open source technologies, particularly 18 00:00:38,393 --> 00:00:42,038 on Dapr, what we'll talk about a lot today, and excited to be here today. 19 00:00:42,112 --> 00:00:42,602 Awesome. 20 00:00:42,602 --> 00:00:43,717 Thank you so much for joining us. 21 00:00:43,976 --> 00:00:48,776 I'm really excited for this episode because I have built distributed systems, 22 00:00:48,776 --> 00:00:54,026 with microservices and workflows, and pubsub event queues and, I love the 23 00:00:54,026 --> 00:00:56,876 polarity, I don't know if that's even the right word, but when we adopt 24 00:00:56,876 --> 00:01:00,296 microservices, I often tell people it's to make their lives simpler, and then 25 00:01:00,356 --> 00:01:04,916 bam, they've now got this horrible, crazy architecture with all of these things. 26 00:01:04,916 --> 00:01:06,941 So maybe we can talk about. 27 00:01:07,356 --> 00:01:09,876 The adoption of microservices, are we going in the right direction? 28 00:01:09,876 --> 00:01:12,456 And how Dapr is hopefully gonna make that easier for people. 29 00:01:13,176 --> 00:01:16,026 Yeah, microservices is not new now in any way. 30 00:01:16,146 --> 00:01:20,526 If you look at a lot of the publications, and we, there's a great thing from 31 00:01:20,526 --> 00:01:24,036 InfoQ where they published, they're crossing the chasm technologies from 32 00:01:24,036 --> 00:01:25,146 the architectural point of view. 33 00:01:25,146 --> 00:01:27,316 And microservices is way over on the. 34 00:01:27,611 --> 00:01:31,904 The right now, and it's crossed the chasm from a technology perspective, and have 35 00:01:31,904 --> 00:01:35,204 been around for, I mean, people been talking around for good 15 years now. 36 00:01:35,234 --> 00:01:36,714 And you have to look back. 37 00:01:36,714 --> 00:01:37,854 what does it actually mean? 38 00:01:37,884 --> 00:01:41,364 You know, it was a driving factor from the businesses because the business 39 00:01:41,364 --> 00:01:47,444 wanted to move faster when you built this large compiled piece of code that wasn't. 40 00:01:48,054 --> 00:01:49,454 distributed in some manner. 41 00:01:49,804 --> 00:01:53,009 It meant that, its rate fast and ship features fast. 42 00:01:53,039 --> 00:01:54,239 And there's this requirement. 43 00:01:54,239 --> 00:01:58,829 Actually the two driving requirements was one was as we moved more services to 44 00:01:58,829 --> 00:02:02,549 the cloud and ran things on the cloud and kinda distributed them around, so they 45 00:02:02,549 --> 00:02:07,079 ran on more machines, coping with the fact that the business wanted to ship features 46 00:02:07,079 --> 00:02:08,849 faster, because I wanted to be able to. 47 00:02:09,409 --> 00:02:13,969 Update my inventory application faster than sort of my payment application. 48 00:02:14,039 --> 00:02:15,179 that split things apart. 49 00:02:15,719 --> 00:02:18,509 And so there's just a big debate, which I think is a big, kind 50 00:02:18,509 --> 00:02:22,139 of strange in myself, which is, what's the size of a microservice? 51 00:02:22,149 --> 00:02:26,406 you know, the size of a, The answear is it could be anything. 52 00:02:26,406 --> 00:02:29,016 It could be a giant piece of compiled code, or it could be, 53 00:02:29,356 --> 00:02:30,796 millions of little small things. 54 00:02:31,276 --> 00:02:32,896 And often it lies somewhere in between. 55 00:02:33,266 --> 00:02:36,506 usually around, you know, domain driven, data driven design where, you 56 00:02:36,506 --> 00:02:40,296 buy, draw, and, domain and context is where you sort draw boundaries 57 00:02:40,296 --> 00:02:42,396 around your business itself. 58 00:02:42,476 --> 00:02:45,626 where's my payment application sit, and where does my kind 59 00:02:45,626 --> 00:02:47,246 of other business process sit? 60 00:02:47,246 --> 00:02:49,196 And you sort of draw boundaries around those. 61 00:02:49,556 --> 00:02:51,466 And then of course, as developers do. 62 00:02:51,466 --> 00:02:56,086 You know know you sort of have to choose a choice of implementations. 63 00:02:56,206 --> 00:02:59,471 so that's kind of really kind of the brief reason for microservices and, 64 00:02:59,531 --> 00:03:02,386 and you know, the history around them of, you know, why they've developed. 65 00:03:02,386 --> 00:03:06,436 Because, you know, we're often now in this sort of Cloud Native world 66 00:03:06,436 --> 00:03:09,046 where everyone runs things on top of Kubernetes is the platform. 67 00:03:09,046 --> 00:03:13,576 And what we just saw time and time again is that people were reinventing 68 00:03:13,996 --> 00:03:19,186 the same pieces of code themselves, the same software patterns in order to 69 00:03:19,186 --> 00:03:22,756 build these distributed architectures, which run on multiple machines. 70 00:03:22,756 --> 00:03:24,346 And so that's where, you know, Dapr comes in. 71 00:03:24,452 --> 00:03:24,754 Awesome. 72 00:03:25,289 --> 00:03:25,648 yeah, 73 00:03:25,648 --> 00:03:30,868 So with microservices, I often say to people, and it's, I don't know if it's 74 00:03:30,868 --> 00:03:33,833 like the best analogy I've ever had in my life, or the worst, it's if we 75 00:03:33,833 --> 00:03:35,363 think about a carrot on a stick, right? 76 00:03:35,363 --> 00:03:37,703 And we're leading, or a horse, we're leading the horse to water. 77 00:03:38,243 --> 00:03:40,433 We're like, microservices are gonna make your life better. 78 00:03:40,433 --> 00:03:41,123 They're simpler. 79 00:03:41,123 --> 00:03:42,503 You can rewrite them in a day. 80 00:03:42,503 --> 00:03:46,193 And all, we've all heard these terms before, but unfortunately we take all 81 00:03:46,193 --> 00:03:49,523 these developers, we guide them to the water, and actually it's a notion and now 82 00:03:49,523 --> 00:03:51,314 they've got to boil it in some degree. 83 00:03:51,314 --> 00:03:54,404 It is a notion of complexity with the regards to the tools that they need. 84 00:03:54,764 --> 00:03:59,204 Because when we simplify the code itself, the application, the 85 00:03:59,204 --> 00:04:01,094 microservice, that is really easy. 86 00:04:01,094 --> 00:04:03,644 It could be 12 lines of code, it could be a hundred lines of codes. 87 00:04:03,694 --> 00:04:04,474 it's not important. 88 00:04:04,954 --> 00:04:07,474 But that complexity doesn't really get removed. 89 00:04:07,474 --> 00:04:10,054 It gets pushed to the platform or to the infrastructure. 90 00:04:10,444 --> 00:04:15,034 And I think from, my knowledge of Dapr, you're solving that, that big ball 91 00:04:15,034 --> 00:04:17,075 of complexity of the platform bit. 92 00:04:17,539 --> 00:04:18,109 Exactly. 93 00:04:18,109 --> 00:04:21,229 I mean, that's what it does is that, you, everyone approaches this and you 94 00:04:21,229 --> 00:04:24,649 jump in, you go, yeah, I can create, you know, process A, process B, or 95 00:04:24,649 --> 00:04:28,259 container A, container B, and I'm just gonna talk between this front end 96 00:04:28,259 --> 00:04:32,039 application, talk through usually some typically gateway service that's deployed. 97 00:04:32,039 --> 00:04:35,069 And then I have, you know, say we built a fictitious application, had 98 00:04:35,069 --> 00:04:38,729 a shopping cart service, a checkout service, and maybe an inventory service. 99 00:04:38,984 --> 00:04:41,189 And you deploy all these things, but all of a sudden. 100 00:04:41,207 --> 00:04:44,361 There's all these difficult problems that emerge and I think they usually 101 00:04:44,361 --> 00:04:48,781 stem down to things like communication between them, coordination across them 102 00:04:49,021 --> 00:04:50,701 and sort of state around them all. 103 00:04:51,181 --> 00:04:53,551 And so the first thing that you often run into is that you want to 104 00:04:53,551 --> 00:04:57,001 be able to do communication between some services because everything 105 00:04:57,001 --> 00:04:59,826 is not running in isolation in a giant compiled ball anymore. 106 00:04:59,851 --> 00:05:03,001 And so you've really distributed the problem to a networking problem 107 00:05:03,001 --> 00:05:04,501 now, which means communication. 108 00:05:05,161 --> 00:05:08,611 And so all of a sudden, you know, you've gotta have service A talk to service 109 00:05:08,611 --> 00:05:12,431 B. and so the first thing you run into is it's gotta be discoverability. 110 00:05:12,761 --> 00:05:16,151 And so, you know, one of the key tenets that Dapr brings to 111 00:05:16,481 --> 00:05:19,841 a distributed substance platform is this concept of identity. 112 00:05:20,211 --> 00:05:23,841 where every piece of code, actually, every piece of process or running code. 113 00:05:24,126 --> 00:05:25,566 Has a name associated with it. 114 00:05:25,791 --> 00:05:29,616 And it turns out that this is incredibly important because, if you're in the 115 00:05:29,616 --> 00:05:32,616 infrastructure land, you don't really care about name pieces of code. 116 00:05:32,616 --> 00:05:36,736 You deploy these processes, but you wanna say, I want to call my inventory 117 00:05:36,736 --> 00:05:41,446 service and I want to call, the payment, method on the inventory, or sort of 118 00:05:41,596 --> 00:05:45,046 the stock service, I should say, on inventory service to see if it's there. 119 00:05:45,046 --> 00:05:46,576 do I have stock inside of man inventory? 120 00:05:47,056 --> 00:05:49,636 And so you have these named identities the first problem 121 00:05:49,636 --> 00:05:53,346 you've run into is discoverability and then calling, securely. 122 00:05:53,526 --> 00:05:57,216 and then also then you fall into the concept of retries because you've done 123 00:05:57,216 --> 00:05:59,976 a call and it's failed and you have to retry 'cause there's network failures. 124 00:06:00,621 --> 00:06:00,841 Yep. 125 00:06:00,906 --> 00:06:03,036 top of this, of course, you want to have observability. 126 00:06:03,086 --> 00:06:05,786 did my call succeed and do I have observability data? 127 00:06:06,296 --> 00:06:11,496 So, this whole thing turns out to be a you get a big challenge in the end, and 128 00:06:11,496 --> 00:06:14,886 before you know it, people jump in and they think, oh, I'll do a, a simple rest 129 00:06:14,886 --> 00:06:19,176 call between these and they, I gotta make it secure and then I go do retries. 130 00:06:19,616 --> 00:06:22,196 and then this whole discovery mechanism where you bring in something 131 00:06:22,196 --> 00:06:26,746 like zookeeper or, what's it, uh, the, the one from HashiCorp the. 132 00:06:27,616 --> 00:06:28,066 Console. 133 00:06:28,501 --> 00:06:28,921 console. 134 00:06:28,921 --> 00:06:29,341 Yes. 135 00:06:29,531 --> 00:06:32,261 in order to do name resolution around those things, and you're sort of 136 00:06:32,261 --> 00:06:35,531 building the whole platform up yourself just to kind of talk between two 137 00:06:35,531 --> 00:06:36,911 services and call a method on them. 138 00:06:38,181 --> 00:06:40,431 and run this on some distributed systems platform. 139 00:06:40,431 --> 00:06:42,201 So that's exactly what Dapr does. 140 00:06:42,231 --> 00:06:46,821 Dapr says, well, why are you reinventing the wheel or reinventing the pattern? 141 00:06:46,821 --> 00:06:51,351 We say, let's take advantage of building a platform and a set of 142 00:06:51,741 --> 00:06:53,811 consistent APIs that allow you to do. 143 00:06:53,811 --> 00:06:58,946 This communication coordination and sort of state management, and also things 144 00:06:58,946 --> 00:07:01,396 like secrets management, between things. 145 00:07:01,816 --> 00:07:06,776 And so, you know, to take that into concrete example, Dapr has this concept 146 00:07:06,776 --> 00:07:11,306 of a service invocation, API, which says, you create two services, service 147 00:07:11,306 --> 00:07:14,516 A and service B. they both have names. 148 00:07:14,816 --> 00:07:20,036 And then I kind of get, those are registered into a resolution service that 149 00:07:20,036 --> 00:07:21,836 can discover where those services are. 150 00:07:22,136 --> 00:07:27,896 And now as a developer, I can simply call onto the invoke API that says invoke. 151 00:07:28,231 --> 00:07:32,826 the method near the stock service on the inventory, service wherever 152 00:07:32,826 --> 00:07:36,216 it's running or, and call that method for me, and that's all I have to do. 153 00:07:36,486 --> 00:07:38,226 And up is all heavy lifting for you. 154 00:07:38,226 --> 00:07:42,456 Does the discoverability, the secure calls, the retries, the 155 00:07:42,456 --> 00:07:43,716 observability around all that. 156 00:07:44,106 --> 00:07:46,061 And basically what this is all about is. 157 00:07:46,801 --> 00:07:49,581 developers have to write business code in the end, that's 158 00:07:49,581 --> 00:07:50,391 what you're trying to get to. 159 00:07:50,761 --> 00:07:52,981 not build platforms the whole time. 160 00:07:53,401 --> 00:07:55,471 And so, although it's fun for developers to build those 161 00:07:55,471 --> 00:07:59,041 platforms, you keep reinventing this just for every application. 162 00:07:59,731 --> 00:08:03,841 So, Dapr solves these hard distributed systems problems and 163 00:08:03,841 --> 00:08:06,181 we can go into each one of those APIs and talk about it a bit more. 164 00:08:06,181 --> 00:08:08,281 'cause each one of them is fairly significant. 165 00:08:09,271 --> 00:08:13,591 but that's what its underlying concept is to accelerate this. 166 00:08:14,566 --> 00:08:18,136 we've shown, actually we do a every, in fact, we are just about to release, 167 00:08:18,166 --> 00:08:23,326 now a thing called a state of Dapr, a state of Dapr report to 2025, where we 168 00:08:23,716 --> 00:08:28,566 interviewed, 200 plus, developers, who are using Dapr and asked them, what was the 169 00:08:28,566 --> 00:08:30,496 number one thing that, you got from Dapr. 170 00:08:30,516 --> 00:08:33,306 And, you know, the categor thing that came back was that 171 00:08:33,576 --> 00:08:37,116 it accelerated the development of my microservices application. 172 00:08:37,821 --> 00:08:41,921 Anywhere between, 30 and 50% productivity around all of them. 173 00:08:42,943 --> 00:08:44,953 you kinda asked for a better response than that, right? 174 00:08:44,953 --> 00:08:46,183 that's exactly what you want be here. 175 00:08:46,183 --> 00:08:49,653 I'm assuming not to put words in your mouth, but yeah, that's really cool. 176 00:08:49,713 --> 00:08:54,163 So there's one thing I want to touch on a little bit there is, you talked about 177 00:08:54,373 --> 00:08:58,813 where Dapr fits into the stack with Sandlin retries to a certain degree, it 178 00:08:58,813 --> 00:09:04,103 makes, communication or request to other services, a function call rather than a 179 00:09:04,458 --> 00:09:07,878 generic HDP call where you do the plumbing and the retries and all that, 180 00:09:08,328 --> 00:09:11,628 and people always say, Kubernetes, it gives you service discovery for free. 181 00:09:11,808 --> 00:09:14,898 And it's like, you know, well, yeah, kinda good luck with that, right? 182 00:09:15,383 --> 00:09:18,113 there's a whole market here of service measures that said, no, it 183 00:09:18,113 --> 00:09:21,113 doesn't because you've gotta hook in again, all of this more stuff. 184 00:09:21,533 --> 00:09:25,733 And what I like about where Dapr sits in the stack versus the service mesh is that 185 00:09:25,953 --> 00:09:29,483 Dapr is service and application aware. 186 00:09:29,753 --> 00:09:32,213 It actually understands my code to a certain degree. 187 00:09:32,213 --> 00:09:36,443 Where service mesh is more of this generic fiddle, bit of pipe or 188 00:09:36,443 --> 00:09:41,303 plumbing that does give me value, but Dapr slightly higher up the stack. 189 00:09:41,303 --> 00:09:42,712 I'm assuming that was intentional. 190 00:09:42,712 --> 00:09:43,972 So maybe we can talk about why. 191 00:09:44,002 --> 00:09:47,932 Why is this important for developers as they want to increase their velocity 192 00:09:48,007 --> 00:09:49,247 building in microservice architecture? 193 00:09:49,685 --> 00:09:53,165 that's a question that we often get on the project is, is Dapr service mesh? 194 00:09:53,165 --> 00:09:55,205 And the answer is, is kind of yes and no. 195 00:09:55,645 --> 00:09:58,795 the answer is yes, it does the same sort of functionality, but 196 00:09:58,795 --> 00:10:02,065 service Meshs work purely at the networking layer and only at the 197 00:10:02,065 --> 00:10:02,315 networking layer 198 00:10:02,315 --> 00:10:02,375 Yeah. 199 00:10:02,545 --> 00:10:02,725 layer. 200 00:10:02,995 --> 00:10:05,035 There's no understanding or concept of. 201 00:10:05,210 --> 00:10:07,550 Yeah, of an application, as it were. 202 00:10:08,030 --> 00:10:11,880 And this goes back to, that application identity thing I just referred to, 203 00:10:11,880 --> 00:10:15,900 service meshes are, coordinating network packets and changing things on the 204 00:10:15,900 --> 00:10:20,800 network layer and doing, and, you know, if you want to enforce that consistently 205 00:10:20,800 --> 00:10:24,250 across every single thing that happens inside your company, then great. 206 00:10:24,250 --> 00:10:26,959 you can implement service, a service mesh to do that. 207 00:10:27,009 --> 00:10:29,409 but this idea of application identity. 208 00:10:29,563 --> 00:10:34,363 You know that a piece of code, a process, a container actually has identity 209 00:10:34,633 --> 00:10:39,493 that I can reason about and discover and call is the big difference in the 210 00:10:39,493 --> 00:10:42,943 end between Dapr and service meshes. 211 00:10:43,133 --> 00:10:47,813 and that kind of gets to the point where what happens is that, Dapr really is. 212 00:10:48,053 --> 00:10:50,783 in its comparison with service meshes, there's only just one 213 00:10:50,783 --> 00:10:52,313 API that aligns with on that. 214 00:10:52,313 --> 00:10:53,483 That's a service invocation. 215 00:10:54,083 --> 00:10:57,363 You the other very important API that uses all the time with Dapr is 216 00:10:57,603 --> 00:10:59,583 publish and subscribe, or pubs up, or 217 00:10:59,823 --> 00:11:00,043 Yep. 218 00:11:00,123 --> 00:11:04,663 messaging, where you publish a message and you can sub subscribe to it on a topic. 219 00:11:05,383 --> 00:11:08,623 And you can then sort of broadcast or send it to everyone's listening. 220 00:11:08,623 --> 00:11:12,563 And asynchronous messaging and the concept of, message brokers in between 221 00:11:12,563 --> 00:11:14,363 is sort of key to a distributed system. 222 00:11:14,363 --> 00:11:19,203 In fact, that's probably the most common API that gets used inside Dapr. 223 00:11:19,223 --> 00:11:22,823 and so, you know, at that point as well, you're also sending messages between. 224 00:11:23,178 --> 00:11:25,638 two services or two applications that are running. 225 00:11:26,028 --> 00:11:29,808 And that's the big difference when Dapr does its concepts of end-to-end 226 00:11:29,808 --> 00:11:34,033 security and, it does observability and it does resiliency across these, 227 00:11:34,463 --> 00:11:36,023 you get it across all those APIs. 228 00:11:36,773 --> 00:11:40,973 So in a case of, if you decide to do a service invocation call between 229 00:11:40,973 --> 00:11:44,783 two services and then you do a pub sub message, you get to end-to-end 230 00:11:44,783 --> 00:11:48,203 observability of going through all these APIs and you see that whole call train. 231 00:11:48,593 --> 00:11:52,268 Well with something like with a service mesh, you just see the call that happens 232 00:11:52,268 --> 00:11:55,328 on a network and you don't know, it went over this message broker all of a sudden 233 00:11:55,748 --> 00:11:59,408 and then came back because it doesn't know this at the application level. 234 00:11:59,938 --> 00:12:02,578 So one of the big, differences is that whole concept. 235 00:12:02,578 --> 00:12:06,608 And I think, this often comes down to people who think about the 236 00:12:06,608 --> 00:12:10,298 infrastructure layer of things and in that space, and then people are 237 00:12:10,298 --> 00:12:11,798 looking at the application layer. 238 00:12:12,488 --> 00:12:16,688 And what's very unique about the Dapr Project is, we solely talked about what 239 00:12:16,688 --> 00:12:18,878 are the needs of an application developer. 240 00:12:18,928 --> 00:12:23,338 how is it they need service invocation, a asynchronous calls 241 00:12:23,338 --> 00:12:27,028 with pub sub and then I think one of the most important ones is workflow. 242 00:12:27,718 --> 00:12:27,868 Where 243 00:12:27,998 --> 00:12:28,468 do coordination 244 00:12:28,488 --> 00:12:28,588 Yep. 245 00:12:28,903 --> 00:12:29,713 between services. 246 00:12:29,983 --> 00:12:30,133 Yeah. 247 00:12:30,133 --> 00:12:33,493 Service A has gotta call service B and call service C, and if it 248 00:12:33,493 --> 00:12:35,473 fails, how do I recover and do that? 249 00:12:35,473 --> 00:12:36,673 Retry mechanisms. 250 00:12:36,943 --> 00:12:39,643 And often what's referred to now is durable execution. 251 00:12:40,063 --> 00:12:43,513 The fact that I can keep a long running workflow running like a piece 252 00:12:43,513 --> 00:12:47,833 of business logic, inventive failure recover to where I was start to. 253 00:12:48,908 --> 00:12:52,988 from where I left off before and keep going, and do this in a coordinated 254 00:12:52,988 --> 00:12:56,378 fashion, just like, you know, any sort of classic workflow process. 255 00:12:57,083 --> 00:13:01,963 but the unique thing that Dapr has, it's a code based workflow, and so you write 256 00:13:01,963 --> 00:13:05,673 your code, as a developer would write in your favorite language, be Python 257 00:13:05,673 --> 00:13:10,278 or C Sharp or Java, and you can do this coordination or, saga type patterns. 258 00:13:11,053 --> 00:13:14,383 As well as combined with orchestration patterns as well for pub sub. 259 00:13:14,653 --> 00:13:18,883 And this is sort of the, the powerful concept of Dapr, has pub 260 00:13:18,883 --> 00:13:21,733 sub messaging for communication, has workflow for coordination. 261 00:13:21,867 --> 00:13:26,032 so, you know, going back to your question about, I. Service meshes and Dapr. 262 00:13:26,052 --> 00:13:27,702 Yeah, service invocation. 263 00:13:27,702 --> 00:13:31,372 and that aligns with some of the service meshes with Dapr, but 264 00:13:31,372 --> 00:13:32,832 Dapr is much, much more than that. 265 00:13:33,232 --> 00:13:38,212 and actually we see Dapr used side by side with service meshes as well. 266 00:13:38,212 --> 00:13:40,282 if people do want to use it with a service mesh, that's good. 267 00:13:40,627 --> 00:13:41,107 All right. 268 00:13:41,437 --> 00:13:43,177 There's a lot we could talk about from there. 269 00:13:43,177 --> 00:13:44,792 I love that you go onto the kinda. 270 00:13:45,487 --> 00:13:48,777 The, I dunno the term, the different actors of Dapr, the different, feature 271 00:13:48,777 --> 00:13:50,487 sets the APIs that are being provided. 272 00:13:50,817 --> 00:13:54,117 Because you're right, durable execution as it's known like 273 00:13:54,327 --> 00:13:55,857 today seems to be everywhere. 274 00:13:55,917 --> 00:13:58,567 Right now everyone is talking about how do we do this? 275 00:13:58,567 --> 00:14:01,567 What are the tools that we're doing and what are the language supports, et cetera. 276 00:14:01,867 --> 00:14:03,367 And I think they solve an important problem. 277 00:14:04,297 --> 00:14:07,987 And This was possible before to a certain degree where you publish something 278 00:14:07,987 --> 00:14:12,367 to Kafka, you have consumers, they do the job and the sagas have been around 279 00:14:12,367 --> 00:14:15,907 much longer than durable execution, but it was completely event driven and 280 00:14:15,907 --> 00:14:19,217 the challenge there, at least from, back in the days when I was doing this 281 00:14:19,217 --> 00:14:23,687 stuff is the visibility across the whole system was really difficult. 282 00:14:24,047 --> 00:14:24,647 Yes. 283 00:14:24,917 --> 00:14:25,487 this event? 284 00:14:25,547 --> 00:14:26,567 What is consuming it? 285 00:14:26,567 --> 00:14:26,837 Then? 286 00:14:26,927 --> 00:14:30,407 How does this chain work through to the point where you have like 287 00:14:30,407 --> 00:14:34,097 whole tracer based test systems that feed end to end workloads work. 288 00:14:34,817 --> 00:14:38,417 This new durable execution pattern of just writing the workflows and code 289 00:14:38,417 --> 00:14:41,687 and making sure that the responses are memorized and continued and all that. 290 00:14:42,227 --> 00:14:43,337 I think it's so cool. 291 00:14:43,337 --> 00:14:46,277 I can remember the first time I've seen it, I was like, wow, like this is amazing. 292 00:14:46,607 --> 00:14:51,107 And I had no idea that Dapr even offered this today until I was kind looking 293 00:14:51,107 --> 00:14:52,667 around on the website to see what was new. 294 00:14:53,267 --> 00:14:57,857 And I, it kind got me thinking is that, you offered Kiwi, I think 295 00:14:57,857 --> 00:14:59,827 there's, the Pub/Sub stuff with Kafka. 296 00:14:59,827 --> 00:15:01,837 I don't know if it's supposed alternative backends. 297 00:15:02,152 --> 00:15:03,352 There's no workflows. 298 00:15:03,682 --> 00:15:06,952 Like you're essentially taking all of the problems of distributed 299 00:15:06,952 --> 00:15:10,582 system or microservice system and bringing out new APIs, climbing up 300 00:15:10,582 --> 00:15:12,022 the stack, whatever you wanna call it. 301 00:15:12,082 --> 00:15:15,902 And I think that is so important and it brings me back, people always ask 302 00:15:15,902 --> 00:15:17,572 when should I start with microservices? 303 00:15:17,572 --> 00:15:19,192 When do we adopt microservices? 304 00:15:19,222 --> 00:15:22,372 And the answer has always typically been, oh, make it work. 305 00:15:22,372 --> 00:15:25,672 And beg, monolith, try not to make it too much of a ball of mud and then refactor 306 00:15:25,672 --> 00:15:27,382 to microservices with all these patterns. 307 00:15:28,267 --> 00:15:30,727 And that's been the status quo for decades. 308 00:15:30,727 --> 00:15:31,057 Right. 309 00:15:31,657 --> 00:15:35,107 And I feel like now with Dapr people are buy into it. 310 00:15:35,227 --> 00:15:39,157 You could be a team of two and ship hundreds of microservices and be really 311 00:15:39,157 --> 00:15:42,667 successful because of all the plumbing and hard work that you're removing from. 312 00:15:43,342 --> 00:15:44,032 Yeah, exactly. 313 00:15:44,032 --> 00:15:44,392 That's it. 314 00:15:44,392 --> 00:15:48,232 I don't think, I think that you can go straight into that design 315 00:15:48,502 --> 00:15:52,062 now and start to use, Dapr is very designed to be incrementally used. 316 00:15:52,392 --> 00:15:53,592 You can just use one API. 317 00:15:54,462 --> 00:15:57,102 And you can just do service implication between two services 318 00:15:57,252 --> 00:15:58,242 and do a call like that. 319 00:15:58,242 --> 00:15:58,812 And that's it. 320 00:15:59,292 --> 00:16:02,482 And then you can add, the pub sub messaging API, and then you can 321 00:16:02,482 --> 00:16:05,752 sort of adopt the long run durable execution workflows to do this. 322 00:16:05,752 --> 00:16:07,192 And it's very incrementally adopted. 323 00:16:07,642 --> 00:16:10,132 It's also very much designed for when you do modernization. 324 00:16:10,132 --> 00:16:12,562 you might have that big bundle piece of code already. 325 00:16:12,742 --> 00:16:14,032 In fact, we see this very frequently. 326 00:16:14,032 --> 00:16:17,722 people have developed that sort of monolith and then they just wanna 327 00:16:17,962 --> 00:16:21,472 split out an individual piece of code and break this thing out. 328 00:16:21,722 --> 00:16:25,982 And just communicate with this first, because they do it, typically, a pub, a 329 00:16:26,012 --> 00:16:29,417 pub sub messaging with that and and do sort of asynchronous communication or 330 00:16:29,417 --> 00:16:30,737 they want to make it part of a workflow. 331 00:16:30,767 --> 00:16:34,397 So it's very incrementally adoptable and, you know, that's 332 00:16:34,397 --> 00:16:36,077 what it's, yeah, it's key element. 333 00:16:36,267 --> 00:16:39,052 it's also about, how you, we see this a lot now. 334 00:16:39,937 --> 00:16:44,137 In fact, AWS talks a lot about this, about the evolution of architecture 335 00:16:44,197 --> 00:16:48,097 where you make decisions at the beginning and then things evolve over time. 336 00:16:48,097 --> 00:16:50,407 And you could have an adaptable system around all this. 337 00:16:50,767 --> 00:16:55,087 And I think this is where Dapr plays a key role because not only those APIs, I think 338 00:16:55,087 --> 00:16:59,767 another thing that's really important to draw out is the abstraction between 339 00:16:59,917 --> 00:17:03,667 the APIs and underlying infrastructure and Dapr does this thing through 340 00:17:03,667 --> 00:17:05,077 what's called its component model. 341 00:17:05,467 --> 00:17:09,757 So you have the pubs of API, and you know what we see a lot of the time 342 00:17:09,877 --> 00:17:12,007 when people go up and they start building their first microservice, 343 00:17:12,007 --> 00:17:13,417 they go, yeah, I'm gonna use Kafka. 344 00:17:13,467 --> 00:17:15,957 Kafka's the best Pub Sub thing in the world. 345 00:17:15,957 --> 00:17:19,102 And they pull in the Kafka SDK, and they embed it in their 346 00:17:19,102 --> 00:17:22,132 application and they start using the kaf and then they realize that. 347 00:17:22,327 --> 00:17:25,237 It's not quite Pub Sub, it's actually got a bunch of things that they've 348 00:17:25,237 --> 00:17:28,627 got to do around it all because it really is a, you know, streaming. 349 00:17:28,627 --> 00:17:31,387 And so they have to build sort of a pub sub API around this. 350 00:17:31,477 --> 00:17:34,267 And then they wanna add some other additional features around all this. 351 00:17:34,267 --> 00:17:38,067 And before you know it, they put the Kafka SDK bed into application and they sort of 352 00:17:38,067 --> 00:17:42,102 do this across lots of them all and then further down the line, someone goes, 353 00:17:42,102 --> 00:17:46,172 well, you know, I like Kafka, but I really always wish I was using MQTT as well and 354 00:17:46,962 --> 00:17:52,082 all of a sudden you got, this SDK embedded in your code and you're trying to satisfy 355 00:17:52,082 --> 00:17:53,882 the requirements of sort of two teams. 356 00:17:53,972 --> 00:17:58,062 So you in a, I mean as code evolution world of things, Dapr actually 357 00:17:58,082 --> 00:18:01,022 abstracts all of that because there's this concept of component model where. 358 00:18:01,587 --> 00:18:06,237 You may use the Pubsub API, but you can plug in Kafka or Rapid 359 00:18:06,237 --> 00:18:09,357 MQ or MQTT or Azure Service Bus. 360 00:18:09,877 --> 00:18:13,592 AWS SNS or Google Pub Sub as your underlying message 361 00:18:13,592 --> 00:18:14,972 broker and abstract that away. 362 00:18:15,332 --> 00:18:18,122 So your code adapts and changes with time. 363 00:18:18,122 --> 00:18:20,782 And if you decide that, Kafka wasn't the best one. 364 00:18:20,782 --> 00:18:24,132 In fact, we've worked with one client, a customer that, they had 365 00:18:24,132 --> 00:18:28,632 2000 microservices and they had Kafka built into every single one of them. 366 00:18:28,632 --> 00:18:32,292 And they decided they didn't like Kafka, and it literally took them. 367 00:18:32,632 --> 00:18:36,572 A year to re-engineer this, because they wanted to change this. 368 00:18:36,572 --> 00:18:41,722 And, the component model allows you to, swap out that underlying one, but 369 00:18:41,722 --> 00:18:45,062 you still get all the benefits of that particular, piece of infrastructure. 370 00:18:45,212 --> 00:18:48,572 So you can still get, take the benefits of Kafka because of some 371 00:18:48,572 --> 00:18:49,532 of its features around this. 372 00:18:50,082 --> 00:18:53,622 going back to your question, that code evolution, the adoption of APIs. 373 00:18:54,397 --> 00:18:58,817 is key, to Dapr success that allows you to build these microservice 374 00:18:58,817 --> 00:19:00,077 architectures from the beginning. 375 00:19:00,317 --> 00:19:05,897 It allows you to evolve their design, improve and incrementally add other APIs. 376 00:19:06,247 --> 00:19:09,427 for example, we see a lot of people start with the pubs of messaging, API. 377 00:19:10,462 --> 00:19:15,442 And then they also start to, in time, typically bring in sort of the secrets 378 00:19:15,442 --> 00:19:17,032 API for managing their secrets. 379 00:19:17,032 --> 00:19:19,972 So they communicate with their underlying infrastructure. 380 00:19:20,572 --> 00:19:24,842 And we're always looking at what's needed in a distributed system architecture. 381 00:19:24,892 --> 00:19:27,592 right now one of the things that's emerged, of course, is a lot 382 00:19:27,592 --> 00:19:28,882 of people like to talk to LLMs. 383 00:19:29,662 --> 00:19:33,272 and before we jump into the AI thing too quickly, we've introduced a 384 00:19:33,272 --> 00:19:37,742 conversation, API that allows you to abstract a consistent way for you to 385 00:19:37,742 --> 00:19:39,902 talk to an underlying language model. 386 00:19:40,322 --> 00:19:47,367 So you may have a hugging face model or a thropic or a open AI AI model and they 387 00:19:47,367 --> 00:19:50,557 all have their own different, clients who wanna pull in things like this. 388 00:19:50,557 --> 00:19:54,847 in this last release, the Dapr one 15 release, It means just a 389 00:19:54,847 --> 00:19:59,467 conversation API that allows you to have a consistent way plug in the 390 00:19:59,467 --> 00:20:04,117 component to talk to that underlying peace of that service underlying piece 391 00:20:04,117 --> 00:20:07,867 of infrastructure, yet keep the a API same, and actually additionally 392 00:20:07,867 --> 00:20:09,727 lead layer features on top of that. 393 00:20:09,727 --> 00:20:12,157 So this API doesn't, isn't just a wraparound the 394 00:20:12,157 --> 00:20:13,807 client, but it actually does. 395 00:20:14,282 --> 00:20:18,962 PII obfuscation so that if data comes back, like social security numbers or 396 00:20:19,142 --> 00:20:24,802 addresses, you know It scrubs all those and also does prompt caching as well, 397 00:20:25,012 --> 00:20:28,602 so that if you retry a prompt and it's a prompt you've already done, it can 398 00:20:28,602 --> 00:20:30,372 cache up prompt for a period of time. 399 00:20:30,702 --> 00:20:32,172 So it basically saves you money. 400 00:20:32,442 --> 00:20:33,912 So that's the thing we're always looking at. 401 00:20:33,912 --> 00:20:37,572 How is it that there are APIs in the world of microservices 402 00:20:38,052 --> 00:20:39,252 and distributed development? 403 00:20:39,457 --> 00:20:43,907 Developers are starting to use a lot, workflow and durable execution is 404 00:20:43,907 --> 00:20:48,077 like a key one because practically every application out there has 405 00:20:48,077 --> 00:20:49,817 to do coordination between things. 406 00:20:50,472 --> 00:20:50,762 Yeah. 407 00:20:51,137 --> 00:20:54,177 you combine that and the joys of Dapr actually is 'cause 408 00:20:54,177 --> 00:20:55,407 it's a code-based workflow. 409 00:20:55,497 --> 00:20:57,772 I can't stress how great that is. 410 00:20:58,417 --> 00:21:02,527 there you are as a developer and you can actually debug and run your business 411 00:21:02,527 --> 00:21:08,102 logic code and set break points in it and see the calls and combine that 412 00:21:08,102 --> 00:21:11,802 workflow with, other, the other Dapr APIs. 413 00:21:11,802 --> 00:21:14,532 there's always been this big debate of what is the difference between 414 00:21:14,712 --> 00:21:17,302 orchestration, versus, coordination. 415 00:21:17,352 --> 00:21:21,072 it's, you know, s you know, the saga coordination as opposed to choreography, 416 00:21:21,072 --> 00:21:22,272 as opposed to orchestration. 417 00:21:22,672 --> 00:21:25,762 and I think, Dapr and the event driven world as opposed to the 418 00:21:25,762 --> 00:21:27,712 long, long running, workflow world. 419 00:21:27,892 --> 00:21:31,162 And I think, basically Dapr says you don't have to choose to can combine 420 00:21:31,162 --> 00:21:32,392 those two and make them work together. 421 00:21:33,272 --> 00:21:39,172 we see a lot of that, usage of Dapr, being very strong in terms of, how you design 422 00:21:39,172 --> 00:21:40,672 and build your Microsoft architecture. 423 00:21:40,812 --> 00:21:45,380 So first thing I'll say is the component model that you've mentioned, I think 424 00:21:45,380 --> 00:21:47,425 is a seriously understated feature. 425 00:21:48,020 --> 00:21:50,810 right off the top of my head I was like being able to not care 426 00:21:50,810 --> 00:21:54,620 about the implementation of that pub sub simplifies a whole lot. 427 00:21:54,620 --> 00:21:57,800 Like even just, oh, in my staging environment, am I really gonna 428 00:21:57,800 --> 00:21:59,900 run a big cafe, cluster, no. 429 00:21:59,900 --> 00:22:01,160 Can I publish something else? 430 00:22:01,160 --> 00:22:02,600 Of course, that's nice. 431 00:22:02,960 --> 00:22:05,840 And production, my constraints are completely different and not having to 432 00:22:05,840 --> 00:22:07,610 modify code is really important there. 433 00:22:08,120 --> 00:22:11,870 And I'd love to ask a kind hands on question now about. 434 00:22:12,075 --> 00:22:13,460 What that would look like. 435 00:22:13,580 --> 00:22:17,850 First, let's talk about a kinda classic dual write problem, and I think everyone 436 00:22:17,850 --> 00:22:22,380 who's ever tried to write a distributed or monolithic micro server, anyone who's 437 00:22:22,380 --> 00:22:25,140 ever tried to write distributed system or microservice architecture, fully aware. 438 00:22:25,290 --> 00:22:29,190 And that is the challenge of I need to write something to the local 439 00:22:29,190 --> 00:22:32,370 database for that service and then publish it to a queue, and it's 440 00:22:32,370 --> 00:22:35,490 something that has to happen or has to fail in an atomic fashion. 441 00:22:36,210 --> 00:22:37,770 How do we do that with Dapr today? 442 00:22:38,175 --> 00:22:39,435 actually that's a fantastic question. 443 00:22:39,485 --> 00:22:44,075 as Dapr looks across these distributed systems patterns and problems, one 444 00:22:44,075 --> 00:22:47,135 of the patterns we actually built was called the outbox pattern, which is 445 00:22:47,135 --> 00:22:50,795 what you described the where I want to transactionally write a piece of 446 00:22:50,795 --> 00:22:55,355 state into a database and then send a message under the same transaction 447 00:22:55,835 --> 00:22:58,425 to, cope with a over a message broker. 448 00:22:59,115 --> 00:23:03,805 you can actually take that, you can dapr has a pluggable components 449 00:23:03,835 --> 00:23:06,085 for 30 plus different state stores. 450 00:23:06,185 --> 00:23:13,525 anything from was Dynamo DB, Azure, Cosmos DB to Postgres to Redis, you name it. 451 00:23:13,525 --> 00:23:14,155 It has more. 452 00:23:14,635 --> 00:23:17,755 And many of those ones that are transactional because not 453 00:23:17,755 --> 00:23:18,925 all of those are transactional. 454 00:23:19,195 --> 00:23:24,075 You can combine with your favorite message broker, for example, you can combine, for 455 00:23:24,075 --> 00:23:31,355 example, AWS Dynamo DB and a and AWS SNS and transactions, save a piece of state, 456 00:23:31,725 --> 00:23:37,035 into that state store and then at the same time publish a message onto, you know, AWS 457 00:23:37,035 --> 00:23:39,165 s and s with inside the same transaction. 458 00:23:39,165 --> 00:23:43,015 And if, the state fails to save or it doesn't save in some way, the 459 00:23:43,015 --> 00:23:45,655 message doesn't get sent and if it does get saved, the message does 460 00:23:45,655 --> 00:23:46,825 get sent on the same transaction. 461 00:23:46,825 --> 00:23:48,715 So that's one of the things that we built in. 462 00:23:48,715 --> 00:23:49,465 And it's a very. 463 00:23:49,550 --> 00:23:50,990 Complex pattern to get right. 464 00:23:51,040 --> 00:23:51,490 you really 465 00:23:51,650 --> 00:23:51,940 Yeah. 466 00:23:52,210 --> 00:23:54,340 make sure there's a transactional guarantee around this. 467 00:23:54,760 --> 00:23:56,480 It's a very common pattern that happens. 468 00:23:56,990 --> 00:24:01,870 And so I'm glad you brought up this exact example because we see that used a lot. 469 00:24:02,030 --> 00:24:05,125 because it's very common for you to say, I just want to, I want to save 470 00:24:05,245 --> 00:24:10,085 the state of this order, and then publish a message to the email service 471 00:24:10,085 --> 00:24:12,965 that tells someone to send an email and make sure that they don't get an 472 00:24:12,965 --> 00:24:16,295 email saying, your order was successful if their order wasn't successful. 473 00:24:16,775 --> 00:24:18,065 so that's what you start to see. 474 00:24:18,065 --> 00:24:18,695 We start to. 475 00:24:19,380 --> 00:24:22,620 Actually combine these APIs together. 476 00:24:22,890 --> 00:24:25,170 That's a combination of state and Pub Sub. 477 00:24:25,800 --> 00:24:28,080 we actually sort of combine other APIs like that as well. 478 00:24:28,080 --> 00:24:31,080 I think one of my favorite ones is where we actually combine 479 00:24:31,080 --> 00:24:36,030 state and service invocation, Dapr actually has this concept of actors. 480 00:24:36,840 --> 00:24:39,930 and actor are long running durable stateful objects. 481 00:24:40,240 --> 00:24:41,860 I think that it was super cool. 482 00:24:41,860 --> 00:24:45,040 If you go back and look at the original paper from Carl Hewitt who 483 00:24:45,040 --> 00:24:48,400 published all about the actor model in the seventies, and he was a great, 484 00:24:48,730 --> 00:24:51,760 American computer scientist who came up with, talked about the actor model. 485 00:24:52,110 --> 00:24:55,350 he basically foresaw the whole world of distributed computing 486 00:24:55,350 --> 00:24:56,910 and things running into. 487 00:24:57,115 --> 00:24:59,215 millions and millions of little pieces of code. 488 00:25:00,625 --> 00:25:06,565 you know what Dapr has as another API is this actor API that brings 489 00:25:06,565 --> 00:25:09,175 together state and service invocation. 490 00:25:09,355 --> 00:25:13,585 So you can have lots and lots of running instances of durable state 491 00:25:13,585 --> 00:25:16,945 that you can call and it does it and provides you with lots of guarantees, 492 00:25:16,945 --> 00:25:21,210 like around concurrency and, prevents, multi-threaded calls inside all this. 493 00:25:21,630 --> 00:25:25,510 and what we see quite frequently is that people, for example, use 494 00:25:25,510 --> 00:25:27,220 these to represent iot devices. 495 00:25:27,580 --> 00:25:31,850 So we work with a great, customer of ours that does lighting systems. 496 00:25:32,490 --> 00:25:36,280 And they have, they do lighting systems for clients and every single 497 00:25:36,280 --> 00:25:38,080 one of those lights is a little actor. 498 00:25:38,560 --> 00:25:41,860 And if you imagine, the actor says, here's the luminosity of the light. 499 00:25:41,980 --> 00:25:44,710 Here's when it was turned on when it was turned off these are all the methods, 500 00:25:44,920 --> 00:25:48,620 and you have like literally millions of them and each one has an identity 501 00:25:48,990 --> 00:25:53,990 and basically Dapr then takes all of these say, wherever you're running it 502 00:25:53,990 --> 00:25:58,010 on your Kubernetes, Cluster distributes these millions of little light objects 503 00:25:58,010 --> 00:26:03,120 all around the cluster makes some more reliable, durable, safe, scales in between 504 00:26:03,120 --> 00:26:08,020 machines if a machine fails, it recovers them over here you as a developer just 505 00:26:08,020 --> 00:26:10,030 go, there's this durable object out there. 506 00:26:10,970 --> 00:26:12,390 it's, long running. 507 00:26:12,440 --> 00:26:16,530 it's secure I get all the telemetry from it all that I think is a great 508 00:26:16,530 --> 00:26:18,210 combination of the state invocation APIs. 509 00:26:18,210 --> 00:26:21,840 So I know I took you, you started on the outbox pattern and I took you to 510 00:26:21,840 --> 00:26:25,080 actors, but it's, it's just another of these distributed systems patterns. 511 00:26:25,510 --> 00:26:29,170 and actually what's emerging today is that these concepts of these 512 00:26:29,170 --> 00:26:32,860 actors and what they're about is really can of the same thing as 513 00:26:32,860 --> 00:26:35,320 this whole agentic framework thing. 514 00:26:35,620 --> 00:26:38,950 so yeah, and we'll get onto this topic because I think this is a super cool 515 00:26:38,950 --> 00:26:41,170 area to take the conversation, but these. 516 00:26:41,365 --> 00:26:43,315 these actors are like agents. 517 00:26:43,315 --> 00:26:46,555 they have memory, and now you've just gotta say, how do they 518 00:26:46,555 --> 00:26:48,085 work with these language models? 519 00:26:48,985 --> 00:26:51,505 What we've actually done inside the Dapr framework is we've combined all 520 00:26:51,505 --> 00:26:55,495 these actors and used them as part of the durable execution workflow engine. 521 00:26:55,495 --> 00:27:00,985 I. so the workflow engine that does its coordination of Task A, task B, task 522 00:27:00,985 --> 00:27:03,425 C, make sure we Recovery is itself. 523 00:27:03,425 --> 00:27:05,805 Each one of those tasks is a little actor under the covers. 524 00:27:06,295 --> 00:27:10,385 So if you think about workflow, it runs and it goes, I want to do, 525 00:27:10,985 --> 00:27:14,190 this . task or activity one and then activity two and activity three. 526 00:27:14,490 --> 00:27:15,930 And you could do all sorts of different patterns. 527 00:27:15,930 --> 00:27:18,970 You could do chaining, you can do parallel, you can 528 00:27:18,970 --> 00:27:20,380 do wait for external input. 529 00:27:20,950 --> 00:27:24,550 Um, but each one of those is laced, durable state and then the workflow 530 00:27:24,550 --> 00:27:26,410 engine does all of the smarts. 531 00:27:26,410 --> 00:27:32,050 So basically coordinating those and making sure that they run in your, nice friendly 532 00:27:32,050 --> 00:27:36,890 language preferred way, whether that's net or C#, and it, and storing all the 533 00:27:36,890 --> 00:27:42,710 state so that if your application fails and you wanna recover where your workflow 534 00:27:42,710 --> 00:27:47,870 was running, it loads up all the activity, state loads, all the actors, and back to 535 00:27:47,870 --> 00:27:50,750 where you were running before all of the state variables and off you go again. 536 00:27:51,380 --> 00:27:55,860 So I think, whole combination of APIs, bringing them together and 537 00:27:55,860 --> 00:28:00,340 we're always looking for how to do this, We taking this down the path 538 00:28:00,340 --> 00:28:05,840 of combining pub sub messaging with, state to create this outbox pattern. 539 00:28:06,050 --> 00:28:10,100 We're also taking pub sub messaging and combining it with a jobs API And 540 00:28:10,100 --> 00:28:14,300 the jobs API we introduced is a bit like, allows you to do CR jobs so you 541 00:28:14,300 --> 00:28:15,710 can actually do deferred messaging. 542 00:28:16,445 --> 00:28:20,405 So I could do a Cron job and say, when this Cron job or this job's API triggers 543 00:28:20,405 --> 00:28:25,775 off, at this event in, in five hours time, send us message to go with it 544 00:28:25,775 --> 00:28:30,405 or, so what's key about Dapr is it's all about distributed systems patterns. 545 00:28:30,405 --> 00:28:34,005 How is it you combine these concept APIs, put them together. 546 00:28:34,290 --> 00:28:39,100 For outbox for long running durable actor state for workflow, how you 547 00:28:39,100 --> 00:28:43,350 then put together pub sub with, jobs API for Cron jobs and just 548 00:28:43,350 --> 00:28:44,871 make the developer's life beautiful. 549 00:28:44,913 --> 00:28:46,173 Wow, that was amazing. 550 00:28:46,233 --> 00:28:49,143 you don't know this, and this isn't planned, but the actor 551 00:28:49,143 --> 00:28:50,673 model is my favorite distributor. 552 00:28:50,673 --> 00:28:51,093 Pardon? 553 00:28:51,213 --> 00:28:53,608 And so I even carried a book with me everywhere. 554 00:28:54,291 --> 00:28:54,511 Oh, 555 00:28:54,523 --> 00:28:54,883 and I've, 556 00:28:54,958 --> 00:28:54,959 yes. 557 00:28:54,988 --> 00:28:57,628 I have given more copies of this book away than I have 558 00:28:57,628 --> 00:28:58,888 anything else in my entire life. 559 00:28:58,888 --> 00:29:00,688 I always feel that everyone needs to learn about the actor. 560 00:29:00,688 --> 00:29:01,018 Pardon? 561 00:29:01,018 --> 00:29:05,538 Because the power, once you model your applications in that way, is phenomenal. 562 00:29:05,913 --> 00:29:10,053 And, yeah, and again, you just went and chatted about that for nearly, I 563 00:29:10,053 --> 00:29:12,273 don't even know how long I was just sitting, listening and smiling, but, 564 00:29:12,543 --> 00:29:14,523 I could spend a whole day talking about the act of patterns because 565 00:29:14,523 --> 00:29:16,953 it also is one of my favorite things about, because I think it's the most 566 00:29:17,313 --> 00:29:21,043 underrepresented and misunderstood, because if you look at the world of, you 567 00:29:21,043 --> 00:29:24,798 know serverless Serverless as it became, and functions and that sort of thing. 568 00:29:24,798 --> 00:29:26,838 Everyone got a very excited by this and, for all the 569 00:29:26,983 --> 00:29:27,133 yep. 570 00:29:27,378 --> 00:29:27,948 it's great. 571 00:29:28,368 --> 00:29:33,408 but those things are basically stateless, they, yes, they store their state, but 572 00:29:33,408 --> 00:29:37,668 they themselves are a stateless function and they run and you put 'em in the cloud. 573 00:29:38,448 --> 00:29:41,058 Just think of actors as just like a functioned runtime. 574 00:29:41,238 --> 00:29:43,128 It is a functioned runtime, but in the case of the 575 00:29:43,156 --> 00:29:43,376 that one 576 00:29:43,406 --> 00:29:43,466 Yeah. 577 00:29:43,578 --> 00:29:47,088 it's stateful, So in memory, it's a combination of. 578 00:29:47,898 --> 00:29:49,378 the state variables you have in it. 579 00:29:49,588 --> 00:29:53,338 So going back to the light, it'd have state variables for its luminosity 580 00:29:53,338 --> 00:29:57,198 and time it was switched on and maybe, the color of the light. 581 00:29:57,548 --> 00:30:00,833 and then it has methods of act on it, like turn light on, turn light 582 00:30:00,833 --> 00:30:04,963 off, tell me it's current temperature and things like this or luminosity. 583 00:30:05,443 --> 00:30:09,543 and an actor really is a stateful long running, function that you can put 584 00:30:09,543 --> 00:30:11,043 and that turns out to be very useful. 585 00:30:11,748 --> 00:30:12,078 and then 586 00:30:12,168 --> 00:30:12,458 Yeah. 587 00:30:12,523 --> 00:30:14,118 you just be able to do communication between 'em all. 588 00:30:14,488 --> 00:30:17,648 so one of the, you know, of, as we look towards our roadmap, the actor 589 00:30:17,648 --> 00:30:21,938 pattern inside Dapr gets heavily used, as I said, I mentioned in our workflow. 590 00:30:22,478 --> 00:30:25,028 and we're starting to introduce more features inside this 591 00:30:25,028 --> 00:30:28,138 particularly, improvements on sort of its messaging patterns. 592 00:30:28,348 --> 00:30:31,858 So it can do the, it can do a, the message box, like pattern in the 593 00:30:31,858 --> 00:30:36,078 original actor model, which allows you to send messages, asynchronous 594 00:30:36,078 --> 00:30:37,728 messages between named actors. 595 00:30:37,998 --> 00:30:39,948 That's sort of one of the things that we've had on roadmap it's 596 00:30:39,948 --> 00:30:41,298 been an ask for many years. 597 00:30:41,628 --> 00:30:43,038 We're finally getting round to it all. 598 00:30:43,428 --> 00:30:46,373 but yes, the actors, as steep for long running objects is super cool. 599 00:30:48,043 --> 00:30:51,058 Yeah, so I'll tell you some of my frustrations 'cause I'm curious 600 00:30:51,058 --> 00:30:52,618 now if Dapr fixes this, right? 601 00:30:52,708 --> 00:30:57,568 So I spent nearly 10 years in the elixir ecosystem or airline ecosystem, depending 602 00:30:57,568 --> 00:31:02,008 on how masochistic, I felt that day, because I wanted to write processes, 603 00:31:02,008 --> 00:31:06,658 actors, distributed, things like this and then ventured over to New Orleans 604 00:31:06,833 --> 00:31:09,523 the framework because they brought the whole idea of virtual actors, which 605 00:31:09,523 --> 00:31:11,203 to me I was like, this is really cool. 606 00:31:11,673 --> 00:31:14,073 But the challenge is with both of those approaches and other 607 00:31:14,073 --> 00:31:15,303 approaches and rust, et cetera. 608 00:31:15,918 --> 00:31:20,238 You then get really locked in to only that language or ecosystem because 609 00:31:20,238 --> 00:31:23,148 communicating with other actors that involves you bringing in a new layer 610 00:31:23,148 --> 00:31:27,948 of communication such as H-B-G-R-B-C generating types across multiple languages 611 00:31:28,158 --> 00:31:29,838 gets very painful and complicated. 612 00:31:30,318 --> 00:31:35,598 So with Dapr, if I want to go down actors in this approach, I can 613 00:31:35,598 --> 00:31:38,478 do that in any of Dapr supported languages, and it's just gonna work. 614 00:31:39,643 --> 00:31:41,433 Yeah, the answer is, yes. 615 00:31:41,493 --> 00:31:43,563 and there's a little caveat inside all that. 616 00:31:43,806 --> 00:31:44,046 Okay. 617 00:31:44,223 --> 00:31:50,261 Dapr has actors written in Python, in C# , in Java, in JavaScript, and in Go. 618 00:31:50,351 --> 00:31:52,661 So it is got five major supported languages. 619 00:31:53,061 --> 00:31:56,151 we see the actor model used heavily across all of those. 620 00:31:56,771 --> 00:32:00,261 Um, and people create active types and start to use them more. 621 00:32:01,011 --> 00:32:04,641 the one challenge that you do have to be aware of across these different 622 00:32:05,241 --> 00:32:08,601 languages though, and this really comes down to the languages themselves, is 623 00:32:08,601 --> 00:32:11,091 that they end ended up serializing. 624 00:32:11,391 --> 00:32:14,781 How they serialize their objects is slightly different between the languages. 625 00:32:15,361 --> 00:32:15,571 Yeah. 626 00:32:15,891 --> 00:32:19,521 and unfortunately, there's no agreement even on things like JSON serialization. 627 00:32:20,151 --> 00:32:23,901 and so the challenge you get is even though people are serializing adjacent 628 00:32:23,901 --> 00:32:28,371 format, that might be inside.net, that JSON format can't necessarily be 629 00:32:28,371 --> 00:32:30,861 reread back into your Python actor. 630 00:32:32,036 --> 00:32:36,086 so it is totally possible it's just that you've just gotta make sure that when you 631 00:32:36,086 --> 00:32:40,556 plug in the serialization mechanism that you've chosen between your actors, you've 632 00:32:40,556 --> 00:32:44,996 had to choose a serialization mechanism that's consistent across those that 633 00:32:44,996 --> 00:32:48,416 can be read between those two different actor types from different languages. 634 00:32:48,476 --> 00:32:49,466 And if you. 635 00:32:49,801 --> 00:32:54,571 careful to choose that and choose a adjacent serialization format or adjacent 636 00:32:54,901 --> 00:32:58,201 serialized it that will, for example, do that or you could use a binary format. 637 00:32:58,201 --> 00:33:01,701 it doesn't really matter then you can achieve that, out of the box. 638 00:33:01,701 --> 00:33:07,131 So because we've tended to write the SDK owners in those particular repos have 639 00:33:07,131 --> 00:33:10,611 tended to use the preferred serialization format for that language specific. 640 00:33:11,326 --> 00:33:14,946 It doesn't happen just naturally but it's not too hard a problem to 641 00:33:14,946 --> 00:33:17,321 solve if that's a key thing for you. 642 00:33:17,321 --> 00:33:20,081 And so it is totally possible as long as you're aware of 643 00:33:20,381 --> 00:33:21,401 the serialization that you do. 644 00:33:22,716 --> 00:33:26,376 So I have the choice to pick between using some from string base like JSON. 645 00:33:26,406 --> 00:33:30,456 But if I wanted to use Flatbuffers or Protobuffs, that's possible and 646 00:33:30,456 --> 00:33:33,246 I'm assuming that would give me some sort of level of guarantees. 647 00:33:33,276 --> 00:33:36,006 'cause I think those are almost ubiquitous across languages. 648 00:33:36,036 --> 00:33:37,491 Although always say JSON is, and it isn't, but. 649 00:33:38,396 --> 00:33:39,656 Exactly JSON ISN and isn't. 650 00:33:39,656 --> 00:33:43,456 you could have a serialization format, put a above that you write 651 00:33:43,456 --> 00:33:46,696 out and then read that back in and then achieve that sort of thing. 652 00:33:46,996 --> 00:33:50,626 And this is one of the other goals at Dapr would really wanted to do 653 00:33:50,626 --> 00:33:54,566 is we see now that when we go into, organizations that, there is a 654 00:33:54,566 --> 00:33:56,786 multitude of languages quite frequently. 655 00:33:56,786 --> 00:34:01,406 there's one major language like net or Java, and there's 656 00:34:01,406 --> 00:34:02,726 a lot of Python coming in now. 657 00:34:03,656 --> 00:34:07,256 And, this was another key tenant that we wanted to address in the whole, the 658 00:34:07,256 --> 00:34:11,276 Dapr ecosystem was that we saw lots of different microservices frameworks out 659 00:34:11,276 --> 00:34:14,806 there, but they were always very language specific and then I would, I'd pick, 660 00:34:15,086 --> 00:34:16,736 spring Boot is a great example of this. 661 00:34:16,736 --> 00:34:17,966 It's a fabulous framework. 662 00:34:18,216 --> 00:34:21,066 it, it does sort of allows you to build Microsoft's concept, but 663 00:34:21,066 --> 00:34:24,366 it's all in the Java world and you're bought into a Java world. 664 00:34:24,366 --> 00:34:27,846 And so, you know, if you start bringing the Python developers to work next 665 00:34:27,846 --> 00:34:31,896 to them, there's a harder challenge about, well, okay, how do I make my 666 00:34:31,896 --> 00:34:33,516 Python code work with your Java code? 667 00:34:33,576 --> 00:34:37,656 Dapr breaks down all of those language and barriers between developers because 668 00:34:38,621 --> 00:34:42,431 you can send pub sub messages, you can work across workflows, you can 669 00:34:42,431 --> 00:34:44,801 use a, common SDKs across them all. 670 00:34:45,151 --> 00:34:48,831 and, bring in and make, particularly, being able to call, 671 00:34:48,901 --> 00:34:51,126 a service that's written, say in a 672 00:34:51,356 --> 00:34:55,196 java and it calls a Python service over pub sub or service invocation. 673 00:34:55,296 --> 00:34:57,966 you can do that and then of course, as we talked about with 674 00:34:57,966 --> 00:35:00,696 actors, it's also, possible if you think about that serialization. 675 00:35:00,696 --> 00:35:04,716 So breaking down those barriers between different teams and 676 00:35:04,716 --> 00:35:07,776 different languages and different choices of tools was a core tenet. 677 00:35:07,776 --> 00:35:09,156 There's been very successful with that. 678 00:35:09,586 --> 00:35:12,016 particularly as you see more python code emerge inside. 679 00:35:12,436 --> 00:35:12,646 Yeah. 680 00:35:12,646 --> 00:35:13,786 Application development today. 681 00:35:15,571 --> 00:35:16,171 Nice. 682 00:35:16,221 --> 00:35:19,731 I'm gonna ask one more question and then we can move it back to the 683 00:35:19,731 --> 00:35:23,151 agent, LLM stuff and kind of get into maybe a practical workflow there. 684 00:35:23,181 --> 00:35:23,961 'cause I do think that. 685 00:35:24,491 --> 00:35:25,991 It's just so on topic these days. 686 00:35:25,991 --> 00:35:29,351 I don't know anyone who isn't trying to integrate AI into whatever they're 687 00:35:29,351 --> 00:35:33,681 working on, but I'm curious about this now, polyglot support with Dapr, 688 00:35:33,701 --> 00:35:35,561 because you're a company, right? 689 00:35:35,561 --> 00:35:38,891 You're the founder of Diagrid, you're supporting an open source project. 690 00:35:39,851 --> 00:35:44,531 It must be tough to work out, okay, do we go and support in new language and at what 691 00:35:44,531 --> 00:35:46,181 level of demand do we decide to do that? 692 00:35:46,181 --> 00:35:50,051 Versus are we building new value for existing developers there? 693 00:35:50,051 --> 00:35:50,951 I've seen this problem. 694 00:35:51,341 --> 00:35:54,581 I used to work at PMI and people were always asking for languages. 695 00:35:54,581 --> 00:35:55,361 They wanted rust. 696 00:35:55,361 --> 00:35:58,661 they wanted Java support, they wanted Blab, whatever new language is out this 697 00:35:58,661 --> 00:36:02,801 week and it is really difficult because the level of commitment and maintenance 698 00:36:02,801 --> 00:36:06,671 required for these SDK is not trivial, and we're seeing the same right now with 699 00:36:06,671 --> 00:36:09,161 Dagger who are trying to do CI/CD is code. 700 00:36:09,536 --> 00:36:13,386 And their ability to add languages is coming down to community it's support 701 00:36:13,386 --> 00:36:16,316 and whether people are willing to take on that challenge because they need 702 00:36:16,316 --> 00:36:20,126 to focus on their product, especially given how early they are at the moment. 703 00:36:20,186 --> 00:36:23,636 So from, from your perspective, are you gonna add 12 more 704 00:36:23,636 --> 00:36:24,926 languages in the next 12 months? 705 00:36:24,926 --> 00:36:27,716 What is, like, how is that, is it easy as all generated? 706 00:36:27,716 --> 00:36:28,856 Like I'd love to know more there. 707 00:36:29,711 --> 00:36:32,231 Yeah, we have five core SDKs. 708 00:36:32,231 --> 00:36:34,121 I think you could probably count there, there were, there 709 00:36:34,121 --> 00:36:35,531 are sort of seven in total. 710 00:36:35,751 --> 00:36:38,691 we have those five I talked about plus rust and C plus 711 00:36:38,691 --> 00:36:41,001 plus, on PHP on top of all that. 712 00:36:41,331 --> 00:36:45,796 But you're right, getting maintainers to look after all the SDKs is a 713 00:36:45,796 --> 00:36:47,386 little challenge around all of this. 714 00:36:47,386 --> 00:36:47,716 We do 715 00:36:47,793 --> 00:36:48,073 rely 716 00:36:48,103 --> 00:36:48,233 Yeah. 717 00:36:48,346 --> 00:36:49,636 on the community around those. 718 00:36:50,066 --> 00:36:54,416 but we've also taken a philosophical approach with Dapr that, its APIs that you 719 00:36:54,416 --> 00:36:57,506 can use are HTTP or GRPC under the covers. 720 00:36:58,996 --> 00:37:03,616 when you're working, for example, with JavaScript, the actual, SDK on top of that 721 00:37:03,616 --> 00:37:09,106 is very thin because, JavaScript naturally is born into an http world and so you can 722 00:37:09,106 --> 00:37:11,686 call the HTTP APIs for Dapr very easily. 723 00:37:12,296 --> 00:37:15,446 You just have to be able to kind of make sure that you think through http 724 00:37:15,446 --> 00:37:18,696 concepts as opposed to maybe your language concepts around these things. 725 00:37:19,356 --> 00:37:24,541 so generally, you know, our SDKs are a language shim layer, as it were on 726 00:37:24,541 --> 00:37:27,001 top of the http or an underlying GRPC. 727 00:37:27,481 --> 00:37:32,456 And you can interact them directly I mean, we showed multiple languages 728 00:37:32,456 --> 00:37:36,056 that we didn't have SDKs for just calling an HTTP call because they 729 00:37:36,056 --> 00:37:38,236 wanted a pub, send a pub sub message. 730 00:37:39,256 --> 00:37:42,336 but, we do, and you know, Dapr is driven by a large community. 731 00:37:42,661 --> 00:37:45,961 there's over 8,000 developers in the Discord community. 732 00:37:46,426 --> 00:37:46,846 Amazing. 733 00:37:47,078 --> 00:37:51,271 There are community maintainers and core maintainers for the T net, SDK, 734 00:37:51,661 --> 00:37:54,671 you know, inside, inside the Java, SDK. 735 00:37:54,821 --> 00:37:58,611 In fact, in all the SDKs there are, maintainers from the community and so we 736 00:37:58,611 --> 00:38:03,061 rely a lot on that, community effort and engagement and it's been built up over the 737 00:38:03,061 --> 00:38:05,701 years in order to make the SDK successful. 738 00:38:06,011 --> 00:38:09,971 typically, we start with a new API that we put into the runtime, In this 739 00:38:09,971 --> 00:38:15,381 last release, the conversation API, and then, we encourage the community 740 00:38:15,381 --> 00:38:17,571 to come along and add that in. 741 00:38:17,571 --> 00:38:22,501 In fact, just this last week, with a community member, contribute into the 742 00:38:22,501 --> 00:38:27,951 Java, SDK, the conversation, API that can be used there directly, rather than 743 00:38:27,951 --> 00:38:30,321 you having to do an http call from Java. 744 00:38:30,416 --> 00:38:34,256 It's a first class language concept inside that it was a contribution. 745 00:38:34,556 --> 00:38:37,436 It gets reviewed by the JavaScript SDK maintainer. 746 00:38:38,486 --> 00:38:40,856 So we're very community orientated. 747 00:38:40,916 --> 00:38:44,876 we strongly encourage the community to come along, add things into 748 00:38:44,876 --> 00:38:48,816 the SDKs, the runtime takes a little bit more to get used to. 749 00:38:48,876 --> 00:38:50,916 There's a lot, more, let's just say. 750 00:38:51,128 --> 00:38:55,428 it takes time to learn, core runtime features to be able to contribute to that. 751 00:38:56,148 --> 00:38:59,058 but we also get a lot of people who contribute to the components contribute 752 00:38:59,238 --> 00:39:00,558 API with all these components. 753 00:39:00,978 --> 00:39:03,348 in fact, to go along with the conversation, API this also in this 754 00:39:03,348 --> 00:39:09,533 last week, we've had contributions for you know, other language, other LLMs, 755 00:39:09,773 --> 00:39:14,663 particularly, that, I've got added into as components that you can communicate with. 756 00:39:14,663 --> 00:39:19,313 So, know, going back to your question, community support is important. 757 00:39:19,313 --> 00:39:23,383 We recognize that, our SDKs are critical to community. 758 00:39:23,663 --> 00:39:25,933 and, they do take time maintaining all of these things. 759 00:39:25,963 --> 00:39:30,443 Um, we just keep pushing out there and encouraging the community 760 00:39:31,373 --> 00:39:32,783 to be part of the Dapr project. 761 00:39:33,283 --> 00:39:36,628 I'm curious if when you were you know, putting together the 762 00:39:36,628 --> 00:39:39,898 idea of the conversation API and building out how it worked. 763 00:39:39,928 --> 00:39:44,228 Did you have like that, definitive use case that you can tell a story about 764 00:39:44,228 --> 00:39:47,828 where you're like, this is what we want to make work, and what would that be? 765 00:39:48,733 --> 00:39:51,283 Yeah, so what we've seen is increasingly, I mean, I'm gonna 766 00:39:51,283 --> 00:39:54,853 take this onto one other exciting advancement actually that's coming 767 00:39:54,853 --> 00:39:57,760 out tomorrow and I'm, from the CNCF. 768 00:39:58,413 --> 00:40:00,663 we're gonna be announcing what's called Dapr Agents. 769 00:40:01,113 --> 00:40:04,893 and it's actually right now as we do this podcast, you know, it's not 770 00:40:04,893 --> 00:40:08,763 known, but if this podcast goes out after the 12th of March, it'll be 771 00:40:08,763 --> 00:40:11,083 publicly known about, but Dapr agents. 772 00:40:12,043 --> 00:40:15,673 it's a framework that's been donated by the community that allows you to 773 00:40:15,673 --> 00:40:20,583 build on top of the actor and, the conversation and the workflow model 774 00:40:20,703 --> 00:40:24,933 in order to create the first class concept of an agentic agent that allows 775 00:40:24,933 --> 00:40:27,273 you to have long running durability. 776 00:40:27,583 --> 00:40:30,973 and the same time combine that with the conversation API, in order 777 00:40:30,973 --> 00:40:33,883 to talk to language models so you know what's happening in the world. 778 00:40:34,573 --> 00:40:36,728 All this excitement about agentic systems. 779 00:40:37,008 --> 00:40:40,823 We just see as just another way of talking about distributed systems again, 780 00:40:41,063 --> 00:40:45,353 and so lots of people have created new terms for saying your agents and 781 00:40:45,353 --> 00:40:49,433 how they communicate and how they have memory and how they're durable and 782 00:40:49,433 --> 00:40:51,233 recoverable and they need workflows. 783 00:40:51,233 --> 00:40:54,203 Well, actually it turns out that's all just a distributed systems 784 00:40:54,203 --> 00:40:55,973 problem with a new name around it all. 785 00:40:56,963 --> 00:40:59,183 The thing that makes it different of course, so of course is the 786 00:40:59,183 --> 00:41:02,483 integration with language models and what does that make, that makes it 787 00:41:02,483 --> 00:41:04,253 very much more dynamic in nature. 788 00:41:04,933 --> 00:41:08,598 So the way I look at it all is that, you want to be able to write your 789 00:41:08,598 --> 00:41:13,278 very traditional, structured, and consistent workflows that go step A 790 00:41:13,278 --> 00:41:14,958 state B just like a state machine. 791 00:41:15,128 --> 00:41:18,488 I know the states to go through and it does these things and it 792 00:41:18,488 --> 00:41:20,018 doesn an embrace systematic way. 793 00:41:20,828 --> 00:41:24,278 But also you wanna be able to write these hi agentic ones which allow you 794 00:41:24,278 --> 00:41:25,778 to take advantage of language models. 795 00:41:26,603 --> 00:41:30,173 With a language model, which is sort of non-deterministic in some way, can 796 00:41:30,173 --> 00:41:34,403 come back with different answers, can help you achieve human-like tasks. 797 00:41:34,403 --> 00:41:38,553 It were, I mean, of course the classic one is, I want to build agentic system 798 00:41:38,553 --> 00:41:42,693 that helps me book an airline ticket, book a hotel, and a favorite event that 799 00:41:42,693 --> 00:41:47,448 I'm going to when I visit City X. And in that world, you'd have an agent that knows 800 00:41:47,448 --> 00:41:49,968 how to talk to airline ticketing systems. 801 00:41:50,178 --> 00:41:54,828 You'd have an agent that knows how to talk to hotel booking things, and an 802 00:41:54,828 --> 00:41:56,448 agent that would figure out how to. 803 00:41:57,048 --> 00:41:59,688 go off into a particular city and defend your events and they would all 804 00:41:59,688 --> 00:42:01,818 be communicating with language models. 805 00:42:02,268 --> 00:42:05,928 But in the end, it's still a distributed systems problem you don't want halfway 806 00:42:05,928 --> 00:42:09,228 through this, that the whole thing fails and gives up and lost all your 807 00:42:09,228 --> 00:42:11,388 hotel bookings and forgot everything. 808 00:42:11,708 --> 00:42:15,138 and that has to be recoverable and so it has to be durable in memory and 809 00:42:15,198 --> 00:42:16,728 durable executions is all part of this. 810 00:42:17,418 --> 00:42:21,658 what we've gone and done, is that we've built this ag agentic framework 811 00:42:21,928 --> 00:42:27,838 first class into Dapr again, built on all of these core APIs around actors 812 00:42:27,838 --> 00:42:32,518 and workflows and conversation API, which is just a way of talking to 813 00:42:32,878 --> 00:42:36,868 any generic underlying language model to bring into the agentic system. 814 00:42:36,868 --> 00:42:41,103 So you have this concept of a workflow agent and a standalone agent. 815 00:42:41,873 --> 00:42:46,433 And by annotating these and saying, I want this to be a long 816 00:42:46,433 --> 00:42:48,153 run, durable, type of agent. 817 00:42:48,423 --> 00:42:50,703 And by the way, here's the tools it can use. 818 00:42:50,923 --> 00:42:55,693 this agent knows how to use the API to call onto the weather service 819 00:42:55,693 --> 00:42:57,363 or the airline booking system. 820 00:42:57,863 --> 00:42:58,003 You 821 00:42:58,003 --> 00:43:01,133 can then combine and build these, agent systems. 822 00:43:01,133 --> 00:43:01,613 So I think. 823 00:43:02,528 --> 00:43:06,308 What's exciting for us about this is that we see a lot of other frameworks 824 00:43:06,308 --> 00:43:11,168 out there, starting to build these agen distributed applications, but 825 00:43:11,168 --> 00:43:14,618 we're like, well, you know, Dapr was kind of pretty much designed 826 00:43:14,618 --> 00:43:16,028 from this, from the very beginning. 827 00:43:16,673 --> 00:43:20,273 Especially going back to the actor model, which is this durable state that keeps the 828 00:43:20,273 --> 00:43:22,643 memory of something and was recoverable. 829 00:43:23,123 --> 00:43:26,303 You've now just gotta combine this with a language model because, the 830 00:43:26,303 --> 00:43:29,598 language model, is coming back with some answers and you can keep asking 831 00:43:29,598 --> 00:43:33,858 it and refining it and that's why the conversation API with this language 832 00:43:33,858 --> 00:43:38,028 model combined with basically actors and workflows has been key for us to 833 00:43:38,403 --> 00:43:43,173 announce this Dapr agents model and one of my kiosks from this is like, please 834 00:43:43,173 --> 00:43:49,173 go out and try out this Dapr Agents, framework it's only in Python right now. 835 00:43:49,473 --> 00:43:52,833 we started there because Python was by far the most popular language. 836 00:43:53,253 --> 00:43:56,043 We are gonna bring it to Java and.net and go. 837 00:43:56,523 --> 00:43:58,833 and, And JavaScript in time. 838 00:43:59,083 --> 00:44:03,283 but we think it's a very exciting way of kind of bringing developers 839 00:44:03,283 --> 00:44:06,853 into the Gentech AI world, which is a distributed systems problem 840 00:44:06,853 --> 00:44:08,263 with language models in the end. 841 00:44:10,213 --> 00:44:13,773 Wow, that's really awesome and I can't believe it's happened tonight, tomorrow, 842 00:44:13,773 --> 00:44:15,153 whenever, as you're gonna release that. 843 00:44:15,213 --> 00:44:18,853 'cause I literally spent the last three weeks playing with every AG agentic, 844 00:44:18,873 --> 00:44:23,013 LLM framework there is trying to put together some real scenarios for the 845 00:44:23,013 --> 00:44:27,163 Rawkode Academy because when I have new videos that I put into an R two bucket, 846 00:44:27,343 --> 00:44:31,243 you know, I want an agent that converts 'em into the HLS format that I use for 847 00:44:31,243 --> 00:44:33,433 distribution and then want it transcribed. 848 00:44:33,433 --> 00:44:37,463 But I want an agent that can then go over the transcription from X API, 849 00:44:37,533 --> 00:44:40,713 and check it for comment errors and terms that I have in the system. 850 00:44:40,743 --> 00:44:44,343 Because, let's face it, no LLM so far has been able to transcribe Rawkode 851 00:44:44,643 --> 00:44:50,058 probably wouldn't get Dapr correct but if we give them context, yeah. 852 00:44:50,058 --> 00:44:52,968 They can look at text and say, we actually think, given that this is a 853 00:44:52,968 --> 00:44:56,598 Cloud Native podcast about a product called Dapr, we probably wanna 854 00:44:56,598 --> 00:44:57,708 make sure it's spelled correctly. 855 00:44:57,713 --> 00:45:01,698 And it, and even now to generating thumbnails where I post it to my slack 856 00:45:01,698 --> 00:45:03,138 and I can thumb up to approve it. 857 00:45:03,168 --> 00:45:05,813 And then it schedules the episode like, I believe I could do all 858 00:45:05,813 --> 00:45:08,443 this with agentic, LLL systems, 859 00:45:08,703 --> 00:45:09,123 Yes. 860 00:45:09,133 --> 00:45:11,323 hadn't really found the framework to make that happen yet. 861 00:45:11,383 --> 00:45:14,743 And it sounds like you've just solved my problem in a 50 minute podcast. 862 00:45:14,743 --> 00:45:15,388 I'm pretty happy. 863 00:45:15,483 --> 00:45:18,123 that you'll find, I, I would love to hear your opinions. 864 00:45:18,123 --> 00:45:22,593 In fact, we could do a whole podcast in itself of comparison between the 865 00:45:22,593 --> 00:45:25,023 different Lgentic frameworks out there. 866 00:45:25,263 --> 00:45:29,373 There's a few common of popular ones that emerged like Lang Chain and Crew AI 867 00:45:29,373 --> 00:45:34,343 and, auto gen around these things but I think the difference that we're expecting 868 00:45:34,343 --> 00:45:36,113 that the Dapr one brings is that, we've. 869 00:45:36,848 --> 00:45:40,193 You know, Dapr has been, Dapr is used by thousands of thousands, tens 870 00:45:40,193 --> 00:45:41,423 of thousands of companies today. 871 00:45:42,033 --> 00:45:45,723 we track, 40,000 different companies through the open source 872 00:45:45,723 --> 00:45:47,253 project that are using Dapr today. 873 00:45:47,523 --> 00:45:49,383 It's heavily used in production scenarios. 874 00:45:49,383 --> 00:45:51,873 It's used, we've shown it can be scalable. 875 00:45:52,173 --> 00:45:54,753 Going back to the active model, it's incredibly efficient. 876 00:45:55,023 --> 00:45:59,253 given that each one of these agents that will run will be an underlying actor, the 877 00:45:59,253 --> 00:46:02,293 actor can start up under 50 milliseconds. 878 00:46:02,293 --> 00:46:03,883 So it's super fast startup time. 879 00:46:04,223 --> 00:46:07,913 you can pack tens of thousands of these on a single core machine. 880 00:46:08,153 --> 00:46:09,563 So it's very cost effective. 881 00:46:09,713 --> 00:46:11,183 It's kind of production ready. 882 00:46:11,183 --> 00:46:12,353 It's very well tested. 883 00:46:13,223 --> 00:46:17,788 and it has all the needs because a lot of these other urgent systems haven't thought 884 00:46:17,788 --> 00:46:21,418 about the communication problem, about distributed messaging around these things. 885 00:46:21,658 --> 00:46:24,568 They haven't necessarily thought about and had a great workflow engine for doing 886 00:46:24,568 --> 00:46:25,918 all the coordination around them all. 887 00:46:26,278 --> 00:46:28,948 And they certainly haven't even thought about the component model, 888 00:46:29,128 --> 00:46:32,258 which is abstracting, your code from the underlying infrastructure. 889 00:46:32,588 --> 00:46:37,073 They all tightly, couple into some particular infrastructure around 890 00:46:37,073 --> 00:46:39,663 these things and thought about that because, that wasn't a core tenant. 891 00:46:40,103 --> 00:46:43,183 that's where, Dapr agents we believe is kind of has an 892 00:46:43,183 --> 00:46:44,263 edge around all these things. 893 00:46:44,353 --> 00:46:46,443 Of course, we've still gotta prove it over time. 894 00:46:46,753 --> 00:46:47,833 it's still new. 895 00:46:48,053 --> 00:46:51,183 it's playing, catch up probably in, in the agent framework world, but then. 896 00:46:51,983 --> 00:46:52,883 Hopefully it'll take off. 897 00:46:52,883 --> 00:46:54,923 So please, I'd love you to try it out. 898 00:46:55,343 --> 00:46:58,583 I would love to hear your feedback and I would love you to do an entire session 899 00:46:58,583 --> 00:46:59,993 of comparing all these frameworks. 900 00:47:00,413 --> 00:47:03,773 'cause I bet you the Dapr agents one will come out pretty close to the top 901 00:47:04,253 --> 00:47:09,123 in my mind in terms of ease of use and in terms of functionality, and 902 00:47:09,123 --> 00:47:10,413 particularly in terms of production. 903 00:47:10,413 --> 00:47:10,913 readiness. 904 00:47:11,558 --> 00:47:13,928 I definitely will, we'll definitely make that happen. 905 00:47:13,958 --> 00:47:16,333 But you did set yourself up for one more question, just 906 00:47:16,333 --> 00:47:17,928 with that, amazing talk there. 907 00:47:18,288 --> 00:47:22,878 You said thousands of agents on a single node and 50 milliseconds starting time. 908 00:47:22,878 --> 00:47:24,228 So right off the top of my head, I was like. 909 00:47:24,498 --> 00:47:28,158 Buying a container, how are you running and orchestrating them things. 910 00:47:28,813 --> 00:47:31,483 those are actually done as individual pieces of code. 911 00:47:31,483 --> 00:47:34,693 So I mean, what happens is that Dapr runs on sort of 912 00:47:34,783 --> 00:47:36,573 on, Kubernetes as a platform. 913 00:47:36,903 --> 00:47:40,593 But you know, the way, an actor actually works is it's 914 00:47:40,593 --> 00:47:42,723 just a it's a stateful object. 915 00:47:42,873 --> 00:47:46,653 So just as you write a class object inside, say a, an object orientated 916 00:47:46,653 --> 00:47:50,883 language like .Net or Java or one of these things, it's just a piece of 917 00:47:50,883 --> 00:47:52,683 code that runs inside your system. 918 00:47:52,683 --> 00:47:53,433 I mean, you 919 00:47:53,501 --> 00:47:56,278 you can give of it in some ways as like a process, but actually 920 00:47:56,278 --> 00:47:57,838 it is a lower level in a process. 921 00:47:58,138 --> 00:48:01,028 So if you imagine, you've got processing inside that you've got 922 00:48:01,028 --> 00:48:03,408 object types it's just an object type. 923 00:48:03,828 --> 00:48:06,618 And so, you know, that's why it starts up fast. 924 00:48:06,768 --> 00:48:09,708 it's just a piece of code and it's got, but it's got a piece of code 925 00:48:10,128 --> 00:48:11,778 with an identity associated with it. 926 00:48:11,778 --> 00:48:15,058 So it's actor 1, 2, 3, or, Mark's agent number one. 927 00:48:15,418 --> 00:48:20,688 And The cleverness of Dapr is that it routes messages through to an 928 00:48:20,688 --> 00:48:24,678 individual piece of code with a named identity, of which you have tens of 929 00:48:24,678 --> 00:48:28,518 thousands of them, or even millions of them running on your system and 930 00:48:28,668 --> 00:48:30,408 route, routes that message correctly. 931 00:48:30,678 --> 00:48:34,818 it's at that level of granularity and that's the thing that people, 932 00:48:34,948 --> 00:48:36,238 fail to understand sometimes. 933 00:48:36,238 --> 00:48:39,658 You know, like, you know, containers are large things and you know, 934 00:48:39,658 --> 00:48:42,808 even getting down to processes, you know, great a process, but this 935 00:48:42,808 --> 00:48:46,108 is sort of multiple actors within inside a process, as it were. 936 00:48:46,158 --> 00:48:46,998 does that answer your question? 937 00:48:47,823 --> 00:48:48,783 Yeah, it definitely does. 938 00:48:48,783 --> 00:48:52,953 I mean, in my head I thought, okay, an agent is a Dapr service that 939 00:48:52,953 --> 00:48:55,263 gets deployed to my ClusterAPI. 940 00:48:55,413 --> 00:48:57,483 so I need to take a look at the conversation API and actually 941 00:48:57,483 --> 00:48:58,923 see how this all pieces together. 942 00:48:59,253 --> 00:49:02,223 but it's definitely sounds very interesting, very exciting, 943 00:49:02,253 --> 00:49:04,503 and I've got so many things I want to throw out already. 944 00:49:04,603 --> 00:49:07,843 this might be a late night in the office room, me we'll see how things go, but. 945 00:49:08,103 --> 00:49:10,443 As we finish up here, I do want to just mention how does 946 00:49:10,443 --> 00:49:11,943 Diagrid come into all of this? 947 00:49:12,093 --> 00:49:14,733 because, you know, what, what would, what do we do at Diagrid, well, 948 00:49:14,828 --> 00:49:19,098 at Diagrid, you know, we actually, we're very, source orientated, 949 00:49:19,408 --> 00:49:21,268 particularly around the Dapr ecosystem. 950 00:49:21,973 --> 00:49:25,963 and you know, what we focus on particularly here is that, we want 951 00:49:25,963 --> 00:49:30,553 to make your solutions successful using Dapr, the open source project. 952 00:49:30,553 --> 00:49:34,593 So we focus on, we have, we have two services that we, have today. 953 00:49:34,903 --> 00:49:38,443 we have a service called Diagrid Conductor that allows you to manage 954 00:49:38,443 --> 00:49:40,123 and operate Dapr on top of Kubernetes. 955 00:49:40,513 --> 00:49:43,333 So you imagine that Kubernetes is kind of a key platform for 956 00:49:43,333 --> 00:49:44,263 people running Dapr on it. 957 00:49:44,818 --> 00:49:50,833 conductor allows you to do monitoring and upgrade and kind of visualization of 958 00:49:50,833 --> 00:49:56,243 your applications and all the ops inside that and then we have a very core service 959 00:49:56,243 --> 00:50:01,703 called Diagrid catalyst, which you think of it as a serverless offering of Dapr. 960 00:50:01,723 --> 00:50:06,533 It provides you just a, think of it as a take away this Dapr sidecar. 961 00:50:06,543 --> 00:50:10,053 we never actually mentioned that, but Dapr runs as a sidecar for your app application 962 00:50:10,323 --> 00:50:14,493 rather than you managing and operating it all we simply host all the Dapr APIs 963 00:50:14,493 --> 00:50:19,933 for you, like the workflow, API or the pubs, API, API on a service and you can 964 00:50:19,933 --> 00:50:21,343 then literally call 'em from anywhere. 965 00:50:22,038 --> 00:50:27,078 So you can basically build an application and deploy it onto a VM or a container 966 00:50:27,078 --> 00:50:31,608 service or even a function runtime, and then take advantage of say, the 967 00:50:31,608 --> 00:50:35,918 workflow Dapr, API, in order to do coordination across these things. 968 00:50:36,228 --> 00:50:41,128 as a random example, if you are an AWS developer and you're 969 00:50:41,128 --> 00:50:44,728 using step functions, and if step functions can only be used with. 970 00:50:45,613 --> 00:50:50,603 as AWS functions instead, and you wanna take advantage of Dapr workflow, you could 971 00:50:50,603 --> 00:50:56,073 use, Dapr workflow, for example, to work across, AWS Fargate service to coordinate 972 00:50:56,073 --> 00:51:00,103 a set of, containers if you wanted to, and do the coordination of, service A 973 00:51:00,103 --> 00:51:01,723 equivalent service B across containers. 974 00:51:01,723 --> 00:51:06,123 So Catalyst is allows you to have an easy way to, you consume the Dapr 975 00:51:06,143 --> 00:51:10,158 APIs from anywhere and actually very well fits in the concept of platform 976 00:51:10,158 --> 00:51:14,638 engineering as a team which also is a very key area that we've seen emerge 977 00:51:14,638 --> 00:51:18,988 recently where in platform engineering, what's the contract between the platform 978 00:51:18,988 --> 00:51:21,388 team and the application developer? 979 00:51:21,418 --> 00:51:24,118 Turns out that app, Dapr is an amazing. 980 00:51:24,808 --> 00:51:29,038 Contract between those two because it allows the platform team to 981 00:51:29,038 --> 00:51:30,778 provide a set of different services. 982 00:51:31,108 --> 00:51:33,028 and yet the developers don't have to change all their 983 00:51:33,028 --> 00:51:34,648 code around all these things. 984 00:51:34,898 --> 00:51:37,088 if they're using, for example, Pubs up API. 985 00:51:37,428 --> 00:51:42,198 but the underlying platform team wants to provide a new message broker, whether 986 00:51:42,198 --> 00:51:46,038 that's Kafka or RapidMQ , without going back to our previous conversation, 987 00:51:46,038 --> 00:51:47,748 ripping out the SDKs of everything. 988 00:51:48,078 --> 00:51:51,078 With the platform engineering trend that's happening in this world as well. 989 00:51:51,298 --> 00:51:55,318 particularly in sort of the Cloud Native ecosystem that contractual 990 00:51:55,318 --> 00:51:59,368 or interface understanding between those two is where Dapr shines 991 00:51:59,398 --> 00:52:00,718 beautifully around these things. 992 00:52:00,919 --> 00:52:01,249 Awesome. 993 00:52:01,339 --> 00:52:02,749 Thank you for sharing all that as well. 994 00:52:02,819 --> 00:52:05,049 will Diagrid have a booth at KubeCon? 995 00:52:05,674 --> 00:52:08,874 We will do, yes, we will be at KubeCon,  KubeCon Europe. 996 00:52:08,894 --> 00:52:13,094 That's coming up on the 1st of April, so please come along and meet us there. 997 00:52:13,364 --> 00:52:15,648 We would love to hear all your questions, hear you wanna hear about 998 00:52:15,648 --> 00:52:19,788 Dapr, talk about agentic systems, talk about platform engineering. 999 00:52:19,788 --> 00:52:22,083 Talk about, how you build applications. 1000 00:52:22,083 --> 00:52:23,433 Distributed runtimes. 1001 00:52:23,463 --> 00:52:24,633 we're a game for everything. 1002 00:52:24,903 --> 00:52:25,833 Yeah, please come find us. 1003 00:52:26,988 --> 00:52:31,258 Yeah, go to the booth, get a demo, and definitely enjoy the conversation. 1004 00:52:31,755 --> 00:52:32,955 Thank you so much for joining me. 1005 00:52:33,025 --> 00:52:35,265 that was a, I just loved everything we talked about there. 1006 00:52:35,265 --> 00:52:37,485 That's completely up my street and I hope that everyone listening 1007 00:52:37,485 --> 00:52:38,475 at home enjoyed that too. 1008 00:52:38,574 --> 00:52:39,594 thank you for having me today. 1009 00:52:39,654 --> 00:52:40,254 It has been great. 1010 00:52:40,340 --> 00:52:40,790 Awesome. 1011 00:52:40,790 --> 00:52:41,445 Thanks for joining us. 1012 00:52:42,155 --> 00:52:45,425 If you want to keep up with us, consider us subscribing to the podcast 1013 00:52:45,575 --> 00:52:49,945 on your favorite podcasting app, or even go to cloudnativecompass.fm. 1014 00:52:50,305 --> 00:52:55,135 And if you want us to talk with someone specific or cover a specific topic, reach 1015 00:52:55,135 --> 00:52:57,295 out to us on any social media platform 1016 00:52:57,805 --> 00:53:01,495 and tell next time when exploring the cloud native landscape on three 1017 00:53:01,945 --> 00:53:02,485 on three. 1018 00:53:02,955 --> 00:53:06,785 1, 2, 3. Don't forget your compass. 1019 00:53:06,785 --> 00:53:07,025 Don't forget 1020 00:53:07,025 --> 00:53:07,440 your compass.