Ep. #84, Maddy Montaquila on .NET Aspire

Maddy Montaquila: Remember when you could like subversion, clone a repo before Git and then you could run it, and then it would all just run, and then the app would show up and everything would work?

And there was no scripts and containers and bullshit, and like, we always have to text, like, someone and be like, "Oh, what's the key that I need for this? Where do I get that?"

And they're like, "Click through here," blah blah blah blah blah blah.

Aspire lets you clone and run again. That's the magic of it. Like if you use Aspire to its fullest potential, all of the other magical features aside, which there are a lot, just the ability to just clone a repo, and then run said repo, and get a working app without, like, two to four days of just fucking around, trying to get it to work is so magical.

And the way we do it is just a bunch of things. There's tooling, we have a CLI now, there's templates and packages, and like you know, we give you stuff and we turn stuff on.

We'll be talking all about telemetry, I'm sure. But like, that to me is the magic thing.

Like, I don't have to mess around to get someone's sample app working anymore. I can just run it.

Ken Rimple: And this is different than like Docker Compose, Docker up and down, that kind of stuff, like.

Maddy: Yeah, 'cause you have IntelliSense bro. Like, YAML sucks, and that's actually not true.

I know a lot of people, we started going on this like F YAML tirade, and people were like, "Actually Docker Compose works really well for me and you guys are just being dramatic."

And we were like, "Okay, cool," but YAML, it's good. It's not debuggable. You can't stick a break point in it.

You can't like use types, I don't know, like VS Code yells at me when I fuck up my Aspire, my Aspirification, my "Aspirification" of the thing.

So it's like, yo, that's not the type. This must be an endpoint, not like just a random thing. And I'm like, "Oh, okay."

Martin Thwaites: Yes, YAML is great. We have somebody at Honeycomb called Pierre and he has a T-shirt that says, "YAML is a programming language."

And YAML is great, until it's not.

Maddy: That's like people who say that XML is a good format for a project file.

Martin: Bring back project JSON!

Maddy: Martin, you say that this was said to me in a meeting last night. I shit you not, 13 hours ago.

Martin: Anyway, that sounds like an amazing time for you to introduce who you are and what you are all about, Maddy.

Maddy: Yes, I'm Maddy. I am a PM, program manager, product manager, whatever they call us now at Microsoft. Professional Vibe Coder, actually, is what my title is now.

I am the lead for Aspire on the product side. So I came in a bit over a year ago now, which is crazy, so that Damien Edwards could stop doing the annoying PM stuff and go back to working on important things, and so that Fowler could have a full-time babysitter.

And it's been great, I love it. I was on MAUI before, so I had a whole-

Martin: Blink twice if you're under duress.

Maddy: No, Fowler and I fighting is my favorite part of the week.

And I know he is going to listen to this podcast and be like, "LOL," and then he's going to text me, and he's going to give me exactly, like, he'll be like, "That was a great podcast, except for that one thing you said like halfway through."

And then I'm going to be like, "Eek," so hi. Hi, guys.

It's fun, we have a good time. But yeah, I've been at Microsoft for seven years as of last month.

I just hit seven, which is gross, 'cause I feel like I was just joined last year. So that's me, hi, everybody.

Martin: So contrary to popular belief, I do actually like Aspire. But the thing I like most about Aspire is how it has popularized telemetry as a first class citizen to engineers.

Maddy: Yeah.

Martin: So maybe if you could explain to Ken, who knows nothing about Aspire, exactly what the reason and the process that you went through to try and popularize this telemetry.

What's the reaction that you've seen from engineers?

Maddy: Yeah, so when we started the Aspire journey, right? There were a bunch of things we knew that most people should just do with apps.

And so telemetry is the obvious one, and we have really good OpenTelemetry built into .NET, but just better logging, resiliency, so there's just like a standard retry policy on your API is like just normal things that you run into while you're developing an app.

And so we came up with the concept of service defaults, which is just a .NET project that turns all this shit on for you.

And the telemetry part of it is we just turn on the OTel stuff that exists in .NET. We pass the correct environment variables between Aspire's AppHost, which is like the core orchestrator, the Docker Compose on crack if you will.

And then, you know, the actual project. And so when you run the app, you just magically, with a file new project, or if you just shove it into an existing app, you get the full OTel, just like stacks and traces and logging and all of that.

And so there's a couple different reactions we've heard. One is, "Oh, my god, I can test my telemetry without having to deploy things," which was, I think, the Xbox services team had this issue.

They did like a huge framework to core migration, and they were like, "Hey, so we keep spelling telemetry events wrong, but we can't figure it out because we have to push to prod to get like address into whatever, you know, data, whatever we're using."

I'm going to use all the wrong words. It's going to make Martin have a freaking aneurysm, because I just.

Martin: Well, interestingly, I am wearing the T-shirt that says, "I test in prod," today.

Maddy: That is so true.

So yeah, but you know, Aspire you can like see it locally, we have an OTel dashboard built in Blazor, btdubs, very cool, that you can use when you're just developing.

Martin: Which version of the 12 versions of Blazor is it written in?

Maddy: That's a great question. You'll have to ask, not me, that, because I don't know, but they let me put some icons in it so I have contributed code. So that's really good.

Ken: Okay, so as you're doing development using Aspire, you're literally developing with OTel from first principles, immediately starting it with telemetry as opposed to just to debugging in steps.

Maddy: Yeah, I actually like don't have the browser tools open all the time anymore because I can, yeah, just look at the OTel traces.

And at some point, you do go into the browser tools and you want to see the console.

And especially in this like AI landscape, where you're just getting slop generated all the time, having this telemetry by default, it makes it much more debuggable. And you could see what's actually happening, it's very cool. The other thing is now, people who wouldn't care about this at all, are caring about it.

So enterprises, obviously, at some point, your boss goes, "Where is my telemetry?" And you go, "Uh-oh, spaghetti-O," and you like build it.

Startups, you have to kind of force them to, especially front ends, because front end developers think that like, "How could this be slow? This is not my fault."

And it's like, "Put some tracing in your fricking app."

Ken: Yep.

Martin: "It's fast on my machine."

Maddy: "It worked on my machine."

Ken: Fast with no network between the two points, right?

Maddy: Yeah. And it's like, "Wow, this request is taking a really long time, must be an API issue."

And you're like, "Are you sure? Are you sure you're sure?"

Ken: Prove it.

Maddy: Prove it. And so that's where a lot of the Aspire magic is, is people who just wouldn't worry about telemetry at all now are worried about it.

And so we've been doing this whole like polyglot, kind of, Aspire as a Trojan horse for .NET thing, where we sneak into other ecosystems.

And one of the big driving forces for that were backend teams, who really wanted their front end team to use Aspire, so that their front ends would have telemetry without them having to bully people.

But the JavaScript devs were like, "Eh, C#, eh." And so we've been trying to make it less of a barrier to entry to Aspire without the full .NET kind of thing.

Martin: What you need to do is tell those frontend people that TypeScript is actually C#, but you know, written in JavaScript.

Maddy: People are talking, "Should we build a version of Aspire that you can write the app post in TypeScript?"

And the argument with Fowler and me is I say, "It's the same fricking thing. They look the same. It's just the amount of semicolons and the casing."

And his argument is, "But people care," and I'm like, "Ugh, I'm not!"

Martin: So I'm a big Polimi fan and I've written two very, very similar things.

One in C# and one in TypeScript, and then I had to write a third thing that was very similar and I copy and pasted the wrong one, and it took me about 20 minutes to work out why I was getting little squigglies underneath.

And it was because I'd pasted the C# one into a TypeScript code base, and the syntax was so close.

Maddy: It's so close. I love TypeScript, don't get me wrong. Like I think TypeScript's a great language. I'm just like, come on, people.

Ken: All right. So let me pull you back from this a bit, 'cause the reason I came to Honeycomb was front end expertise as well as backend, but mainly front end single page apps and things like that.

Maddy: Yeah.

Ken: And we were starting our front end observability product, and I came in to be the DevRel on that. So I've been spending a lot of time on web and mobile front ends.

Talk to me a bit about what it means to build a front end application with Aspire and telemetry.

What does it mean to me as a developer? What do I have to do differently?

Maddy:

If you only use Aspire as a fancy launcher with types, you don't have to change your app code at all.

You can you use whatever ports you have hard coded and you can tell Aspire to do that. You can not turn on any of our service defaults, whatever it is.

The only code changes you make if you want to turn on telemetry and our service discovery, and they're all kind of lumped together in the resiliency, right, the service defaults concept, is you add builder.addservice defaults in the beginning of your builder of your program CS.

And you add app.map default endpoints towards the end before you do app.run.

And those two things pull in all of the code from the service defaults, which is a C# project.

So it's code, so you can comment anything out or replace whatever you want.

I know Martin and I have talked a lot about, like, well, what if people want to stand up like Prometheus locally and egress to that, so that they don't have to use your dashboard, and like, they want to use what it's going to look like in prod when they get their data.

Or like, what if they want to do Honeycomb stuff at dev time? You can just do the code, write the code for it, comment on our stuff, I don't care.

It's not my fault, I didn't write it. So it's fine.

Ken: And on the client side, you just install OpenTelemetry JS for the browser, right? Like we would do in any other case or does it do that also and add that script?

Maddy: It does that for Blazor. On the JavaScript side, there's some environment variables you turn on.

For MAUI, we now have service defaults that will turn it on for you in MAUI, which is good.

So that's coming in .NET10 because we had to redo the actual builder pattern for MAUI apps because we built our own on the MAUI side, and now we're like, "Yikes, can't do that."

Turns out adding :IHostApplicationBuilder to the fundamental builder pattern for your entire stack is not a light change that you can put in the service release, but that's coming in .NET 10.

Martin: One thing I want to add there is Blazor is about 17 different things. Blazor WASM does not have a good OTel story yet.

Maddy: Yet, correct.

Martin: Until we get threads in I think .NET26, I think, we're getting those, we won't have them.

Maddy: Yeah.

Martin: So fun sort of little digress there. I did a conference a number of years ago, a front end conference and they asked me to do a talk on OTel. So obviously, I did how to implement OTel in Blazor.

And in a true professional speaker style, I waited until two weeks before the conference to build my demos and the rest of the talk.

Maddy: Actually, that's a long time.

Martin: I know, I was a professional. And I found out that it actually doesn't work.

So I changed my talk from how to implement Otel in Blazor to seven ways to not implement OpenTelemetry in Blazor, and one way that you can, but you absolutely should not.

Maddy: Nice, nice.

Martin: So there were hacks on top of hacks that implemented some hacks that made it work.

But yes, there is a story coming for anybody listening that is looking at Blazor. If you're using Blazor server, that absolutely, obviously, works and that kind of stuff.

But if you're using Blazor WASM, no, unfortunately not. There isn't anything yet.

Ken: So I'm going to pull you all back from Blazor. A quick blurb about what Blazor is, for the uninitiated, is it a web framework?

Maddy: Yeah, it's FrankenSAML. I'm just kidding, that's not what it is. People do not like when I say that.

No, it's basically like C# in front end HTML. Like, Razor is the fundamental language or whatever pattern you want to call it, where you can have HTML and then you can inject C# and use dependency injection and the patterns that you're used to using in C#.

It's awesome. It's really, really good.

The reason Martin and I are both like, ah, with Blazors, there's server which runs on the server.

There's client which runs fully in the browser. There's WASM which runs as web assembly.

There's these, like, mixed rendering modes. And so what's cool about Blazor is it's really, really flexible.

Like whatever you need it to do, it can probably do, but it's very easy to not know what you're doing. And so you have to kind of go in with a formed opinion.

Like, Copilot has a very hard time with Blazor right now 'cause it hasn't quite trained on the latest, like, last two or three years of Blazor stuff. And so it just.

Martin: You mean AI gets things wrong?

Maddy: No, never. AI, my overlord. Thank you so much.

Ken: Sure it is.

Maddy: Yeah.

Ken: You know, to close the loop on that, though. Also I have found, to your point, of like, you know, Aspire being able to enable telemetry right away.

And using an AI with Aspire with your code, I had the same thing with basically with Honeycomb is that I was building a mobile application, and the thing that unlocked me getting somewhere with Claude in my mobile application was actually telling it to go use our MCP to go look at the trace.

Maddy: Yeah.

Ken: And say, "All right, you say this is working. I call bullshit, 'cause if you take a look at these four traces, these all fail in different ways and you have not accounted for these. So you give me a plan on what you're going to do to unfuck this."

Maddy: Yep.

Martin: So is Aspire getting an MCP?

Maddy: Oh yeah, of course, we are. We're good, we're good. I don't actually know that for a date.

MCP is like the thing, right, that everyone's shipping right now. We're kind of like, "Is an MCP the right thing?" Probably, but there's like a couple different artifacts you can do. We have some really cool experiments going on. But right, now we're waiting to see what the correct artifact is. We're not waiting too long, 'cause if you wait in AI, then you miss it.

Martin: Yeah, that was so last hour.

Maddy: Seriously, seriously.

I will say like all of us now have our own, like, fake prompt files that we use when we want to Aspirify things, where I'm like this, or, I use the learn or the Context7 docs MCP is really good, and I'll be like, "Go look at the Aspire documentation before you answer this question."

And then it does a much better job.

Martin: And I think that one of the really interesting things that we are finding from an observability perspective is, so one of only comes real values, one of the reasons I went there is basically the ability to ask any question and get a meaningful answer from your telemetry.

That's really the core of what observability is. Observability as a concept is the ability to ask complex questions and get meaningful answers. It's not about the telemetry.

And this idea of being able to debug your applications locally without touching a debugger, because when you're working in a microservices scenario and you've got, you know, 50 microservices interacting, I'm sorry, but you can't step through. That just doesn't work.

Maddy: No.

Martin: But also, it produces a lot of data. And using something like an MCP that we've been finding using when it comes to MCP is being able to say, "I've got a bug. Go and look at the telemetry and tell me what that bug is."

And it goes, "Oh, well, this other service is sending you this information and you are not being able to take it 'cause it's taken the telemetry information," and then married that up with your local code base, and went, "Well, you know that's sending you this information and you're not taking it because I've looked at these two code bases."

And I think that is that next step. Like Aspire was really great. Aspire brought in this idea of telemetry is a thing. It's like, oh.

Maddy: Yeah.

Martin: As I was saying earlier, the amount of people who believed that Microsoft invented tracing, because all of a sudden, Aspire showed them a trace water format. This is amazing.

Maddy: Yes, we are the only ones, who have ever traced anything ever, yes.

Martin: Yes, exactly. I loved the transformation of Fowler from "logs of everything" to, "wow, traces allow us to debug so many things in eShop and we found so many..."

I was like, "Dude, yeah." But you know, this idea of what is that next step? So you've got this data and you're seeing these things.

One of the things that amuses me is that when we move to an MCP, we're essentially then going to stop people from looking at that telemetry.

Essentially, now what's going to happen is people won't even look at the Aspire dashboard, because they'll use the MCP as that interaction with it, in order to be able to do it.

But that is at its core, we need telemetry. We need people to be thinking about telemetry to be generating that data.

Maddy: Yeah.

Chat is just the new UX. It's the new Pinterest Grin or whatever flashy UX thing you want, right? Like, the command line is back, baby.

CLI is back in style, except now, I use natural language and the thing like glazes me and it's like, "I'm so sorry, you're so right."

Instead of the CLI being like, "What did you just type, no."

Martin: Yeah, I love when the CLI turns around to you and says, "Yeah, you are absolutely right. I was wrong."

That's why I love AI. Every time I tell it, "Can you say this?" It's like, "Oh, you're absolutely right."

I'm like, "I know I'm right. Thank you very much for accepting that." Humans don't do that

Ken: Or, "I've solved it." No you haven't. You haven't solved it. In fact, try it again and I know you'll break it three more times until I ask the right question at the right time. When the moon is full and the stars are aligned.

Maddy: Oh yeah.

Ken: And then it gets it, but then it's worth it when it actually happens.

Maddy: Oh, it totally is. What I want is it to just update my stuff for me.

I don't want to have to ever rev a dependency and then wait for the build to spin again. I don't want that. Stop it, make AI do it.

Ken: I wonder if like the instruction you could give your AI, like, you know, if I told Claude and you know, make sure that you check our dependencies and notify me at least when the dependencies have revved. I wonder if you could do that kind of thing with it?

Maddy: I probably would do something, I don't know.

Ken: Hmm. Okay, so let's get the discussion back to Aspire itself a little bit more.

So when you're building an Aspire app, let's say you're building a bunch of microservices.

So this is something, if I was trying to draw a Java parallel since that's my old world, like, something like what Spring Boot would do.

Maddy: Yeah.

Ken: It just makes things easy to test, easy to run, easy to debug, easy to look at. You've got dependency injection.

Like, what would you say are like the killer things for developers that make their eyes pop out when they see them, and say, "Oh, I want to use Aspire."

Maddy: Yeah, it's the dev loop, right? It's the the one, the clone and run. That's the big one, first thing.

Two is the dashboard of lighting up with all of this data without you doing anything. That's crazy.

That's when you say like the five minutes to wow or whatever product turn you want to use, like the dashboard turning on and you're being like, "Oh my god, requests." Like, that's the big thing.

Three is just, we have this concept of like being opinionated, where we have opinions.

As Martin knows, I have a lot of opinions. I know Martin has a lot of opinions.

Ken, I'm sure you're lovely and you have no opinions at all.

Ken: What's an opinion?

Maddy: Yeah, exactly.

Ken: I got opinions myself, yeah.

Maddy: But like we things on and telemetry is the big opinion. That's kind of a less spicy opinion, but you know, the further you go...

Martin: It was, though. That's the interesting part.

Now it is not a spicy opinion that you should be using tracing logs and metrics together, using resource attributes and pulling all this stuff together and using that as your debug experience.

That was a spicy thing, like, three years ago when I was, like, yelling about this on the socials.

And it was like people, like, "No, no we don't need that. That's for ops." That was a spicy opinion. Now it's not, at all.

Maddy: Yeah, that is how you know that we are customer driven because we told you to shut up for two years and then we did the thing you said anyways, so. Customer feedback.

Martin: Yeah, shut up, we're building it, but we can't tell you yet.

Maddy: Yeah, yeah, pretty much. So yeah, but the thing about being opinionated is like you're allowed to disagree with my opinions.

You're allowed to BYO opinions, and so that's what makes Aspire really good is we don't vendor lock you into anything.

We don't vendor lock you into Azure. We don't vendor lock you into .NET.

You can use Aspire with a full JavaScript non-.NET stack. I don't care. Like, the only .NET is the AppHost. Sweet, great, C#. You don't have to deploy to Azure.

We have the easiest deployment to Azure because I can message the Azure container apps people on Teams, and say, "This is what we're building, can you build this with us?"

And they can say, "Sure, this will be great." But we also have an AWS story.

We now have this like docker-composed generic deployment publishing thing.

So, and I'm doing this to rile Martin up, intentionally, by the way.

I want him to start talking about deployment and how mad he is about it, so we can argue about it in public.

Ken: You knew this was coming, didn't you?

Martin: My tongue hurts. I have bit it so hard.

Maddy: Good, good.

Ken: We won't look as you use this spittoon to get rid of all the blood, yeah.

Martin: Just use Pulumi, it's way better.

Maddy: Yeah, so yeah, it's just basically, like, we keep saying the Aspire AppHost is a Lego base plate. It's that big green Lego base plate.

And we give you a bunch of Lego kits, and we say, "This is how you build a tie fighter and this is how you build a Minecraft sheep, and you can put them all in the Lego base plate however you want, but you can also dump whatever Legos you have lying in the closet and stick them on the base plate, too."

So they all work together. The primitives are basically containers and executables. That's it.

Martin: Have you, I mean, are you working with your events team on Swag?

Because it sounds like you've built this as an idea that basically you want your events team to buy you Swag that you never give to anybody that just stays in your own home and that you build the Lego yourself.

Maddy: I would love that. However, they keep telling me not to spend money on silly things.

Martin: Yeah, my wife keeps telling me that. It doesn't work.

Maddy: Yeah, yeah, no.

Martin: But yeah, I mean, the idea that we give people Lego, I mean, I would actually say, I'd probably say that in a very positive way, Aspire is more like Duplo than Lego. The pieces are bigger and easy to use.

Maddy: Yeah.

Martin: But it's maybe Duplo that you can break apart and make into Lego if you really wanted.

Ken: I just need a sawzall.

Maddy: Yeah.

Martin: You know with a nice knife, and you know, some expertise, you can break apart the Duplo and make it into Lego.

Ken: So it seems like you've done a lot of nice things, like for example, you've got these Aspire tags in your NuGet libraries.

So tell me a little bit about, like, how you're enabling all these different integrations.

Maddy: Yeah, it's kind of like curation. Like, with extra steps, I guess.

With the Lego analogy, right? We have these first party ones. We have the kits that you see on the shelves at Target, but then you have the ones that the community makes.

And the people go on to the websites and they put in the part list and they buy the kit, and it comes with the instructions.

And then eventually, sometimes, we adopt those into the core thing. Like Lego just pulled in a new community build into their, like, key, whatever they call like the core ones.

But now you're going to be able to buy that at Target, whatever it is.

So we have the in-the-box ones, and those are pretty small, like, not small.

We just have few of them because there's only so many of us and we don't want to have to become experts in all of these things because we're not.

So why should we be telling you what the opinions are for everything if we're not the expert in them, right?

Then we have the community toolkit, which is, it's .NET Foundation. So it's fully open-source, it's maintained.

We have one guy on our team, Aaron, who is the best. And then whoever else in the community is kind of elected to be one of the involved people in it.

And so those are, like, sort of blessed. They have to have a certain level of quality and usefulness and whatever to be in the toolkit.

So they get to be owned by Aspire and CommunityToolkit.Aspire.Hosting instead of Aspire.Hosting. So there's a differentiation, but it's still like the official others.

And then we have this in the middle, we call them like tier one partners, a ring one depending on the week.

And those are companies, like Elasticsearch just did this, Amazon, I don't know, there's a bunch, that they own their own Aspire integration, but they talk to us, and we say, "Cool, we will put this as an Aspire owned package on NuGet, and we'll give it the proper tags and everything."

So when you right click add, it's curated. And we know that these are all blessed and are going to work, and are going to have a baseline of telemetry that turns on.

And local development and service discovery, like there's kind of a few things that you have to have to be a proper Aspire integration.

And so then you can put whatever you want up on NuGet, I don't care, like, just go find your regular NuGet package.

But when we do a right click add Aspire with the command line when you do Aspire add, we give you this curated list of community toolkit, non-community toolkit, and then these these ring one, vendor one's partner integrations, so that those are your nice Duplos.

Martin: There's even a package for the OpenTelemetry collector. Apparently, the author is an awesome person and an all-round great human, yeah.

Maddy: Really, isn't it in the toolkit?

Martin: There is a PR to get it in the toolkit with a very, very long argument about container versions, but yes.

Yes. There is currently an argument as to where the latest is a valid tag, but yes, it will be there. It will be there.

Maddy: Yeah.

Martin: Me and Aaron have had chats.

Maddy: Good. Don't drive him nuts. I need him desperately for a lot of things. Protect him at all costs.

Martin: That's fine. But yeah, I mean one of the things Aspire is doing really well, and you mentioned it in what you were talking about there, which is baseline telemetry.

It's this idea that everything that you do, when it's transitions outside of your application, needs telemetry.

You need to be able to know that that thing is running. It needs to be able to, whether that's metrics, logs, or traces, I can argue about whether trace is more important than all of that kind of stuff.

But at least a baseline of telemetry is really important. And making sure that when we say, "Let's pull in the Elasticsearch library to be able to communicate with the Elasticsearch instance, making sure that it's actually got the right level of telemetry in there."

Steve has done a great job with building telemetry into all of those Elasticsearch libraries. And making sure that when we bring it in, we turn all those things on.

And make it optional to turn them off. So basically, and as a, I think a term that's been used a lot inside of Microsoft, which is the help people fall into the pit of success.

You know, this idea that, well, if they bring it in and it's just got all of the things there, and they go and they're about five minutes to wow, it's like I've just brought in the Aspire Elasticsearch library.

And look at all this telemetry, I know what's going on. I'm a wizard. You know, that kind of experience, I think, is really important.

Maddy: Yeah.

Martin: And I am thankful that Microsoft have embraced this idea that telemetry is really, really important and that people should be, and I hope that it's then sort of transitions into things like Azure App Insights, where they treat these things as a first class citizen that we start thinking about custom telemetry.

We can start thinking about how we allow people to... . NET is amazing in terms of its OpenTelemetry integration, purely because we have activity that 's built into the the runtime.

Maddy: Yeah.

Martin: And it's just so easy to add stuff in there.

Maddy: Oh, it's so good. As we've looked at like extending service defaults to other platforms or languages, right?

Like, we got kind of spoiled by how easy, easy because we built it.

But like easy it is to turn all these things on in .NET, because when you go to something like JavaScript or Python, or there's all these different ways to pull in Otel, and we're like...

Martin: We don't talk about Python OTel.

Maddy: Oh, my apologies.

Martin: Nobody talks about Python OTel.

Maddy: But I'm like, "You guys don't like have a way to do this? You just, like, make it up? That's not good, what?"

Martin: Yeah, there is a lot of trauma from Python OTel.

Maddy: Sounds like Python, in general. There's a lot of.

Ken: It's a "just so"story. Just so you've configured it properly.

Maddy: Yeah, yeah.

Ken: It'll work. Is your VM properly set up?

Maddy: Oh, don't even, mm. VMs give me heartburn, and that's that.

Ken: I mean, they're needed, but they're awful.

Maddy: Yeah, they're almost really, really good. Almost, if it's going to work. But when they do, they're great.

Ken: And that almost aren't wasting a week, you know?

Martin: So Maddy, what is your favorite feature about Aspire? And if you say deployment, we're canceling the podcast and it won't go out.

Maddy: It's the CLI, which kind of is deployment, but not really. It's the CLI.

First and foremost, because I really wanted one, and now we have one. And so that is on sheer will. End of story.

No, two, because I can just run it anywhere. And in Codespaces or on like a dev container, or on my Mac, I switch between Mac and Windows all the time.

I mean, I come from the mobile world, so I was always already doing that. But now like I'm mostly in VS Code, and VS does a lot of magic stuff.

Like, if you're a .NET developer and you're used to VS, I'm not going to tell you to go use VS Code, right? Like VS does a lot of stuff for you.

But .NET hasn't had this, like, very consistent cross-platform story. Especially since VS for MAC went away, which wasn't anything like VS in general.

Like, it was a whole different ball game.

Martin: It was mono developed.

Maddy: Yeah, yeah, exactly, exactly. It was like not VS, which is part of the reason it's just people would download it, and be like, "This is not Visual Studio."

Ken: Yeah, they're confused by it, yeah.

Maddy: Yeah, but you know, you have people coming in and learning or coming from other languages, or whatever it is, and they're like, "Okay, if I do this in VS Code, it's completely different than if I do it here."

Aspire, like the CLI completely, I don't know what the word I want is, it just makes it all the same. It brings it all to the same baseline.

You can Aspire run, and whatever you have in your Aspire AppHost just runs. Done.

Doesn't run right? You fix it in C#. You just fix the code.

Like, there's no magic project system, or like you don't really have to worry about you just run NPM install or whatever package manager install, and you don't have to worry what web server you have for your JavaScript or what, I don't know, versions of things exist.

You just kind of let Aspire handle it. And being able to do that in the CLI, it's amazing.

Like, I can just go onto any computer and run it, and I know it's going to work.

Ken: So normalizing your development across operating systems. So you don't really care, if you feel like working in Windows one day, you work in Windows. If you feel like, "Oh, I've got my Mac with me, I'll put the Mac. pull it up, and work." Is it pretty much not like that then?

Maddy: Yeah.

Martin: What kind of animals work between a Windows and a Mac machine on a regular basis?

Maddy: Me, I'm insane.

Ken: I used to. When I used to teach, I used to teach people that had Windows and Mac when I was teaching, you know, web development.

So I, this is crazy. I got myself a Surface book, and I loved it and hated it at the same time, 'cause it did some almost well.

Maddy: Yeah, they're really pretty.

Ken: Yeah, see? But yes, but some things it doesn't do that well, but that doesn't matter.

But the point being I could open up whatever and do all my builds in either operating system, and I had to, 'cause my students would be on any of the platforms.

Maddy: So for learning, Aspire's great because instead of having to deal with how to configure a Redis cache, you just add it, and then you know, you have to teach them how it works.

But if you want to just get the sample running or you want to be able to have people clone the sample project and make changes to the caching operations or whatever, like, that just works now.

You don't have to sit there and troubleshoot between 18 different devices and installations, and oh, well, you have VS 1713 and you need 1714 and like this. There's none of that, it's just gone.

Ken: Yeah, that whole thing like in the spring world, what you miss in that is the exactly like the setup of the services.

Like you can configure connection to the services very easily, but you've got to find some recipe to do the setup of the platform, and you still have to install the platform.

It sounds like this is a great way of quickly bootstrapping a lot of common services.

Maddy: Yeah, it's really fun.

Martin: Awesome, well...

Maddy: Can we talk about deployment before you wrap this up?

Martin: Do we have to, though?

Maddy: Martin, explain to me what Aspire deployment is and why you don't like it?

Martin: Aspire deployment is something that should never have existed b ecause Pulumi exists and it's way better.

Maddy: Okay.

Martin: For me it's mixing concerns. As a engineer building an application, I should be able to describe my dependencies and somebody else should do the deployment.

Which is why early days, it was really cool that you had the deployment manifest and then you could send the manifest into something else, and let the ops team take what you said as the things I need.

I need a Redis cache, I need a Postgres database with this version. I need a MySQL with this or I'm using Dynamo and I need a connection, and it's up to somebody else.

Because in 99% of organizations, nobody's going to let you deploy using Aspire because that is a different team that does the managing the infrastructure.

So I love the idea of describing how my application has dependencies and what those dependencies are, and then doing that inside of that, great.

Using an Aspire CLI to deploy, I think, is an abomination. I think it's incredibly cool and there is so much complexity that has gone into that, but I just don't think that is the tool that most people would use.

I think it really, it's friends don't let friends, right -click deploy. And this is right-click deploy for microservices, so.

Maddy: So I goaded you into this because I have, for a long time, been on your side of this argument because I agree.

Anyone with an ops team is not going to let you Aspire deploy and run that in prod.

No one's that stupid, except for your shirt that says, "I test in prod." Maybe that might allow it.

Martin: It doesn't say I only test in prod.

Maddy: That's true. Where I got sold on deployment, where I softened, and this happened like three or four months ago, was this concept of a dev time deployment.

Meaning, I'm logged into my Azure sub or whatever, and I'm developing the app locally and I know it works on my machine now because I've been, and I'm using Aspire and of everything, but I want to see what would happen if I ran this in a simulated cloud environment.

And by simulated, I mean deploy it to my Azure sub, let it run, have someone else hit it on a different machine, make sure all my endpoints are talking correctly, and then tear it down.

And so it's this concept of dev time deployments, right? Or like iterative deployment or whatever you want to call it.

That's what sold me on Aspire Deploy, because we were working with first parties and because deploying it within Microsoft and within really, really big organizations is such a cluster F, and you have to have an ops team willing to dink around to make sure everything works.

It's a disaster. And so we had all these teams that were basically writing manual deployments to deploy to their own personal Azure sub or their team staging sub just to make sure things worked, and then they would tear it down and give it to the ops team for realsies.

And so that is where I softened on this concept. I still fundamentally do not believe that if you are running Aspire deploy and you're going to prod.

Although my husband is a big startup person, he's always worked at startups. I've seen him do it, it's horrifying.

It gives me like actual, like, nightmares. So it does happen, but you know, we're talking about mature companies.

Martin: I mean, I used to edit HTML on the server, so.

Maddy: Yeah, well, yeah, but this dev time deployment kind of like, it's not a staging environment 'cause staging kind of feels more legit.

But this, I can spin up. I can let my system operate autonomously on hardware that I don't control and verify that everything works. I can run tests on it that way.

Where Aspire needs a lot of work is, like, yeah, what happens in CI, right?

Because I don't think you're going to have someone on your ops team run Aspire deploy as a step in their CI pipeline.

So how do we bridge that gap, where we give them the assets and whatever, and they are able to do exactly what you said.

Translate them and say, "Oh yeah, it's a Redis cache," and blah, blah, blah, blah, and like make it less of a handoff.

But I don't use Aspire Deploy to deploy to prod. Just don't do that.

Use it to test that your deployment to prod is going to work without spinning all the meters and then pulling down your system.

That's my theory.

Martin: Yeah, I mean, I can kind of get behind that, but I think there's better ways to do all of those things, generally, but that's probably for a different podcast and maybe a beer at the next conference.

Maddy: Yeah, yeah, that's true. Don't worry, we'll get you on board one day.

Martin: I am on board with the Aspire dashboard. The Aspire dashboard is amazing.

I love the Aspire dashboard and I love what Aspire has done for the .NET development community in terms of making them care about well-curated telemetry. Those are the things I love.

Maddy: Yay.

Martin: So thank you so much for coming on and talking about all of this stuff for us. Where can people find you? What are you doing next? Where can people see you?

Maddy: That's a good question, bluesky@maddymontaquila.net.

You can also donate to me, @maddy, because I want maddy.net and it's $3,000.

So I'm just kidding. You don't have to actually donate to me.

Conference-wise, I'm actually kind of like chill right now. I think the next big one will be the Azure Dev Summit in the fall in October. So I'll be there causing problems in Lisbon.

Martin: In Lisbon.

Maddy: Very excited. But yeah, I'm around, catch me on the internet.

We're trying to do, like almost every Friday, a live stream now, where we take someone's app and we add Aspire to it.

We call it Aspire Fridays because "Aspirify" is the official verb. So you can catch us on there and it's very low key.

So that's the best thing to do. Otherwise, maddy@microsoft.com. If you have been a, you know, concern question.

If you email me an issue and you don't have a GitHub issue link, I'm going to ignore it. So you have to file the issue first.

Martin: So make AI create the issue. So write the email, file that into AI, make that create the GitHub issue.

Maddy: Right.

Martin: Got it, awesome.

Maddy: Yeah, but it's going to take me two weeks to respond to my email, and if you don't have an issue in the first one, then it's going to be another two weeks until I respond. So you need to...

Martin: Get it right first time.

Maddy: Yeah.

Martin: Thank you so much for being here, and hopefully, everybody in the .NET development community goes and tries Aspire and sees how awesome it can be, and how awesome telemetry can be. So amazing.