Mark Fussell: Number one is you've got to solve a real problem, and if you solve a real problem, people will love you for it. Building community is getting other people excited about the technology. How is it that you go out there and show how a open source project can really help solve developers problems or whoever your target audience is/ Eric Anderson: This is Contributor a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. You're joining a conversation today with Mark Fussell, who is the creator of Dapr and also a longtime Microsoft veteran creator of Azure Service Fabric, among other things. Mark, thanks for joining us. The Service Fabric is kind of this foundational part of Azure and was maybe a contemporary competitor to Kubernetes in some ways. Mark, when I was looking at Dapr, I got the impression that it felt a little bit like a service mesh with almost like a past capability. What do you think of the service mesh analogy? Is that related at all to Dapr? Mark Fussell: Oh yeah, for certain. I mean there is definitely an overlap and a correlation between what Dapr does in terms of service meshes and in terms of what Dapr can do as well. I mean there is an overlap here. When I look at service meshes, they are very much focused on the networking layer and the networking layer of the infrastructure. And so I would say infrastructure teams love the idea that they can put a service mesh in place and can control the traffic that is routed through their platform that they deploy. But where the key difference that Dapr has in terms of a service mesh that makes it very unique and different that you don't do at a service mesh level is it provides identity at the application level and it provides an actual process level or container level identity. And that turns out to be crucially important because there you are as a developer, you don't want to be messing around with networks and ports and how you can figure this. You just want to say, "I just want to build a call from service A and I want to call this method on service B wherever it's inside my environment." And so Dapr very much works at the application level and provides identity. So as a developer you can just go, you may have, for example, my application deployed into a platform like Kubernetes, my application's running somewhere inside here and I just want to say, "Call from application A to application B, call method X on it and do the discovery, do the routing, do the failover, do the security, do all that for me." So that application identity is very distinct differentiation from what service meshes can do, which can only sit at the network level and can only sort of route through ports and DNS addresses and things like this. So that's kind of the key distinction. So saying that Dapr does play very nice with service meshes is Dapr is a set of APIs and so there are plenty of people who come along and say, "Well, I still want to use a service mesh and deploy Istio or Linkerd, but there are other Dapr APIs I want to use instead." So when you think about Dapr, it's a set of APIs of which one of them called a service invocation API. How are you calling between two services has an overlap with a service mesh, but that's just one of its many APIs. And so if you do want to deploy Dapr and still use other APIs and still use a service mesh, please go ahead. That's perfectly acceptable. Eric Anderson: Okay, so is it fair to say Dapr is a set of APIs that sits atop some kind of service mesh? Maybe Dapr gives you one out of the box or if you want to bring your own, you can bring your own and map the APIs to that? Mark Fussell: Yeah, I mean it doesn't layer on other service meshes, just work side by side with them. So let's just take another API that Dapr has that's got nothing to do with service mesh. That happens a lot and that is asynchronous pub/sub messaging. So every service in the world that wants to build an adventure driven application has to send messages between two things. So if you think of service mesh as direct request reply type calls and do it that way, well then you want asynchronous calls and you want pub/sub messaging. So there's a different messaging mechanism that you need in apps and typically behind that you have a message broker of your choice. Now, what Dapr does do is it provides an API for pub/sub. And what's really good about this is it's exactly the semantics and the behavior that developer wants. I want to publish messages and I want to have subscribed to messages for a named topic and how they get there, they want them to get there reliably. I want to get them to be secure, I want there to be retry mechanisms on them. All I want to do is reliably send messages between two systems and that's the API that Dapr provides. Got nothing to do with service meshes, but it's all to do with messaging between systems because you want to broadcast messages or tell the inventory service now that it goes off and sort of kicks off its inventory processing to do something in some event-driven architecture. So that's another API and we can go through and talk about the other ones that make Dapr very powerful for building these distributed applications. Eric Anderson: The thing that queued me on the service mesh was the sidecar deployment. So Dapr is kind of a containerized thing that can sit alongside your application kind of in a sidecar fashion. And so when your application communicates with other applications, it does via the sidecar, it kind of just talks to Dapr and Dapr relays those either pub/sub like messages or logs kind of activity of the application. Mark Fussell: For certain, I mean the sidecar pattern, which is a general pattern got popularized because of service meshes when they emerged, what seven years ago, but especially general pattern and it does is one thing. It turns out that's one API, but why not have your sidecar also do pub/sub messaging? Why not do sidecar also do a workflow engine? Why not have like Dapr has a secrets API? So it starts to encompass much more than just that thing. Or the benefit even provides of the sidecar pattern is because you've got these set of APIs that a developer can just use. First is clean separation between here is my code and here's the methods that I'm calling and they don't get all jumbled together in terms of trying to tease apart a library you've bought in and where it's running. There's clear distinction between the two. Turns out that's very good for you to be able to separate concerns about where who's responsible for what my business logic versus this, but also what that API provides that sidecar pattern provides. It allows you to do cross-cutting concerns, particularly things like observability. So now whenever I call one of these APIs, I can write out open telemetry events of all the APIs and I can actually trace calls that go into this pub/sub API into the service invocation API, into the secrets into any one of the APIs and sort of trace a call end to end because it's sitting there as a sidecar doing all your tracing and all your logging for you. You can also do another crosscutting concern is that on all those APIs you could put resiliency policies where you do things like circuit breakers and timeouts. So what happens is developers not only get concrete APIs like messaging workflow, but they get crosscutting concerns for end-to-end security, telemetry, and resiliency that just happen out of the box or because DAOs host as a sidecar that gives you these generalized patterns with these generalized cross-cutting behaviors. Eric Anderson: That's interesting. As you were describing the various services that you can get via sidecar, it started to feel like a cloud platform has compute and networking and maybe database, but also has a bunch of services that are common secrets management and pub/sub patterns observability that you would kind of expect or need for building any application. And it's almost like you're delivering the engineering services, the building blocks of an app, the common building blocks via sidecar. It feels like a little cloud platform. Mark Fussell: Well actually, yeah, you touch on a very good point here actually because what we've seen recently in terms of a great use of Dapr is within platform engineering teams inside these organizations. And so yeah, what's happened now is that everyone inside infrastructure is calling themselves a platform engineer now. And rightly so because I mean if you look at platform engineering, it's nothing new to the likes of big cloud providers than Microsoft or Google's the AWS of this world because they had to have platform teams to build their own services. But now, organizations are recognizing that they need to have more than one application themselves and they don't want every team to have their own DevOps person inside their managing their own infrastructure and deploying all that. If they've got at least 2, 3, 4 applications one of the platform engineering team where Dapr shines and comes into this is it provides this sort of very clean contract between the application developers and the platform engineering team. And one way it does this is this concept of being able to plug in your underlying infrastructure for the API that you choose. So if we return back to that pub/sub API, what's so great about it is that the developers can use the Dapr pubs of API, but behind that, the infrastructure team or the platform engineering team can plug in different message brokers of their choice that correspond to that API. So they can plug in Google GCP pub/sub if they want, or AWS SNS, or Azure's Service Bus, or Kafka, or RabbitMQ, MQTTT, or Solace's platform. And the actual code that they have doesn't change in any way. All it has is that they have a declarative mechanism that allows them to have all of the behavior that they want for a particular message broker and switch out this declarative YAML concept for a component to switch the underlying infrastructure whilst maintaining a clean contract. And this turned out to be very important for platform engineering teams because they can adjust the type of infrastructure they provide. It means that the application teams don't have to fight, am I using Kafka, or using RabbitMQ, or GCP pub/sub? They can choose just the one API and they don't bake all of the client code into their application. And that provides you the ability to evolve your architecture over time. It also means there's less code to maintain. So you're not having to suddenly take the Kafka or SDK or the client and then decide how you're going to layer this pubs of API and do it best on top of Kafka. Sort of all of that experience and knowledge has been deeply baked into the Kafka component that Dapr provides, and it's got hundreds and thousands of users of this component and it's been refined over so many years. So these are all sort of really good benefits that have kind of suddenly emerged in this platform engineering trend for this contract between your paths platform as it were, wherever, whatever you like to define that to be. Yeah, it could be Kubernetes or it could be you're using this telemetry store and all those other things, how you built your own sort of paths inside your organization as a platform and sort of the application developers using it. Eric Anderson: One of the tensions I feel like these platform engineering teams face is microservices has allowed us to have a lot of agility in the engineering team. You could build your app however you want independent of the organization, and then the platform engineering teams are trying to do some standardization across the organization for good purposes. And you maybe there's some tension there, but I think what I'm hearing from you, Mark, is that I could kind of encourage engineering teams to adopt Dapr APIs, but you don't, if you're already running on Kafka or you're running on RabbitMQ, we just leave that there, put the Dapr shim in between. We now kind of have standards in some ways across the organization with allowing product teams, engineering teams to have opinions of their own on the stack. Mark Fussell: Yeah, I mean I'd like to say that Kubernetes was successful because everyone agreed on a set of APIs and a platform that would run on across different clouds, and we could all agree on this one sort of technology that allowed me to have some level of portability. Well, the more we can agree on standards, the more it kind of helps us accelerate our development and we don't have to keep reinventing the wheel. So in many ways from an API perspective, from what developers build, I like to look at Dapr's a set of standards that you can have that we've donated into the cloud native computing foundation. Dapr's is a graduated project there now, which is the highest level of echelon of how you can achieve. It's been endorsed basically by lots of end users who are using it all. And so the Dapr APIs can be considered a quote "standard" in the sense of can use these things. It's not part of a standards body where they have to endorse, here's the API and it's like the HTTP protocol, but nevertheless, it's standard enough for developers to be able to make sure that even if they have an existing message broker, they can switch few things out and hopefully I should simplify their code and make it more portable. And certainly we see a lot of multi-cloud behavior now as well. Certainly every financial company I talk to is required to run on more than one cloud and Kubernetes has become the defacto sort of hosting layer. Well, what's the sort of application layer equivalent for my application developers to be able to say, I can do multi-cloud deployment? As well as multi-language as well, because I think that's important nowadays. There's a lot of existing sort of Java code out there. Dapr plays very nicely with the likes of Spring Boot and these Java frameworks, but it also plays nicely with other frameworks like Django from the Python world and Node.js and express in the JavaScript world and in the .NET world of ASP .NET core. And you can put these different language and different frameworks together and sort of build your applications and break down barriers between different teams. Eric Anderson: Mark, maybe we can take a step back and tell me how you, you seem like you were comfortable with Microsoft, you were the guru of many sorts, and now you find yourself in a startup. How did that happen? When did you discover the need for Dapr and what led to Dapr's development? Mark Fussell: Yes, I spent a long time working Microsoft, 20 plus years, which is an eternity for some. I worked on many different developer technologies. In fact, my very first role was I turned up there and did the XML support and ado.NET support inside the .NET framework at the time. But over my career, Microsoft worked on various different distributed systems technologies. Microsoft created this thing called Windows Communication Foundation, WCF, which was a big standards body thing for a long time. And then that eventually led me down the path to kind of building service fabric, which was sort of a platform play for running all large services in Azure. And then in turn, as we built all of that, I recognized the fact that the need for an open source project that you could build that was sort of independent of any one particular platform. So for me, it was very much about is it possible to stop developers reinventing the wheel and create an open source project that we could layer? I mean, at that time you still had the likes of Docker Swarm, Mesosphere, ServiceFabric, Kubernetes, other PaaS platforms all emerging, and everyone was talking about how do they kind of build applications on these things. But all of those were very much infrastructure layers. And the whole idea of Dapr was like, well, let's make the developers who are all the ones who have to struggle and build on top of things like Kubernetes, let's make their life easier. And so that's where Dapr was effectively born. Let's just start off with the common patterns of request, reply, pub/sub, and you build on those, and it is all born out of seeing not any Microsoft developers build services, but actually working with many, many enterprises who are still trying to build, particularly on top of Kubernetes. How do I even get started? And even now, the classic play is, is that people love to build their own. They come along like, oh, I've got to do messaging and I'm going to pick Kafka and I'm going to spend three months building a message brass broker thing on top of Kafka that does pub-sub messaging and do all the thing myself. And it just seems kind of an unnecessary layer that could be generalized a lot more. So the incubations team, which was part of Azure who worked for the Azure CTO, Mark Rozonowicz, and he's a lot of credit to kind of kickstarting Dapr off and providing that sort of impetus and support around it all. We started open source projects and when we released it, there was a lot of excitement around it all. And six years later, since release, actually six and a half years later since releasing, it's taken off and it's kind of very well established around tens of thousands of organizations. So the inspiration sort of came from just seeing and wanting to do something for those application developers rather than just being solely infrastructure focused and sort of many ways kind of allowing people to build and design their own paths as it were with these patterns and put it together. So that's kind of the background around it all. Eric Anderson: I think one advantage, the way you've done this Mark, is I work with a lot of open source startups and many of them, they start a company and then they create an open source project, and investors tend to give money in two-year allocations. And open source projects I think have an incubation time. They take a number of years before they kind of find their footing and their audience. And so if you start a company and then start an open source project, you might be looking at five years of incubation. And that's not really within the investment horizon of- Mark Fussell: Not anymore. Not anymore. Eric Anderson: Yeah. And so I think, you know, start this thing at Microsoft, it kind of finds its footing and audience and then you can kind of spin out and reap what you've sown. Mark Fussell: Well, what I wanted it, so the reason why I started Diagrid along with my co-founder Yaron Schneider, is we wanted to continue the innovation trend inside large companies you can take things so far, but at the same time there is a direction of innovation that you sort of have to convince many other people around these things. And so our innovation that we've done at Diagrid is that we've continued to not only invest in the open source project to keep it going, but we've actually built two services there. One that helps you provide and manage Dapr on top of Kubernetes. So we call it Diagrid Enterprise. We come along and we help you manage Dapr on top of Kubernetes, not only in terms of support, but also a service we have called Diagrid Conductor that helps you do DevOps processes in order to deploy Dapr onto a Kubernetes environment, do some of its control plane upgrade, doing some of its monitoring, doing a lot of admin tasks that you do just because it's Kubernetes. But I think the more exciting thing that we've also built is we have a service called Diagrid Catalyst, which is basically a platform play entirely for Dapr and effectively we host and run sidecars on your behalf so you don't see them all. And we just expose you the Dapr APIs. And so we deploy this Diagrid catalyst platform into your own environment, into your own infrastructure, and now you can actually build and deploy your applications on any form of compute. You can run your application on a container service or a function or a VM, it doesn't really matter. And yet take advantage of all these Dapr APIs to do sort of communication. Increasingly, I think workflow is really, really important here. I don't know how familiar you are with workflow engines, but that workflow engine built into it in order to do long-running durable execution. And so you can do a lot of the coordination between the services like call service A, call service B, do these two in parallel. Once one's returned, another one's returned, carry on. I mean, it's classic. Google was a workflow and AWS has step functions and these state machine engines, but the key thing about the Dapr one is it is a code based one. And so it's very, very developer friendly. And so when you have this code based workflow engine combined with the other Dapr APIs like messaging, you can actually build a very powerful thing. So that workflow engine built into our Diagrid catalyst platform, we've seen a lot of excitement around that because you can actually use it in any classic workflow engine for doing a business orchestration of your services. But in the case of Dapr, it's not just a workflow engine, it's got the other messaging, API secrets management and other capabilities that you can put together. So you get the sort of this holistic set of APIs. Eric Anderson: These categories of software like pub/sub or workflow engines. There's new innovation and there's kind of a commoditization where they more or less start to look the same. They have standard kind of interface patterns. And I suppose that's when Dapr can be really quite useful is like, well, we'll give you the standard interface pattern and then you can kind of mix and match under the hood or just use out of the box Dapr capability. And you're right, I think the workflow engines have become, we've kind of arrived at a standard way of doing those things. Mark Fussell: I mean, a lot of the workflow engines though today, they're kind of declarative nature. They have a sort of domain specific language, a DSL language, and you write those things and those are okay. And I mean some people claim that they're good for sort of the business side of those things, but those DSLs are not very developer friendly in any way. And the great thing, at least the innovation that we took down, Dapr workflows is a code-based workflow. So you basically write the concept of a workflow class and then a workflow class consists of a set of activities. And those activities can be orchestrated, you can either do them in sequential activities, this one followed by this one, or you can run them in parallel. And there's first class language concepts. So whether you're a Java developer or .NET developer, how you run three activities in parallel and then they wait for them all to complete before you carry on the next step of your workflow is a sort of all built into the code itself. There's concepts, things like your monitor pattern where you're monitoring a particular endpoint or human in the loop. And I think these common workflow patterns become very easy for developers to codify. And that if you look at 90% of applications out there today, they probably consist of some business logic where they're trying to do a bunch of if-else statements to tie some business logic together. But at the same time, you've got to build resiliency into this. What happens when I've called service A and service B and then my application dies and the machine it was on puts out, it gets recreated on another one? I don't have to figure out, well, where was my application running? I just want to carry on from where I was at this particular point. So this concept of durable execution where it ran these 20 steps already, you just got these 10 more to run. It's kind of key part of what long-running durable applications do. But on top of that as well, you also want resiliency. So if I've called this service here and it failed, let me retry three times in a certain way, and then if it still fails, well I have to do some compensation logic to figure this whole thing out. So Dapr workflows takes all of this pain away from you and gives you this long-running resiliency, durable compute you combined with the other APIs and I think and then code first way. And I think this is something that we've seen particular large takeup inside the Dapr community. Eric Anderson: What's the state of Dapr today, given the kind of ambition of what you are trying to do or could do? It seems like you can imagine we support a couple languages most of the way, and we support a lot of these services partially, you can imagine a world where it's like the direction is really promising, but we're not quite there. Is Dapr kind of ready for the average engineering team and probably the languages and services they want to support? Mark Fussell: Oh yeah, yeah. I mean, I would point to the Dapr graduation as kind of key endorsements in CNC that after, I mean we track 40,000 plus different companies that use Dapr today. So it's got a big ecosystem of users and all of them, I mean of those thousands of them are using it in production today. So it's been production ready for four years I would claim. But is that Dapr still evolving? Yes, it definitely is. In fact, in the last two releases, we've added APIs that were often requested by the community. I think the other one that was added that also went along with workflows is this concept of a jobs API. I think it's just like cron jobs where you want to kick off a cron job, do this thing 10 times, do this thing in the future and make your durable cron jobs that are recoverable. That turned out to be a key API. Another API that we added on this whole AI trend was a conversation API. If you think about, there's lots of different services out there I can do called Google Gemini, or AWS Bedrock, or OpenAI, Anthropic. They all have a conversation LLM behind the API. Well, we added into the Dapr SDK. In fact, it was done by a community contributor, a conversation API that allows you to plug in any one of these different language models behind it all. But laid on top of that was a set of features in terms of not only prompt caching generally, but also some data obfuscation. So it kind of scrubs things like PII and social security numbers and things like this across all these generally. So now you get this benefit again of like one API, I can call this, but I can plug in any number of these different language models without my API changing. So they are constantly innovating. I mean, I would even say that another innovation that's happened quite recently that is also picking up a trend, and that is this whole concept of building agent systems, agentic systems. Which to me is just, it's a distributed systems problem and I call it's a distributed systems problem with smarts, where you're swap substituting language models to help you make some decisions now, but you still need all those key primitives of something and durable and recoverable like workflow. You still need some messaging between these different agents. You still need the concept of state and memory. And so another thing that we introduced recently that was done by a community contributor was Dapr agents, which actually builds on top of Dapr workflows and many of the other APIs in order to create an agentic set of applications that you give a set of tools to, you can plug in your own language model and it makes it very easy to build either a simple agent that just does one thing or multiple agents that start communicating because they need to send messages or communication with each other. And I think this general trend of building agents to take to use language models to help you make a few decisions is going to accelerate quite a bit. Of course, you know, have to trust the decisions of the language model in the scenario you want, but I think that for an example, an agent that does sort of a code PR review will be, is becoming very common already and just does it on your behalf or might walk, have more consumer ones like, I'm going off to this city for the week, go and build me an agenda for based upon the weather and find me some flights and these agentic applications or review these research papers and give me a summary and sort of send results to this other service. And so these general agent applications of language models is something that we're also sort of embracing quite strongly in the Dapr world based upon all of its core API and primitives that have been well tested. Eric Anderson: And then tell us about, we haven't to the extent you want, I know this is a show about Dapr, but I'm just curious about Diagrid. This is presumably a company related to Dapr and your work there. Mark Fussell: Oh, totally, yes. I mean at Diagrid we fully embrace open source and diagrid is all about enterprise Dapr, yes. But we are the main contributors to the Dapr open source project now. And we're also, we keep the community going and make sure that we work in collaboration of course with many other companies who sort of contribute into this. But you can consider Diagrid as the enterprise arm as it were of Dapr. So you could come to us for key questions in order to help you with your support with a sort of developer tooling or ops tooling, I should say DevOps tooling to help you manage your Dapr in terms of on Kubernetes environment, and particularly as I mentioned earlier, we have this product called Diagrid Catalyst that brings a serverless version of Dapr to as a set of APIs so that you can start to build and put Dapr inside your environment without you having to run and manage Dapr yourself. That platform play just makes sure that you have great adoption around this. So yeah, I mean Diagrid is very much focused on Dapr. We also spend a lot of time with KEDA as well. I don't know if you're familiar with KEDA, but my co-founder Yaron Schneider also actually started KEDA as a project and sort of was one of the original creators of that. So we spend a bit of time with that as well. But to a large degree, we see nowadays all of these companies who are building cloud-native applications, Kubernetes is being the main platform. How do they go about building those things without reinventing the wheel? Well, Dapr is the answer. And then if you want to be able to have someone who has got your back, helps you with architecture guidance, gives you sort of training reviews and then support, you come to us Diagrid. Eric Anderson: As people are listening to this, maybe they're trying to figure out am I a good use case for Dapr? And I suppose most people are, but walk us through a couple scenarios of where people adopt Dapr. Is it like I'm doing a whole new company or project and I use Dapr from the start? What's a common migration path if I kind of bring it in later? Mark Fussell: Yeah, I think that's a great question. In fact, maybe I should have kicked this off a little bit sooner on this, but Dapr both is very much aligned with both the Greenfield brand new as well as sort of the Brownfield applications. And I'll run through a couple of examples here. In fact, I think generally we see more Brownfield adoption of Dapr in terms of how it gets used. So here's kind of some classic examples. I'll start with pub/sub. FICO has a good case study around this where FICO actually were building and had built on top of Kafka and yet they wanted to provide another mesh broker. And so they wanted to introduce Apache Pulsar as another type of message broker inside their platform. And so they were able to use Dapr to provide both the migration from one message broker to another, but also just provide two different message brokers inside their platform. But we also see things like people who are just sort of modernizing existing applications. And so you might have some traditional Java application that you've built and you're trying to move this and to run it. And modernization here might be, I'm trying to move it to run it on top of Kubernetes. And Kubernetes is very different from maybe the client server world it might've come from before because you're hosting it and running it on a platform where you have multiple services now that need to communicate. And so we often see the modernization of existing Java code or.NET code. They're trying to make it and run on top of Kubernetes as a platform and Dapr is ideal for just giving you sort of the message communication between those services or even adding things like secrets. I mean, we see it where a developer simply wants to be able to get hold of a secret from a secret store, whether that's sort of like hash code vault or some other cloud-based secret store. And they simply run Dapr next to extract all they can use the secrets API plug in the underlying backing store that they want and sort of just modernize their application with sort of secrets management. So whether it's communication or because you're running and just reading application communities or just getting hold of a single secret or going a little bit further and using workflow, that modernization of taking something to be sort of a cloud native first and cloud native here means you can ship faster, you can release quicker, you run it on cloud infrastructure and you have sort of a DevOps pipeline around this. It fits in perfectly with this modernization side of things. And so that's what we see the vast majority of people doing this modernization of existing code running on onto cloud principles, particularly Kubernetes, but also general breaking your application down into a few more different microservices like architecture because you had a sort of a larger application before. And so because you can now ship independently faster, you can ship this service at a different pace to this service and scale this one out in a different way compared to this service. And the advantages of effectively sort of a cloud-based approach or cloud native infrastructure or design approach I should say. But there are plenty of people also just do Greenfield. It's like great, I love Dapr from start. I don't have to build any of these APIs for myself and let me just go off and start using it and you can basically, we say Dapr-ise entire application and T everywhere, but you can just put Dapr on two different services themselves. You don't have to do it on everything. So it's very incrementally adoptable in terms of how it gets used and in terms of its APIs. Eric Anderson: And it's both developers, if you needed to do this kind of message broker thing, you might reach for IT or platform engineering teams. You find adoption in both paths it sounds like? Mark Fussell: Yes, for certain now because the platform engineering teams go, "Look, I can give you this API, but I can change infrastructure for you and make that adaptable." And then I think what used to happen is we used to get a lot more of the application teams first who adopted it. And that was, I would say if I reached back two, three years ago, they were the majority of people effectively picking up Dapr building into their application, deploying it on top of single instance Kubernetes, that they managed themselves and going down that path. But now with many more organizations having a platform team, which to me is kind of their own PaaS team, as it were you, how do I define my own PaaS for my company, what it's like in terms of particularly running on top of Kubernetes as a hosting platform, but I provide my own DevOps pipeline, my own observability tools, my way of doing security and authentication. How do you fit in with all of this? So that's what a platform team is defining security observability and sort of also resiliency as a whole. And then they bring along Dapr to kind of help the contract to the application team. And that's exactly where it's fitting in today. Eric Anderson: Good. Mark, we're kind of winding down here as we approach time, so if there's anything you wanted to include in this conversation, we haven't, please jump in. But maybe I'll, as you think about that, I'll hit you with one last question here, 25,000 GitHub stars on Dapr. CNCF graduated project. Dapr's accomplished quite a bit, a lot of adoption. Do you have any kind of hacks, any kind of adoption tricks? What do you credit to that growth? Anything aspiring open source managers could use or any tips and tricks for them? Mark Fussell: Well, I mean I think number one is you've got to solve a real problem. And if you solve a real problem, people will love you for it. I think you have to be a little bit patient. I mean, certainly building community and building community is getting other people excited about the technology. How is it that you go out there and show how a open source project can really help solve developers problems or whoever your target audience is and get some people in the community excited by it all so that they start contributing? Yeah, we did that very early on and got very great excitement from the community. Great early contribution. We had many of these components generated by the community and sort of built that. But I mean, I think today it's actually, it does get a lot harder with open source projects just given the number of them that there are. I think that going to a foundation's body like CNCF is useful. I think it helps amplify your message. You've just got to trade that off with the fact that if it isn't a body like that, you don't actually control it in any way. You're giving it to the actual foundation and as much as anything about helping you promote it as you are yourself. But I mean certainly building community and going out there and getting other people excited and doing hackathons, solving a real problem, and just believing generally in open source. Because I think open source has tremendous potential and it has tremendous opportunities today. The challenge, of course, is getting someone to come along and pay you some money for open source. And there's still a lot of companies there who take advantage of open source, but don't necessarily put as much, let's just say either contribution back to it all or let's just say seek to kind of contribute or kind of help the people who are also contributing to open source. So I would also say that if you're a large organization out there using lots of open source, you also have a duty yourself to kind of help support the open source communities and make sure that they're there around for you, because you can't always take, you have to give some giving around these things. And so my message would also be, hey, all companies using open source donate back or contribute back, or even just find companies like ourselves, Diagrid, who are here to make sure we'll keep the open source community going, but in turn we're trying to build a business around all this. And so every open source community does have business entities around it that need kind of continued support and engage them with. Eric Anderson: Mark. Thank you for your contributions. It's like you've taken a 20-year career in Microsoft and given it to all of us in this highly usable Dapr construct. And thanks for coming on the show today. Mark Fussell: Well, thanks for having me. It's been fantastic being here. Eric Anderson: You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.