In this RedMonk conversation, Mark Fussell, CEO of Diagrid, discusses Dapr, a runtime designed to simplify the development of distributed applications, with James Governor. Mark shares insights from his extensive experience in the field, including the importance of community contributions and the role of observability through OpenTelemetry. The discussion also touches on the future of Dapr in the context of agentic systems, the rise of programming languages like TypeScript, and the ongoing trend of application modernization.
Links
Transcript
James Governor (00:12)
Hey, it is James Governor of RedMonk and I’m here with Mark Fussell, CEO of Diagrid. We’re gonna talk about, well, we’re gonna talk about what we always talk about, distributed systems. This is something that Mark has a lot of experience about. We all know about the issues, like how do we either simplify via APIs, how do we simplify the environments? How do we make them programmatic? How do we have better experiences for operators and developers?
Basically, Mark has spent his career working on these issues. And the latest sort of incarnation of this is the work that he’s doing through Diagrid and a standard called Dapr. So two things. One, hello, Mark. Welcome to the MonkCast.
Mark Fussell (00:56)
It’s fantastic to be here James, thank you for having me.
James Governor (00:59)
Amazing and two what even is Dapr
Mark Fussell (01:03)
Yeah, well that’s a good start. I Dapr actually is quite an old project now. It’s actually six years old. In fact, it had its sixth birthday earlier this month on the 16th of October. We shipped it in 2019. But what’s your question?
James Governor (01:16)
way. I mean, apparently we’ve got some things in common, my friend, because so my my youngest is born on the 11th of October. And my eldest is born on the 14th of October. So don’t know what we’ve got going on about nine months before that. But treat that as a time to birth a new project. So
Mark Fussell (01:35)
Yeah, I have the same thing. have two children who were born the two days after Christmas day. So I was doing a lot a little bit later than you. But what is Dapr? Yeah, Dapr is a set of APIs for building distributed applications and provide those APIs as a set of design patterns. So effectively you don’t reinvent the wheel or what I like to say is don’t reinvent the pattern. And the common patterns are things like pub/sub messaging. You’ve got to send a message from A to B. You want to be able to just publish a message.
You just want to subscribe to a message. And from a developer perspective, they want to create a topic. They want to put a payload in it. They want to send off that publish a message and whoever’s listening receives it. Very simple from a developer perspective, but you create a whole bunch of complexity on top of different message brokers, whether you’re running on Kafka, whether you’re running on RabbitMQ
James Governor (02:28)
I’m running on rabbit I’m running on Kafka I’m running on, Redis give me, I mean…
Mark Fussell (02:33)
Yeah. So everyone rushes off and they want to build their own abstraction on top of this thing and build that API. And then they reinvent the wheel several times. And then we see that people sort of bind themselves into Kafka really, really heavily. I mean, there was one bank we worked with who had 2000 applications talking to Kafka. And then they decided they didn’t like it and they wanted to move to AWS, SNS instead. And so, you know, there you go, reworking sort of months and months of code onto.
You know, different message broker with a different API. and so Dapr provides an API that not only gives you that, that semantic of pub/sub but it allows you to swap the underlying infrastructure. So if you change your mind and you don’t like Kafka and you want to swap to something else, you keep the same API and move the infrastructure and, away you go. So that’s what Dapr is in a nutshell. and you’re one of the things that we’ve built into it recently over the last, but recently over the last two years, would say.
is workflow as an engine. And workflow allows you to have durable computing as people love to hire it, or durable execution. So you can now combine this durable execution of creating long running, stateful, reliable code that coordinates other services. And I think that’s kind of one of the key values that Dapr now brings coupled with these other APIs for reading state, sending messages, calling other systems. So basically you take Dapr and you can build your system in 50 % faster than you could normally.
James Governor (04:05)
Okay, okay. So, an abstraction layer that enables you to build applications with messaging and network oriented services more easily. So, and more portably, I guess, is key.
Mark Fussell (04:23)
Yeah, exactly. It’s about reducing the time and for you to build these abstractions. There is a communication piece to it. So Dapr does asynchronous pub/sub messaging, but it also does direct calls as well. So it does the whole service discovery and service calling and does that all securely with retries. So it has the essence of a distributed system where everything has a name and an identity.
There’s Mark services and there’s James service and I can call the James service and call a method on it. And Dapr does the discovery of where that’s running in somewhere inside your environment, typically like a Kubernetes cluster, whatever, and calls it and does all the retries and the security for you. But it has more than that. It’s not just a communication piece. It also does state management. So it saves things to databases. It does secrets. So if you pull out secrets and to use to talk to a database,
or some other resource you can. And then sort of going back to this workflow side of those things, it has API for workflow and for job scheduling as well. So if you want to kick off like a cron job and things like this. So sticking together workflow and cron job and communication and secrets API, it’s give you this sort of complete, pretty much suite of APIs, including data access in order to build your app.
James Governor (05:43)
So firstly, I’m slightly annoyed at myself because when we began this, you talked about the birth of the project. You said six years, you said 2019, went through the 16th, the 11th and the 14th. And then I said 2016 for the birth of the project, which is wrong. It’s 2019. My brain, I’ve been caught in a process until I got rid of that and flushed it out of the buffer. I was not happy. So I’ve admitted my…
Mark Fussell (05:59)
2019, yeah, yeah.
James Governor (06:11)
mathematical issue there and now I can I can properly concentrate question for you why are you I mean what what makes you the person that should design the API for these things like what’s your like what gives you the right say actually this is a better API service for all these kinds of calls like tell me about that
Mark Fussell (06:33)
Well, I mean, in the end, it’s API. There’s nothing really new in this. mean, it’s not as if it’s hard to, or there’s a lot of controversy over something like, for example, a pub/sub API. mean, it really is publish a message, subscribe to a message. You know, it’s as simple as that. And the, mean, the, it’s been shown by, I mean, and also Dapr was a very much a community driven project. It’s not as if there’s one single vendor as part of the Cloud Native Computing Foundation. It’s a graduated project inside CNCF.
for its level of maturity and all the contributions that have come. We’ve just defined an API that was very consistent with all of the best practices for development over the last 30 years. I a pub/sub API has lived for 40 years. IBM first created it back in the 70s or even before that, I would say. I don’t think there’s lot of controversy there. But I mean, of course, if people don’t like the API, don’t have to use it all. But Dapr gives it the portability.
consistency and it works very well with platform engineering teams. So we’ve seen this a lot where platform engineering teams kind of, they, they, they build this sort of infrastructure themselves of like I running these sort of databases or these message brokers or this networking, but they kind of somewhat ignore or don’t want to take on the developer responsibility for their platform. So we found that Dapr fills this really nice
contracts between a platform team and the application developers to say, well, here’s an API that you can use. FICO is a good example of this. worked closely with FICO where they put, had, you know, they had to either use Apache Pulsar or Kafka and they couldn’t decide between the two and they wanted to have both of them available in their platform. So they used Dapr as the pub/sub API. And then if one team wants to use Pulsar or another team uses Kafka, there’s no difficulty over this. So.
That platform contract has been pretty important in terms of driving kind of Dapr’s adoption. And yeah, it’s one API, but I’d like to think they’re pretty simple.
James Governor (08:38)
Okay. Okay. Yeah, that makes sense. Tell me a bit about that said. So I was, yeah. So give me, a slight dig on me. Like, let’s talk a bit about your experience and like, where, where did you come from? Where you built this experience and some of the building that into the platform. So say a bit about like, how, how, how did you get to where you are today? Like where are, you know, I said, you’ve got a wealth of distributed systems experience, but like, yeah, where
Where were you working building systems that helped you gain the stars? And obviously you’re a team. Yes. You’re talking about best practices that an industry has created. But yeah, tell me a bit about your history and how you got here.
Mark Fussell (09:18)
Yeah. Well, my history is that I actually worked at Microsoft for 21 years and very early on I got started working on Azure back in 2008, just as it was kind of starting to be created. And those were in the days of you imagine you go back in 2008, everyone was like, well, you you have the client server model three tiers and all that sort of wonder. And, they were just touching on how is it you actually build these large scale services that actually run across hundreds of machines and what they all look like.
And I started to build a platform for Azure. The platform was actually called Azure Service Fabric. It got shipped as a product, but it was the platform that was, think of it as Kubernetes like, but plus, plus, plus. It didn’t only just do sort of a replication protocol and sort of distributing the processing and the compute, but it went all the way up to the developer level about how a developer modeled an application and deployed it and ran it all. And we built this platform.
basically for Microsoft in order to host all their large scale services, like particularly their database services. And I think the hardest service you can build is a distributed database service where you have to replicate the state and do the failover and everything else like this. Anyway, in building that with Microsoft and working with hundreds of enterprises, you started to kind of realize the developer space where they just wanted to turn up. They just needed to build a business application. There was a set of a
distributed app, a microservices architecture, whatever you like to call it, cloud native, whatever, you know, and now because the business is trying to drive agility and the business is saying you have to ship faster, you’re breaking this thing up into smaller pieces that different teams can do. And hence you need all of this design approach, which includes communication and secrets management and coordination and saga patterns and all this sort of stuff.
So having built this platform, that inspired us to really think about creating an open source version of this that would particularly run on any platform. And of course, if you go back when the project was first stated, there was things like Mesosphere and we had this platform called Service Fabric and you’d even say Docker Compose, but of course Kubernetes has sort of won this out. So pretty much the whole idea was give developers the tools that they needed to focus on business.
not on this sort of programming paradigm that they needed for communication and coordination and secrets management and job scheduling that they constantly reinvented themselves. And hence the Dapr project was born. We tested it out, became very successful and donated it to CNCF.
James Governor (12:04)
Mm-hmm. Okay. Okay.
That makes sense to me. Now, tell me just a bit about adoption. You mentioned FICO. You mentioned, let’s talk about maybe a bit of partners. in terms of accepting, you’re accepting contribute or the project, Dapr is accepting contributions from third parties. Who were some of the other contributors? Like who’s actively involved enough that they’re investing?
Mark Fussell (12:35)
Yeah, well today, so just kind of just follow my story. I left Microsoft four years ago and formed Diagrid and at Diagrid we continue to have support and be the primary maintainers and contributors to Dapr the open source project and we did that because I saw an innovation path along with my co founder to build an enterprise platform around Dapr that was kind of far more kind of let’s say extensive and
to be able to use that Dapr project that people can run modern distributed applications on. So today, Diagrid, or my company, is a primary contributor to this. Microsoft does contributions into this, but we also have contributions from Nvidia, from Red Hat, from even companies that do a lot of OpenTelemetry code. So we have contributions from New Relic and Datadog and other companies like this.
Okay. They tend to be very specific in different areas. would say that, you know, we at Diagrid today are sort of primary maintainers of the runtime, but we get a lot of people who contribute different components. So like Oracle contributed a component for their databases. We get people who contribute components to talk to their OpenTelemetry stores, like New Relic is one of them. So we get a wide variety of contributors. In total, there’s been about four and a half thousand contributors, individual contributors across the lifetime of the project.
James Governor (14:04)
Okay, okay. So yeah, it’s definitely not single source. You know, in the this broad community. So I mean, there’s a bunch of directions there. I mean, first, let’s talk a bit about OTel. You know, everyone gets very excited about that OpenTelemetry. So standardizing telemetry events for running applications, lots of excitement about it. You know, I think the vendor adoption has been ahead of
the of the enterprise adoption, frankly. But yeah, so what exactly is the problem that you are helping a Datadog or a New Relic to solve in other why, what are they using that for?
Mark Fussell (14:48)
Well, well, yeah, mean, OTel is a fantastic, we have adopted OTel right at the very beginning of the project. So literally go back six years when the OTel standard was still kind of being put together and people are still figuring this all out. We adopted OTel as the way of writing out telemetry events across all the Dapr APIs. So the benefit that you get is there you are, you’re using any of the SDKs that Dapr supports. You can use, using Java.
Actually, Java is a hugely popular SDK for Dapr along with .NET and TypeScript and Python. And all of them, as you call onto the Dapr APIs, write out OTel events. And so you call the pub/sub API and it writes an event. And then you call from the pub/sub API and call on to say the service invocation, cause you’re calling another service or the secrets call, or you call it down into the workflow engine and all these OpenTelemetry events flow through your entire application.
So the benefit that you get is you literally have this end-to-end observability where a call comes into like a gateway like NGINX, flows through Dapr APIs. All those OpenTelemetry events are written out to whatever OpenTelemetry store you care about. There are hundreds of vendors and they can actually see these end-to-end calls across your whole application, your whole applications to API, you know, from beginning to end. And so this, think is one of the greatest benefits.
that Dapr provides. If you look at other technologies like service meshes that only work at the network level, all they happen to see is like a call that happens at the network level. But with Dapr, when I call that pub/sub API and then onto that Jobs API, and then call onto that Secrets API, that whole OpenTelemetry call can be seen and all of the metrics and telemetry against it on time the call takes, everything else like this.
It’s fantastic for the vendors because they are saying, look, you really should have diagnostics built into your app. Developers don’t like to think about this into the last moment. They then go in and have to retrofit it in lots of different places. They pull in some SDKs that may have in OTel in them or not. They’ve augmented all themselves. Dapr just sits there as a little, you know, like helper.
And injects OpenTelemetry into every single one of your calls that you make to it. And off you go, you have that end to end visibility and developers love this because they can, they don’t care what they got to Datadog on New Relic or any of the other vendors and can see those end to end calls. that, that along with kind of security and resiliency are kind of cross cutting concerns that you get for the benefits of using the Dapr APIs because it’s built foundationally across the whole API set.
James Governor (17:45)
Okay.
Mark Fussell (17:45)
So that’s why that’s why the OTel lovers have us because they come along and say, Hey, look, here’s how you just hook up that. And it’s very easy because there’s just an OpenTelemetry endpoint that writes all it that writes out all the events you send that through OpenTelemetry collector and then off you go. see it all.
James Governor (18:02)
But I mean, but so let me ask you then, I mean, is this just you’ve got enough customers, they can see an opportunity there or are they actively using it within their own platforms in terms of injecting that instrumentation?
Mark Fussell (18:13)
I think it’s more about, they just want to show that they can hook up to using Dapr as an open source project that shows those things.
James Governor (18:20)
I mean, that’s a mark of the fact that Dapr is successful enough a project that these vendors are actually, yeah, I’m going to invest some time and effort in it.
Mark Fussell (18:28)
Yes, they invest time kind of contributing docs, samples, blog posts themselves and making sure that their customers, their users who are using Dapr have a great experience hooking up.
James Governor (18:40)
Let’s talk more about that. We mentioned FICO. Who else is using Dapr? how big is this ecosystem?
Mark Fussell (18:49)
We track about 40,000 different companies who use Dapr on and off over the time. it’s kind of, it’s a pretty large ecosystem. There’s a whole set of case studies that on the CNCF website, some of the other users inside that are like HDFC, which is the largest bank in India. do all of these. India’s transformed its economy recently because they have all these micro transactions, literally three rupees, five rupees, buy all these things everywhere.
Everyone does it with their phone. All of the banks were required to support all these micro transactions. The biggest bank, HDFC, built this micro transaction platform on top of Dapr to do all these tiny, I think they call them UDI transactions. And it does about a billion transactions a month on their platform. Dapr is kind of doing all of the service invocation calls and coordination and the pub/sub are behind all this whole. So that’s pretty impressive. Yes, I mentioned FICO.
We have other people that do, IOT systems are pretty popular. Dapr’s got this actor framework built into it all. Love actors, know, a concept of like a stateful, long running object. Schréder is this IOT lighting company in Portugal that controls these huge lighting systems, like in parking lots and buildings and things like this. And every light bulb is an intelligent light bulb. You can control its luminosity.
And it’s, you know, when it’s on and off and things like that, and they model, you know, millions of these lights as an actor, and each one has an identity and you have,
James Governor (20:27)
That sounds like my son’s gaming room.
Mark Fussell (20:30)
Yeah, it is. Exactly. And you can turn them all on off. you know, it’s this actor model in Dapr is just a perfect way of giving you a stateful, long running thing with functions on it. And there you go. I think that I think those are cool ones. There’s a company. Yeah, another company. We’ve seen quite a few of those actually. So Watts Water Company that manages your water flow system, they created a device that manages the water flow in people’s residential houses and
Things like
James Governor (21:02)
if you’re water you don’t want to be watts I mean that
Mark Fussell (21:06)
Exactly. Yeah, exactly. Yeah. You don’t want to put your hand in the water. It is it actually it is a contradiction in terms of good point. Yeah. And then I don’t know like Zeiss Zeiss is another great Ram Zeiss. They are you know, Zeiss they create all these incredible lenses. Yeah.
James Governor (21:07)
Right there Zeiss lenses are, I mean, well, they’re literally, I mean, Zeiss is a byword for lenses. mean, they are.
Mark Fussell (21:34)
The most amazing ones by the way, the ones that they use in lithography, know, when you create your silicon chips and they have a lens that goes down to like five nanometers now and does all the lithography, you know, and this lens must be incredibly precise for them to do.
James Governor (21:50)
They’re absolutely essential to the silicon supply chain. They’re like literally without them, we’d have no computer chips. We’d have no AI.
Mark Fussell (21:53)
They are, yes, yes.
Yes.
Yeah.
Was it, it’s the Dutch company, was it ADSL, isn’t it? That one that creates all the lithography equipment and in that it has all the Zeiss lenses. But yes.
James Governor (22:13)
So amazing sort of single points of failure in the tech supply chain. And people, I think, don’t know that. But so Zeiss is using
Mark Fussell (22:24)
Yeah, yeah. So they use it as a, in fact, in fact, on the 5th of November, we’re having Dapr Day coming up next week. And you’ll be having the lead architect on that to come along and talk about the story of Zeiss inside that. So can I put that on your calendar? And yeah, they do lens manufacture, worldwide manufacture for hundreds of their customers. Every customer can submit their order. And so they’ve used it very much as a sort of an order.
a classic business process ordering system. You know, goes 150 steps, you know, where’s my lens product being ordered? What’s the step is that customer can monitor this or they’re saying, you know, it’s at this stage now and things like this. And it’s a classic sort of steep fall long running durable workflow type thing, but they use Dapr for messaging and state and things like this. And they like the active
James Governor (23:18)
different example, for example, from the microtransaction one. Yes. In terms of the range of messaging patterns that you’re supporting, that’s very different kind of workflow.
Mark Fussell (23:22)
It’s that-
It is, it is. I mean, to me that that’s where I think the greatest, you know, going to your point on complexity, the hardest thing that we see is that, you know, people, you you build these systems and you build an application and you like to write all your if-else code and if-else this, and then you go, Hmm, what happens if things go wrong? Yeah. How do I handle this? And then, well, what happens if this entire machine shuts down? What do I do? Yes.
And, know, I’m halfway through this process and I have to, and then you start to, well, I have to save all this state. And all of a sudden your simple if-else statements and then handling all these failures and then handling the durability just becomes exceedingly complex. So, you know, in my mind, there are only two forms of compute. There’s a state machine and it’s durable and there’s stateless, but stateless is something I could throw away and I don’t care about. So as, and.
You know, and so a workflow process where you want durability and recoverability and retries and just like take away all this pain from me. I’m just trying to write my business logic because I’ve got to put this business process running by next week and I don’t need to deal with these failures is the hard problem that effectively, you know, workflow engines have solved or solve. And I think that’s one of the.
the key benefits that Dapr has now, it has a long running, durable workflow engine in it where you can save the state to your state store and query it and view it all. But it combines that with the messaging side of those things as well, because you know, no workflow is an island as I like to say in it. It sends messages to other systems. So I think that, you know, when you take that to 90 % of businesses, that’s what they’re trying to do. And that’s where Dapr has evolved into now. And being an open source project vendor neutral, Yeah, it means that you are not logged into one particular vendor.
James Governor (25:29)
So, it’s interesting when you went through that description. One of the things that I think is very interesting at the moment is, well, we’ve both been around long enough that we’ve seen people, you know, reinvent computer science many times. Every week and every generation every week or every day forgets all of the lessons that we previously learned. And one thing in particular, I think that as an industry, we’ve become very confused about
Mark Fussell (25:46)
every week.
Yeah.
James Governor (26:06)
writing applications that involve AI. Yeah. We’ve, you know, particularly, I think one of the things that I’ve noticed that is, is, is odd is because there was this, you know, Python is the language of machine learning. And then like, you know, Python is the language of AI.
You’ve got organizations going, Oh, well, what we need to do is to hire a load of Python developers in order to build general purpose business applications that touch LLMs and agents. And I’m like, that just seems tremendously wrong headed to me.
Mark Fussell (26:44)
Yeah, it is, yes. Everyone’s… Yeah, everyone’s stumbling through the AI-agentic Python chaos.
James Governor (26:54)
I mean, why does everyone have to program in Python? just doesn’t…
Mark Fussell (27:00)
Well, think that’s changing now. mean, like, let’s just take Java and Java is like the big, massive ecosystem. you know, they’ve done a pretty good job of embracing Spring AI inside there and that side of things. Then of course, you got LangChain4j that’s coming inside there as well.
James Governor (27:24)
Roll as pretty as bubble.
Mark Fussell (27:26)
Yeah, yeah, exactly. You got that. Yes.
James Governor (27:29)
Honestly, there’s one thing about Java. It has very tremendous antibodies in going, hang on a minute, general purpose applications. We’re ready to go.
Mark Fussell (27:39)
Exactly. in fact, I mean, of all our customers, I think that we have a Diagrid probably at least half of them still use Java. mean, going back to HDFC inside there, it’s all Java. Tons of it everywhere. You’re not going to get rid of it all.
James Governor (27:55)
No, the pattern you described as well, particularly that does sound a bit like agents chatting to me. Like you’re like, I mean, we’re talking about a workflow and orchestration problem where you do have issues of state. You do have issues of, hang on. What if the, what if the behavior is not what we expected? Let’s do it again.
you know, I’m yeah, like, you mentioned Nvidia as well. What’s the Dapr? What is the Dapr agent story Mark? It’s 2025. We’re on a podcast. Like what? Yeah. Tell me what you’re doing to inject yourself into that conversation.
Mark Fussell (28:43)
Yeah. we, we’re, the way we look at the agentic framework around there is that there’s been this massive, like just a industry shift where people are building agents. And in the end, they are no more than distributed applications with LLM smarts added to them, where people have decided that there are some places where I used to write an application before and now I can use an LLM or actually it doesn’t have to be an LLM can just be a model, like a vision model.
to do something on my behalf. And so, and then, you know, the agents are coming in here now because, you know, we’re redefining things like tools, which are like API calls, and we’re inventing new ways of connecting to them like MCP. And in the end, you know, we’re doing and we’re doing these reasoning loops around these things, but it’s a level of automation that in a place where you can have some non determinism to help you, and that’s very important.
You know, you can put that into your application. But the way I see it really is that the vast majority of these are, they’re going to be existing applications that have some business workflow in them where they’re agents in some, well, let’s just say LLMs in some place to do some work. So let’s take a good example. We’re working with a logistics company today and a logistics company has a warehouse manager.
And he is looking after his warehouse and his job is to kind of get everything shipped on time and out that day and things like this. And a lot of unstructured data comes into him, emails, updates, and all this sort of thing. And so he’s constantly going back, looking at all this unstructured data, trying to figure out, someone’s just sent me this email saying that this is going to be late, this shipping order is going to be late. And so they rightly so think, well, I could create an agent that is helping this agent.
Sorry, it’s helping this warehouse manager look over all this unstructured data understand it all and help him in his day-to-day job figure out whether this order is not going to go out in time because the shipment hasn’t come in and Rather than him trying to build like SQL queries or some other tool around this stuff Perfect example for that And so this is what’s gonna and this is what agents are in my mind that distributed systems That’s why Dapr fits really well with it to answer your question
We’re bringing Dapr to our goal is to bring Dapr to literally any agentic SDK out there that you care about. Whether it’s OpenAI SDK, NVIDIA have one called, is it Nemo? I think it’s Nemo that they call theirs. You have Google SDK, have LangChain, you have a Crew AI and the work that we’re doing, in fact, we’re just about to publish this next week is we’ve done an OpenAI extension.
that allows you to put Dapr workflow under the covers of OpenAI to make all of the OpenAI agents long running, durable, and to be able to receive and send messages over a pub/sub message broker of their choice. So if you look at what an agent is, it needs to communicate, it needs to be durable, it needs to have memory and state and recover. And you want that because if your agent fails, you don’t want to have to go back and replay.
thousands of dollars of LLM costs again, because it got to step number 50. And it just has to step number 51 and goes back to the beginning again. So effectively, every agent has to be durable, has to communicate, to be have memory. And all of these terms, going back to your point that everyone’s invented new words for existing systems that already existed. And everyone now is figuring out how to bring that to their favorite framework.
like Spring Boot or .NET and things like this. With Dapr, we’re to bring that to every agent SDK out there that exists and integrate it all. So you can build whatever agent SDK you like, LangChain for example, we’re integrating with LangChain4j on top of Dapr so that you can produce long running durable agents using LangChain4j on top of Dapr. That’s our direction with the project, which I think is really, really exciting.
James Governor (33:04)
Yeah, for sure. mean, I think, you know, that’s the thing on the one hand, we sort of joke, my God, they reinvented computer science again. On the other hand, what it does mean is if you built a tool, as you say, with distributed systems in mind, mean, hello, agents, like these patterns are not really, they’re not really new.
Mark Fussell (33:26)
They’re not. And I the biggest failure, the biggest technical difficulty with all these agentic frameworks today is they’re not durable. So imagine that, you you’ve called 50 LLMs and maybe that’s been five LLMs you’ve asked to do this, you call this tool and things like this and you’re going through your process and then, you know, it fails. You you don’t want to have to go back and run the whole thing again. It’ll cost you a lot of money. I think there’s another thing as well that’s important that I call it that.
companies are sleep walking into an agentic AI nightmare. And I think the biggest challenge as well as you look at this, you know, people are giving these agents complete access to their databases, to their CRM systems. You know, imagine the attack threat for this is I get to your agent, and I, you know, I attack this agent and it’s got full access to all your databases. So yeah, mean,
James Governor (34:25)
Yeah, You mentioned MCP and I’m honestly, I mean, there are cool things about MCP, but like just cause anybody can build Hello World doesn’t mean that I want to front end every single database that I’ve got with a very immature standard that just provides access with very little in the way of security reliability control.
Mark Fussell (34:26)
Yes, and without identity on agents, think everyone is there could have this can be an identity crisis at happening at machine speed if you want to say that word where you know, these machines have access to these databases and if you don’t say well these agents can only access these databases on that one and how do you do all of this because they have some identity then I think chaos will ensue.
James Governor (35:16)
You haven’t been tempted to just completely rebrand Dapr as a how to not have horrific things happen to you when you adopt MCP platform.
Mark Fussell (35:25)
Well, actually we’re going down that path because actually what happened is by using Dapr and its identity framework, you can actually do identity authentication over MCP. So by combining Dapr with MCP protocol, you actually do get the full authentication. So you can actually say over the MCP protocol, are you allowed to access this resource or not combined with Dapr, which I think is a very powerful thing to do.
James Governor (35:49)
Yeah, I mean, that does make a lot of sense to me. It was very interesting. Honestly, it was really interesting. Not not exactly the same thing, but but yeah, so, you know, Tyler Jewell, over at Akka, which has been type safe and various other things again, distributed systems company, they’ve 100 % pivoted to being like, no, we’re about managing like agentic systems now. Yeah. So they went from we’re about and you know, high scale concurrent systems to actually just we just manage agents. Yes.
Mark Fussell (36:22)
Yeah, I mean, it’s, it’s, it’s, well, it’s the new paradigm in some ways. It’s, it’s the old becoming new. It’s the next level of abstraction that just sits on top of other layers. But interestingly, I think, I think in the end, you still need the underlying infrastructure to be solid. And I think a lot of the agent SDKs today are surface level veneers and the underlying infrastructure isn’t solid. Yes. You know, I know that. A lot of companies are pivoting towards this. We ourselves at Diagrid…
James Governor (36:57)
Well, we’ve seen a global search and replace that if you were an API gateway vendor, you’re now an AI gateway vendor.
Mark Fussell (37:05)
Exactly.
Yep. That’s happened everywhere. Yes. And we’re doing the same thing. mean, we’ve in some ways, we’ve done the same. We’ve built a platform at Diagrid called Diagrid Catalyst. And it’s a platform for running workflows and agents at scale based upon Dapr. But I mean, here’s where Dapr is where it brings the reliability of workflow and it brings identity and it brings security and it brings us observability.
So we think that by having Dapr as the core substrate underneath every agentic SDK running on our platform, which we call catalyst, and that gives you governance and control and auditing and basically effectively the management of that. You know, that’s the best combination. So as a company, you know, we’re recognizing the fact that I think a lot of people, there is, there is a rush to build these agentic applications, but the experimental stage is still there.
And it’s going to take years to thrash out the best of it in different ways. But yeah, you’re right. It is interesting how the agentic space has exploded.
James Governor (38:13)
Yeah, yeah, yeah. I mean, platforms, but definitely so many ways you can cut your thumb off. I mean, it’s like, you know, it’s a bit of a, it is a bit of a chainsaw. Like, it’s like, okay, this is great. Let’s do it. And I mean, yeah, I, yeah, I look at the, the MCP thing.
Mark Fussell (38:38)
MCP thing suffers from authentication. It’s like, you who is doing what here and why.
James Governor (38:46)
which is just, you know, here we go. And that was not, that was not a problem that, I think was taken off account of. the fact that we’ve now literally look, mean, you’ve got, you know, when you’ve got Oracle, obviously they know a bit about databases. and then you’ve got Supabase like new kids on the block. Yep. And they’re both like, don’t be using this with MCP and MCP and production. Yeah. Like anyone that knows anything about databases, I think is quite cautious.
Mark Fussell (39:24)
I mean, it’s not only, it’s also a very, it’s a very bloated protocol as well. I mean, if you look at all the history of protocols, you know, if you don’t have a nice binary protocol in the end, you know, that’s why, you know, GRPC got invented because you want something that’s nice and fast and binary and you’re sort of shifting large, you can’t shift large quantities of a database, data out of a database with a bloated large fat protocol that’s JSON based. It doesn’t make sense. So, you know, that’s, that’s another element of it all.
But you know, it’s got some grips and I think it will evolve over time. I think we will. But yes, it’s got a long way to go. But I mean, you have to just recognize the fact that the ultimate trend here though is that it’s to do with just automation. Can I find these, use these language models to automate and improve certain bits of business process? And I think that’s where people should start is like injecting it. Yeah.
James Governor (40:23)
Absolutely.
Mark Fussell (40:24)
As long as it’s non-deterministic, mind.
James Governor (40:27)
Exactly. Yeah, I quite like it when my bank transactions are guaranteed.
Mark Fussell (40:35)
Yeah. Have you ever, have you ever talked to anyone about how they do testing yet on all of this non-determinism? Like every time I test it’s different. So I have to like just test and generally the answers right.
James Governor (40:47)
I I don’t know, I feel like we’ve just got, we just go evals like, you know, you just talk about evals a lot evals and then evals evals and then, know, yeah, no, think the, the, the testing, especially as the models evolve and they change and they evolve so fast that creates all sorts of challenges.
Mark Fussell (41:08)
I mean, exactly. got, I mean, it’s got the combination of the model changing, the model changing underneath you for even the same model, the results, everything else like this. and then choosing these things, I think it’s going to be, yes, it’s going to take a while for this to thrash out, but you that’s, you have to ask yourself, why is the money flowing there?
James Governor (41:33)
And honestly, I mean, I think just from a software development perspective, the truth is bloody hell, they are getting quite good.
Mark Fussell (41:38)
Yes. yeah.
James Governor (41:40)
you know, it’s been amazing the progress and, um, you know, have been playing around with some of these like, and I’m slightly horrified by, vibe coding as a, as a term, um, and also as a thing, but to, mean, a good example. So I’m, I’m having written this book on progressive delivery. I was playing with some of the tools and I was like, you know, went to, uh, uh, v0 and Lovable and like Heroku Vibes.
And just was like, me a CRM kind of lightweight CRM to track people I’ve sent books to and the reviews that they’ve written about the books. It did that. built.
Mark Fussell (42:21)
Yeah, from a prototyping perspective and you building something fantastic. But you know, you’ve got to take that the dangers turning a prototype where you go like,
James Governor (42:36)
Yeah, no, I’m not planning on turning that into a business, Mark.
Mark Fussell (42:39)
Yeah, because just think of the legal side of these things that you pull in some code that you don’t have the license for or refute some license and you put that inside there and you ship it from a company and you did that license check and you’re open to a lot of litigation.
James Governor (42:58)
Absolutely.
Yeah, no, 100 % not not not ready for production. Yeah, but but really fun. It is fun. think the dopamine thing, the dopamine thing is mad. You know, it’s just like the the and then you do and and it is great for learning too, because how did it do that? And you look and can begin to understand that and it’s it’s yeah, it you know, so I think there’s a lot of power there.
Mark Fussell (43:16)
you just-
James Governor (43:26)
Not, you know, unfortunately as you know, modern society, a lot of power without so much responsibility, but yeah, that’s why we’re to need a lot of these sorts of tools. But gear change, because I do want to finish up, you mentioned sort of languages. Now, RedMonk, we spend a lot of our time trying to understand language adoptions. We’ve, programming language adoption, we’ve understand it from a sort of a futures perspective, our classic methodology.
relied on sort of understanding behaviors in GitHub, stuff that was happening on Stack Overflow, doing a scatterplot basically based on those, they set and you’re like, look, things have emerged. We can see programming languages and the chatter about them and the excitement about them. It’s not a proxy for actual enterprise adoption, or it’s a proxy for future behavior. It doesn’t tell you about enterprise adoption.
There are some really interesting things going on now at the moment. So you came out of this world of like, obviously Microsoft heritage. So .NET you can distributed systems that enterprise are using. So Java, but there is a lot of interesting stuff happening. And you mentioned a couple of these. mean, TypeScript is going absolutely bonkers. I think yesterday at GitHub universe, they said that’s like, number one now.
Mark Fussell (44:49)
Yes.
James Governor (44:51)
Some of that is, think, because of CodeGen by AI. Some of it is just kind of the return of types and excitement about that, optimization around that, maintainable code bases. But yeah, so TypeScript, what are you, where are you, is that a conversation you’re having with customers? you, have you got users that are, I mean, and obviously TypeScript has been a little bit more associated with the front end, but yeah, where are you, what are you seeing in terms of changes in programming language. mean, I’m assuming you’d probably more like node meets Dapr. What are you saying? Yeah.
Mark Fussell (45:28)
Yeah. So I mean, what we’re seeing is that as you point out from our enterprise focus, the .NET and Java dominate that space entirely. Still, I mean, least two thirds of our customers have those two languages because they’ve historically have a lot of code and lot of experience in that space. We have seen Python grow enormously fast inside the Dapr SDKs.
James Governor (45:58)
We’ve discussed that, I mean it doesn’t always make sense but…
Mark Fussell (46:01)
Yep. but, but I still try to figure out why people are, mean, don’t forget we’re using Dapr to build backend systems. So this is backend software development. And we have seen a rapid rise actually of JavaScript and TypeScript inside that interestingly. but that must all run pretty much inside Node frameworks around these things. We don’t have the visibility of what the frameworks that they use.
We just have the visibility of the SDKs that can be downloaded and what they look at inside there. We’ve seen certainly in the last year, the type or the JavaScript TypeScript SDK for Dapr triple or nearly quadruple in usage, which has been interesting actually. I don’t know if that’s to do with code gen, it might be, but it’s certainly that there’s obviously a increased surge of writing backend systems now with TypeScript, which I think is really interesting and what that means.
That’s still less than our Java and .NET SDK downloads. Oh, actually, no, that’s not true. Actually, that’s not true. We’ve gone, Maven took away the ability to see download numbers about six months ago. So we’ve sort of lost some visibility there, which is a little annoying, but we still see a rapid usage of that. But yeah, TypeScript, to answer your point, TypeScript has taken hold on the backend a lot more than we anticipated. Yeah.
And that is very interesting. And we don’t necessarily know entirely why yet, but it would be good to kind of find out more. We’re doing a state of Dapr survey that’s coming out in a month’s time, that’s going to be published. And then in that, we always ask, what’s your favorite framework? get, it’s a small sample size. get to about maybe 300 developers who ask us, but you know, it’s good enough. But yes, to answer your question. Yeah. TypeScript has seen a rapid rise and Python majority still is .NET and Java. Yeah, for those enterprise.
James Governor (47:59)
Yeah, mean, think that’s the truth is that, you know, for all the excitement for all the new stuff. Yeah, there are still these just, you know, huge staffs of people with skills and they’re good at building general purpose applications. And I, know, I think we shouldn’t. Yeah, I mean, I think we should not leave that. The fact is, is that we need business applications. That’s that’s what hopefully we’re doing here.
Mark Fussell (48:22)
Yeah, exactly. I mean, there’s a lot of code there still. So yeah, I mean, that’s where Dapr fits in really well. Actually Dapr fits in incredibly well with taking existing Dapr, uh, existing applications and just substituting an API like pub/sub inside there. And, uh, and you know, getting back to workflow, you know, we see a lot of people now who building, you know, putting workflow into their existing applications is sort of ripping out their kind of old, stateful logic that they had before. So it’s a very easy thing to adopt.
James Governor (48:53)
I think we’ve had a pretty decent run here in our conversation.
Mark Fussell (48:58)
Yeah,
thank you.
James Governor (49:01)
No, let me know. last, just one last thing. So what about, and if I think about what you said about, know, organization adopts Kafka and then is like, hang on. So, have you got organizations actively using Dapr for their application modernization?
Mark Fussell (49:22)
massively, yes.
James Governor (49:24)
project. I was thinking about building apps, but actually it makes a lot of sense in a modernization.
Mark Fussell (49:31)
It’s all about modernization. If you want to go into the enterprise, literally 50 % of the projects that exist still and will carry on for the next decade are modernization of existing code. It’s like time and time again, it’s that there’s, yes, people like to think about the greenfield, but no, it’s modernization. And all of that is like just a simple, well, I just want to run it on rightly or wrongly Kubernetes. And that’s because they feel as if that’s the direction. And
Yeah. mean, it’s, you know, Dapr is all about reducing your code base. I mean, we’ve, we’ve done it. We’ve shown this numerous times rather than you write all that code to build all the right experience to using Kafka in the right way and figuring it out. Just throw away all that code, stick Dapr inside there. Best practices are all built in. It’s, you know, a declarative component that’s been refined by the best Kafka developers who’ve used how to
wrap the SDK and use it in the best way and you can configure it as a component that’s used in the most optimal way rather than you trying to figure out the Kafka SDK and how it works. I mean, that’s what you get from it. So yeah, this modernization play of like, okay,
James Governor (50:45)
want to migrate my database. I want to migrate my messaging platform. I want to migrate a thing. Or you’re a means to doing that.
Mark Fussell (50:52)
Yes. Exactly. Dapr does that. Yes. you know, and if you want to help have help with that, you know, we, Diagrid, provide you with ongoing advice and guidance and architectural guidance on using Dapr. You can come to us. Yeah. We can help you with the modernization strategy, your new application. And we give you a full kind of open source support to the Dapr project. And you can come and work with us and build and do that modernization. So.
I think that that’s a great play. You reduce your code base, you make it portable, you make it multi-cloud. I look at multi-cloud now. That’s the other thing that everyone’s rushing to us. Since AWS went down, was it two weeks ago, and the internet stopped for a while, everyone’s going, yeah, we probably need to run on another cloud if things happen sometimes.
James Governor (51:48)
Maybe those API dependencies are not such a good thing.
Mark Fussell (51:51)
Yeah, exactly. Yes. Maybe those APIs also are not such a great thing with all those agents calling them as well. That’s another thing you have to fix out. But yes, so the modernization of the portability, the less code base, easier to maintain open source project. That’s what it’s all about. You want to write your business code. want to be on the golden paths of success, having to build a new wheel every time I… Whatever, I build my new car.
James Governor (52:23)
God, I love, I love ending a podcast on the golden path of success
Mark Fussell (52:27)
Well, isn’t that your thing as well? mean, it’s our thing. know, take away, you know, why are you causing yourself pain when you can, you know, choose technologies? Because I mean, in the end, it’s about correct abstractions, whether you like it or not, you know, from the very world of writing that machine code and then machine language and then first programming models. And then on top of that, the modernization of programming models and then frameworks.
and then everything on top of it. You only get to the complexity that you want of modern systems doing all this crazy stuff with right levels of attractions and you’ve just got to embrace them.
James Governor (53:11)
Okay, there you go. Amazing. Really enjoyed this chat, Mark. Thanks so much for joining us today. Thank you.
Mark Fussell (53:16)
Thanks for having me, it’s fantastic to be here. Thank you.
