Simplifying Microservices: The Rise of Dapr Explained with Yaron Schneider

This is Textron tv. Hey guys, thanks for the throw. We're here with Yan Schneider with CTO for DIA Grid, and we're talking about Dapper, which is a kind of a, a standard set of run times for making things a lot more efficient for developers.

That's kind of gaining a lot of momentum, but it's not clear to me that everybody's aware. I mean, I think people are talking about it, but it's certainly not driving the same level of headlines as some other things out there, but I think it's starting to have a significant impact. You're welcome to the show.

Thank you so much for having me, Mike, For those who are, uh, uninformed, you know, what is the history of Dapper? We know it came outta Microsoft. Um, what's the backstory and, and, and where are we now?

Yeah, so the backstory is that it's an open source project that's part of CNCF. Um, it's been in c CF since, um, 2021 and, um, it started back at Microsoft in 2019. I was working at Microsoft at the time under Vic, who's the CTO for Microsoft Azure, the Azure Cloud.

Um, and me and my team, we were tasked with finding gaps in, um, user experience for cloud native developers. You know, Kubernetes came along and all of these networking primitives came along and monitoring stacks and all of these low level stuff that really catered to infrastructure teams. But developers were really phase two deal with the complexities that was, that caused to them because of this sprawled tools and technologies.

Um, and so what we recognized was that application developers who we call the silent majority of the cloud native space, were just left to, uh, fend these complexities on their own and they didn't have the tools they needed. Um, you know, to do things like sort of discovery and managing state at scale and creating, uh, reliable fault tolerant workflows and pub sub aven driven architectures and all of that, uh, stuff that developers look to deal with day in, day out. And so this is how Dapper came as a set of APIs for developers to focus on their business logic and not on their infrastructure, uh, concern.

So dapper really takes the pain away from interacting with your infrastructure of choice. Most of the tools that, you know, we see, um, that's being talked about most, you know, things like Terraform and, and others are really about provisioning, uh, infrastructure monitoring infrastructure. And dapper really fills the gap when it comes to interacting with that infrastructure in a secure and reliable way, and also making it very easy for developers to build multi-cloud, uh, multi-platform applications.

So who wakes up in the morning and discovers dapper? Is it the developers who are presented with this kinda low level Kubernetes infrastructure that they're not all that fond of? Or is it the Kubernetes slash platform engineering team realizing that there's a a gap here?

That's an amazing question. I'll tell you why. Um, in the first three years of Dapper, it was definitely the applications developer, um, the application developers doing the discovery.

Uh, they needed a, a way to basically create vendor driven architectures or manage stay at scale or do service discovery. They would discover dapper, they would see the APIs and they would go, oh, this solves my particular problem. Um, and this is basically the bottoms up adoption pattern that we saw for Dapper when it just got started.

But in the past year and a half, I would say we're seeing more and more platform teams and architects, uh, coming into Adopt Dapper even before their application developers have started adopting it. And this is because platform engineering today is more focused on APIs for developers to be able to consume provision and monitor infrastructure. But when it comes to interacting with that infrastructure, it's still the Wild West.

Developers can do things wrong in any number of ways, and Dapper really fills that gap for platform engineering about providing them the golden paths for how do you interact with those infrastructure services that so far the platform team have been focused on, uh, creating provisioning and monitoring. And if you look at the CNCF white paper study that came up last year, they actually, from the platform engineering group, they have a, a white, uh, case study, oh, sorry, white paper, uh, with a case study that showcases how dapper can be used, um, as a critical tool within the platform engineering space. So yeah, I highly recommend everyone to look at that white paper published by CCF F Microsoft Build was just recently an event that, um, every developer who's ever been in a Microsoft space knows something about, and they were talking about dapper as well.

But, um, has dapper grown well beyond its original kind of Microsoft centric, uh, architecture? Yes, I, I would wanna say that it has, um, we at DIA Grid are seeing a lot of, uh, AWS users and GCP users too. Um, adopting Dapper Dapper had an interesting adoption, uh, take, you know, from the get go.

It was adopted by Fortune 2000 Tech Savvy Enterprises making use of it, where some other cloud Native Tech really started with, you know, some web scale startup based companies. Um, and these types of companies are much more lenient when it comes to listing themselves as public adopters. Unfortunately, uh, you know, the major enterprise that they're running, DRA and AWS and GCP beyond Azure, um, are doing so.

And, and that's great, but we haven't been as successful in, you know, getting them to, to at least as public adopters. But, um, the usage is definitely there. And, you know, you can also see huge cloud providers like Alibaba Cloud who have, um, actually released posts showcasing how they build, uh, all of their internal, uh, f infrastructure on top of dapper.

You see them taking advantage of it. And, um, yeah, dapper is definitely making its way beyond the Microsoft ecosystem. Do you think we'll see a lot more cloud native applications being built and deployed?

'cause I'm asking the question because going back to your earlier thing, um, it feels like Kubernetes was kind of like, you know, a platform built by engineers for other engineers, and they kind of forgot about the developer who was gonna be presented with this thing. And so, you know, are we, are we plugging a hole here that's been kind of hold in back that ing, which we actually build and deploy cloud native applications? Oh, definitely.

I think, you know, I, I was at BUILD this last week and I've talked to so many developers who basically went, you know, my biggest pain point right now is figure out how do I transition from an on-premises environment to Kubernetes. But with all of the sprawl that we're seeing in, in, you know, all of the tooling we need or being told we need to adopt just to make Kubernetes attack, that we can, you know, adopt securely, um, and efficiently within our organization, that that makes us rethink this. And we're basically pushing off the modernization of our systems because of the complexity of Kubernetes.

Um, and a lot of these developers while they can look at dapper like, okay, well this is gonna help us atton, um, because now we don't have to worry about, uh, so many things, um, as we would've needed to if we didn't adopt dapper, All right? Because otherwise I have to go get a whole platform engineering team that kind of manage everything. And then if I do that, it kind of defeated the purpose of having DevOps in the first place, right?

'cause it's kind of a, a push pull at some point. The developer just wants everybody to get outta the way. Yes, for sure.

And this is what, what the to do, and for the platform engineers to offer the developers' way to interact with the infrastructure, um, and know that it's basically best practices in Golden Pass right out of the box. And so they don't need to, uh, safeguard everything that developers do. All right.

So where does Dapper go from here? What's next? Well, we're extending our APIs.

We're getting a lot of community feedback. Um, one thing that's really, really, really crucial for us to get right this year is workflows. Um, it's a durable execution.

So, you know, it's basically a programming model where developers can go, Hey, process this transaction, and once it's done, sleep for 15 days or 15 months, and then wake up and send an email confirmation. And if that workflow fails anywhere in the middle, dapper will just rehydrate the state. Um, it'll replay the, the entire thing and, and see it to completion without developers needing to do anything when it comes to state management, failure handling, uh, you know, uh, logging errors and, and having compensating logic.

Um, and so this is really, really special for, uh, for developers because they can just create very durable applications that orchestrate different processes that could span clouds and even, um, you know, regions and platforms, uh, very, very easily, um, using five or more languages. So it's really important for us to get this right. We're getting a lot of feedback about those APIs.

They're currently in a beta state, but we're hoping to get them stable. Um, and, um, if, if you're familiar with the durable execution model, it's something that I, for example, does. And so we are really looking to, to, uh, have dapper workflows be an alternative to that programming model because we think it adds a lot, um, to developers, especially now Dapper is a one-stop shop for all of your, you know, workflows and pub sub and state management needs.

It just, it, it doesn't just do workflows, it does workflows and a bunch of other stuff. So this is one thing. Um, and then just, you know, hearing other community feedback around features that are really important, we're gonna be investing more, uh, in cross cluster communication, which is something hot that's been coming up from a lot of developers.

They go look, um, you know, we we're writing multi-cloud applications, or we have multiple clusters because we have high availability needs. Um, and, uh, some of our processes are running one cluster, our other processes are running on a different cluster, and we need this cross cluster communication. We'd love it if dapper made that thing easier for us too.

So this is definitely something that will, we're gonna be taking a closer look at, uh, for 2024. Do you think there's any relationship between dapper and the rise of generative ai? Because it seems like there's a lot of capabilities in there that may are interesting to developers.

There's things that I can use to asynchronously manage things, and, you know, dapper kind of provides an interesting abstraction layer. So is there some sort of primordial soup here that needs a little catalyst? Definitely.

There's two things. Um, there's two things I I see dapper improving for generative ai. The first is something you can already do today.

Um, if you're inferencing gen ai, if you're running a gen AI model and you're exposing it, you know, to to your customers, whatever those, whatever that customer base may be, um, dapper will have, uh, basically make it more secure and reliable because dapper has these developer primitives like, you know, mutual authentication, authenticating middleware, um, you know, quality control over data that goes in, goes out, uh, timeouts, retry, circuit breakers, all of these things dapper can basically put in place to make sure that calls to your gen AI endpoint become more secure and reliable. And you can do that today. The second thing that we're talking about, you know, in the inside of the dapper ecosystem is maybe coming up with something like a conversational ai, API for dapper with where it can abstract over multiple models, um, and really be the entry point for developers when they reach into these, uh, different models.

So instead of developers needing to figure out different SDKs for different, for very specific languages to interact with these gen ai, um, models, apple will essentially give you this really simple H-G-T-P-G-R-P-C endpoint that every developer knows how to interact with. And Decker will basically take the hard distributed systems challenges of interfacing with a model for you. Um, so this is definitely something that we're hearing and we're gonna be taking a look at.

Do you think that data science teams are gonna discover dapper? Because when I talk to them, they're having the same conversation that developers had, which is the heck is this Kubernetes thing? Yes.

Um, Mo most definitely, and there is actually a really good case study that CCF released, um, last week for dapper. Uh, it's a CCF case case study for a company called ivco. And they built their, uh, AI and machine learning system on top of dapper, uh, and they use, you know, different APIs from dapper to basically send data, um, that, uh, participates in the AI training and, and learning, um, processes that they have going on internally.

And so we're, we're definitely seeing more and more of these, uh, different AI use cases being used with dapper. What's your best advice to all these cloud native application developers beyond the fact that they should probably use dapper, but it seems like a lot of them are struggling. They're trying to figure out, you know, how many microservices, what makes sense, um, maybe a model that at the end of the day is just a big ass microservice, who knows?

But, um, how, you know, how should they be approaching this whole thing? Yeah, I, I think, um, my biggest advice to developers is really, you know, tackling the question of, Hey, my modernization journey, should I really decouple to microservices or not, um, would be look at your security and scale boundaries. If that thing should, you know, scale to more than one instance, and it has a different security boundary, uh, then other pieces of your code, you'd probably wanna split it out into a separate service.

And this is the decision you're, you're gonna need to make. Because just deciding that everything should be in market services is not viable. Um, you will face additional challenges and hurdles and more costs probably.

Um, and if you think you know that something can run a single instance, hey, don't split it up into multiple services. It's fine to run things as a monolith and, uh, you know, dapper can help for both monoliths and microservice architectures. And now we, we use the word microservice a lot, um, in, in dapper.

I personally don't like it so much, um, because, you know, what, what constitutes micro, you know, is it five lines of code? Is it 10 lines of code? Um, what's a nano, you know, service?

It, it's all really an exercise to be taken from the beholder and the beholder is the developer writing the application. So I think developers need to be very explicit about when, uh, they should be splitting out a piece of functionality into multiple services. And for me, it's when something needs to, uh, scale differently than other pieces of code that it integrates with.

And when there is different security boundaries for it. And that's when you'll wanna split things out. And I think if developers really start with that baseline, it's gonna make things a whole lot easier for them.

All right, folks, while you heard it here, as always, when it comes to it and the debate between microservices and Model S, the correct answer is all of the above. Hey, you're on. Thanks for being on the show.

Thank you so much for having me. All right. And back to you guys in the studio.