Agentic Shift in Microservices | Mark Fussell, CEO of Diagrid

Hello and welcome to Infinite Curiosity. This is your host, Pratik Joshi. In each episode of this podcast, we talked to an amazing AI founder or a VC and dive deep into a specific topic. Today we have Mark Fassel on the show. He's the CEO of Diagrid, a developer platform that provides tools and services for building cloud native applications. They've raised 24.2 million from the likes of Amplify and Norvest. He's also the co-creator of Dapper, an open source tool used by 40,000 companies. In today's episode, we dive deep into microservices, open source and what it takes to build a company around that. Mark is fantastic and I'm sure you'll enjoy this one. All right, ready for left off and three and two and one. Let's go! Mark, thank you so much for joining me today. It's fantastic to be here, Pratik. Thank you for having me. Let's start with the fundamentals and even before that, the open source project Dapper, which stands for Distributed Application runtime for people who may not know what problem we're trying to solve when you first built Dapper. Yes. When you look at Dapper, you see today that lots of developers are struggling to build cloud native microservices, Distributed Apps, are named on top of platforms like Kubernetes. The common thing is, as an organization says, Kubernetes is fantastic. It's the best place to run and host our software. Go off and build on top of it all. Kubernetes has got nothing to do with the application itself. It's just our way to host and run pieces of code really. Dapper solves the problem of providing these consistent developer design patterns for common golden paths and applications designed for developers to put together so that they can be productive building their business app. I think it's always good to talk through an example particularly and that is often you build these applications that require communication and messaging or a vendrige and applications. We're sending one message to another. Dapper has a Pub/Sub API inside of it all that allows you to publish messages and subscribe to them. Using that Pub/Sub API, developers can easily build an vendrige and application with messaging and importantly layer that on top of the infrastructure of their choice so it can be on top of any message broker. So this set of APIs, whether it's workflow, whether it's Pub/Sub, whether it's service-to-service communication or secrets and putting them together the common design patterns is the goal of Dapper. And you are the founder of Dapper and it's you're taking Dapper and you're bringing it to the enterprise. Now, I'll be the Dapper as a big community. It's growing. What prompted you to launch Dapper? Yeah, well what we saw was so first, you know, I found it and created Dapper projects while I was working at Microsoft and I spent a many, many years working at Microsoft and saw all of the developers, not an inside Microsoft, but outside struggling with building on these distributed systems platforms. Of course, there were many at the time. There was the likes of message sharing many of these others. So I prompted me and my co-founder to actually create the Dapper project which we started over six years ago and in building that project, you know, became successful. We donated it to the Cloud Native Computing Foundation, the CNCF, where today it's a graduated project actually, which is kind of the most mature, is built a big ecosystem around it all. You know, we know that there's around 40,000 companies actively engaged with using Dapper. And so, you know, in that development, we said, well, wouldn't it be great to drive our own path of innovation ourselves? You can only do so much sometimes inside a large organization. And so we left. We formed Diagrid with the purpose of innovating in this space, particularly, you know, in the space of, you know, microservices being, you know, the de facto way for building these platforms and wanting to also create our own platform for helping developers to build distributed applications based upon Dapper. So that's the premise of Dapper. Can we build a better platform for developers to build these applications using Dapper's Open Source technology? Micro services. We, it's been around for a number of years. And many people, many developers have embraced it. They've shipped applications. And yet, when you launched Dapper in 2019, it grew at 40,000 companies. It's a big community and many, many developers using it. So if you had to point out, why did so many people, you know, last shot or started using Dapper? Like, what's, why, why did that happen? Yeah, I mean, I think there's two driving trends here. In the end, you have to realize that when people talk about microservices and distributed applications, the driving trend is actually the business itself. You know, if you just reflect back 20 years, when everyone was in the client server era and deploying that, it was still, you know, the monolith architecture designer. That's okay, but you know, you had to wait for everyone to link together all your code and ship one engraving binary every six months or a year. And the microservices approach was simply a business saying, look, you get a ship faster. That's it. Break things apart, put network calls between them all release independently, scale independently, created design. And you know, that got boosted by platforms like Kubernetes in the end, achieving all of that. You know, so that was the goal of microservices around it all. And then Dapper project really came down to the fact that, you know, let's just say, the more savvy developers realized that, you know, if they wanted to get a business app out there fast, you know, rebuilding or building their own kind of common design patterns and reinventing the wheel every time wasn't the best used of their time. Just like, you know, you wouldn't build a linked list class inside a language anymore, or, you know, that's sort of a lot of abstraction. So it provided this, you know, level of abstraction that helps developers be productive so that they can hit their business needs, particularly in this design paradigm of distributed applications on microservices, which was the driving force from the business. Now for companies that have a, have an open source, a founding story. And in this case, you have donated, uh, Dapper, so slightly different, but for a second, let's, let's assume that many companies, they start with open source, they commercialize it. How do you advise or guide them to forget about, hey, what ideas should stay free for the community? And what, what will the complete features that you can commercialize and obviously monetize on top of it? Yeah, I think this is probably the one of the hardest questions you could ask. Because so much of it comes down to where you want to draw the line as a company, you know, and there's different things around this. And I think a lot of that question really comes down to licensing in the end. And, you know, the licensing is the key around this all and how you adopt that. If you go the direction and around, we took, which was very much that Dapper gets part of a foundation, it gets adopted with the Apache 2.0 license. That makes it freely available for anyone to modify and maintain and makes it very, very vendor neutral. But then you get, but, you know, the disadvantage of it's it's not directly tied to Diagrid anyway. And so you've got to double down on all your marketing initiatives and everything to, you know, bring that community to know about Diagrid. You know, there's also an open source model as well, where you open source it as a company, but you sort of own all of that in its underneath this single umbrella. And I think that's good. Of course, the obvious danger there is what's the license and connect B pull from you under the rug. And, you know, that's what we've seen a little bit recently with the business source licenses and the change within side some of these other large organizations. For the right reasons, I can understand from their business perspective being out, but people have to sort of be prepared for that in some way. So I think that it's a hard choice in many ways. I think if I was to go down this direction, you know, I think that both of them have their pros and cons. Being inside a foundation allows you to take advantage of all the richness of that foundation and being called our independence, but, you know, you have to double down your marketing. So yeah, it's, it's not the easiest of walls, but I would say certainly the open source is a direction that's very beneficial because you can really get community to help around you and promote that. And I think that's the most important part of this. For companies that are already running Dapper on their own using internal teams, as they keep using it and scaling like what headaches will they encounter? And at what point will they say, okay, we we got to get to like diagram because this is too much of a hassle. Yeah, I mean, I think what happens is that, you know, the way I look at it all is that open source is extremely beneficial from a productivity side of the company. But I mean, there's this, there's this tricky line of where, you know, that company can't become, let's just say, deeply engaged and kind of knowledgeable about every piece of open source technology they adopt. So they have to accept at some point that when it becomes core to their infrastructure that, you know, they, well, either they employ people full time who are going to work on the project and you don't see that very much or they come to a company like Diagrid who basically, you know, takes on all of the risk for them as it were or I should say, do risks are projects, I should say, such that, you know, they can be successful in what they're trying to achieve. Getting to benefits of, you know, a big open source ecosystem, but sometimes, you know, no code is perfect. You know, there's always bugs, there's always issues. There's always integration things with your particular environment. There's continuing your future developments, you know, anything that wants to live and survive has to be maintained. And so, you know, when it becomes core, it's very important to come to come to like Diagrid because, you know, where the primary maintainers of the project and where they're there to help the companies be successful without them having to necessarily gain all the knowledge themselves, but benefit from the acceleration and the adoption and the community that they get from from DAPR itself. There's a trade off both ways and, you know, we really welcome and, you know, love all those companies that come to us because that helps us maintain and grow them open source projects. So, you know, we love them when they do come to us because, you know, it builds the bigger ecosystem. And the product offering itself, the this conductor, this catalyst, and I'm sure there are many other features. So, the average customer, like what, what aspect or what feature do they rely on the most? Or rather, that's the one, like, one thing they're like, hey, this is the main key reason why we use DAPR and obviously why we come to Diagrid. Yeah, and I'll bring that down in two ways. So, you know, in the open tools projects, DAPR is a set of APIs. The ones that we see by far the biggest adoption are messaging between things, which is publish and subscribe based on message, brokers, and providing that. And increasingly right now, workflow, I know, don't know how familiar work flow, but, you know, workflow is allowed you to do effectively durable execution. You know, you could call this service, call that service, call another one here. If your process fails and dies, it remembers all of the previous state of how it was running, the set of sequences it went through can recover on another machine and sort of, seamlessly keep running. So if you've got a state machine and you've called these things, that becomes a very needed piece of business code. And it's a very hard piece of code to write and people think they can do it and then it gets horribly wrong. So, the workflow, the pubs of APIs are by far the biggest drivers. And interestingly now, we're also seeing a lot of people bring in language models as well. So I think the combination of language models into code and what that looks like is important. And so what we've done is that's the new resource project that people can run at themselves and host on Kubernetes. Or we have our own platform player diagram called Catalyst, which is where we host and run that before you, like a server, many way inside your infrastructure, so that you don't have to host and run it yourself. And that increasingly is sort of as important to use for customers and ease of adoption. Let's move to our company building. Now, you've raised venture capital and now you're able to team. So, start off, what's the, what's the north star metric for the company? Obviously revenue is the easy one everyone wants that, but just to break it down in a little bit more, what's your north star metric and what do you rally your team around? Yeah. So, I mean, we have to rally value around growth, as it were, and revenue because that's the driving factor so you can get to the next levels of investment around these things. But I think we also strongly value as well growth of community. That's a huge thing and growing the project. And with that goes sort of contributors and things like this. But also, I think, growth of innovation. We want to show that we've created very novel and particularly driving in this world now with AI being a massive disruptor. So we recognize that AI has been provided a lot to developer tooling, but also is affecting a lot about this backend systems about how they're being developed. So we also would have been seen as an innovative company using AI to build backend systems and how they integrate with these language models, particularly in this world of agentic applications. So I'd say a key driver for us is showing innovation, what that's like, growing community, and bringing those together of course, to create revenue so that we can get to next level of investment. And when you think about infrastructure and then dev tools companies pricing becomes a very interesting topic. It's evolving fast AI and LLM are changing a lot. So how do you think about pricing for the hybrid and also more broadly, how should infrastructure companies or dev tools companies think about monetization and pricing mechanics? Yeah, that's interesting question. I think there's been a little shift, at least we went through a shift of how you position your products. We very much, if you go back five years producing SaaS services, it's a very much strong trend. But as an infrastructure team building a SaaS service where you build a worldwide API, so people use, it's a lot of investment and a lot of time. And increasingly, what's happened over the last, there's been a big shift to the cloud, but there's also been a big shift when you used a cloud that you still want to maintain your own secure boundaries around it all. And so the enterprises today are very, very hesitant on data privacy or they want data privacy, data locality, control around where they have their network boundaries. So even though they made deploy on a cloud, it's very key for them that they have, the dependencies on external SaaS services from their security are hugely skeptical around these things. So that shifted us a lot more towards being enterprise sales driven and building a product that focused on deploying into customers infrastructure and fixably pricing much more in the enterprise sales space as opposed to trying to price lots and lots of small companies building on a SaaS. And it's not that SaaS is not achievable, it's just I think that that's sometimes a harder market to grow initially, where targeting some of these enterprises with a deployment of a key piece of infrastructure that they want and they're willing to pay for is certainly a model that we've adopted embraced a lot more recently. And for startups building in the sector, there's always the big gravitational pull of hey, if the customer is already inside Azure AWS, not that those tools are better, but it's just easier to stay inside the ecosystem and use those tools. So for startups building products here, what's the simplest pitch they can make to a customer to for them to consider? They take the pain of using our product and you'll see how much you know that you love us as opposed to just doing the lazy thing of just sticking with them, what are tools unavailable in the big cloud? That's a tricky question. Well, I think you can have to solve a customer problem as much as anything, yes, and we really clear on the problem space that you're solving. In our case, it was developer productivity, making sure that if you took DAPA, you can accelerate and demotratively show that side by side is less code to maintain, less code to develop, and your acceleration time is 30, 40%. So I think like everything, you really get a get back to the customer pain points and be really clear about them and then show the value prop, whether that's less code or faster development time or of course, these are the ones that save me money or make me more secure. I mean, in the end, startups are usually successful because people know they don't want to lose their job because of this, they don't want to lose, or they want to make money or all you want to, and the productivity side of these things is kind of a little bit of a harder one of us sell, but I think you can be very clear about it as long as you show that there's value benefits around this all. And building sort of, I mean, I think the first five customers are always the hardest. And can you get those first five customers? That's the hardest goal of a startup to get the case studies, to get the momentum, to get the flywheel going. I think that's where we've been successful ourselves. I think that's where you know, you was a startup that really have to focus on as much as you possibly can. Between the big cloud providers or other startups versus internal tools, who do you find yourself competing with the most? Yeah, I mean, I do think the common way that you see is that you see the big cloud sort of say, look, AWS says, you know, use RSDK to integrate with our services, and of course they want that because they want that sort of actual locking. And there are many other players that we compete against, particularly in the workflow space, and there are many other workflow engines as well. And inside the communications space in terms of other service meshes, also sort of overlap with that. But I think an important play here in many ways is that a lot of the organizations have seen that there's been this rise of platform engineering. And platform engineering is all about how platforms inside company service, many application teams. And in that role that they play, they realize that they can't be locked into a single platform themselves. And they've got to be a little bit more flexible in that. And so, a data plays a crucial role in that it provides a sort of consistent sort of APIs which the platform team can swap out their underlying infrastructure. They can have a Pub/Sub API, but they can use AWS's SNS and then switch to Google GCP or Azure Service Bus within hours. And so rise of platform engineering within side organizations and the need to have multi-cloud and abstraction over them and have a flexibility of choice is something that they've discovering a lot now. And I think it's probably the most underrepresented thing in that flexibility of choice and evolution of code that platform engineering teams often miss because they say, "Oh, just use the SDK and use it all." But once you have that lock in, there's just sort of disaster for the applications if they need to change. The world of microservices keeps evolving and so many changes coming in. What's the one big change you think is coming that we are not talking about enough? Well, I mean, the one big change, I think that we are talking about enough that is going to happen. And that's this agenteic application and what they do. And this is very interesting because there's a lot of new terminology that's being created around the concept of tools and memory and how you put these agents together when actually they are like many things we have existing things already in terms of terms, memory is merely states and how you retain all that and tools is really just function calling that existed already. And so I think that what's happened is that you see this blending together now of traditional procedural code and using models and particularly language models to solve particular problems and increasingly what's happened is those language models are going to be more and more involved in terms of the decision making and their dynamics and what's happening inside here. But I don't think we should escape the fact that I think many of these enterprise frameworks that have been built or should say many of these agenteic frameworks that have been built are still very new and not very mature enough for running enterprise workloads. And this is where going back to the DAPR again we've built an agenteic framework deeply in top of all the DAPR APIs using workflow, using state, using the conversation API, using for example all of its state primitives to build something that's very durable, reliable, long running and this change of this agenteic applications as a form of distributed application or microservices and the huge impact is going to have because effectively they're going to replace small pieces of work let's just say from humans is going to happen across every industry. In addition to the agenteic shift, how else do you think the AI boom will shape the way people build around microservices? Well I see that I mean I think you're going to use lots of different types of models the multi model world of those things is going to affect things a lot. I mean it's clearly much easier to solve a problem with a vision model than it is to try to write procedural code with this and you'll see a more and more of a replacement of some of the traditional pieces of code that you wrote say procedurally with models instead and those models will come are certainly becoming more and more reactive as well. So I think the reactive element of these things where the decision making is pushed down to the model is going to change things rather than trying to put that decision into code itself and can you let a model make decision. It's also going to come down a lot to date people's data and in the end all these models are really as good as that data so I think you'll also see a lot more people build their own localized specific models on their local data that allows them to be very specialized and specific in what they do and then just blend that into existing code. So there's going to be a great slow migration of incorporating your data models, your specific language models, these reactive models into existing applications that have been there for maybe decades in order to blend the two together. What new capability are you most excited to add in the in the next 12 months like what is the team working on or are you excited about? Yes, I mean we have a whole roadmap ahead of us. I think that this the workflow side of these things where you've reduced long running durable execution and how we continue to refine that is exciting. I see you know we're introducing new forms of how you can store state into unstructured databases and sort of no-sequel models around all that storing state there today. I will go back and talk about the agent excited with those things still because we introduced a language conversation API that allows you to abstract and talk way to any underlying LLM what that looks like and I think we'll see more of those sort of APIs for talking to other types of models emerge. So for me you know the combination of seeing the community contribute more APIs to allow you to be more productive about how you build your apps and then how that gets blended in with the different language models particularly is every exciting space to be in and you know it's seeing and seeing particularly how the decision making of these language models will actually affect you know how developers build applications and change the backend systems ourselves. One other thing I should add is that we've done this really cool piece of code where we're trying to we're taking diagrams that you draw pictures and sort of generate the application from them using AI in order to generate those systems. So how could you do fast POC development from a systems level sketch greatly accelerating your time to getting things up and running is also I think a a core place to develop new technology. Earlier you mentioned how the first five customers that usually you know it's the hardest. So looking back with the benefit of hindsight if you're guiding somebody new what learnings would you like to share like what worked and also if you had to do it again what would you do differently. Yes I mean I we I was fortunate in that we kind of had built some good relationships so many relationships working on Microsoft with lots of existing customers and you had the time it took you know for a couple of years to kind of mature a dapper enough to get it to a point that you knew what those customers were doing and how they were developing it all and I think that any you know start up that would be producing their own thing like their own run time from scratch would have to sort of accept that there's sort of a two-year learning period around these things that they'd have to develop these things. So I think that was the fortunate thing having that time at the beginning to iterate and learn and test and find your customers for example like Zeiss which is a big lens manufacturer with one of our early customers you know they deployed and ran a worldwide order processing system for all their lens manufacturing and we just learned a lot about how they built applications on top of Kubernetes what it was like their pain points. So I mean it gets back down to observing customers finding their pain points and building relationships and community and it's it's tough I mean you just got to find your niche area and be massively focused on pain points customers you know and basically getting getting your message out there such that you know people hear you know how you're innovating in that space. I say our path was very much because of the success of an open source projects and continue to accelerate that you know what I would say that we'd learn is that you know you would sort of focus on building some communities in particular and getting a lot of advocates behind you so that they can sort of be the voice of you and I think if you can get other people to be the voice of your projects and accelerate that I think that's the best advice. Amazing with that we're at the rapid-fire round I'll ask the cities of questions and would love to hear your answers in now 15 seconds or less. Ready? Yes perfect question number one what's your favorite book? Oh well I think if you look it from a business perspective I've always admired crossing the chasm that one I just love that book and it just tells you what you should achieve and also I actually like good to great if it's another book I would also if it was a fun reading book I think anything from Ursula Le Guin and in sci-fi space yeah particularly the dispossessed is like the ultimate choice. Amazing the left kind of darkness by my heart it's some of my all-time favorites it's just a wonderful writer I the next question which historical figure do you admire most and why? Well I love all of the 20th century early world are done by all of the great scientists in quantum mechanics I think Shoddend Boer, Einstein and hearing about the effect that all of a sudden they went from this Newtonian world this quantum world was just incredible so I recently read a book called Waves an Impossible Sea that tells about that story another great book and so I would say Edwin Shoddend Jad particularly when he wrote a paper about what is life and tying together that with how he predicted effectively DNA in advance is probably one of the greatest jumps in mental even the capacity I've ever seen. Incredible next question what has been and important but overlooked technology trend in the last 12 months? Oh wow I probably would say you know platform engineering is still an important trend both wouldn't necessarily have been overlooked but I would say in platform engineering the role that you have to have to make sure that there's the right level of abstraction on top of your platform so that you don't tightly couple things together but I would also say that Generally, security as well is something that you have to really focus on in your app. So I would say, if you look at a lot of these emerging technologies, even in Engine space, they're very security light. And I think there's going to be a lot of problems there. What's the one thing about open source that most people don't get? Oh, I would say that going back to the sort of the license side of things, check your license and what it's like. Well, I would say that I'd also say, you know, open source isn't free. Yes, in the sense of people think it's free and unfortunately that attitude prevails too much. And I think you should treat open source not as free, but that it's freeing you up your time, but you should find a way of either contributing back or supporting the companies that do it. What separates great infrastructure products from the merely good ones? The making sure they solve the right problem at the right level of abstraction. I think that abstractions are important and getting a right abstraction to make sure that you solve a real issue and a really hard problem. You have to focus on a hard problem. You have to say, you have to be able to do a pitch where you say, these are the five hard problems I've solved. And if you solve those five problems, you know, this is how you have success. So it's purely pointing to the fact that you've solved a fundamental problem. What have you changed your mind on recently? Probably over the use of AI as a tool and what it's like, you know, a year ago I was pretty much as a skeptic around these things a little bit more. Now I think the tools are getting very powerful. And I think we have to be also very attentive to how we use them actually. I think there's a lot of responsibility for this. So I certainly changed my opinion on how AI is going to be used inside back in development. And I also changed my mind that fact that we should be very careful about how these things get applied so that we don't disrupt society too much. What's the wildest AI prediction for the next 12 months? Well I think that this rise having seen these real world models where people can take a set of photos and then create a world out of it all. And as they get better and better at some point, you're not going to tell the other difference between reality and what reality is in terms of what it is. And I think if you stretch forward five years from now and games are entirely built with real world models entirely and how they're running, I think it's both an amazing and scary future. Alright, final question. What's your number one advice to founders who are starting out today? Find a great partner that you believe in and make sure that you have a very good relationship with them and your focus on really finding that passion that couples with a pain point. And if you could combine your knowledge of a particular pain point area whether that's in software or hardware or any other industry for that matter, and really understand how you can do that with a great partnership. Someone you'll have amazing fun time because there's nothing better than driving your own future and your own direction getting forward. Amazing. Mark, this has been a wonderful episode. Love diving deep into all the all the experience you've had, open source and now the company building. So thank you so much for coming onto the show. Well, thank you for having me. It's been wonderful being here. What a brilliant discussion on open source, AI, agents and open source company building. Thanks to Mark for coming onto the show. You can visit infinitecuriositypod.com to listen to all the other episodes. Thanks again for tuning in. I'll see you soon.