Agentic Shift in Microservices | Mark Fussell, CEO of Diagrid

Mark Fussell is the CEO of Diagrid, a developer platform that provides tools and services for building cloud native applications. They've raised $24.2M from Amplify and Norwest. He is also the co-creator of Dapr, an open source tool used by 40,000 companies. 

Mark's favorite books: 
- Crossing the Chasm (Author: Geoffrey A. Moore)
- Good to Great (Author: Jim Collins)
- The Dispossessed (Author: Ursula K. Le Guin) 

(00:01) Opening and Introduction
(00:09) The Origins of Dapr: Solving Developer Pain
(01:53) Why Launch Diagrid After Building Dapr at Microsoft
(03:36) Why Dapr Gained Traction Among Developers
(05:30) Open Source Commercialization: What to Charge For
(07:51) When Do Companies Turn to Diagrid for Help?
(09:53) Key Features: PubSub, Workflow, and Catalyst
(11:48) North Star Metrics and Innovation Philosophy
(13:17) Pricing Strategy for Infra and Dev Tools
(15:28) Competing Against Hyperscalers Like AWS & Azure
(17:32) Who Diagrid Competes With and Role of Platform Engineering
(19:29) The Agentic Shift in Microservices
(21:28) How AI Is Changing Microservices Design
(22:59) What's Coming Next at Diagrid: Roadmap and AI Features
(24:51) Lessons from the First Five Customers
(26:59) Rapid Fire Round

--------
Where to find Mark Fussell: 

LinkedIn: https://www.linkedin.com/in/mfussell/

--------
Where to find Prateek Joshi: 

Newsletter: https://prateekjoshi.substack.com 
Website: https://prateekj.com 
LinkedIn: https://www.linkedin.com/in/prateek-joshi-infinite 
X: https://x.com/prateekvjoshi 

Transcript

Prateek Joshi (00:01.715)
Mark, thank you so much for joining me today.

Mark (00:05.07)
It's fantastic to be here Pratik. Thank you for having me.

Prateek Joshi (00:09.033)
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 were you trying to solve when you first built Dapper?

Mark (00:25.4)
Yes. When you look at DAPA, you see today that lots of developers are struggling to build cloud native microservices, distributed apps as they're named on top of platforms like Kubernetes. mean, 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. But Kubernetes has got nothing to do with the application itself. It's just a way to host and run pieces of code, really.

And so Dapr solves the problem of providing these consistent developer design patterns for, let's just say, common golden paths in application design for developers to put together so that they can be productive building their business app. And I think it's always good to talk through an example particularly, and that is, know, often you build these applications that require communication and messaging or event-driven applications, you're sending one message to another. And so Dapr has a...

PubSub API inside it all that allows you to publish messages and subscribe to them. And using that PubSub API, developers can easily build say an event driven 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 PubSub, whether it's service to service communication or secrets and putting them together with common design patterns is the goal of that.

Prateek Joshi (01:53.125)
and you are the founder of Diagrid and 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 Diagrid?

Mark (02:11.778)
Yeah, well, what we saw was, so first, you know, I founded and created DAPA project while I was working at Microsoft and I spent many, many years working at Microsoft and saw all of the developers, not only 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 Mesosphere and many of these others. So that prompted me and my co-founder to actually create the DAPA 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. It's built a big ecosystem around it all. We know that there's around 40,000 companies actively engaged with using DAPM. And so 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 in the space of microservices being 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 Dapr. So that's the premise of Dapr. Can we build a better platform for developers to build these applications using Dapr as the open source technology?

Prateek Joshi (03:35.977)
microservices. It's been around for a number of years, and many people, many developers have embraced it, have shipped applications. And yet, when you launched Dapper in 2019, it grew at 40,000 companies. It's a big community, and many, developers using it. So if you had to point out, why did so many people latch onto it or started using Dapper? Why? Why did that happen?

Mark (04:04.238)
Yeah, I mean, 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. If you just reflect back 20 years when everyone was in the client server era and deploying that, it was still the monolith architecture designer. That's okay, but you had to wait for everyone to link together all your code and ship one great big binary every six months or a year.

And the microservices approach was simply a business saying, look, you got to ship faster. That's it. Break things apart, put network calls between them all, release independently, scale independently, create a design. And that got boosted by platforms like Kubernetes in the end achieving all of that. So that was the goal of microservices around it all. And then the Apple project really came down to the fact that, let's just say the more savvy developers realized that if they wanted to get a business app out there fast,

rebuilding or building their own kind of common design patterns and reinventing the wheel every time wasn't the best use of their time. Just like, you you wouldn't build a linked list class inside a language anymore, or, you know, that sort of level 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 or microservices, which was the driving force from the business.

Prateek Joshi (05:29.991)
for companies that have an open source founding story and in this case you have donated dappers are slightly different but for a second let's assume that many companies they start with open source they commercialize that how do you advise or guide them to figure out hey what ideas should stay free for the community and what will become paid features that you can commercialize and obviously monetize on top of that.

Mark (05:57.014)
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 the route we took, which was very much that DAPA gets part of a foundation, it gets adopted with the Apache 2.0 license.

Prateek Joshi (06:01.449)
Yeah.

Mark (06:25.78)
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 not directly tied to Diagrid anyway. And so you've got to do double down on all your marketing initiatives and everything to 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 and it's underneath a single umbrella. And I think that's good.

Of course, the obvious dangers there is what's the license and can it be pulled 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 with inside some of these other large organizations. For the right reasons, I can understand from their business perspective, 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 by independence, but you have to double down on your marketing. yeah, it's not the easiest of worlds, 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.

Prateek Joshi (07:50.751)
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 gotta get to like the aggregate because this is too much of a hassle.

Mark (08:09.986)
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 takes on all of the risk for them as it were, I should say risks, they de-risk their projects, I should say, such that they can be successful in what they're trying to achieve, get the benefits of a big open source ecosystem. But sometimes no code is perfect. There's always bugs, there's always issues, there's always

integration things with your particular environment. There's continuing feature development. 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 companies like Diagrid because, we're the primary maintainers of the project and we'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 DAPER itself.

So it's a trade off both ways and we really welcome and love all those companies that come to us because that helps us maintain and grow them open source projects. So we love them when they do come to us because it builds the bigger ecosystem.

Prateek Joshi (09:53.255)
And the product offering itself, there's Conductor, there's Catalyst, and I'm sure there many other features. So the average customer, what aspect or what feature do they rely on the most? Or rather, that's the one thing, they're like, hey, this is the main key reason why we use Dapper and obviously why we come to Dynadrid.

Mark (10:16.622)
Yeah, and I'll break that down in two ways. So, you know, in the open source 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 don't know how familiar you are workflow, but you know, workflow is allowing 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 PubSub 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 a new resource project that people can run it themselves and host on Kubernetes. Or we have our own platform player diagram called Catalyst, which is where we host and run DAPA for you, like a server, many ways inside your infrastructure so that you don't have to host and run it yourself. And that increasingly sort of is important to ease of...

use of for customers and ease of adoption.

Prateek Joshi (11:47.359)
Let's move to company building. Now you've raised venture capital and you've built a team. To start off, what's the North Star metric for the company? Obviously, revenue is the easy one. Everyone wants that. But just to break it down even a little bit more, what's your North Star metric and what do you rally your team around?

Mark (12:08.898)
Yeah, so I mean, we have to rally around kind of growth as it were and revenue because that's the driving factor to 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 kind of growing the project. And with that goes sort of contributors and things like this. But also I think growth of innovation. We wanna 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 is being provided a lot to developer toolings, but also it's affecting a lot about this backend systems, about how they're being developed. So we will sort of be 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 two together of course to create revenue so that we can get to the next level of investment.

Prateek Joshi (13:16.893)
And when you think about infra and dev tools companies, pricing becomes a very interesting topic. It's evolving fast. AI and LLMs are changing a lot. So how do you think about pricing for by grid? And also more broadly, how should infra companies or dev tools companies think about monetization and pricing mechanics?

Mark (13:41.742)
Yeah, that's an interesting question. And 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, it was a strong trend. But as an infrastructure team, building a SaaS service where you build a worldwide set of APIs that people use, it's a lot of investment and a lot of time. And increasingly,

What's happened over the last, know, there's been a big shift to the cloud, but there's also been a big shift, you know, when you use the cloud that you still want to maintain your own secure boundaries around it all. And so the enterprises today are very, very, let's just say, hesitant on data privacy or they want data privacy, data locality, control around where they have their network boundaries. So even though they may deploy on a cloud, it's very key for them that they have.

you know, the dependencies on external SaaS services from their security are hugely kind of 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 effectively 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, think that

you know, that's sometimes a market to grow initially, whereas, you know, targeting some of these enterprises with a deployment of a key piece of infrastructure that they want and they're willing to pay for, you know, it's certainly a model that we've adopted and embraced a lot more recently.

Prateek Joshi (15:27.935)
For startups building in this sector, there's always the big gravitational pull of, if the customer is already inside Azure or 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 for them to consider?

take the pain of using our product and you'll see how much you'll love us as opposed to just doing the lazy thing of just sticking with whatever tools are available in the Bitcoin.

Mark (16:04.942)
Um, that's a tricky question. Um, well, I think you kind of have to solve a customer problem as much as anything. Yes. And be really clear on the problem space that you're solving. You're in our case, it was developer productivity, making sure that if you took DAPA, you can accelerate and demitrable show that, you know, side by side is less code to maintain less code to develop and your acceleration time is 30, 40%. So I think.

Like everything, really get to 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, the easiest ones is save me money or make me more secure. I mean, in the end, startups are usually successful because people, 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.

productivity side of these things is kind of a little bit of a harder one of a 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 always the hardest and you know, 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, you know, been successful ourselves. I think that's where.

you as a startup really have to focus on as much as you possibly can.

Prateek Joshi (17:31.913)
between the big cloud providers versus other startups versus internal tools, like who do you find yourself competing with the most?

Mark (17:42.764)
Yeah, I mean, I do think the common way that you see is that you see the big clouds 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 lock-in. And there are many other players that we compete against, particularly in the workflow space. And there are many other workflow engines as well. you know, inside the...

communication space in terms of other service meshes also 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 companies serve as 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. so Dapper plays this crucial role in that it provides a sort of consistent set of APIs, which the platform team can swap out that underlying infrastructure. They can have a PubSub 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 with inside organizations and the need to have multi-cloud and abstraction over them and have flexibility of choice is something that

they're 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, 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.

Prateek Joshi (19:28.629)
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?

Mark (19:40.706)
Well, I mean, the one big change I think that we are talking about enough that is going to happen and that's this agentic 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, know, memory is merely state and how you retain all that.

And tools is really just function calling that's 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 sort of the decision-making and the dynamics of 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 I should say many of these agentic 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 Dapr again, we've built an agentic 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. this change of this agentic applications as a form of distributed application or microservices, and the huge impact is going to have because effectively they're going to replace, you know, small pieces of work, let's just say from humans is going to happen across every industry.

Prateek Joshi (21:28.031)
In addition to the agent tech shift, how else do you think the AI boom will shape the way people build around microservices?

Mark (21:38.574)
Well, I see that I mean, I think you're going to use lots of different types of models. The multimodal 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 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, you know, in the end, all these models are only 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.

Prateek Joshi (22:59.221)
What new capability are you most excited to add in the next 12 months? Like what is the team working on or what are you excited about?

Mark (23:08.3)
Yes, I mean, we have a whole roadmap ahead of us. I think that, you know, 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 NoSQL models around all that storing state there today. I will go back and talk about the agentic side of those things still because we introduced

a language conversation API that allows you to abstract and talk away 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 a very exciting space to be in.

and seeing particularly how the decision making of these language models will actually affect 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 taking diagrams that you draw, pictures and sort of generate the application from them using AI in order to generate those systems.

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 cool place to develop new technology.

Prateek Joshi (24:50.951)
Earlier you mentioned how the first five customers are usually, it's the hardest. So looking back with the benefit of hindsight, if you were 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?

Mark (25:10.008)
Yes, I mean, I was fortunate in that we kind of had built some good relationships, so many relationships working at Microsoft with lots of existing customers and had the time it took for a couple of years to kind of mature DAPR 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 startup that would be producing their own thing, like their own runtime from scratch would have to sort of accept that there's sort of a...

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, you know, customers, for example, like Zeiss, which is a big lens manufacturer, was 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 tough. I mean, you've just got to find your niche area and be massively focused on pain points, customers, and basically getting your message out there such that people hear how you're innovating in that space.

I'd say our path was very much because of the success for open source projects and continuing to accelerate that. What I would say that we'd learn is that 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.

Prateek Joshi (26:59.861)
With that, we are at the rapid fire round. I'll ask a series of questions and would love to hear your answers in 15 seconds or less. You ready? Perfect. Question number one. What's your favorite book?

Mark (27:09.421)
Yes.

Mark (27:15.54)
well, I think if you look at it from a business perspective, I've always admired Crossing the Chasm from that one. I just love that book. It just tells you what you should achieve. also, I actually like Good to Great. If it's another book, would also, if it was a fun reading book, I think anything from Ursula Le Guin and in sci-fi space, and particularly The Dispossessed is like the ultimate choice.

Prateek Joshi (27:34.389)
Yeah.

Amazing. The Left Hand of Darkness by her is some of my all-time favorites. It's just a wonderful writer. I agree. Next question. Which historical figure do you admire most and why?

Mark (27:46.477)
Yes.

Mark (27:53.73)
Well, I love all of the 20th century early world done by all of the great scientists in quantum mechanics. I think Schrodinger, Bohr, Einstein and hearing about the fact that all of a sudden they went from this Newtonian world to this quantum world was just incredible. So I recently read a book called Waves and Impossible Sea that tells about that story, another great book. And so I would say Edward Schrodinger, particularly when he wrote a paper about what is life.

Prateek Joshi (28:02.515)
Hmm.

Mark (28:22.338)
And tying together that with how he predicted effectively DNA in advance is probably one of the greatest jumps in mental capacity I've ever seen.

Prateek Joshi (28:34.355)
Incredible. Next question. What has been an important but overlooked technology trend in the last 12 months?

Mark (28:44.42)
wow. Probably I would say, platform engineering is still an important trend, it's 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. And so I would say,

If you look at a lot of these emerging technologies, even in agentic space, they're very security light. I think there's going to be a lot of problems there.

Prateek Joshi (29:22.601)
What's the one thing about open source that most people don't get?

Mark (29:29.358)
I would say that...

Going back to the sort of the license side of things, check your license and what it's like. I would say that I'd also say, 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.

Prateek Joshi (30:02.493)
What separates great infra products from the merely good ones?

Mark (30:08.876)
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 able to do a pitch where you say, these are the five hard problems I've solved. And if you solve those five problems, this is how you'll have success. So it's purely pointing to the fact that you've

solve the fundamental problem.

Prateek Joshi (30:41.011)
What have you changed your mind on recently?

Mark (30:45.454)
probably over the use of AI as a tool and what it's like. 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 backend 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.

Prateek Joshi (31:25.907)
What's your wildest AI prediction for the next 12 months?

Mark (31:30.764)
Well, I think that this rise of, and you've 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 be able to tell the 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.

Prateek Joshi (32:00.629)
That final question, what's your number one advice to founders who are starting out today?

Mark (32:06.702)
Find a great partner that you believe in and make sure that you have a very good relationship with them. And 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 with someone, you'll have amazing fun time because there's nothing better than driving your own future and your own direction going forward.

Prateek Joshi (32:45.461)
Mark, this has been a wonderful episode. Love diving deep into all the experiences you've had, the open source and now the company building. So thank you so much for coming onto the show.

Mark (32:56.382)
Thank you for having me. It's been wonderful being here.

Prateek Joshi (32:58.973)
Give me one.