0:00 Welcome, everyone. Unfortunately, Laura could not join us today again. What does she even do? Geez, sorry. In today's episode, I'm joined by Mark, the co founder and CEO of Dapr. A CNCF project that helps make microservice development almost possible. Let's go dig in without me. Enjoy the episode. Hi, Mark. Welcome to Cloud Native Compass. Could you please take a few moments to introduce yourself to our audience? Thank you, David. It's fantastic to be here. Yeah. My name is Mark Fossil. I'm the CEO of Diagrid. Diagrid is a company where we build on open source technologies,

0:38 particularly on DAPA, where we'll talk about a lot today, and excited to be here today. Awesome. Thank you so much for joining us. I'm really excited for this episode because I have built distributed systems, both microservices and workflows, and if PubSub event queues. And I love the polarity. I don't know if that's even the right word. But when we adopt microservices, I often tell people is to make their life simpler, and then bam. They've now got this horrible, crazy architecture with all of these things. So maybe we could talk about the adoption of microservices. Are we going in the right direction?

1:10 And how dapper is hopefully gonna make that easier for people? Yeah. Microservices is not new now in any way. If you look at a lot of the publications, and we've said there's a great thing from Infocube where they published their crossing the chasm technologies from the architectural point of view. Microsoft is way over on the right now and has crossed the chasm from a technology perspective. Have been around for, I mean, have been talking around for a good fifteen years now. And you have to look back, what does it actually mean? I think it was a

1:38 driving factor from the businesses because the business wanted to move faster. And when you built this large compiled piece of code that wasn't distributed in some manner, it meant that it's rate fast and ship features fast. And there was this requirement, actually the two driving requirements was one was as we moved more services to the cloud and ran things on the cloud and kind of distributed them around so they ran on more machines, coupled with the fact that the business wanted to ship features faster because I wanted to be able to update my inventory application

2:11 faster than sort of my payment application that split things apart. And so there's just a big debate, which I think is a bit kind of strange in myself, which is what's the size of a microservice? The answer is it could be anything. It could be a giant piece of compiled code, or it could be millions of little small things. And often it lies somewhere in between, usually around domain driven design, you draw a domain and context is where you draw boundaries around your business itself. Where is my payment application sit, and where does my kind of other business process sit?

2:47 And you sort of draw boundaries around those. And then, of course, as developers do, you sort of have to choose a choice of implementations. So that's kind of really kind of the brief reason for microservices and the history around them of why they've developed, because we're often now in this sort of cloud native world where everyone runs things on top of Kubernetes as the platform. And what we just saw time and time again is that people were reinventing the same pieces of code themselves, the same software patterns in order to build these distributed architectures which run on multiple machines. And so

3:23 that's where Dappa comes in. Awesome. Yeah. So with microservices, I often say to people, and it's I don't know if it's like the best analogy I've ever had in my life or the worst. If we think about a carrot on a stick, right, and we're leading or a horse, we're leading the horse to water, Really, microservices are gonna make your life better. They're simpler. You can rewrite them in a day. And all we've all heard these terms before. But, unfortunately, we take all these developers, we guide them to the water, and, actually, it's an ocean. And now they've gotta boil in

3:50 some degree. It's an ocean of complexity with regards to the tools that need. Because when we simplify the code itself, the application, the microservice, that is really easy. It could be 12 lines of code. It could be a 100 lines of code. It's not important. But that complexity doesn't really get removed. It gets pushed to the platform or to the infrastructure. I think from my knowledge of Dapr, you're solving that big ball of complexity of the platform bit. Exactly. Mean, that's what it does is that you everyone approaches this and you jump in, you go, yeah, I can

4:22 create, know, process A, process B or container A, container B. And I'm just going to talk between this front end application, talk through usually some typically gateway services deployed. And then I have, say we built a fictitious application that had a shopping cart service, a checkout service, and maybe an inventory service. And you deploy all these things, but all of a sudden, there's all these difficult problems that emerge. And I think they usually stem down to things like communication between them, coordination across them, and sort of statefulness around them all. And so the first thing that you

4:52 often run into is that you want to be able to do communication between some services because everything's not running in isolation in a giant compiled ball anymore. So you've really distributed the problem to a networking problem now, which means communication. And so all of a sudden, you've got to have service A talk to service B. And so the first thing you run into is it's got to be discoverability. And so, one of the key tenants that DAPA brings to a distributed systems platform is this concept of identity, where every piece of code, actually every piece

5:22 of process or running code has a name associated with it. And it turns out that this is incredibly important because if you're in the infrastructure land, you don't really care about named pieces of code, you deploy these processes. But you want to say, I want to call my inventory service, and I want to call the payment method on the inventory or sort of the stock service, I should say, on the inventory service to see if it's there. Do I have stock inside of my inventory? And so you have these named identities. The first problem you run into is discoverability

5:51 and then calling securely. And then also then you fall into the concept of retries because you've done a call and it's failed and you have to retry because there's network failures. And then on top of this, of course, you want to have observability. Did my call succeed? And do I have observability data? So this whole thing turns out to be a big challenge in the end. And before you know it, people jump in and they think, oh, I'll do a simple rest call between these and then I got to make it secure. And then I could do retries.

6:19 And then this whole discovery mechanism where you bring in something like Zookeeper or was it the one from how should you call the console console? Yes, in order to do name resolution around those things, and you're sort of building the whole platform up yourself, just to kind of talk between two services and call a method on them, and run this on some distributed systems platform. So that's exactly what DAPA does. DAPA says, well, why are you reinventing the wheel or reinventing the pattern? We say, let's take advantage of building a platform and a set of

6:51 consistent APIs that allow you to do this communication, coordination and sort of state management, and also things like secrets, my dear friends, between things. And so to take that into a concrete example, DAPA has this concept of a service invocation API, which says you create two services, service A and service B. They both have names. And then I kind of get those registered into resolution service that can discover where those services are. And now as a developer, I can simply call on to the invoke API that says invoke the method, the stock service on the inventory service wherever

7:32 it's running and call out method for me. And that's all I have to do. And that is all heavy lifting for you. Does the discoverability, the secure calls, the retries, the observability around all that. And basically, what this is all about is developers have to write business code in the end. That's where you're trying to get to, not build platforms the whole time. And so although it's fun for developers to build these platforms, you keep reinventing this just for every application. So DAPA solves these hard distributed systems problems. And we can go into each one of

8:04 those APIs and talk about it a bit more because each one of them is fairly significant. That's what its underlying concept is to accelerate this. We've shown actually, do it every, in fact, we're just about to release now, I think called a state of DAPA report to 2025, where we interviewed 200 plus developers who were using Dapr and asked them what was the number one thing that you got from Dapr. The categorical thing that came back was that it accelerated the development of my microservices application anywhere between 3050% productivity around all of that. You can ask for a better response than

8:44 that. Right? That's exactly what you wanna be here, I'm assuming, not to put words in your mouth. But, yeah, that's really cool. So there's one thing I wanna touch on a little bit there. You talked about where Dapr fits into the stack with Sandalyn retries. To a certain degree, it makes communication or request to other services a function call rather than a generic HTTP call where you do the plumbing and the retries and all that. And people always say Kubernetes, it gives you service discovery for free. And it's like, you know, well, yeah, kinda. Good luck with that.

9:14 Right? There's a whole market here of service meshes that said, no, it doesn't because you've got a hookup. Again, all of this more stuff. And what I like about where Dapr sits in the stack versus the service mesh is that Dapr is service and application aware. It actually understands my code to a certain degree where service mesh is more of this generic federal bit of paper plumbing that does give me value, but Dapr is slightly higher up the stack. I'm assuming that was intentional. So maybe we can talk about why why is this important for developers as

9:46 they want to increase their velocity building a microservice architecture? That's a question that we often get on the project is, is Dapr a service mesh? And the answer is kind of yes and no. The answer is yes, it does the same sort of functionality, but service meshes work purely in the networking layer and only at the networking layer. There is no understanding or concept of an application as it were. And this goes back to that application identity thing I just referred to. Service meshes are coordinating network packets and changing things on the network layer and doing and you know, if

10:18 you want to enforce that consistently across every single thing that happens inside your company, then great. So you can implement service, a service mesh to do that. But this idea of application identity, that a piece of code, a process, a container actually has identity that I can reason about and discover and call is the big difference in the end, and between DAPA and service meshes. And that kind of gets to the point where what happens is that DAPA really is in its comparison with service meshes, there's only just one API that aligns with on that. That's the

10:52 service invocation. The other very important API that uses all the time with DAPA is publish and subscribe or pubsub or asynchronous messaging, where you publish a message and you can subscribe to it on a topic and you can then sort of broadcast or send it to whoever is listening. Asynchronous messaging and the concept of message brokers in between is sort of key to a distributed system. In fact, that's probably the most common API that gets used inside DAPA. And so, know, at that point as well, you're also sending messages between two services or two applications that are running.

11:25 And that's the big difference when DAPA does its concepts of end to end security, and it does observability, and it does resiliency across these, you get it across all those APIs. So, in a case of if you decide to do a service invocation call between two services, and then you do a pubsub message, you get to end to end observability of going through all these APIs and you see that whole call train. Well, with something like with a service mesh, you just see the call that happens on the network and you don't know it went over this message broker all

11:55 of a sudden, and then came back because it doesn't know this at the application level. So one of the big differences is that whole concept. And I think this often comes down to people who think about the infrastructure layer of things and in that space, and then people who are looking at the application layer. And what's very unique about the DAPA project is we solely talked about what are the needs of an application developer? How is it they need service invocation, asynchronous calls with PubSub? And then I think one of the most important ones is workflow,

12:27 where you do coordination between services. Yes, service A is going to call service B, service C. And if it fails, how do I recover and do that retry mechanisms. And often what's referred to now is durable execution. The fact that I can keep a long running workflow running like a piece of business logic, invent a failure, recover to where I was, start to replay from where I left off before and keep going, and do this in a coordinated fashion, just like any sort of classic workflow process. But the unique thing that Dappa has is a code based workflow.

13:01 And so you write your code as a developer would write in your favorite language, be Python or C sharp or Java. And you can do this coordination or saga type patterns, as well as combined with orchestration patterns as well for PubSub. And this is sort of the powerful concept of Dapr. It has PubSub messaging for communication, workflow for coordination. So, going back to your question about service meshes and DAPA, yeah, service invocation and that aligns with some of the service meshes with DAPA, but DAPA is much, much more than that. And actually, we see Dapr used side by side with service meshes

13:37 as well. If people do want to use it with a service mesh, that's good. All right. There's a lot we could talk about from there. I love that you got into the the kind of don't know the term, the different actors of Dapr, the different feature sets, the APIs that are being provided. Because you're right, durable execution as it's knowing, like, today seems to be everywhere right now. Everyone is talking about how do we do this? What are the tools that we're doing? What are the language supports, etcetera? And I think they solve an important

14:03 problem. And this was possible before to a certain degree where you publish something to Kafka, you have consumers, they do the job. And the sagas have been around much longer than durable execution, but it was completely event driven. And the challenge there, at least from back in the days when I was doing this stuff, is the visibility across the whole system was really difficult. Yes. What is published in this event? What is consuming it? Then how does this chain work through to the point where you have, like, whole tracer based test systems that seed end to end workloads

14:33 work? And this new durable execution pattern of just writing the workflows in code and making sure that the responses are memorized and continued and all that. I think it's so cool. I can remember the first time I've seen it. Was like, wow. Like, this is amazing. And I had no idea that Dapr even offered this today until I was kinda looking around on the website to see what was new. And it it kinda got me thinking is that you offered KV. I think there's the PubSub stuff with Kafka. I don't know if it supports alternative back

15:01 ends. There's no workflows. Like, you're essentially taking all of the problems of distributed system or microservices system and bring it out new APIs climbing up the stack, whatever you wanna call it. And I think that is so important. And it brings me back people always ask, when should I start with microservices? When do we adopt microservices? And the answer is always typically been, oh, make it work in a big monolith. Try not to make it too much of a ball of mud and then refactor to microservices with all these patterns. And that's been the status quo for decades.

15:30 Right? And I feel like now with DAPR, people are it's a buy into it. You could be a team of two and ship hundreds of microservices and be really successful because of all the plumbing and hard work that you're removing from. Yeah, exactly. That's it. I don't think I think that you can go straight into that design now and start to use. DAP is very designed to be incrementally used. You can just use one API, and you can just do service implication between two services and do a call like that, and that's it. And then you can add

16:00 the PubSub Messaging API, and then you can sort of adopt the long run durable execution workflows to do this, and it's very incrementally adopted. It's also very much designed for when you do modernization, that you might have that big bundle piece of code already. In fact, we see this very frequently. People have developed that sort of monolith, and then they just want to split out an individual piece of code and break this thing out and just communicate with this first, because they do it typically a pub sub messaging with that and do sort of asynchronous

16:28 communication or they want to make it part of a workflow. So it's very incrementally adoptable. And that's what it's key element. It's also about how you we see this a lot now. In fact, AWS talks a lot about this, about the evolution of architecture, where you make decisions at the beginning and then things evolve over time and you could have an adaptable system around all this. And I think this is where DAPA plays a key role because not only those API, I think another thing that's really important to draw out is the abstraction between the APIs and underlying infrastructure.

17:02 And DAPA does this thing through what is called its component model. So you have the PubSub API and what we see a lot of the time when people go up and they start building their first microservice, they go, Yeah, I'm going use Kafka. Kafka's the best PubSub thing in the world. And they pull in the Kafka SDK and embedded in their application. They start using the Kafka, and then they realize that it's not quite PubSub. It's actually got a bunch of things that they've got to do around it all because it really is streaming. And so they have to build sort of

17:30 a PubSub API around this. And then they want to add some other additional features around all this. And before you know it, they put the Kafka SDK embedded into application and they sort of do this across lots of them all. And then further down the line, someone goes, well, I like Kafka, but I really wish I was using MQTT as well. And all of a sudden you got this SDK embedded in your code and you're trying to satisfy the requirements of sort of two teams. So in this code evolution world of things, Dapr actually abstracts all of that because there's this

17:59 concept of component model where you may use the PubSub API, but you can plug in Kafka or RapidMQ or MQTT or Azure Service Bus or AWS SNS or Google PubSub as the underlying message broker and abstract that away. So your code adapts and changes with time. And if you decide that Kafka wasn't the best one, in fact, we've worked with one client customer that they had 2,000 micro services. And they had Kafka built into every single one of them. And they decided they didn't like Kafka. And it literally took them a year to reengineer this because they wanted to change this. And

18:37 the component model allows you to swap out that underlying one, but you still get all the benefits of that particular piece of infrastructure. So you can still get take the benefits of Kafka because of some of its features around this. Going back to your question, that code evolution, the adoption of APIs is key to Dappa's success. Allows you to build these microservices architectures from the beginning. It allows you to evolve their design, improve and incrementally add other APIs. For example, we see a lot of people start with the PubSub Messaging API, and then they also start to, in time,

19:13 typically bring in sort of the secrets API for managing their secrets so they communicate with their underlying infrastructure. And we're always looking at what's needed in a distributed systems architecture. Right now, one of the things that's emerged, of course, is a lot of people like to talk to LLMs. And before we jump into the AI thing too quickly, we've introduced a conversation API that allows you to abstract a consistent way for you to talk to an underlying language model. So you may have a hugging face model or a Thrompic or an open AI model, and they all have their own different clients.

19:49 Want to pull in things like this. In this last release, the DAPA 1.15 release, we introduced a conversation API that allows you to have a consistent way, plug in the component to talk to that underlying piece of that service, underlying piece of infrastructure, yet keep the API the same. And actually additionally layer features on top of that. So this API isn't just a wraparound the client, but it actually does PII obfuscation, so that if data comes back like social security numbers or addresses, it scrubs all of those. And also does prompt caching as well. So that if you retry

20:26 a prompt and there's a prompt you've already done, it can cache that prompt for a period of time. So it basically saves you money. So that's the thing we're always looking at. How is it that there are APIs in the world of microservices and distributed development that developers are starting to use a lot? Workflow and durable execution is like a key one because practically every application out there has to do coordination between things. And then you combine that. And the joys of Dapr actually is because it's a code based workflow. I can't stress how great that is. There you are as

20:59 a developer. And you can actually debug and run your business logic code and set breakpoints in it, and see the calls, and combine that workflow with other, you know, the dapper API, there's always been this big debate of what is the difference between orchestration versus coordination is the saga, you know, the saga coordination as opposed to choreography, as opposed to orchestration. And I think that and the event driven world as opposed to the long running workflow world. And I think basically Dapra says, you don't have to choose, you can combine those two and make them work together.

21:33 We see a lot of that usage of Dapa being very strong in terms of how you design and build your microservices architecture. So first thing I'll say is the component model that you've mentioned, I think, a seriously understated feature. Right off the top of my head, I was, like, being able to not care about the implementation of that PubSub. It simplifies a whole lot. Like, even just, oh, in my staging environment, am I really gonna run a big Kafka cluster? No. Can I publish something else? Of course. That's nice. In production, my constraints are completely different, and

22:05 not having to modify code is really important there. And I'd love to ask a kind of hands on question now about what that would look like. But first, let's talk about a kind of classic dual rate problem that I think everyone who's ever tried to write a distributed or monolithic microservice anyone who's ever tried to write distributed system or microservice architecture fully aware. And that is the challenge of I need to write something to the local database for that service and then publish And it to a it's something that has to happen or has to fail in an atomic

22:35 fashion. Yes. How do we do that with DAPR today? Actually, that's a fantastic question. As DAPR looks across these distributed systems' patterns and problems, one of the patterns we actually built was called the outbox pattern, which is what you described, the where I want to transactionally write a piece of state into a database, and then send a message under the same transaction to over a message broker. So you can actually take that you can DAPA has a pluggable components for 30 plus different state stores, anything from AWS DynamoDB, to Azure, Cosmos DB to Postgres to Redis, you name it, it has more.

23:14 And many of those ones that are transactional, because not all of those are transactional, you can combine with your favorite message broker, For example, you can combine, for example, AWS DynamoDB and AWS SNS and transactionally save a piece of state into that state store. And then at the same time, publish a message onto AWS SNS with inside the same transaction. If the state fails to save or it doesn't save in some way, the message doesn't get sent. And if it does get saved, the message does get sent on the same transaction. So that's one of the things that we

23:48 built in. It's a very complex pattern to get right. You really want to make sure there's a transactional guarantee around this. It's a very common pattern that happens. And so I'm glad you brought up this exact example, because we see that used a lot, because it's very common for you to say, I want to save the state of this order, and then publish a message to the email service that tells someone to send an email and make sure that they don't get an email saying your order was successful if their order wasn't successful. So that's what you start to

24:17 see. We start to actually combine these APIs together. That's a combination of state and PubSub. We actually sort of combine other APIs like that as well. I think one of my favorite ones is where we actually combine state and service invocation. And Dapr actually has this concept of actors. And actors are long running durable stateful objects. I think that it was super cool if you go back and look at the original paper from Carl Hewitt, who published all about the actor model in the 70s. And he was a great American computer scientist who came up with talk about the actor model. He

24:52 basically foresaw the whole world of distributed computing and things running into millions and millions of little pieces of code. And what Dappa has as another API is this Actor API that brings together state and service invocation, so you can have lots and lots of running instances of durable state that you can call. And it does it and provides you with lots of guarantees like around concurrency and prevents multi threaded calls inside all this. And what we see quite frequently is that people, for example, use these to represent IoT devices. So we work with a great customer of

25:30 ours that does lighting systems. And they do lighting systems for clients, every single one of those lights is a little actor. And if you imagine the actor says, here's the luminosity of the light, here's when it was turned on, when it was turned off, these are all the methods. And you have like literally millions of them. And each one has an identity. And basically, Dapo then takes all of these and say wherever you're running out on your Kubernetes cluster, distribute these millions of little light objects all around the cluster, makes them more reliable, durable, safe, scales them between machines. If a

26:04 machine fails, it recovers them over here. And you as a developer just go, there is this durable object out there. And it long running, it's secure, I get all the telemetry from it all. That I think is a great combination of the state identification API. So I know I took you, you started on the outbox pattern and I took you to actors, but it's just another of these distributed systems patterns. And actually what's emerging today is that these concepts of these actors and what they're about is really kind of the same thing as this whole agentic framework

26:35 thing. So, yeah, and we'll get onto this topic because I think this is a super cool area to take the conversation. But these actors are like agents, they have memory. And now you've just got to say, how do they work with these language models? What we've actually done inside the DAPA framework is we've combined all these actors and used them as part of the durable execution workflow engine. So the workflow engine that does its coordination of task A, task B, C, makes them a recovery is itself each one of those tasks is a little actor under the covers.

27:06 So if you think about workflow, it runs and it goes, I want to do this task or activity one, and then activity two, activity three. And you can do all sorts of different patterns, you can do chaining, you can do parallel, you can do wait for external input. But each one of those is lacked a durable state. And then the workflow engine does all of the smarts of basically coordinating those and making sure that they run-in your nice friendly language preferred way, whether it's dot net or C, and storing all the state so that if your application fails and you want to

27:41 recover where your workflow was running, it loads up all the activity state, loads all the actors, and back to where you were running before all of the state variables and off you go again. So I think tall combination of API's bringing them together, and we're always looking for how to do this. We taking this down the path of combining PubSub messaging with state to create this ad box pattern. We are also taking PubSub messaging and combining it with a jobs API. And the jobs API we introduced is a bit like allows you to do cron jobs.

28:14 So you can actually do deferred messaging. So I can do a cron job and say, when this cron job or this jobs API triggers off, this event in five hours time, send this message to go with it all. So what's key about Dapr is it's all about distributed systems patterns. How is it you combine these concept APIs, put them together for Outbox, for long running durable actor state, for workflow, how you then put together PubSub with Jobs API for cron jobs and just make the developer's life beautiful. Wow. That was amazing. You don't know this, and this isn't

28:47 planned. But the actor model is my favorite distributed pattern, and so I even carry the book with me everywhere. Oh, okay. I have given more copies of this book away than I have anything else in my entire life. I always feel that everyone needs to learn about actor pattern because the power, once you model your applications in that way, is phenomenal. And yeah. And, again, you you just been attracted about that for nearly I don't even know how long I was just sitting listening and smiling. But I could spend a whole day talking about the actor patterns because it

29:14 also is one of my favorite things, I think it's the most underrepresented and misunderstood because if you look at the world of, you know, serverless as it became and functions and that sort of thing, everyone got very excited by this and for all the right reasons, it's great. But those things are basically stateless. They, yes, they store their state, but they themselves are a stateless function, and they run and you put them in the cloud. Just think of actors as just like a function runtime. It is a function runtime, but in the case of the data ones, it's

29:43 stateful. So in memory, it's a combination of the state variables you have in it. So going back to the light, it would have state variables for its luminosity and time it was switched on, and maybe the color of the light. And then it has methods of act on it, like turn light on, turn light off, to tell me its current temperature and things like this or luminosity. And an actor really is a stateful long running function that you can put and that turns out to be very useful. And then you've just got to be able

30:12 to do communication between them all. So one of the, know, as we look towards our roadmap, the active pattern inside DAPA gets heavily used, as I said, mentioned in our workflow. And we're starting to introduce more features inside this, particularly improvements on sort of its messaging patterns. So it the can message box like pattern in the original actor model, which allows you to send messages, asynchronous messages between named actors. That's sort of one of things that we've had on road map. It's been an ask for many years. We're finally getting around to it all. But,

30:43 yes, the actors are steeped for long running objects is super cool. Yeah. So I'll tell you some of my frustrations because I'm curious now if Dapr fixes this. Right? So Yeah. I spent nearly ten years in the elixir ecosystem or airline ecosystem depending on how masochistic I felt that day because I wanted to write processes, actors, distribute things like this. I then ventured over to New Orleans, the framework, because they brought the whole idea of virtual actors, which to me, I was like, this is really cool. But the challenge is with both of those approaches and other approaches

31:14 in Rust, etcetera, you then get really locked in to only that language ecosystem because communicating with other actors then involves you bringing in a new layer of communication, such as HTTP, gRPC, generating types across multiple languages as it gets very painful and complicated. So with Dapr, if I want to go down actors in this approach, I can do that in any of Dapr supported languages and it's just going to work? Yeah. The answer is yes. And there's a little caveat inside all that. Okay. Yes, Dapr has actors written in Python, in C, in Java, in JavaScript,

31:49 and in Go. So it's got five major supported languages. We see the actor model used heavily across all of those. And people create actor types and start to use them all. The one challenge that you do have to be aware of across these different languages, though, and this really comes down to the languages themselves, is that they ended up serializing how they serialize their objects is slightly different between the languages. And unfortunately, there's no agreement even on things like JSON serialization. And so the challenge you get is even though people are serializing in a JSON format

32:24 that might be inside dot net, that JSON format can't necessarily be reread back into your Python actor. So it is totally possible. It's just that you've just got to make sure that when you plug in the serialization mechanism that you've chosen between your actors, you've had to choose a serialization mechanism that's consistent across, though that can be read between those two different actor types from different languages. And if you careful to choose that and choose a JSON serialization format, or JSON serializer that will, for example, do that, or you could use a binary format, it doesn't really

32:58 matter, then you can achieve that out of the box. Because we've tended to write the SDK owners in those particular repos have tended to use the preferred serialization format for that language specific. It doesn't happen just naturally. But it's not too hard a problem to solve if that's a key thing for you. And so it is totally possible as long as you're aware of the serialization that you do. Yeah. So I have the choice to pick between using some from the string based like JSON. But if I wanted to use flat buffers or poor buffs, that's possible. And I'm

33:30 assuming that would give me some sort of level of guarantees because I think those are almost ubiquitous across languages. Although we say JSON isn't isn't. But Exactly. JSON isn't isn't, but you could have a serialization format, put a buff that you write out and then read that back in and then achieve that sort of thing. And this is one of the other goals that DAPA would really wanted to do is we see now that when we go into organizations that there is a multitude of languages. Quite frequently, there's one major language like dot net or Java,

34:00 and there's a lot of Python coming in now. And this was another key tenant that we wanted to address in the whole DAPA ecosystem was that we saw lots of different microservices frameworks out there, but they were always very language specific. And I would pick Spring Boot as a great example of this. It's a fabulous framework. It does sort of allows you to build Microsoft's concept, but it's all in the Java world and you're bought into a Java world. And so, if you start bringing the Python developers to work next to them, there's a harder challenge about, well, okay, how do I

34:31 make my Python code work with your Java code? Dapr breaks down all of those language and barriers between developers Because you can send PubSub messages, you can work across workflows, you can use common SDKs across them all and bring in and make particularly being able to call a service that's written, say, in Java, and it calls a Python service over PubSub or service invocation, you can do that. And then, of course, as we talked about with Actors, it's also possible if you think about that serialization. So breaking down those barriers between different teams and different languages and different choices of tools

35:06 was a core tenet. It's been very successful with that, particularly as you see more Python code emerge inside application development today. Nice. I'm going to ask one more question, and then we can move it back to the agentic LLM stuff and kinda get into maybe a practical workflow there. Because I do think that's it's just so on topic, this is. I don't know anyone who isn't trying to integrate AI into whatever they're working on. But I'm curious about this now Polyglot support with Dapper because you're a company. Right? You're the founder of DiaGrid. You're supporting an open source project.

35:39 It must be tough to work out, okay, do we go and support a new language what level of demand do we decide to do that versus are we building new value for existing developers there? I've seen this problem. I used to work at Pulumi, and people are always asking for languages. They wanted Rust. They wanted Java support. They wanted Blab, whatever new languages out this week. And it's really difficult because the level of commitment and maintenance required for these SDK is not trivial. And we're seeing the same right now with Dagger who are trying to do CICD as code. Yes. And their

36:10 ability to add languages is coming down to community support and whether people are willing to take on that challenge because Yes. They need to focus on their product, especially given how early they are at the moment. So from your perspective, are you gonna add 12 more languages in the next twelve months? What is like, how is that as easy as all generated? Like, I'd love to know more there. Yeah, we have five core SDKs. I think you could probably count that there are sort of seven in total. We have those five I talked about plus Rust and plus plus

36:39 and PHP on top of all that. But you're right, getting maintainers to look after all the SDKs is a little challenge around all this. We do rely a lot on the community around those. But we've also taken a philosophical approach with Dappa that its APIs that you can use are HTTP or gRPC under the covers. So when you are working, for example, with JavaScript, the actual SDK on top of that is very thin because JavaScript naturally is born into an HTTP world. And so you can call the HTTP APIs for Dapr very easily. You just have to be able to kind

37:13 of make sure that you think through HTTP concepts as opposed to maybe your language concepts around these things. So generally, our SDKs are a language shim layer, as it were, on top of the HTTP or an underlying gRPC. And you can interact directly. I mean, we showed multiple languages that we didn't have SDKs for just calling an HTTP call because they wanted to send a PubSub message. Dappa is driven by a large community. There's over 8,000 developers in the Discord community. There are community maintainers and core maintainers for the dot net SDK you know, inside

37:53 the Java SDK. In fact, in all the SDKs, there are maintainers from the community. And so we rely a lot on that community effort and engagement, and it's been built up over the years in order to make the SDK successful. Typically, we start with a new API that we put into the runtime in this last release, the conversation API. And then we encourage the community to come along and add that in. In fact, just this last week, we had a community member contribute into the Java SDK, the conversation API that can be used there directly, rather than

38:28 you having to do an HTTP call from Java. It's a first class language concept inside that. It was a contribution. It gets reviewed by the JavaScript SDK maintainer. So we're very community orientated. We strongly encourage the community to come along, add things into the SDKs. The runtime takes a little bit more to get used to. There's a lot more, let's just say, it takes time to learn core runtime features to be able to contribute to that. But we also get a lot of people who contribute to the components contribute API with all these components. In fact, to go along with the conversation

39:02 API, this also in this last week, we've had contributions for other language, other LLMs, particularly got added into as components that you can communicate with. Going back to your question, community support is important. We recognize that our SDKs are critical to community and they do take time maintaining all of these things. We just keep pushing out there and encouraging the community to be part of the DAPA project. I'm curious if when you just were, you know, putting together the idea of the conversation API and building out how it worked, did you have, like, that definitive

39:42 use case that you can tell a story about where you're like, this is what we want to make work and what would that be? Yeah. So what we've seen is increasingly, I mean, I'm going to take this on to one of the exciting advancement actually that's coming out tomorrow. And I'm from the CNCF. We're going to be announcing what's called DAPA agents. And it's actually right now, as we do this podcast, you know, it's not known, but if this podcast goes out after the March 12, it'll be publicly known about. But DAPA agents, it's a framework that's been donated by the

40:14 community that allows you to build on top of the actor and the conversation and the workflow model in order to create the first class concept of an agentic agent that allows you to have long running durability, and at the same time combine that with the conversation API to talk to language models. So, you know, what's happening in the world? All this excitement about agentic systems, we just see as just another way of talking about distributed systems again. And so lots of people have created new terms for saying your agents and how they communicate and how they have memory and how they're

40:49 durable and recoverable and they need workflows. Well, actually, it turns out that's all just a distributed systems problem with a new name around it all. The thing that makes it different, of course, though, is the integration with language models. What does that make? That makes it very much more dynamic in nature. So the way I look at it all is that you want to be able to write your very traditional structured and consistent workflows that go step A, step B, just like a state machine. I know the state to go through and it does these things that it does in a very

41:19 systematic way. But also you want to be able to write these agentic ones, which allow you to take advantage of language models. With a language model, which is sort of nondeterministic in some way, it can come back with different answers, can help you achieve human like tasks that were. I mean, of course, the classic one is I want to build an agentic system that helps me book an airline ticket, book a hotel, and a favorite event that I'm going to when I visit City X. And in that world, you'd have an agent that knows how to talk to airline ticketing

41:49 systems. You'd have an agent that knows how to talk to hotel booking things and an agent that would figure out how to go off into a particular city and defend your events. And they would all be communicating with language models. But in the end, it's still a distributed systems problem. Don't want halfway through this, that the whole thing fails and gives up and lost all your hotel bookings and forgot everything. And that has to be recoverable. And it has to be durable in memory and durable execution is all part of this. So what we've gone and done is that

42:19 we've built this agentic framework first class into DAPA, again, built on all of these core APIs around actors and workflows and conversation API, which is just a way of talking to any generic underlying language model to bring into agentic systems. So you have this concept of a workflow agent and a standalone agent. And by annotating these and saying, I want this to be a long run durable type of agent. And by the way, here's the tools it can use. This agent knows how to use the API to call on to the weather service or the airline

42:56 booking system. You can then combine and build these systems. So I think what's exciting for us about this is that we see a lot of other frameworks out there starting to build these agentic distributed applications. But we're like, well, know, DAPA was kind of pretty much designed from this from the very beginning, especially going back to the active model, which is this durable state that keeps the memory of something and risk recoverable. You've now just got to combine this with a language model, because the language model is coming back with some answers and you can

43:29 keep asking it and refining it. And that's why the conversation API with this language model combined with basically act as workflows has been key for us to announce this Dapr agents model. One of my key asks from this is like, please go out and try out this Dapr agents framework. It's only in Python right now. We started there because Python was by far the most popular language. We are going to bring it to Java and .net and Go and JavaScript in time. But we think it's a very exciting way of kind of bringing developers into the Jintiq AI world, which is a

44:05 distributed systems problem with language models in the end. Wow. That's really awesome. And I can't believe it's happened tonight, tomorrow, whenever as you're gonna release that because I literally spent the last three weeks playing with every agentic LLM framework that is trying to put together some real scenarios with the Rawkode Academy because when I have new videos that I put into an r two bucket, you know, I want an agent that converts them into the HLS format that I use for distribution. And then when it transcribed, but I want an agent that can then go over the

44:35 transcription from xAPI and check it for comment errors and terms that I have in the system because let's face it, no LLM so far has been able to transcribe Rawkode. Probably wouldn't get Dapr correct. But if we give them context, yes, they can look at text and say, we actually think, that this is a cloud native podcast about a product called DAPR, we probably wanna make sure it's spelled correctly. Even though to generating thumbnails where I post it to my Slack and I can sum up to approve it and then it schedules the apps. Like, I believe I could do

45:05 all this with agentic LLL systems. Yes. But I hadn't really found the framework to make that happen yet. And it sounds like you've just solved my problem in a fifty minute podcast. Pretty sure that you will find I I would love to hear your opinions. In fact, we could do a whole podcast in itself of comparison between the different agentic frameworks out there. There's a few common, you know, popular ones that emerged like LangChain and CrewAI and Autogen around these things. But I think the difference that we're expecting that the Dappa one brings is that we've,

45:36 you know, DAPA is being, DAPA is used by thousands of thousands, tens of thousands of companies today. We track the 40,000 different companies through the open source project that are using DAPA today. It's heavily used in production scenarios. It's used, we've shown it can be scalable. Going back to the actor model, it's incredibly efficient, given that each one of these agents that will run will be an underlying actor. The actor can start up in under fifty milliseconds. So it's super fast startup time. You can pack tens of thousands of these on a single core machine. So it's very cost

46:09 effective. It's kind of production ready. It's very well tested. And it has all the needs because a lot of these other agentic systems haven't thought about the communication problem, about distributed messaging around these things. They haven't necessarily thought about and had a great workflow engine for doing all the coordination around them all. And they certainly haven't even thought about the component model, which is abstracting your code from the underlying infrastructure. They all tightly couple into some particular infrastructure around these things and thought about that because that wasn't a core tenant. That's where DAP regions, we believe, has

46:42 an edge around all these things. Of course, we still got to prove it over time. It's still new. It's playing catch up probably in the agentic framework world, but then, you know, hopefully it'll take off. So please, I'd love you to try it out. I'd love to hear your feedback and I'd love you to do an entire session of comparing all of these frameworks. Cause I bet you the DAP regions one will come out pretty close to the top in my mind in terms of ease of use and in terms of functionality and particularly in terms of production readiness.

47:11 I definitely will. We'll definitely make that happen. But you did set yourself up for one more question just for that amazing talk there. You said thousands of agents on a single node and fifty milliseconds starting time. So right off the top of my head, was like, die in a container. How are you running and orchestrating them things? Those are actually done as individual pieces of code. So, I mean, what happens is that Zapr runs on sort of on Kubernetes as a platform. But, you know, the way an actor actually works is it's just a it's a stateful

47:42 object. So just as you write a class object inside, say, an object orientated language like dot net or Java or one of these things, it's just a piece of code that runs inside your system. I mean, you give it in some ways as like a process, but actually is a lower level in a process. If you imagine you've got process and inside that you've got object types, it's just an object type. And so, you know, that's why it starts up fast. It's just a piece of code and it's got end up, but it's got a piece of code with

48:10 an identity associated with it. So it's actor 123 or marks agent number one. And the cleverness of dapper is that it routes messages through to an individual piece of code with a named identity, of which you have 10s of 1000s of them, or even millions of them running on your system, and routes that message correctly. It's at that level of granularity. And that's the thing that people fail to understand sometimes. Containers are large things and even getting down to processes, greater process, but this is sort of multiple actors within inside a process as it were.

48:46 Does that answer your question? Yeah. It definitely does. I mean, in my head, I thought, okay. An agent is a dapper service that gets deployed to my cluster. So I need to take a look at the conversation API and actually see how this all pieces together. But it definitely sounds very interesting, very exciting. And I've got so many things I wanna throw at it already. That's maybe a late night in the office where we will see how things go. But As we finish up here, I do wanna just mention how does DieGrid come into all of

49:11 this? Because, you know, what what would what do we do at DieGrid? Well, at Diagrid, we were very source orientated, particularly around the DAPA ecosystem. And what we focus on particularly here is that we want to make your solutions successful using DAPR, the open source project. So we focus on, we have two services we have today. We have a service called Dagrid Conductor that allows you to manage and operate DAPR on top of Kubernetes. So you imagine that Kubernetes is kind of a key platform for people running Dapr on it. Conductor allows you to do monitoring and

49:47 upgrade and kind of visualization of your applications and all the ops inside down. And then we have a very cool service called Diagrid Catalyst, which is think of it as a serverless offering of Dapr. It provides you just a think of it as a takeaway this Dapr sidecar. We never actually mentioned that Dapr runs as a sidecar for your application. Rather than you managing and operating it all, we simply host all the Dapr APIs for you, like the workflow API or the pubs API as a service, and you can then literally call them from anywhere.

50:22 So you basically build an application and deploy it onto a VM or a container service or even a function runtime, and then take advantage of, say, the workflow DAPR API in order to do coordination across these things. As a random example, if you're an AWS developer and you're using Functions Step Functions can only be used with AWS functions instead, and you want to take advantage of DAPA workflow, you could use DAPA workflow, for example, to work across AWS Fargate service to coordinate a set of containers if you wanted to, and do the coordination of service A,

51:00 equivalent service B across containers. So Catalyst allows you to have an easy way to consume the Dapr APIs from anywhere and actually very well fits in with the concept of platform engineering as a team, which also is a very key area that we've seen emerge recently, where in platform engineering, what's the contract between the platform team and the application developer? Turns out that DAPR is an amazing contract between those two because it allows the platform team to provide a set of different services. And yet the developers don't have to change all their code around all these things if

51:35 they're using, for example, PubSub API. But the underlying platform team wants to provide a new message broker, whether that's Kafka or RapidMQ, without going back to our previous conversation, ripping out the SDKs of everything. With the platform engineering trend that's happening in this world as well, particularly in sort of the cloud native ecosystem, that contractual or interface understanding between those two is where Dapr shines beautifully around these things. Awesome. Thank you for sharing all that as well. Will Diagrid have a booth at KubeCon? We will do. Yes. We will be at KubeCon. KubeCon Europe that's coming up on the

52:10 April 1. So please come along and meet us there. We would love to hear all your questions. Wanna hear about DAPR, talk about agentic systems, talk about platform engineering, talk about how you build applications, distributed runtimes, we're at game for everything. Yeah. Please come find us. Yeah. Go to the booth, get a demo, and definitely enjoy the conversation. Alright. Thank you so much for joining me. That was a I just loved everything we talked about there. That's completely up my street, and I hope that everyone listening at home enjoyed that too. Thank you for having me today. It has

52:40 been great. Awesome. Thanks for joining us. If you wanna keep up with us, consider subscribing to the podcast on your favorite podcasting app or even go to cloudnativecompass.fm. And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform. Until next time when exploring the cloud native landscape on 3. On 3. One, two, 3. Don't forget your compass. Forget your compass.