S07E21 - Dapr: The Secret Sauce to Simplifying Distributed Applications with Mark Fussell

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

• RJJ Software’s Software Development Services, whether your company is looking to elevate its UK operations or reshape its US strategy, we can provide tailored solutions that exceed expectations.

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

The Modern .NET Show

S07E21 - Dapr: The Secret Sauce to Simplifying Distributed Applications with Mark Fussell

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode, we have the pleasure of connecting with Mark Fussell, the CEO of Diagrid and a veteran of Microsoft, where he has dedicated over 21 years to advancing developer technologies. We delve into his extensive background, beginning with his early experiences working on .NET before its official launch, specifically with the System.XML component, and extending his contributions to various Microsoft projects, including WCF. Mark also highlights the inception of Service Fabric and the Distributed Application Runtime (Dapr), acknowledging the evolution of software architecture toward distributed systems and microservices.

Mark elaborates on Dapr, emphasizing its role as a cloud-native solution designed to simplify the development of microservices by providing a consistent set of APIs for common distributed system patterns. He further explains how Dapr facilitates communication between services and orchestrates functionality such as state management and pub/sub messaging across platforms like Kubernetes. Utilizing Dapr empowers developers to focus on building business value rather than wrestling with networking complexities or hardcoded configurations.

We dive deeper into the practical applications of Dapr, illustrating how it not only aids in the development of new applications but also supports the modernization of existing applications (brownfield projects). Mark discusses Dapr’s capabilities surrounding microservices architecture, highlighting its unique features like service discovery, end-to-end security, and observability, which dramatically enhance developer productivity.

As we explore the multi-language support of Dapr, Mark demonstrates how it enables seamless communication between services written in different programming languages, reinforcing the ecosystem’s flexibility. He emphasizes the ease of deploying Dapr applications to Kubernetes clusters, detailing how developers can use Dapr’s CLI and Visual Studio integrations to streamline their workflow with minimal overhead.

The conversation takes an exciting turn as we discuss Dapr’s new features, including a built-in workflow engine, which simplifies the development of long-running, durable applications. Mark introduces the concept of Dapr Agents, a framework that allows for the creation of sophisticated, agentic AI systems that leverage language models for various tasks while ensuring durability and recovery in distributed applications.

Listeners will also learn about Dapr University, a platform created by Diagrid that offers courses designed to teach Dapr’s extensive features. Mark encourages developers to engage with the vibrant Dapr community via Discord, a hub for collaboration and support.

Episode Transcription

Yeah, exactly. In fact, one of the central premises of Dapr has, you know, one of its goals is not only to be multi-language, in that anyone can use the APIs from any language they come from. So it has SDKs. First, you can call it HTTP if that’s all you care about. But it has SDKs for Java, JavaScript, of course, .NET, Python, and Go.

Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am your host: Jamie “GaProgMan” Taylor.

In this episode, Mark Fussell from Diagrid joins us to talk about Dapr—that’s D-A-P-R—the Distributed Application Runtime, which aims to make it trivial to build applications in a distributed manner: covering things like service discovery, Pubsub messaging, and distribution of your microservice-based applications.

And the reason why I mentioned that is because, going to your AI discussion, is that we had an amazing contributor actually from Microsoft, actually he’s ex-Microsoft now, a guy called Roberto Rodriguez, who worked in Microsoft Research, We built an agentic AI framework on top of Dapr workflows because it had this power of being able to do recoverability and coordination.

Along the way, we cover the history of Dapr, how it started as a Microsoft incubator project (and was heavily inspired by Project Tye), and how it’s now a full graduated project of the CNCF (Cloud Native Computing Foundation).

Anyway, without further ado, let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : [0:00] Hello, everyone, and welcome back to another episode of The Modern .NET Show. I am with a wonderful guest today, Mark, who is going to talk us through some stuff. But I thought before we even get to that, Mark, would you mind giving us a brief introduction, a little bit of like get to know you, that kind of thing?

Mark : [0:21] Yeah, well, it’s fantastic to be here on the show today. I’m excited to have a conversation with you. Yes, let me give you some background. You know I’m originally from the UK but I immigrated to the US 25 years ago, and worked at Microsoft for many, many years. I worked on many developer technologies, in fact when I first joined Microsoft, I actually worked on .NET, before it was even released. In fact I did the System.Xml inside .NET, was my first job when I turned up at Microsoft; and created the things like a Reader and XmlWriter. And XSLT transform when that was a thing around us, then those were the heady days of XML. You know, back in the early 2000s when there were lots of XML conferences.

Mark : [1:03] After that, I went on and worked on WCF, Windows Communication Foundation, if your listeners know all about that, I’m sure they do. I was actually the program manager lead on the security part. And then as Azure started to take provenance, I actually started realizing that we had to build these large-scale distributed services, joined Azure, and there I actually started a project which became known as Service Fabric. And service fabric was a key platform that we built inside Microsoft that really was kind of, when you look back at it was the days of platform engineering before we called it platform engineering. But it was literally the platform engineering team that where we built a distributed systems platform which had everything from replication technology to data access technology, to how we actually do a set of services for coordination, all the way up to a programming model layer and even an application description layer on top of it all. And we built this and used it in many large services, particularly all the data access services inside .NET.

Mark : [2:15] And then while I was at Microsoft, I actually then started realizing that we had to make sure that any developers who built on these distributed systems–particularly as Kubernetes came into play and there were other ones–we needed to have a way for all developers to be able to enjoy the fact that they can build applications in any language of their choice and on any distributed systems platform. And so I started the Distributed Application Runtime or the DAPP project, whilst I was working on the Azure Incubations team, which was actually part of Mark Rosonovich’s org. Mark Rosonovich, the Azure CTO, he was my manager when I was actually my final days at Microsoft, which was actually nearly four years or three and a half years ago now. But anyway, we started the Dapr project there in the Incubations team, and it became very successful.

Mark : [3:08] So that’s kind of a brief kind of background of my kind of full 21 years of Microsoft career through lots of different development technologies. There are lots of other pieces as well I can touch on, but I do love the main pieces.

Mark : [3:21] Actually, including a thing called WSE, which everyone ever remembers, which was a precursor to Windows Communication Foundation, which was fun. So I spent a lot of time on the W… the standards at those times, like SOAP and things like that, which was both good and bad around those things. So hopefully that gives you a bit of an outline of where I am.

Mark : [3:43] And actually, I should say right now, I actually left Microsoft and now I’m the CEO of Diagrid. And Diagrid is where we build commercial services based around Dapr, open source projects. And inside that, particularly, we should dive into some of this, but we help developers and IT professionals and DevOps people be very successful taking Dapr and building it into their solutions. Particularly focusing on Kubernetes as a platform. In the case of Azure, that’s particularly building up top of Azure Kubernetes Service, AKS. We can dive into a lot of these things.

Jamie : [4:24] Yeah, I feel like I could talk to you for hours about all this stuff, because there’s a a definite lineage there from System.Xml all the way toDAPR. There is so much in there that I would love to talk about think, you’d said it anyway, but I think it bears repeating that because in naming things is hard right. There is Dapper, d-a-p-p-e-r, which is not what we’re going to talk about. There is Dapr, d-a-p-r, which is we are going to talk about. Naming collisions happen all the time right, and it’s fine; it is what it is. There are only so many words in the language so this kind of thing is going to happen

Jamie : [5:11] I guess, before we get into the lineage and all that kind of stuff, because I would love to pick your brains about your overview of being partially involved in it from the beginning of your career with Microsoft all the way to the world as it is now. I would love to hear your thoughts on .NET and seeing it evolve and becoming this open source thing, and being adopted by lots of people, just sort of want your own thoughts on it.

Jamie : [5:40] But before we get to that, let’s really quickly talk about what Dapr is. I know you’ve mentioned it a few times, but I think it might be worth the listeners just knowing before we get to it, what it is and what it does. I know you said that you used the acronym earlier on. I know it as the Distributed Application Runtime, and I believe that is what it is called. But I’m going on old information from when it first, sort of, became a thing just before things like project Tye; which I guess kind of evolved into .NET Aspire. So what, I guess, what is Dapr?

Mark : [6:17] Well, yes that’s a great question. So what Dapr is it’s a recognition of the fact that you know what happened in industry is that we moved generally from building those sort of three-tier, client-server designs through to cloud-native designs. And cloud-native, really, when we talk about cloud-native, we’re talking about here distributed applications that run on platforms, pretty much nowadays considered things like Kubernetes. But of course, you know, Service Fabric as well, one of those that also came from Microsoft and, if you reach back, there was things like Docker Swarm and Messisphere and the other ones as well.

Mark : [6:52] But in that world of things, there was a need for developers, too. And why did that emerge? That emerged because there was a need to scale out these applications, but also to be able to ship things faster and more agile, rather than the sort of large, chunky things that typically serve maybe large organizations, but services that run to scale, that you can scale up and scale down. And together, individual feature sets of inside or calls a distributed architecture or Microsoft’s architecture to a whole. And so developers were told, “go off and build on Kubernetes.” Which turned out to be very painful for most developers because it was like, “oh my gosh, what do I do?”

Mark : [7:35] And so when it comes down to this, the need for the businesses to create these microservices architectures where you had, say, you come up with a fictitious order processing application or like a retail application where you have an inventory service, you maybe have an order processor service, you maybe have an email service, and they have to communicate in some way. All of a sudden, you have an application that can be shipped fast because you separate things out, but you’re given the complexity of additional messaging and communication and discovery, and all those things that result in your application being distributed across, say, a set of pods inside Kubernetes cluster.

Mark : [8:19] So Dapr is very much like, “how do we make life easy for developers to build these microservices architectures and recognize the fact that in order to do that, there’s a common set of patterns that they do?” So, for example, a very common pattern is to be able to send two messages between two services, a published and subscribed message, I want to send a message, and anyone who’s listening to a particular message topic can receive those things.

Mark : [8:45] So that turns out to be, actually it’s been a common pattern for 40 years, all around queuing and messaging, none of that’s new. But in a distributed application world, it became even more important and became the basis of event-driven design.

Mark : [9:01] So what is Dapr? Dapr is a set of consistent patterns for developers that has a set of APIs based around them all that allow them to build distributed applications, including things like communication, sending messages asynchronously, PubSub. Including things like direct communication, like request reply, request reply, and we call that service invocation, for things like orchestration across multiple services, so that’s workflow. In fact, I think that’s one of the most amazing things built into Dapr is the sort of saga pattern or workflow orchestration, but also things like state management for saving key value pairs in a database of your choice, as well as things like secrets, configuration, job scheduler, and all the things that you’d expect to build.

Mark : [9:52] So now, to be really, really concrete, Dapr set of APIs that accelerate how you build applications that run in these distributed platforms, strictly on Kubernetes, and deliver your business application literally 50% faster than you could do otherwise, because you’re not reinventing the pattern, as I like to say, or reinventing it, because these common distributed systems patterns are given to you as a set of APIs that you can just use out of the box. So hopefully that’s given a sort of a good perspective to your listeners.

Jamie : [10:27] Well, it’s given me a fantastic perspective and place to start this conversation with, because, you know, we’ve all been in that position where either we have to build something from scratch. We don’t always have to get to do the fun bit of building a greenfield application. But when we are building a greenfield application, wouldn’t it be brilliant to just go “file new project” and have everything wired up or be able to go, “here are my services, figure it out.” That is the dream, right?

Mark : [11:00] Yes. Yeah, I mean and Dapr actually isn’t just for greenfield projects; in fact we see more projects that are being modernized, you know, the existing code that was designed not to run on these cloud data systems like Kubernetes into deployment. I mean, today, we see many organizations using platforms like Kubernetes to modernize their applications because they can scale them out.

Mark : [11:26] And Dapr very much plays into the brownfield space where, say, you are taking an existing application and you want to split it into two pieces. Well, how do I start them to communicate? Well, Dapr fits in very well with the modernization of those as well. So yes, we see the greenfield, but we also see equivalent amount of brown field, just as people sort of decide how they have to kind of modernize their applications into this distributed world.

Jamie : [11:56] Wow. So that’s even better then, because I can imagine maybe I’ve built this monolithic app 10 years ago, 12 years ago, 15 years ago, 20 years ago, and it has been on an on-prem server. And I’ve decided I want to leverage the power of the cloud want to use someone else’s server, right,

Mark : [12:14] Yes.

Jamie : [12:15] I’m gonna figure out a way to slice off chunks of functionality from my monolithic app and say, “this is, maybe, my registration service. This is, maybe, my inventory service,” and start to break those down. My feeling is, from what you’re, saying I can do some… there’s some process there can’t say it’s magic but there’s some process where: I’ve split everything out, I’ve involved Dapr somehow. I’ve told Dapr, maybe, how all of these things talk to each other, and then suddenly I can go, “cool, that can go on an AKS or any Kubernetes thing ever,” right?

Mark : [12:49] Yeah, exactly. In fact, one of the central premises of Dapr has, you know, one of its goals is not only to be multi-language, in that anyone can use the APIs from any language they come from. So it has SDKs. First, you can call it HTTP if that’s all you care about. But it has SDKs for Java, JavaScript, of course, .NET, Python, and Go.

Mark : [13:11] But at the same time as well you can use those APIs irectly in your application and, for example, if you want to communicate between two services, you can simply launch your application locally, Dapr is a CLI that goes along with it. So Dapr has a run command so you just say, “run my application.” And what it does is it launches Dapr’s little sidecar next to your application. So say you have application A and application B, and I just do dapr run on one and dapr run on the other, they both get their own little sidecars; but it effectively provides all the heavy lifting around the APIs.

Mark : [13:49] And then in my application code I just say, “call the invoke function.” Say I want to invoke the order method on the cart application running in my other service: I just literally call that method in my code as developer goes, and then Dapr does the discovery, the coordination of where that message gets sent. It does end-to-end security. It does things like resiliency. So if they’re able to retries, it retries more. And it even does observability. So it writes out telemetry events so you can understand what’s happening.

Mark : [14:23] So it does all this heavy lifting for you. And all you do is you just call the invoke method, effectively, and Dapr sidecar does all of the heavy lifting of that call, and all the retries between the replications. And you can do this with a CLI. So getting started is very simple. You install the CLI, you do dapr init to get going and then you do dapr run to launch your applications. And then once you’ve built it, you can take exactly the same code and run it on a platform like Kubernetes and run the same thing there.

Jamie : [14:55] Right so that’s a that’s a lot of that is non-trivial stuff that Dapr is doing, right. And just to sort of underline that point right: Yes I could spin up both of those two things locally, let’s say they’re .NET apps; I you run, know dotnet run application A, dotnet run on application B then make a note of where they have started, which ports they’re maped to and things. And then go change the code for application A so that it has a hard coded, or maybe in config, but still it’s hard code. Do you know, “this is how we communicate with application B. You know, send an HTTP, or raise an event, or whatever, to this particular address.”

Jamie : [15:41] Whereas actually being able to go, “start my app over here: app A. Start my app over here: app B. Hey app A, go tell Dapper to figure out how to send this message, but I want you to send this message to application B at this method or this endpoint.” That’s non-trivial, right? I just want to point that out.

Mark : [16:03] Yeah, in fact, you nailed the central premise of what Dapr’s about. That’s one of the most important things, and that is it gives your little piece of process, your little code, some identity, and it gives it an identity of a name.

Mark : [16:16] So, you know, like you’re called Jamie and I’m called Mark. Developers like to cover identity. So rather than you messing around with ports and DNS addresses and what it’s all like, and then you’re messing around locally and then it translates into a different set of things in production, all of that goes away for you as a developer because you simply say, “application A with this identity and application B with this identity.” And then wherever that’s running in your environment, whether it’s just a local machine or whether it’s on two completely different machines inside a Kubernetes cluster doesn’t matter, you know.

Mark : [16:52] Dapr will figure out if application A is on a different machine in your Kubernetes cluster; it doesn’t care you just called it, you know, application B and it will route the message to it all so you don’t have to think about ports, or DNS addresses, or routing, or anything. You just care about calling, you know, the actual method you know, the say, the order processing method on application B in the environment you’re in whether it’s a local machine or things like Kubernetes. And so it all becomes transparent to you and this is kind of the you know powerful thing that Dapr brings. And if you look at any of the other frameworks out there, they don’t actually do this. They still require you to kind of set up all of that heavy kind of network lifting and ports and identity and that. And they may try and hide it behind you, but they don’t hide it in a convenient identity way.

Mark : [17:40] And because you have that identity, things can even more convenient with Dapr because that identity actually gets handed to you as an X5O2 certificate issued by Spiffie, which is an open standard. And so the actual message encryption that happens between those two sources is actually fully mTLS encrypted as well. So you get full end-to-end identity discovery, but also full encryption across all that. So you get security and identity and authorization.

Mark : [18:10] Effectively, can you call me or not call me all built into it as well. Because you can say, “application B can only be called by application A, but not by application C.” So you get that sort of authorization and identity as well as encryption all built into this identity mechanism as part of Dapr. And that’s very, very powerful.

Jamie : [18:31] Oh, absolutely. And I feel like you, I mean, you didn’t gloss over it, but you also mentioned another thing that is non-trivial, which is mTLS, right? Any kind of TLS connection between two services is non-trivial, right? We take it for granted that we can just upload some kind of app to an app service or some kind of hosting provider, and they’ll give us a TLS certificate. But when you’re behind the veneer of, say, a Kubernetes or a Docker Compose network or something like that, all of that communication is done in HTTP in like unencrypted messages right. So being able to just say, “hey Dapr, figure it out,” and then it goes, “oh cool. I will also include your messages within my network, too.” That is something that is again it’s non-trivial.

Mark : [19:19] Yeah. It’s non-trivial exactly. And so, as part of this when you deploy Dapr in an environment like Kubernetes it has a control plane. And the control planes, instead of supporting services for your application, one of those control planes services is actually called a sentry service. And the sentry service is responsible for issuing these certificates to every application. And those certificates not only, as I said, use for identity, but also for that mTLS encryption.

Mark : [19:47] Now, one of the questions we often get that people say is like, “oh, that sounds just like a service mesh.”

Mark : [19:53] And the answer is, “yes, it is just like a service mesh. And that’s the beautiful thing about it all.” But in many ways you see a service mesh still only operates at the network level, so when you deploy a service mesh, something like istio or Linkerd, you know they help but they’re still bound by this world of ports and ip addresses and setting that all up. Whereas the thing that Dapr brings in terms of each service mesh concept is this concept of identity, so there is an overlap between Dapr you know working as a service mesh but with this concept of identity as well as sort of actual, service meshes in the sense of things like istio, for example.

Mark : [20:31] But there are a bunch of people as well that we work with, or organizations, I should say, who do choose to run a service mesh next to Dapr, and you can do that because they want to have an enforced policy at the network level, but they can still take advantage of other Dapr APIs, for example, PubSub asynchronous messaging, and still using service mesh for direct communication. So it’s not an either or even in that case, but quite often we see that when people do understand that Dapr’s identity concept, it often replaces a kind of traditional networking service mesh. And, you know, because all the benefits we just described.

Jamie : [21:07] Right. Okay, so we were able to. .. Thing is that there’s a whole bunch of stuff there that is magical, non-trivial stuff that you’re doing, that I really want to deep dive into.

Jamie : [21:22] But I guess for the audience, because most of the people listening in are interested in .NET things, I guess the most important question for them will be, well, where does this fit in with me, right? I have an ASP .NET Core service. Maybe I have an ASP .NET Framework service. Maybe I also have something in Java that I’m usually calling. Some other external API. Like, can I wire those up? Maybe not the external API, but maybe can I wire those up so I’ve got one deployable thing. Is that is that possible?

Mark : [21:54] Yeah. Wellmean … So first off Dapr itself is deeply integrated with ASP .NET Core, and so if you launch an ASP .NET Core service you know we actually have integration with that that allows you to do dependency injection such that when you run your application you can get hold of, for example, typically there’s a create builder class that returns your builder, and through dependency injection you can get back different clients from Dapr.

Mark : [22:28] Recently, actually, the core maintainer of the project, Whit Waldo, has been working pretty closely to kind of break apart these different clients into particular packages. So you get a client that’s represented of the sort of API that you want to work on. But yeah so that, dependency injection mechanism, the integration with ASP .NET Core and the fact that you know Dapr has you know a very sort of clear client APIs in sort of design or you know certainly sort of .NET, not only in terms of .NET starting with anything from .NET 6 and beyond, but the latest versions of .NET are on these things. And so you can take the .NET SDK, use that in order to get hold of a client’s fee in front of the APIs, put that as part of your ASP .NET Core service, and deploy that into your chosen environment.

Mark : [23:27] Now, you still have to build individual applications, and segregate those into the design you want. So you still have your order processing application separate from your payment application, but they’re just all done as ASP .NET applications that you can just deploy. Saying that, if you just want to do a console application, go for it as well. Dapr just has a set of clients that you can use in the same way as that. So that’s how a .NET developer consumes it. easily best through the .NET SDK.

Mark : [24:04] But also, going back to your question, Dapr itself is multi-language, And in fact, one of its core premises is that there’s a lot of Java developers as well who sit side by side with, well actually I should say, any developer now, or actually any development team usually has sort of multi-language inside it all. So you may have some .NET code, but increasingly there’s a lot of Python developers that now come in, particularly with more sort of the AI side of these things building next to it all. So we see a lot of .NET with Python, or Java with Python, or .NET with some JavaScript or TypeScript, I should say, combined together. And so one of the beautiful things about Dapr is that because underlying all of this is just a set of HTTP calls, you can actually call from a .NET application and invoke another service that may be related to TypeScript without having to concern yourself in any way in terms of the call being successful, the fact that it’s written in a different language, all of the APIs work across multi-language.

Mark : [25:16] And that applies not only for the direct service and invocation calls, but also things like the PubSub calls, the asynchronous messaging where you can plug in the message bus of your choice and build around this all. So there’s a great set of quick start samples. If you go to Dapr/quickstarts (on GitHub), you can sort of try them all out and you’ll see all the APIs inside there and how they all work together. So hopefully that’s given you a little overview to the .NET listeners.

Jamie : [25:46] It, well, it certainly has for me. I will say that it certainly has for me. I’m… one of the things I’m going to be doing this evening is seeing if I can put together some ASP .NET Core applications using Dapr and just sort of see how different that process is of saying, “hey application B, go call application A and do the thing, or raise an event. I don’t care how it gets there, just put it on whatever, message queue A, right. Invoke that message, right.”

Mark : [26:16] Well one place I suggest you can try this all out, if you really want to get your hands on, is that we at Diagrid have created a Dapr University Course. And if you go to if you search for “Dapr university,” you’ll see that we have a, sort of, a course set up that’s all run under instructor queue and you can come along and you can take this course, and inside the one-on-one courses it teaches you the service invocation the PubSub, and the state management, and so you can choose the language of your choice. You can do it as .NET and it’ll walk you through all of the code samples inside the quickstarts. It’s all fully interactive. And at the end of it all, you go like, “wow, that was pretty easy.” So go and try out the Dapr University course, the 101 course.

Mark : [27:01] In fact, just yesterday, we launched part two of that course, which was for Dapr Workflows . Specifically, we launched it for the .NET developers first because we had the greatest demand there. We have the Java ones and other languages coming after that. But going and trying out Dapr University is the best way to get engaged in trying out Dapr.

Mark : [27:22] But touching on your topic of PubSub, I think another key aspect that Dapr also provides is this pluggability behind the API for the underlying infrastructure. So for example, behind the PubSub API, you can plug in any one message brokersthat you want to use, depending upon the hosting platform you want to run this on. In the case of Microsoft and .NET developers, you have things like Azure Service Bus. There’s a common one there. You also have event hub around those things inside the Azure space. You also might just use something like Redis or RabbitMQ as another way of doing this messaging.

Mark : [28:04] The great thing is that when you build your application against that API and using the .NET SDK, you can actually say, for example, in the PubSub API, “I want to plug in Azure Service Bus,” or “I want to plug in Azure Event Hubs behind us,” and none of your code actually changes. You just have to choose the message broker of your choice for your infrastructure. And this makes a very powerful because it sort of gives you a couple of things here. One is, as we’ve all experienced, that sometimes people change their mind about how they design their architecture. And you can’t tell me how many times I’ve seen the big debate about, “should I use Kafka or should I use Azure Service Bus or should I use RabbitMQ?” And the big debate around all the answers is, “well, it doesn’t matter with Dapr.” In fact, pick two or three because you can plug in and try out any one of those message buses with your choice without affecting your code.

Mark : [28:57] And another thing it gives you is some level of cloud portability, whether that’s developing locally and moving it to something like Azure, or actually, as we see increasingly today, is that most applications, or certainly lots of big companies, have to be a little bit cloud agnostic. And if they deploy an application that may use say Azure Service Bus, but then they want to move it and run it on say AWS there they could switch into AWS SNS you know, as a different message book, and make their cloud portable between these things. So I think that that portability of code or an evolution of your code by plugging in the underlying infrastructure behind the API is something that really was a very hard problem tackled by Dapr, very early on that really helps to work with your application in a multi-cloud way or how it evolves in time.

Jamie : [29:53] Yeah. And I guess you know, without saying it, you kind of said it decouples you from your dependencies, I guess, right. Because if my app requires.. if when I’m developing my app I require Redis, I’ve got to start that somehow, right. But if I’ve got Dapr sitting behind the scenes, maybe I can just go, “hey Dapr, fire me up a Redis and let me connect to it somehow.” And then it will do some magic. I’m greatly reducing the amount of work that is involved on the Dapr side, but it can do some magic, figure out how to start a Redis, give me an invoke method to call, and then i say, “hey Redis,” or “hey Dapr, put this in the Redis cache. I don’t care how you do it, just get it done,” right?

Mark : [30:35] Yeah. Well, exactly. So whether you’re using sort of the Dapr PubSub API and you’re using the message broker when you do the call, you say… well, I want to use in Dapr words these are called components. So you’d say, “I set up a Redis component for PubSub messaging.” And so when you publish a message, you say, “use this one, say, we’re calling Redis component, and it will send off there.” But I can have a separate component for, say, Azure Service Bus, and instead, when I publish my message, I could just say, “well, use the Azure Service Bus component instead. " And so it’ll do exactly the same call, but using a different way of delivering the message.

Mark : [31:16] Same happens with state management. So Dapr has a way of storing state in key-value pairs. A very common way of storing data is just like key-value pair, like a shopping cart, for example, or a session state with some names in it, or maybe it’s another list of things you have, and just key-value pairs like this. And behind the key-value pair API, you can plug in Cosmos DB or MySQL or Azure SQL Server or any one of these numerous different databases around these things to store all that data without you having to specifically hard code all that particular SDK into your application itself. So that’s where it gives you the flexibility.

Mark : [32:00] In fact, each one of those components, say you’re talking to the Cosmos DB component, it’s very tailored and specific to how it most efficiently stores key value pairs inside a Cosmos DB database, for example. So you don’t have to do any of the SDK heavy lifting of understanding Cosmos. You just call the API, and pipe in these components, and off you go. So all of the best practices of usingCosmos DB for state management with this key value API are, sort of, baked into this component.

Jamie : [32:29] Right. And then I guess that also means that if I need to quickly experiment, say I’m using one particular component and I know that there are three or four different alternative components that do the same thing, I presumably can then very rapidly experiment to see which one fits my goal the best, right. I can say, “oh cool. i’m going to use Cosmos, and I’m going to use MqSQL, and I’m going to use Postgres.” I don’t know if all three of those have components, but let’s just say that probably do, and I’m going to try all three and see which one fits my problem domain best. I might be able to do that and sort of rapidly evolve that, guess. Is that a thing that we can do?

Mark : [33:10] Yeah, yeah. That’s certainly one of the things that you can do. Yes, we see both that, in that you can test out different environments. The other one I said is sort of the one that you can sort of choose to evolve your application. We also see this actually very much in these, or I don’t know how much you spend or follow sort of the platform engineering trend that everyone refers to now, but Dapr has become sort of a very agreed interface between sort of the platform engineering team and the application team.

Mark : [33:40] And it benefits both of them because it means that the platform engineering team can say, “here’s a set of APIs that I give to you, particularly in this case, PubSub messaging.” But it also might, for example, one of the other APIs that provides us with things like secret management. And they can say, “here’s the secrets API for how you get hold of secrets.” Behind this, we’re going to plug in Azure Key Vault around these things, or we can use Kubernetes secrets, or we can use another secret store like HashiCorp Vault if we wanted to.

Mark : [34:13] But you, application developer, whether you just use a PubSub API or the secrets management API, it doesn’t change for your code. In fact, your code becomes simpler because you just specify the company you want to use. And me, the application platform team, can provide all these component models and allow you to have either a choice of service brokers or a choice of secrets management, whatever else you want, without you having to bind specifically to that SDK and have a really, really tight coupling.

Mark : [34:44] A classic one in here all the time is, going back to PubSub, is that people start off and they’re like, “oh, we’re going to build a messaging system. " They bind with Kafka. They use a Kafka and they’re typing into their clients. They bake that all in. And then someone says, “oh we’ve got to make this thing work on Azure, and you’re going to just move to Azure Service Bus now.” And they’re like, “oh, but I’ve got this Kafka SDK in my code,” and they spent six months ripping it all out to put Azure Service Bus back in with SDK just to like do no work other than to send a message, like they did before; and you know that’s yeah … why do all that?

Jamie : [35:23] Absolutely. So let’s say I’m building up my… Okay. I was about to use “the M word” there and say “microservices,” but let’s do it. Right.

Jamie : [35:33] Let’s say I’m building my application. Let’s say I’ve got a number of different services all hosted in a Dapr application–( wonder if that’s the right phrasing–I have all of the setup for all of my components I’m going to use. I’m maybe going to use some cloud services maybe, maybe I’m not. And it comes to deployment time, right. It all works wonderfully on my machine because I can just do, “hey Dapr, start my application stack,” and everything fires up right.

Jamie : [36:02] So how do I then go about translating that onto a cloud provider? Is there like a… do I have to do anything specific? Or is there like a, you know, a lot of devs love CLI tooling because then we can script it; is there some CLI tooling? Is it a case of somehow like “right click or alternate click, publish”? Like, what does that look like for a dev?

Mark : [36:24] Yeah. Yeah. Good question. So you know Dapr has a CLI if you use it to launch or run, you know. So typically you have a project, and by the way Dapr has a really good Visual Studio Code plugin that you can create a Visual Studio project, pull in the Visual Studio Code plugin, and it gives you really good debugging capabilities for numerous Dapr applications you’ve built.

Mark : [36:50] So typically, you may have a project, it may have, say, 10 Dapr applications inside them all: application A, B, C, D, E, F, like this. You have a sort of components folder or a resources folder, I should say, because you can have other resources inside there as well, not just components. And when you run this thing you can actually use the Visual Studio debugger and the plugin in order to launch and run those applications. And that works really, really well, coupled with a local Dapr CLI, where if you want to drop to the CLI you do dapr run and the name of the application you want to run.

Mark : [37:27] Inside the Dapr CLI there’s also this thing called a multi-app run, where you can actually launch multiple applications at the same time; which is very common. And so typically I want to launch application A, B, and C together. And so the multi-app run format, it’s a bit like a Docker Compose format. Think of it like that. We also have a bunch of people who actually do like to use Docker Compose as another way they like to describe their app. But the multi-app run format inside the Dapr CLI allows you to do that.

Mark : [37:55] So then to answer your question, it’s like, “okay, great. I got this thing running locally” The most common place that we see people deploy their applications to is a Kubernetes cluster such as AKS. And really in that world, and this is where Dapr becomes incredibly powerful, is that you really have to do two steps. First off, like anything that runs inside the Kubernetes world, you have to containerize your application. You do have to go to each one of those applications and get a Docker file that goes with it. You build and compile your application into a Docker file. Now, pretty much that’s pretty well provided inside a Visual Studio environment where you can typically right-click, generate a Docker file for it all, and build it all into a Docker image.

Mark : [38:42] And then all you actually really need to do when you deploy this into your application is if I should say into your Kubernetes environment, you then have to create a set of Kubernetes deployment scripts, and when you create a Kubernetes deployment script which says, “run this particular application as a deployment,” inside that you just actually put a couple of annotations to say, “hey launch Dapr as a sidecar. And here’s the name of the application.”

Mark : [39:13] So taking it into production means you don’t have to change any of your code. You just have to dockerize the applications, deploy Dapr onto a Kubernetes cluster. And then when you deploy your Dapr applications as a deployment image, it’ll launch and run all of the application images for you. And then you get all of the service application calls, the discovery, the PubSub, everything like this. So it’s a pretty straightforward step around those things.

Mark : [39:38] But I recognize it is a different setup in this sort of clusterized world in a Kubernetes thing as opposed to on your local machines. But that’s actually where we provide a tool inside Diagrid which is called Diagrid Conductor that actually helps you set up and deploy data on a Kubernetes cluster. It’s a free trial available for it and there’s a free version of it anyway. Go and download Diagrid Conductor use it to deploy Dapr onto your Kubernetes cluster.

Mark : [40:14] And then it gives you all sorts of amazing visualizations. It actually shows you all your Dapr applications running on your Kubernetes environment. It allows you to deploy those, applications inside there, and you can visualize them all, and you get all sorts of amazing metrics out of it. Maybe your listeners [are] going to try that out. If you go to Diagrid and look for “Conductor Service: and install it, you can give it a go.

Jamie : [40:40] That’s excellent. Yeah, because the deployment process that you talked about , “dockerize your application, put some attributes into a Kubernetes file, and away you go.” That’s like maybe one or two steps past, “dockerize your application and throw it at a thing that can run a container,” right? So it doesn’t seem that much more difficult to do, is what I’m getting it.

Mark : [41:11] Yeah. I mean, I’m not saying that Kubernetes is easy in any way. It has its challenges around these things. But that’s just the environment. We see people run things in today a lot. And so this is made easier by some tooling stories around all these things, particularly our diagram conductor service, but also the fact that you have tooling to be able to containerize your applications and sort of build them deployable.

Mark : [41:41] But the benefit that Dapr has is that you don’t have to write your application differently from running on your local machine from Kubernetes. It works in exactly the same way. It’s not as if it runs locally, it’s ready for production effectively. And you also have the benefit of switching out, going back to the component model, that if I run locally, I might be testing, say, with a local Redis component for like PubSub messaging or state. And then when I put it into my production environment, I could just switch it out for the production component there, like Azure Service Bus or Server Store or something like this. So I think that’s the other thing that is the big benefit across all this we’ve seen. But yeah, I’m… not trying to make Kubernetes easier than it already is, but certainly the process isn’t too bad around these things.

Jamie : [42:31] Oh, sorry. Yeah, just to… I think maybe I’ve misinterpreted myself. The point that I did very bad at making was that, from a developer’s point of view if I already know how to dockerize something and I already know how to create a Kubernetes setup file, I’m pretty much 90 percent of the way to production with Dapr right. Sorry that’s, kind of, the point I was getting at. That journey to production is not like, “oh my goodness, now I have to learn a whole new tooling thing.” It’s like, “no, if you want to use Kubernetes and Dapr the process is you’ve already containerized, you just add something to your Kubernetes file and away you go.

Mark : [43:10] Correct, yes, yes. And that’s kind of the beauty and premise of all of this around those things. And AKS is a great environment if you’re running on Azure, but of course, you know, EKS on AWS and, you know, GKE and, in fact, any Kubernetes. In fact, that will run on literally any Kubernetes cluster, whether it’s, you know, a K3 or a MiniKube or, you know, a Digital Ocean, or any one of these ones for that matter. You run literally on any Kubernetes environment. So you’ve pretty much got universal deployment ability, whether it’s a production cloud Kubernetes version or even just a very cut-down version of Kubernetes that’s running on your local machine.

Jamie : [43:56] Or perhaps a stack of Raspberry Pis in my garage.

Mark : [44:00] Yeah, or a stack of Raspberry Pis in the garage. Yeah, exactly.

Mark : [44:02] And you can also make Dapr run on non-Kubernetes environments as well. There are plenty of people that we know who just deploy Dapr on a set of VMs, and particularly if all you’re doing is PubSub messaging between these things, putting an application here on one machine, on one VM, or one Raspberry Pi, if you want to do it that way, and then just sticking a message broker between them, it’s pretty straightforward. So don’t think it’s bound by Kubernetes in any way.

Mark : [44:30] And you don’t even have to containerize it. You could just have a Dapr application piece of code here if you wanted to on one process and another one over here, and it would work perfectly well. So, you know, the containerization was only because of Kubernetes, not because of Dapr itself. Yes, around these things. And we have people who also just deploy Dapr on a set of VMs. So go for VMs if you want as well. There’s a little bit more work for some of the APIs. Right, right.

Jamie : [44:57] In the words of Scott Hanselman, “use what makes you happy.”

Mark : [45:01] Yes, exactly. Use what makes you happy or what you need to do. But I mean, so Dapr taking all this heavy lifting off you. And I think one of the exciting things that also happened in Dapr recently is that we recognize now that a lot of applications have to, and I’m going to take you down the AI path now, yes? But they’re starting to use language models for things.

Mark : [45:26] I mean, not just language models, but I should say generally, lots of pieces of procedural code of the past are being replaced by machine learning models as a whole. I mean, vision being a great example. It’s very hard to do vision in procedural code, let’s put it that way. So models can help you do this thing. And of course, one of the emerging models now is language models. We love using language models around these things. sending requests off them. One of the APIs we had in the last release was a conversation API where behind it you can plug in any one of the language models of your choice. You can plug in OpenAI, Anthropic, DeepSeek, AWS Bedrock, all of these different language models in this component model, and just have an API that you just send a prompt to. It will correctly translate that into the underlying call for the right language model and do things like data obfuscation; so it’ll scrub PII data from it as well, and even do prompt caching as sort of additional features.

Mark : [46:33] So you know Dapr evolves because we recognize and a lot of people said, “as part of my, you know, microservices distributed application I’m starting to call language models.”

Mark : [46:45] And this sort of also leads on what I think is a very exciting development in the world of distributed applications and that’s these agentic AI systems, where we’re building agents, and I always love to say that nothing’s new inside the software world of these things because all these agentic systems are really just distributed systems with smarts. And smarts being a language model, you’re asking it to do something for you. But a lot of this is emerging, and Dapr is very well placed for this, and we can talk a little bit more about that if you want to dive into that sort of side of things.

Jamie : [47:28] You, kind of, read my mind there because I was like, “how can we SEO this episode a little bit more using LLMs and Argentic workflows?” The only thing we need to say now is “MCP” and “Bitcoin”. Then we’ll get all of the people hitting the episode.

Mark : [47:43] Exactly, yes. Well, what’s happened, I think two important things that happened in the Dapr space in the last release. And one is that Dapr has a workflow engine built into it all. I can’t stress how important workflow engines are to basic development of applications or business applications. If you think about 90% of business applications, they consist of a state machine doing something. And you’re either choosing to write this into lots of if statements, “if this, if that, this, if that, do this,” and then figure out what all that logic means. And then, of course, do things like, “well if this fails how do I recover?” and have to deal with sort of failure, and recoverability, and durability, and coordination, and all of that headache around it all.

Mark : [48:34] Or traditionally, you know, you can start to delegate all that to a workflow engine. And you know there’s been lots of workflow engines in the past you know things like you know Comunda is one of those, Airflow, Microsoft still has things called Logic Apps which is a bit like a workflow engine. If you go to the AWS world, it has step functions.

Mark : [48:55] But a lot of those were either proprietary or they were often declarative based. Dapr’s workflow engines are like a code based one. So super easy for developers because now you can sort of break points in your code. But it allows you to create these long-running, Durable, stateful applications that does a state machine. So, “I do task A, I do task B, I do task C. And if it fails, it replays all those again and carries on for where I left off.”

Mark : [49:28] So I might say, “I want to send a message to this other service here. And when it replies, I want to call it an order processing service over here.” And then for whatever reason my application decides to die, and then Dapr then recovers on another machine and knows where it was before, and sort of carries on where it left off; carrying on through the sort of state machine of activities.

Mark : [49:53] So these workflow coordinations, I think, are super important because they take away all the hard problems of durability, retries having to deal with things like compensation around these things. “If I did this, what do I do next?” And so the general business process. And so I’ve been code-based for them, I think is really kind of developer-friendly around.

Mark : [50:19] And the reason why I mentioned that is because, going to your AI discussion, is that we had an amazing contributor actually from Microsoft, actually he’s ex-Microsoft now, a guy called Roberto Rodriguez, who worked in Microsoft Research, We built an agentic AI framework on top of Dapr workflows because it had this power of being able to do recoverability and coordination. We actually released this month. Actually, it’s only in Python at the moment, but we have a .NET version of it coming.

Mark : [50:52] We called it Dapr Agents, but it provided an additional framework. Think of it as just like any framework you have inside .NET, but it’s a framework that allows you to create an agent type, and inside the agent type you give it a sort of instructions. You can give it, for example, a set of tools and you can give it a sort of a language model that you want it to use, and you can do things like create an agent that goes, “here’s some tools that allow you to kind of discover sort of flight or weather information” for example or sort of flight booking you know. If I say to you, “give me a list of flights that are going to Paris next week,” you know, that goes off to the agent model. You know, it comes back, it reasons about using the tool for the flight information API, comes back with some things and kind of give you some suggestions for what your flight might be, as if you’re talking to an agent to help you on your behalf, but nicely coded into this framework. So I think this is quite an exciting development in sort of the Dapr space that I’d love all your kind of listeners to try out an experiment and give us a bunch of feedback on.

Jamie : [52:00] Most definitely. And so I know I will be checking that out because I have a bunch of projects coming out that are basically agentic, in that space where I’m going to be building up a number of different LLMs that are all going to chain together. Maybe I’ll have a code based one. Maybe I’ll have a human language based one. Maybe I’ll have a just an entry point small language model that’s not really powerful, it’s good at understanding what I want to do and writing that response back. So and then it will then be able to go, “cool. This is a this looks like a coding question. I’ll give that to the coding LLM,” and that kind of thing. Ad that sounds like it fits really well with that agentic, what did we say? We’ve got Dapr agent.

Mark : [52:45] Yes. I’ll give you a very practical example that someone wrote for a company we were working with, and they wrote a Dapr agent that just does code reviews for PRs, I should say. And so the problem they were having was just like, “I’ve got lots of code reviews or PRs that are backing up.” The agent sort of just, when you submit them, it goes off to the agent and the agent just sends it off to the language model. The language model of your choice comes back with a code review suggestion. It just helps you accelerate the code review because it gives you some ideas around these things. In some cases, they slightly automated the simple ones, but it just allows you to do an agent for doing code reviews where you can iterate on those sort of things. That, I think, is a very classic, typical example.

Mark : [53:34] Of course, everyone likes to think all these agents will talk to each other, and all this or stuff, and do these things. I think we’re a little bit of a way of not having human loop. I wouldn build one which is like, “here’s my credit card, go and book my entire vacation for me in country X next year and tell me what it is.” But certainly, basically, language models for this agent that has a set of tools combined but that all had a set of instructions about how it behaves. And the ability to plug in different language model providers like OpenAI or Anthropic behind us all is the powerful of this.

Mark : [54:15] And going back to workflow again, because it’s built on Dapr workflows, these things are fully recoverable. And I think there’s a lot of excitement and noise about building agenetic systems out there today. But fundamentally, the problem I see with many of them is that they’re not based upon really hardcore distributed systemsprimitives like Dapr is, particularly around durability and recoverability around these things. It’s all right to build a native system, but if it dies and can’t recover its state, it doesn’t really help very much.

Jamie : [54:51] Yeah, and that would be dreadful for like an AI startup where they’re like, “we’ve built this huge thing and it’s built on a house of sand anyway, but now we’re getting a ba-billion users and our cloud bill is huge. But then somebody pushes the wrong button, and it restarts everything,” and they lose everything, right? They don’t want that. So go and use Dapper Agents, folks.

Mark : [55:09] Yes, go and use Dapr Agents. It’s still, I mean, we still, it’s only been out there a month, but it’s built on some Dapr APIs. In fact, it’s very nicely layered because it’s built on this concept of Actors, and I think this is another very key thing that Dapr has as part of this: is this actor framework and it was originally conceived actually it came out Microsoft many years ago had a project called Project Orleans, and the Orleans came along and had this concept of a virtual actor that concept of a virtual actor actually got built into service fabric.

Mark : [55:41] And we had the virtual actor concept there an actor has sort of identity the virtual actor means it can just unload its state and can persist at state. In turn, that got translated into Dapr as this virtual actor model.

Mark : [55:57] But basically, if you think about what actors are, it’s their long-running, durable functions, I like to think of them. They’ve both got state and functions associated with them, and an identity. There’s actor one, and actor two, and actor three, and you can call them. And so a lot of people sort of stitch these actors together in order to sort of make workflows. And so the Dapr workflow model is built on top of the durability and identity of actors to coordinate them. And so as a result, when you run a workflow inside Dapr, each one of its tasks that you have, so say a workflow consists of task A, task B, and task C, each one of those tasks gets translated into an underlying actor and can be distributed anywhere inside the Kubernetes cluster. It’s highly efficient and highly scalable and distributes its workload across all these things in a very scalable fashion.

Mark : [56:55] I think this concept of the actor framework, and identity, and scalability that workflow builds upon, then the agentic framework builds on top of that, gives you these very scalable and very cost-efficient mechanisms. In fact, you could start a single Dapr actor in under 50 milliseconds and scale them into tens of thousands or millions of them across a set of, say aKubernetes cluster of machines, a five-machine cluster, depending, of course, on your VM size. So very small, very lightweight, very fast to start up, very distributive. And I think that this is something that’s pretty important as part of the Dapr runtime.

Jamie : [57:38] Wow. That is… yeah starting up in as little as 50 milliseconds is… that is. Wow, that’s fast.

Jamie : [57:52] Okay. So this is jolly interesting, I have to say. I’m really liking the discussion about all of things Dapr, all things Dapr agents, and all that kind of stuff. But I also know we’re running low on our time together.

Mark : [58:06] Yes.

Jamie : [58:06] So I want to be very respectful of your time that you’re giving to both myself and to the audience. So what I would like to say is: what’s the best way for listeners to find out more about Dapr or about Conductor, and about all those kinds of things? Is it go to the website follow, Dapr University? Is that the best way.

Mark : [58:27] Yeah. Well I would say two things first off: you go to dapr.io is kind of the website. But if you really want to learn and get dive into Darp, yes go to Dapr university, and we’ve got a couple of courses up there now. We’re having more courses come along you know and just to be clear, Dapr University is put together by my company, Diagrid. Diagrid are the primary maintainers today of the Dapr project.

Mark : [58:54] And also, I should say, we’ve been talking about this all this time, Dapr is a fully open-sourced CNCF project. It’s a fully graduated project. It has tens of thousands of companies that use it in production. A graduated project is the highest level of endorsement that you get inside the CNCF–the Cloud Native Computing Foundation. So it’s been out there six and a half years, truly an open source, resilient, well-tested, hardened project out there. We, Diagrid, are primary maintainers.

Mark : [59:27] If you want to learn Dapr, go to Dapr University. We’ve got some courses. But of course, go into the Dapr Quickstarts as well, which is one of the repos. Then, after you’ve got through that, I think that generally I would encourage you to play with Dapr and build a few things with it locally. We have this amazing tool called Dapr Conductor that allows you to manage Dapr on top of Kubernetes.

Mark : [59:54] And then we also have a service as well that you can try out called Dapr Catalyst, which actually is a fully serverless version of Dapr. So if you just want to run Dapr without nothing running locally, you just want to launch it on any form of computer. So say you want to run it on a container service or just as a VM or just on my local machine. Diagra Catalyst actually is a serverless version of Dapr hosted as a service. You can simply build your application, deploy it locally, and hook up to the serverless version of it where we’re basically running the Dapr sidecars in the cloud for you. So you’re just calling the Dapr APIs.

Mark : [1:00:37] So if you just want to call the Dapr PubSub API, go for it. You can put it on your local machine, you can deploy it on a VM, call the Dapr API, host it on the Dapr Catalyst service, and do some messaging between any two pieces of code wherever they’re running, which is kind of pretty cool, actually, because I don’t have to have Dapr installed on any machines. I just use the Dapr cloud APIs. I can just use the .NET Client API, create an account on the Catalyst service, we have a free version of it entirely for free, go off and use it, it will be free for whatever we’d like to think that you can just use. And so I can give that a try as well.

Mark : [1:01:18] So those are sort of three great ways to get going with Dapr. But yeah, the Dapr University is a great way to get started.

Jamie : [1:01:28] Fantastic. Fantastic. And then I guess if folks then graduate from all of that, they want to get in touch with you to find out how you and your company can help them to build Dapr-based things. They just go to Diagrid and figure that out from there, do they?

Mark : [1:01:43] Yes. In fact, two places I’d go to:

Mark : [1:01:45] One is go to diagrid.io, you know, contact us, come and talk to us; feel free to send me a personal email message as well if you want: mark at diagrid.io More than happy to answer your questions.

Mark : [1:01:57] And then if you want to engage with the community there’s a Dapr discord channel. So if you go to the discord channel we’ve got well over eight and a half thousand people that belong as part of our community; it’s a very vibrant community. Ask lots of questions there. It’s split up into all sorts of topics depending on APIs or depending if you want to talk about Dapr agents. Actually, there’s a .NET framework SDK inside there.

Mark : [1:02:26] There’s also a community there about… we probably could have touched on this, but .NET and Aspire. .NET and Aspire and Dapr work very well together as well. In fact, they’re a beautiful combination where you can actually use .NET and Aspire for your local developer thing. For sort of distributed systems runtime. So you can talk about, maybe that’s another whole episode in itself, talking about .NET Aspire working with Dapr and how that combination goes together. But whether you choose VS Code, with and without .NET Aspire or Visual Studio, there’s lots of options inside the .NET world for working with Dapr. And coming to the Discord channel is the best place to ask those.

Jamie : [1:03:05] Wonderful, wonderful. Well, Mark, I genuinely can’t wait to start working with Dapr this evening. So for everyone listening: we are recording this in the evening, and I will let everyone know how that goes, on a number of different places.

Jamie : [1:03:21] But yeah, thank you ever so much Mark for coming in and discussing this with me because i knew a little bit about Dapr beforehand; I knew that it did something to do with sidecars, and it helped me with my application setup. But this has been like a it’s a whistle stop tour, and a huge amount of information here; so thank you very much for sharing that with us.

Mark : [1:03:42] Well it’s been fabulous being on your show. And, as I say, I’m excited to see what everyone in your listener base builds with Dapr.

Jamie : [1:03:49] Excellent thank you very much.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Useful Links

• DAPR
• Web Services Enhancement
• Diagrid
• Dapper
• Tye
• Spiffie
• mTLS
• istio
• Linkerd
• Dapr/quickstarts
• Dapr university
• Diagrid Conductor
• Workflow Engines:
  • Comunda
  • Apache Airflow
  • Azure Logic Apps
  • AWS Step Functions
• Episode 21 - Orleans with Russell Hammett
• CNCF
• Dapr Catalyst
• Dapr on Discord
• Supporting the show:
  • Leave a rating or review
  • Buy the show a coffee
  • Become a patron
• Getting in touch:
  • via the contact page
  • joining the Discord
• Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show