Cyber Sentries: AI Insight to Cloud Security

Revolutionizing Cloud Security with AI-Powered Distributed Systems
In this episode of Cyber Sentries, John Richards sits down with Mark Fussell, CEO of Diagrid and co-creator of the Distributed Application Runtime (DAPR). Mark shares insights from his extensive experience in distributed systems and discusses how modern architectures are evolving to incorporate AI capabilities.
The Evolution of Distributed Applications
Mark explains how DAPR emerged from observing common challenges teams faced when building distributed systems. The project, which started in 2018 and became open source in 2019, has grown into a graduated Cloud Native Computing Foundation (CNCF) project used by thousands of companies worldwide. He details how DAPR's component model allows teams to swap infrastructure without changing code, providing crucial flexibility for enterprise systems.
Questions We Answer in This Episode
  • How are distributed applications transforming modern software development?
  • What role does security play in distributed architectures?
  • How can organizations integrate AI agents into existing distributed systems?
  • What's next for distributed systems in the age of AI?
Key Takeaways
  • DAPR provides essential building blocks for secure, distributed applications
  • Workflow durability is crucial for enterprise-ready AI agent systems
  • Identity-based security principles are fundamental to distributed architectures
  • The future of distributed systems will blend traditional microservices with AI agents
The Future of AI in Distributed Systems
Mark discusses Diagrid's Catalyst platform, which helps organizations build enterprise-ready distributed applications with integrated AI capabilities. He emphasizes the importance of security, durability, and workflow management as organizations begin incorporating AI agents into their systems.
Links & Notes
  • (00:00) - Welcome to Cyber Sentries
  • (00:30) - Diagrid’s Mark Fussell
  • (01:07) - Meet Mark
  • (04:37) - The Journey
  • (10:55) - New AI Models
  • (15:01) - On the Security Side
  • (16:52) - Where Things Go Next
  • (20:10) - Bringing in New Agentic Models
  • (24:20) - Catalyst
  • (27:12) - Getting in Touch
  • (28:35) - Wrap Up

Creators and Guests

Host
John Richards II
Head of Developer Relations @ Paladin Cloud The avatar of non sequiturs. Passions: WordPress 🧑‍💻, cats 🐈‍⬛, food 🍱, boardgames ♟, a Jewish rabbi ✝️.

What is Cyber Sentries: AI Insight to Cloud Security?

Dive deep into AI's accelerating role in securing cloud environments to protect applications and data. In each episode, we showcase its potential to transform our approach to security in the face of an increasingly complex threat landscape. Tune in as we illuminate the complexities at the intersection of AI and security, a space where innovation meets continuous vigilance.

John Richards:
Welcome to Cyber Sentries from Cyber Proof on TruStory FM. I'm your host, John Richards. Here, we explore the transformative potential of AI for cloud security. This episode is brought to you by CyberProof, a leading managed security services provider. Learn more at cyberproof.com. On this episode, I'm joined by Mark Fussell, founder and CEO of Diagrid and co-creator of the Distributed Application Runtime, also known by the acronym Dapr. We dig into how modern distributed applications are transforming how we build and run software at scale, why resilience and security are non-negotiable in distributed architectures and how agentic AI is rapidly becoming a core pattern in these systems. Mark also shares a look at the next wave of innovations shaping the distributed landscape.
Hello there, everyone. Welcome to this episode of Cyber Sentries. Today we are joined by Mark Fussell. Thank you so much for joining, Mark.

Mark Fussell:
It's fantastic to be here. John, I'm excited to be on the show.

John Richards:
Mark here is the founder and CEO of Diagrid. He really was one of the co-creators of this idea of a distributed application runtime or Dapr. Mark, tell us a little bit about how you got into that spot. You started creating, founding this idea and then creating a company around it.

Mark Fussell:
Well, I've been working in distributed applications for many years, in fact, decades really around these things. My journey through this was probably when I first started and I worked at Microsoft for many years. In fact, I worked at Microsoft 20 plus years and got very early into Azure and at Azure, had to build a platform to run and build all the major services inside that, particularly database services. So there you are, you're running SQL Server databases at scale, what's the platform look like? So we started building a platform inside Microsoft called Azure Service Fabric, and it allowed you to run these large scale distributed systems at scale, but it went all the way up to the application developers layer where you had to build and run and host applications basically running and how you could just deploy across a set of VMs at the time, they became containers.
And at that time, of course there are many platforms to build and run these services on. I mean we had, now of course Kubernetes is one of those, but we did have things like Mesosphere and Docker Swarm around all these things. And so Dapr was born out of the fact of seeing just many, many different teams build on top of these distributed systems platforms and the struggles that they had. And so what we realized was, "Hey, what would be really nice is if we could look at these distributed systems patterns, common ways where you do asynchronous communication, how you discover other services, how you do statefulness, and how can we take those and codify them in a consistent way such that any developer can take them and rapidly build our applications with a distributed or microservices architecture without reinventing the wheel or reinventing a pattern as we like to say all the time?"
And so from that, seeing these common patterns, these ways for developers to build particularly on top of Kubernetes now the Dapr projects or Distributed Application Runtime project emerged where effectively it is a set of APIs for developers to build and run distributed applications. That project we started in 2018, it shipped and became an open source project in 2019. Just been out there for six years now. It's quite a while. It got donated to the CNCF in 2021 and has grown, grown and grown to now be a huge project inside CNCF with thousands of contributors to the projects, and there are thousands of companies that use Dapr open source projects and it's become a graduated project inside the Cloud Native Community Foundation, which is sort of the highest pedigree you can get to. And it's used slice, in other words, to build distributed applications. So we could dive into the details a bit more, but that's kind of the broad history of the project.

John Richards:
Well, and one, thank you for contributing to CNCF. We're big fans here at the show of the CNCF, been to many of their events and just love the way they help the community and the way folks like yourself have contributed to that. So always my heart's with open source, I'm always happy to see that kind of mature and progress. That's amazing. Also, really tapping into what has just become so dominant, this idea of microservices and how powerful that's allowed folks to scale. What have you seen as that journey over the six years that this has been out? How have you seen that mature and what's that look like now?

Mark Fussell:
What you saw probably if we went back 10 years ago is that everyone was effectively building and putting together their own runtime and frameworks. And in fact, the biggest problem was is that someone said, "Here's this platform like Kubernetes, go and build your application." And before you even got started, you had to think about, "Well, okay, I'm building," say this, I'm building a ticketing servicing app where have to order a ticket from one thing, call onto a payment service and then say maybe send an email afterwards. The first thing you have to do is discoverability between these things. We just saw all these teams having to build a communication system effectively, maybe built around a message broker like Kafka for PubSub messaging or ones from one of the clouds like Azure Service Bus or Google PubSub or AWS SNS and then sort of having to stitch together and send messages through these systems.
And then of course you had to do security between them. I think one of the greatest innovations that we did inside Dapr focused on security side is what we focused on is application identity. And this is really, really key because what happens today is that you really want to be able to say from a developer perspective, "I've got Service A and I've got Service B." And rather than me messing around with ports and networks and IP addresses and all that sort of horrible, messy stuff, at the bottom there as a developer, you just want to say, "Hey, I've got Service A. I just want to discover and call this method on Service B or send a message to Service B. What's the identity of that service?" And so Dapr installs this key principle that when you fire up a piece of code and it's just a piece of processes running, it gives it a piece of identity.
And that's actually allocated by a SPIFFE identity. So SPIFFE, which is another CNCF resource project is the identity is given to one of these processes of code and now you can do some clever things between it all. You can do calls between services and discoverability. You can actually sort of limit calls between two different services. Service A can call Service B. We can do things like this particular piece of code could only receive these messages. So that security principle got better deep into Dapr. And then around this, of course you started to build other services and APIs that Dapr has. So going back to your question about the journey, Dapr itself started with a lot of communication and it started with then [inaudible 00:07:20], and then most recently in the last two years, we developed a workflow engine into Dapr, which should allows you to do effectively when you have a microservices application, you often want to do coordination across E services, Call Service A, Call Service B, and then do something to C or do these two in parallel.
And particularly this is often referred to as durable execution. If everything fails, you don't want to have to go back, restart from beginning again about where I was in my business process, I really reserved my ticket and I'd done my payments and I was about to send my email when everything crashed. And so I didn't know I bought this ticket that actually was successful. Rather than start all over again, the workflow engine just picks up where I left off and continues going. And I think this is probably one of the most crucial aspects in the hardest part of building these applications because it's great to kind of build these individual things, but the coordination, the durable execution, the recoverability, the resiliency and sort of making sure that you don't have to go back and figure what you ran before and things do go wrong, deal with compensation is pretty important.
So that workflow engine part of it combined with the communication of PubSub messaging and all of these things and deep security, I think became a dominant factor in Dapr today. And this what we see is the greatest use case workflow combined with messaging like PubSub messaging.

John Richards:
Yeah, I'm not surprised. As somebody's had to try and debug some of that before, if you don't have that kind of durability that it could be a nightmare when you've got problems and then you don't know where you need your... Your operation failed and now you don't know which step you're in.

Mark Fussell:
Exactly, yes. And the good thing about Dapr, what it also does is it also has this critical great security principle where it actually provides a set of APIs, but you could swap out the underlying infrastructure behind those APIs. So it allows for this great adaptability and evolution of your code and also the change of design choices. So let me give you an example here. It's quite common for someone to start with one particular message broker, say they start with... And this happened to, a good example of this is with FICO for example. FICO is, they did a talk at KubeCon last year [inaudible 00:09:36], and they talked about how they started off with Kafka as a message broker, but in time they ran into some scale and some performance issues and wanted to move instead to a Apache Pulsar. Well, what Dapr provides is that you can have this concept of a component model, which merely describes sort of this metadata of how you can talk to the underlying infrastructure.
And the component brings in all the best practices for a particular piece of infrastructure like a message broker. And so you can call onto the pub and describe API, but underneath you can swap out Kafka with RabbitMQ or MQTT or any one of the other cloud message brokers without having to change any of your code. And this makes it amazing because particularly for platform engineering teams who want to control over who has access to what particular piece of infrastructure, but not having to tell developers, "Hey, we just have to tell you to throw away all your code now that you buy bound to this particular SDK like Kafka and now rewrite all to go against this other SDK," you know, which may take months, you sort of just keep the same API but swap the underlying infrastructure. So this provides a great contract between the platform engineering team and the application developers also provides really good security boundaries around this as well.

John Richards:
Wow. So I can immediately see the value of that that brings, but it does ping in my head. Everybody's talking about AI right now and using new models. How does this apply to that? Is there a world where you are swapping? Are you thinking about how agentic fits into this? Can people swap? I've got too many questions right now.

Mark Fussell:
Well, you've asked the right question because what we introduced earlier, actually end of last year, this year was an API into Dapr called the Conversation API. And the Conversation API is an API that allows you to plug behind it any language model of your choice. So you can plug in Anthropic or OpenAI or DeepSeq or any one visual application models and then it's just got an API that's just a prompt API they crawl onto, but your underlying model can just be swapped out without having to change your API. So that's just a very simple way of having this swapability. And this again, we can do this evolution of try out log this model switch, switch, switch, switch, and you're just switching out all these components. And so the community is now going crazy because they're plugging in all of these different models into Dapr that you can use keeping the same API.
And Dapr does provide intelligent things on top of the API because it does also add capabilities. Actually two things it adds on top of that is obfuscation of data. So if you have any privacy data coming back, and it also does prompt caching, so it saves you some money if you reuse the same prompt and it sort of adds those features. So that's one of the ways that Agave plugged in. But what we've also seen really is this rise of agentic AI systems. And the way I look at agentic AI is that you have these classic microservices architectures that you've used that typically arrive a deterministic code, this sends a message to that and sort of workflow central to this, but now all of a sudden you're wanting to plug in language models through this conversation API that we included in Dapr. And so using that plugged in with the agentic AI direction, we actually developed and put into Dapr a concept called Dapr Agents, which basically takes advantage of all these Dapr building blocks, the ability of messaging, the ability of workflow, the ability of the conversation API and switches them all together. So you can create first class really durable enterprise ready agentic applications.

John Richards:
Well that was what I was going to ask. As you talked about workflows, there are challenges with making sure everything's consistent with some of these sometimes and being able to apply those to an agentic setup would be huge. So it sounds like you are able to pull that inside when you're using this kind of Dapr agentic model?

Mark Fussell:
Exactly. So I mean the way look at agents is that they are distributed applications with smarts, and I think language models run more, but the biggest thing about these things is that they do a series of steps. They go and call this language model, they then access maybe some database to get some data from it, or they then maybe query another system and you don't want it to halfway through, it's just found to ask this language model and it was a very complex prompt query and then it dies and then you go, "Well, okay, I have to start cheating again and I just spent a bunch of money on this." So core to Dapr agents is workflow embedded inside or to give you effectively what we call a durable agent. And the durable agent means that it's gone through all the steps, but it's fully recoverable in state.
And I think this is the biggest challenge with a lot of agentic frameworks today is that they don't handle the durability at all very well and it's okay if you have very simple agentic systems, but you need strong durability in order to make sure that you have this recoverability. You need strong messaging around these things. And so, one thing I'd encourage all your listeners to do is we'd love you to go and try out Dapr Agents. It's a very simple model. You can either build a single agent that just sort of runs by itself or you can run this concept of a durable agent that reads its workflow and reasoning around it all. And there's a lot of cool examples of that.

John Richards:
Now on the security side, how do you make sure... Does this identity opponent you were talking about earlier, is this layered on top of here? How do you make sure your model has access to only the right data or is talking to the right services as it goes through?

Mark Fussell:
Exactly. So because Dapr is built on a security principle of identity, the actual workflow, and therefore the agent itself has identity associated with it. And so that's makes it very secure. And then when it spawns or it runs out its separate own workflows, they too have identity associated with them. So you can very much say, "I can keep this security boundary around what my agent is talking or distributed and running in my system." As well as also when you going back to that component model, in a component model, if you use the Dapr components, you could say only this agent is allowed to talk to this piece of infrastructure. And so you can sort of time bound it around there. Of course the greatest challenge with agentic systems as a whole is that they don't run in isolation. And so you get into this world of agentic systems and how they talk to other services.
I'm sure you've talked a lot about MCP and the MCP protocol and what that's like. There's a lot of challenges with that today about how you can have security in that and how there's a lot of threats and tool and what was it? There's the tool of threats where people inject, they can do prompt injection attacks and they can do tool injection attacks on all of the MCP protocol. So although Dapr supports all of that, the actual ecosystem as a whole has got a lot to work on about the security of MCP and [inaudible 00:16:39] around this. And I think that will get there. But certainly when you build with inside Dapr agents themselves, the identity side of these things provides a lot of security boundaries for you.

John Richards:
Yeah, that's huge. Now as you're working on this, where do you see things going next? Because things are escalating so quickly with the advancement of AI, so what areas is Dapr and then I guess even Diagrid, where is effort being focused as you see AI becoming larger and larger?

Mark Fussell:
Yeah, so I see that what's going to happen is that you have to expand this world where the classic... I mean microservices architectures was driven by a business need and the business wanted to accelerate their development in order to be able to ship things fast. And they are the best way today of building applications that are resilient and durable and mission-critical. And typically Kubernetes is a platform that runs on top of that. But I mean what's happening is that you get a lot of language models or let's just say models in general because it could be vision models and other predictive maintenance models and in many applications that are going to take advantage of AI in order to do things. So I mean you're already seeing this emerge in some classic cases where, sort of medical industry where they can build an agent that looks through thousands and thousands of cases of medical imaging records in order to detect medical cancer growth or anything else like this.
And so the concept of an agent working on behalf of a human doing some things, but typically needing human in the loop to do this is going to be critical. So you've got to span this world of microservices development with agentic systems emerging inside all that where the models are doing a lot of work on behalf of humans, but needing human in the loop and of course having that communication between them all, but at the same time you want it based upon sound principles. So that's where we see Dapr come in. We want to take Dapr not only build Dapr Agents and chart it out, but we're taking Dapr and applying it to any agentic framework, whether that's LangChain, CrewAI, Semantic Kernel, and saying, "Hey, we can bring these durable workflow execution, this great communication to these other frameworks as well." So we see that happening.
We want to be able to blend Dapr into this agentic chain system as a whole. We believe that it's security principles, its communication is very strong as part of that. So that's one thing. And then generally what we also see is that the language models themselves are getting more and more intelligent. And so this whole concept of reasoning and how does a model think about things and go in depth and decide what it's going to do? I think it's a bit fascinating world one day where we have these robotic little assistants working for us.
Today, it's great having sort a little virtual assistant. Maybe it's working through my CRM database, finding cases for me to send and maybe sticking over medical records to do things. I'm sure you're already talking about airlines, already talking about having every person that comes to them has their own little personal assistant that helps them rebook their flights. And so rather than you and me to figure this all out, and certainly that will emerge. Of course, I think the truth around this all becomes is how enterprise capable are they? And being built on things like workflows and having workflow durability and security is key to all.

John Richards:
You mentioned different types of agentic here. I tend to, you know, because they were the ones that grew fast first, LLMs, but you've got this vision in other pieces. Is it very different as you look to bring in those kinds of models? Are there new things you're considering size of data or at the end of the day, is it, hey, you just treat it as another AI agent and it kind of fits in a bucket regardless of what type it is?

Mark Fussell:
Yeah, I just think that we've just got to recognize that other types of models are good at doing things. I mean, I think vision is here is the main one, is that this being dramatically shown that vision models are created recognizing images. And so you get these systems that are built, for example, that just do vision in part of automation. I remember working with an old car company and as the car goes through in its manufacturing, they literally have a hundred cameras around this car looking for all sort of defects on their door rather than a person inspecting the door. For example, they get fanatical about, does the door close and is the width of the door exactly right? And it has to be within a 10th of a millimeter accuracy around these things. And so there's vision model that just looks at that and it's checking the quality control of a car and doing all these things, but it's still in a process automation scenario where you have to go through a series of steps around these things.
So that's the sort of scenarios that you get in order to combine vision models. And you could have these predictive maintenance models that look at acoustic patterns with inside engines and what's happening there from when they're going to get maintained. They get these large industry engines and they listen to the acoustics inside the wall and as it starts to get to high-pitched winds, they know it needs to shut down for maintenance and think like this. So that's the swing. But in the whole part of the business workflow, you still need to do step A, step B step C, and still need to build a car. You still need to run the industrial equipment. So that's where those sort fit in. And the agentic applications are just going to be combining the multiple... I think language models, although are the one that's sort top of the line because they're very humanistic.

John Richards:
Yes.

Mark Fussell:
That's where you engage with humans and ask it, "Book me a flight." Or, "What's the latest, most likely people I can send a targeted email list in my CRM system?"
So they're very simple today, but they're going to get more and more complex, especially when we fall into these multi-agent systems. And so I think that the whole security world is going to explode and get ahead and a little bit blown away when if we start talking about these multi-agents talking to each other because I mean, who do you trust? How do I know who's sending to what? I mean, I have no idea how I'd ever do this one, but somehow we'll have to have a trusted agent somewhere that I trust. And if we get into these agents talking to agents, which everyone gets very excited about, I think trust relationships will be enormous.

John Richards:
It's a whole nother... And it still goes back to some of the fundamentals, but the stakes just keep getting higher and higher as less and less concretely about what it knows and what you know in those cases.

Mark Fussell:
So we're going to have to have these approved agent registries. These are the ones, I'm sure there'll be sort of control at some point, but how you then have to trust the authority that controls the agencies around those things and things like that. And I'm sure that some of the major cloud providers will build these general purpose agent registries in time. That will happen. But I mean, I think the important thing here is that it's going to take a long, long time to get there, and the concept of distributed applications is still at the heart of this. And so that's where Dapr itself fits in. Well, and that's where we are Diagrid at working pretty strongly because we've built a product called Catalyst. And Catalyst allows you to build and run distributed applications based upon Dapr and using its APIs along with agentic applications and provides you with a platform for running workflows and these agentic applications are enterprise-ready. And so we very much think of enterprise-ready, quality, agentic applications running in very mmission-critical scenarios.

John Richards:
So this would be for folks that have maybe a distributed system set up already, but they're like, "I want to start adding in agentic to this," and if I'm understanding right, you correct me if not. And then Catalyst is basically a way to say, "Hey, here's how you start to maybe marry those things together, run your distributed, but also start bringing in agentic easily and secure and available."

Mark Fussell:
Exactly. Yeah. So I mean, what we recognize is that there we have is Dapr is a set of APIs that allow developers to be amazingly productive about building distributed applications with PubSub messaging, workflow, service discovery and communication, state management and secrets. We've combined those together to build Dapr as an agentic framework. Catalyst is basically, think of it as Dapr's server, and we deploy this into a customer's infrastructure. It has the concept of projects. It has for example, a visualization for your workflow, visualization for your agents. It has ability to do auditing and RBAC control, and you can now build your application on any compute platform that you choose. You can run your applications on VMs, you can run your applications on container platforms. You can run it on say, functions, but you could take advantage of the Dapr API such as workflow and for example, agentic systems and communication in order to build your distributed app.
So common examples are we're working with several large financial companies who are deploying Dapr into their environment and they're using it as a workflow engine because they've got to create payment services or they've got to create other business workflows around these things. So think of it as a code-first workflow engine, which is very developer-friendly. And because it's a code-first workflow engine, it's very easy to debug code and it's very easy to... And it's multi-language as well. So you can write part of your application in Python, part of it in Java, and to marry it all together.
Dapr is very multi-language friendly. The workflow engine is code-first-based, which means that developers can easily debug it with your environment and you don't have to worry about domain-specific languages and all this side of things that certainly the older style, I would say BPM engines had. This is a code-first, I write a workflow type and then have a series of activities inside us all. And then I can point this to any database of my choice, like a PostgreSQL database to store all the state and recoverability. So think of Catalyst as a server that runs workflow at scale with a lot of enterprise capabilities, visualization and allows you to do code-first workflow and build very resilient enterprise-ready applications. Does that make sense?

John Richards:
It does, it does. Well, thank you so much for coming on here. This has been so fascinating to hear. Tell folks where they can learn more about Catalyst, how they can find out about it, and of course about Diagrid as well, and the CNCF project.

Mark Fussell:
Yeah, so if you want to find out more about Dapr, go to Dapr.io is the project space for that. I would encourage anyone who wants to get into Dapr to come and join the Dapr Discord server. We'll post a link to that afterwards. It's a huge community. There, you can find out and ask questions about building Microsoft's architectures or Dar agents. And then my company, Diagrid.io. And at Diagrid, we effectively provide support not only for Dapr, we source projects if you are starting to use Dapr in any of your deployments, but we also provide Catalyst as this workflow server that you can deploy and running environment.
So you can reach out or you can reach out to me directly. I'll post my email at the end of all this, and I'm happy for people to send email directly, Mark@Daigrid.io and have a conversation with them. I'm always open to talking about Dapr, distribute applications, agentic systems, love to hear more about it all. It's a very, very exciting time and it's amazing time to be a developer as we sort go into this sort of autonomous world of development. And as you see, not only in co-development, but actually in systems development.

John Richards:
Well, thank you so much, Mark, for coming on here on the podcast, it's super informative also for all your contribution to the CNCF. Appreciate that. Everyone, go check it out. Check out the Discord, check out Daigrid and Catalyst as well. And thank you again for being a guest on here. We're so glad we had you.

Mark Fussell:
Thank you for having me. It's been great.

John Richards:
This podcast is made possible by CyberProof, a leading managed security services provider, helping organizations manage cyber risk through advanced threat intelligence, exposure management, and cloud security. From proactive threat hunting to manage detection and response, CyberProof helps enterprises reduce risk, improve resilience, and stay ahead of emerging threats. Learn more at cyberproof.com.
Thank you for tuning into Cyber Sentries. I'm your host, John Richards. This has been a production of TruStory FM. Audio Engineering by Andy Nelson. Music by Amit Sagie. You can find all the links in the show note. We appreciate you downloading and listening to this show. Please take a moment and leave a like and review. It really helps us to get that word out. We'll be back October 8th, right here on Cyber Sentries.