How'd you like to listen to dot NetRocks with no ads? Easy? Become a patron For just five dollars a month, you get access to a private RSS feed where all the shows have no ads. Twenty dollars a month will get you that and a special dot NetRocks patron mug. Sign up now at Patreon dot dot NetRocks dot com. Hey, Carl and Richard here with your twenty twenty four NDC schedule. We'll be at as many NDC conferences as possible
this year, and you should consider attending no matter what. Ndcoslo is happening June tenth through the fourteenth. Get your tickets at ndcoslo dot com. The Copenhagen Developers Festival happens August twenty sixth through the thirtieth. Early bird discount ends April twenty sixth. Tickets at Cphdevfest dot com. Ndcporto is happening October fourteenth through the eighteenth. The early bird discount ends June fourteenth. Tickets at Ndcporto dot com. We'll see you there, we hope. Hey, get down
rock and roll. It's doott need Rocks. I'm Carl Franklin and I'm Richard Campbell and Scott hunters with us. We'll bring him in in a minute. But how's everything going up in the great Western North? Uh? You know it's springtime and springtime is good. We're putting in vegetable gardens. You know. It's now that we're living up here full time, you see things differently. Do you have as many bears there that are going to come and eat your vegetables? No, a lot fewer. The issue here will be deer.
Yeah, so we actually had to put deer fencing around the garden. Oh dear, But we'll find out if you don't find out it works until you're actually growing things and they're eating it anyway, so we'll find out soon enough. But season one, feed the deer. Season two, yeah, keep the deer away. Feed the deer less. Feed. But you know we were talking about it, she said, I said, this will be at arms race. We'll see what they we've brought. We put out our
first salvo. Let's see what they come with. We'll figure it out from there. So here, the weather has a made up its mind. In Connecticut, the couple days ago it was like in the thirties overnight and today it's gonna be eighty. Oh man, it's gonna be eighty. It's like summertime, just like that. Yeah, next week it'll be raining and cold again. All right, Well, let's dive right into this thing with a little thing that I call him that I don't know framework all Right, dude,
what do you got? Okay? Well, I mentioned this maybe a week ago or two, but there's a new Blazer master class happening in September in Tuscany, very dice. And the reason I wanted to mention it with a real URL here, which is Codnecastle dot com or since it's eighteen ninety seven one eight nine seven dot popped at me, is that there's an early bird discount. You can save five hundred bucks if you sign up by next
week. May fifteenth is the deadline for the early bird. Okay. But what's cool about it is if you go there and you watch the video. I actually made a video from last year, and I think that brings the experience home because I talked to the people and I took their pictures that they took as tourists out in Tuscany, and you know, did a little ken Burn's treatment to some Tuscan music, you know, to some Neapolitan songs in
Pavaratti and some Puccini anyway, So it's really great. Basically, it's code in a castle and you spend a week in a castle with your significant other, like in a castle bedroom, having meals and on the grounds and seeing Tuscany. And the first four hours of the day were in class nine to one and then everybody meets up and the rest of the day is all sight seeing and tourism, and the plus ones or the significant others, they get to spend the morning doing things that you know, we don't do nice.
You know, they go out and the cheese shops, the olive oil shops, the beaches, all that stuff, and they do morning activities that are strictly for them. It's just a great thing if you've modernized the immersive event. Carl, I think it's pretty cool. Yeah, And I got to say I didn't do this. It wasn't my idea. It was Larry Lustig's idea, who's been a longtime listener of dot net rocks and also a keto guy right right, and he and his friend Marco, who lives in New
York now but grew up in Tuscany and is from Rome. They put this whole thing together, and kudos to them because you know, the traincation has begun. Yeah, the train cation revolution. It's a good and it's a good idea to just mix the two together. And Scott Hunter almost came last year. I did almost come last year, and maybe this year will be
a better year me to have a chance to come. It just comes up if I have too much travel booked up, like, yeah, I've currently overbooked myself right now, and I need to unoverbook myself right Maybe a week in Tuscany, just the ticket to relax a little bit. Maybe if you're there, carl as my wife can want me to stay for a month. That's the Yeah, that's tell me. The dellside, Well, this castle is something that you just can't book like a hotel. You have to have
a group. And that's why it's so special is that we get a group together and then because of that we own the castle, like where there's nobody else there but our group. Nice and so it's not it's not anything that you could experience any other way anyway, cool man, that's what I got. Who's talking to us today? Richard grabbed the comment of the show eighteen eighty nine, the one we did with one Magnus Martinsen. You know them. Yeah, when we were talking about Azure. Lots of people like this
conversation. It was a very popular show. Yeah, you know by any standards and code Pooter that's Richard Rakimo has been on the show as well in a regular comment or had this great and he was at Coden the Castle last year and he was a go to the gasle he was. I love his comment, it's four am. What a good show. You know, I think your perception was distorted at that time. Ridge were pretty late. For most organization, cloud migration looks like utopia when it's really a minefield. Why
perspective. As Magnus points out, organizations have skilled operations which traditionally manage shared physical resources one server or one black plane and many applications. So cloud migration is a migration of that's meaning the backplane in the infrastructure, rather than migration of the applications to a dynamic scalele resource. Wa we did. Dynamic scale is where it operations can fall short in cloud From a business perspective, the
resources they require as services not servers. Good line, love it, good line man. This is the change in perspective resources the businesses require and putting applications on those resources that will scale in and out based on business demand using time frames of minutes rather than I got done that. He nailed it. It's great. It's a great point. It's like, listen, this is not we're If you're just thinking about dev when you're moving to cloud, you're
missing out. You need your operations folks on board. It's a change in the way they think too. It will affect the way we build software. It's why we move up the services because then you get that scalability. But you know, I've been thinking a lot of lately about the software angle of not just get it there, get to the new platform, but then really taking advantage of the platform. But I think there're two logical steps. First, you got to get there. Then there is an optimization that has to
take place to to really take advantage of what you've got. And part of that what we save money, reduce impact, optimize for better scale, for new business opportunities, like all of those things come, but you do have to get there. Ye, Rich, I know you got a copy of music code by, but I got to call it out as always. If you'd like a copy of music Code buy, I write a comment on the website at dot at rocks dot com or on the facebooks we publish every show
there and every reading on the show. We'll send you copy of music Cobey and you could follow us on the facebooks and on Twitter of course, or x or whatever the hell we're calling it these days. But cool kids are hanging out. I'm masddon, I'm at Carl Franklin at tech Hub dot social, and I'm Rich Campbell at mass do dot social. Send us a twot and that's a really great way to get a hold of us because there's less noise for the time being, and that brings us to you. Scott Scott
Hunter is the VP of Product for Azure Developer Experience. He builds all the dot net tools for Azure and used to be in charge of all the dot net and that's what more can you say? All the dot net? He was all the dot net. Now he's a little more focused on Azure and dot net tools for Azure. Welcome back, Scott, thanks for having me back, guys. I'm excited to be here. Yeah, been too long friend, and certainly you know this all this ties together with I'm glad you're
there helping us be better at Cloud because it's hard. I think about the move we made onto the Internet, you know, from wind forms to web form, and then pretty quickly as you get familiar with that, you're like, hey, you know, there's a better way to do web stuff. And we went to MBC and others. Like I kind of feel like we're
in the same place right now with Cloud. We got there, Now we've got to get better at it. We we It feels like we're at Cloud one on one to me, if I think, if I think of it from a tools perspective, it really feels like we're at Cloud one on one. And I'll kind of explain way back in the day when I was in the asps net team and we you know, Scott got three the VP of Cloud and AI Microsoft. He left devdiv and became the e VP of that
tech. We moved over there and our job was to go build tools to help you as a dot net developer be able to get your application up into Azure. And I think of the tools he built and there they're good tools. I mean, you can you know some people laugh, it's the rightly published tools I got. I got some data just a week ago that that that tools used eight hundred thousand times a month. Wow. Correct. Now, of course that's not for production. That's going to be for just doing
developer interloops. It doesn't matter. Yeah, exactly. So you know when people say, you know, don't, don't, don't let your friends right click publish, that's bs the reality is as a developer, that's exactly what you're going to do, because if you go through your operations team, your IT operations team, it's going to be ten or fifteen or twenty minutes every time you make a change for them to go run their pipeline to get your
code up there. But I said, we're kind of Azure one oh one or Cloud one oh one because right click publish it publishes what a single application? Yeah, how many cloud apps today do we think on? You know, I ask the callers how many power of listeners? How many people do we think are actually building an app? It's just got I just have a web front end. I don't have a web back end. I don't have any of the other pieces of the that of that of that pie right.
And so that's why I say we're kind of a cloud one oh one is we're great for if you want to work on a single app location, you know, and I can parlay this in any ways. Uh, you know, if you're in VS code and you have a front end and a back end, what are you likely to do? I'm going to run two VS codes. I'm gonna run one for the front end, one for the back end. I'm going to start them both. You know, that's it's kind of klutzy if you're This is why I like studio. We have the concept
of a solution and having multiple projects. But even studios klutzy. I mean in studio, I mean, how many people know you can likely k on a solution and say managed startup projects and then you can select multi and then you know, set the order of the project start and all those important super important. But I don't think those tools are that's not the best developer experience. That if you run that experience, you have to choose which ones you
want to debug. You know you can you can decide to start them all with the debugger or start some with the debugger out, and then and to change that you've got to go into the goofy dialogue box and change stuff. It's just I don't think that experience is a great experience, and so it's
it's been. And I've said for a while. Visual studio is great for single apps, right, vis code is great for single apps, but we need to build great multi app, multi app tools because that's how customers are actually building you know, cloud apps today and should be building them, right like this idea of separate services. Of course, we've evolved as developers knowing
what we have in these tools and knowing how to be more efficient. Like I can remember the day the light bulb went off, and anytime because what I was doing was anytime I had to change to any like big file or any JSON file where data was kept or anything like that, I would publish
a new version everything, you know, kick everybody off the site. And then I discovered you know, file zilla FTP, and I could just go in there and copy over some new image files or some new static files or whatever, and everything would just work, you know, Like I see this as not only an evolution of tools, but in evolution of how we use those tools and how we get better as programmers. So let's kind of talk about what I think the future is for this kind of space. And I'm
going to start with the tool that my team built and we shifted. It built last year, so that's May of twenty twenty three. We built a tool called the Azure Developer CLI. And the genesis of this tool was, I'll be very frank, you know, we have lots of Dotinant customers using Azure and they are the majority, and we wanted, you know, in my current team, we want to make sure that we can get more Java developers, more Python developers, more No developers. I mean, the reality
is, I don't think it's a either or rule anymore. I believe most companies are using a variety of technologies and so nobody builds something entirely in one stack. That's the old, classic twenty year old Microsoft customer. I do believe we all have, you know, if you're doing some AI, you might have some Python. If you're doing some front end web you might have
you know, some some JavaScript or some Blazer. But we built this tool because we had various samples that we had created for Azure and on one on one of these days, we were doing a user study where we actually get on a phone call. And we got on a phone call with a bunch of Python developers and said, hey, here's this Python tutorial for getting your flask gap up into Azure and uh, and your goal is to get this up, you know, before we get off the call. So it's it's
it's a quick call. It's thirty minutes. At the thirty minute mark, not a single customer has actually published their Python app to Azure. Wow. In most cases, where they're at is they're installing stuff. Still, that sounds like my Python experience too. They weren't installing Python, Richard. They were Actually, we have this thing called a zy it's the Azure CLI and it's the way that you would, you know, manually provision Azure from the
command line. At the time we have fixed this install. At the time, the installed for that was not very fast. Many of these Python customers were using py charm, you know, they were not using vs code. And what do our docs say. Our docs say install vs code. So here they are going, I have to use install a different developer tool. I've got to install this asy thing. I didn't have to authenticate all these things together. I've got install the Python extension for vs code, and we're
like, wow, this is not good. We're thirty minutes in and nothing's going on. And so we built a tool to address that exact problem, which is like what you do is you with AZD. That's the Asure Developer c ALI. It's a single lexy which means it does not required MSI installer or anything like that. You can actually X copy or just copy the file to your computer and you only need the one file to do all this kind
of stuff. And templates can be marked with some special folders. There's a older called INFRA and that would contain the BICEP, which is the that's the definition language for for azure. Azure is actually built on top of something called ARM, and then by step is an abstraction on top of ARM to make ARM easier to use. But you've got this by step in there. And then literally now I can take the rate the repo, I can clone it, and I can say a z D in it, give it a name,
I can do a z D up. Tell it what you know data center? I want to use region, I should say and subscription And then the whole processes takes off and no longer am I running you know, command line scripts. I'm not installing command line stuff. You get that great experience. And so we we built this experience, and uh, we haven't got as far as I want in it, but uh, a real change happened about six months ago. The dot net team is working on dot net Aspire.
That's their cloud native framework on top of dot Net, and uh, you know, Aspire is super exciting to me as as a dot net What I'd like to tell people is we built all this great capability into dot net ASP dot net Core years ago. We have the ability to do an HDP client factory and you can actually use something like poly to set resilience rules. On top of that, we built tech for ef core lets you do retrit policies. When you're in the cloud you might need to be more resilient.
We added open telemetry APIs to dot net a couple of years ago. But all this stuff I just described, we didn't turn any of it on by default. And so you know, if you happen to watch a video of a Glen Condron and me in dot core three days, you would have seen
a show the HP resiliency stuff. But if you missed any of those things, you don't know how to do this, and so we kind of learned that as you're if you're a dot net developer, lots of challenges come when you start trying to run your wrap in the cloud and we don't really help you. And so the the Aspire framework uh is literally, hey, let's give you a paved path with all the right things. And so where this
gets interesting is is the Aspire folks obviously want to make their tech. You know, great, if you could publish an a spire application it's going to be a multi part application. Uh, you can, you can publish that application to a cloud. And uh, we all got together and had a conversation. It's like, hey, do this the visual studio team build this? Uh? Do we use the A z D tech that my team is
built? Uh? Do they build something new? And we kind of all came to an agreement we should all just centralize on one one piece of tech that actually does this, and it already supported you know, multi project applications already a c D and so we've built a z D to understand a dotted Spire application. Yeah, so let's if you don't if people don't know what Aspire is you know, I was mentioning before I thought our tools, our
visual studio tools are kind of clumsy. When you create an a spire application or you add Aspire to an existing ASP dot net core project, what happens is we create an app host project and we create a service default project in your in your solution. So if you've got your you know classic you know, Razor page or Blaser application or web api, we add this new app host and it's kind of the magic. It's the orchestrator. And so the idea is the app host you codify. Inside that, there's a builder like
we've we've had in the as net cortech forever. And with the builder, you can build or you can add a project. You can add multiple projects. When you control that five we run that project and it's that's project jobs to start all the subprojects that depend on it. That's why it's the orchestrator, right. And so imagine you've got a front end, you got a back end. You can actually you can do a with reference your front end. You say, with reference to the front end, that tells the tech
order is important start this before you start that. And uh, that's kind of the genesis of a of a of a dot net at Aspire project. And by the way, everything's configured for you to fall into the pit of success. Yes you don't. You don't have to worry about how do I do that h T t P client factory thing? Again, I can't remember that? Yes, so yes, so there's that. There's that default project that is added to your solution as well, and we inject a call to
that in each of your projects. You would add a spire orchestration to and so what that if you if you if you just trace the code of that, that's going to turn open telemetry on, which means you're going to have proper telemetry. It's going to try to turn the retry stuff on. Uh, so your APIs and stuff like that. Your HP clients are going to actually be resilient. Uh it's going to turn on service discovery, which is
my favorite feature. And when I say we're kind of cloud one oh one when it comes to our rightly published tech, service discovery is a big piece of this. And let me just quickly get kind of go through each of those things. Open telemetry, you know, we'd love your if you're running an app in the cloud, you'd like to have telemetry, right, you'd like to see how it's running, where the crashes are, how long things take, what's the order of execution. We've had those APIs and gotten it
for a while, but they're not on by default. The resiliency we've already talked about. I want to have a retry policy, so if my API has a problem, it tries again. Because I'll be honest with you, in a big cloud network is kind of virtualized, and it does, you know, have its moments. They things don't always work the first time, but if you just try a little while later, you'll probably be all right, probably okay, And then finally you know, we've all done this.
If you've if you've if you've been using ESPN net core, and you build a multipart project, what do you do. You You go into a folder, you open up the loss settings, you find out what you know, local host port you're on, You hard code the port into your other application, and then when you when you push this thing to the cloud, you have to go find some way to go fix all those to map to the real things in the cloud. So that service discovery, yeah, service discovery
is, and so service discovery in an Aspire application. In that app host, as you add a project and project or service or whatever, you give them all names, and then when you reference those from your applications, you use the names, not the actual low level you know, local host and port numbers and all that kind of stuff, all the individual components. And
that's important. Yeah, that's important because locally we can do all the magic for you, and then on the cloud push we can also change those from being local host colon X y z to as your container app dot whatever or whatever terminology the cloud thing that you're going to go published to is. And so suddenly I've got a great control that F five experience. Locally, I can actually publish the app and it still runs in the cloud. And then
that's where my tool chain comes into play. So what your next step is is to basically take that application and I'm gonna I'm gonna go the low level way. First, I would go to command line and in the folder of the rootfolder of the application, or I should say applications if it's a solution with multiple projects, and I would type a z D in it. And when I type that, it's going to ask me for a name for my thing. My resource name. Well, first off, it's going to scan,
So it's going to say do you want me to scan? If you press return, it's going to scan the folder. It's going to go find, hey, I see an Aspire thing here. It's going to say, I found an Aspire application. What name would you like to use for this? As I publish it, you give it a name and you're done.
And what it's going to do is it's going to create an Azure dot yamal which kind of describes what's going on and it It doesn't do much more than that at this point, but what you can do at that point you can say acd up and then it's going to go ask you what is your asker subscription. It's going to say what region do you want this application to run in? And once you answer those questions, it's going to start building this application and publishing it to the cloud for you. Wow, now there's a
couple of cool things here in this Spire case. Typically you're going to publish this to containers in the cloud. Well, if I'm a container dev, does that mean oh crap, I need to know what doctor files are, I need to know what helm charts are. Yeah, Cubernetes and all that
stuff doing to have doctor Desktop installed. And the answer is no, no, and no, we can actually build the entire application because in dot net seven we added the ability to actually build contains without having any of those types of tools on your on your on your machine. So it's not just that you're you're using those tools under the hood and hiding them from us. You're actually not even using them. We're not even using them, and and that's
that's a cool thing. Is like one of the things a very So this doesn't going to AKS, so you can go to AKS as well. Okay, and once again we're just building, but it's not by default, we're
just building containers. And so you know what, once you build a container in the cloud world, what you typically do is you're going to publish your container to a container registry, right, and then the service of your choice, whether it's something like as You Container Apps or it's akas, it's going to have an action where it's going to pull that image and boot that image up. And so the build aspect of it is actually kind of irrelevant for
the most part. For one point, oh of Aspire, which is going to be out in the build time frame. It's going to ilga it built twenty twenty four. We default uh these applications to Azure container apps, but I should I should step back and say with preview six, our friends at AWS have built their tool chain for this as well, and so this tech is not you know, we're not trying to make us fire be a Azure
only thing. It's meant to be a pluggable ecosystem where you can plug the tools in for whoever you are, So if you're Google or AWS, this all works there as well. The a WS folks have already written some of the techs so they can you can publish these to a WS and we have some tools where you can actually publish our thing to as your kubernety service as well, if that's if that's your choice. But by default today it's going
to do container wrapps. And part of that is I would always say, let's get one of these things really good right first, before we go and try to do like multiple options. But you know, at azd up it's going to go provision all the resources, get your wrapp running in the cloud. The service discovery is going to mean you don't have to worry about changing the ports and the IP addresses of the individual applications. All thats going to work. And uh, you know, I said a lot of coli here.
You can also go to visual Studio. You can write, click on that app, post project, and you can select publish. And what's going to happen is behind the scenes, it's going to do the same stepside is described. It's going to ask you a couple of questions. It's going to then actually run a z D for you, and a CD actually creates some assets. It's going to create those assets and make sure you never see them,
so it kind of hides the whole thing. I mean, arguably that means you get to deploy an Inspire app to your local container store too on prem Yes you could. Yeah, Like it's just they just it's just containers. Run them where you want, run them where you want. But I'm
excited that we built this tool. And you know, you you folks have been along for the whole dot ne core journey, and we said with dot core, we're going to start with command line because everybody has command line, uh, and so I'm excited that it with with Aspire and a z D, we start with command line which means if I'm a VS code developer, I've got a multi part project, I can just azd up that thing. If I'm in visual studio, I can obviously the reight click publish and we're
going to you know, up that thing. And you know, unlike what we said before, this is not the single rec click published where I can only up, you know, do my front end manually or my back end. This takes the entire app. We have that that e shop, which is one of the examples we've had in dot net for a long time. That's got like eight containers and databases and rabbit mqs and a bunch of stuff like that, and you can azd up that thing and it'll put that whole
app in the cloud. And so it feels like we've graduated from single app or our single piece of an app to now we can do your whole app to proper multi app. I mean, this is what we used to spend a lot of time with when we're building these distributed apps, building CICD pipelines for them. Yes, was making sure all those different pieces got their updates and rolled out in the right order and so forth. Like dude, that
was a lot of yam, a lot of yam. They had to craft your my favorite language, and guys, I got to interrupt for one moment for this is a very important message, and we're back. It's not that Rocks. I'm Richard campbelllet's Carl Franklin. Hey, talking to our friend Scott Hunter about I mean, really, I love this thinking that all cloud apps are multiple apps, and most of our tools are oriented on single apps.
So how do we get to better tooling that thinks multi app And also when it comes to cloud like what you're talking with aspires, there is a natural hierarchy. If it's an Aspire app, there is an orchestrator that's where you begin on a lot of stuff. And so the CLI tools and all the tooling when they see an Aspire app go oh, let's talk to the orchestrator first, be the first needs to be deployed, and then pulling each of the services like it's not an amorphous blob. There is a distinct set of
layers here. I laugh because I cannot remember the project. Maybe you do, Richard, there was a project like this in the early Azure days. Somebody that's that's listening to this podcast will actually reply to us and tell us what it was. But there was I remember back back in early early Azure days, we had some visual tool where you actually had a whole XML file that described your application, right, And I'm going to laugh because that was
too complicated. I think this is a much better version of that. I forget what it's called. But we and we talked. We've talked about this for years, right exactly, that there's going to be this tool where you're going to draw out all these bits and set up and it's going to generate the orchestration for you. As much as I've complained about YAML, XML is worse. Yep, true, I much rather have YAML than XM to deal with. True enough, I will tell you that as well. It's it's
uh, XML just hurts. It just hurts. And it feels like, I mean, all these these these file formats are a little rough because I feel like if I make an error in any of them there they're not forgiving of errors. Right. But but XML, as we added schema and all these other things to it, it just felt like it has became this huge pile of complicated tech. But this whole deployment pipeline stuff and writing all that Yamel, it's still super bespoke, like every app you end up crafting your
own. At best, it's cut and paste. Like I feel like we're feeling around with stuff like BICEP and Poloomy, feeling around for reusable chunks of deployment management. I just haven't seen a good solution yet. I don't think we have a good solution. I'll be honest with you. Even inside of
Microsoft. You know, when first first started doing Modern Nature, we had ARM, you know, which is this description Jason Fiola describes, you know, all the app and the problem is, you know, like any of us on this call, if I want an app service, I'm like, well, I want an app service with four CPUs and thirty two gigs a
RAM and X amount of storage. But if I, if I, if I define that definition and ARM, I'm going to start talking about the networking layers and all this stuff that is just you know, that's beyond me. I just if I go to the Azure portal, I just say I want an app service with this much stuff in it in this area, and what it does is it kind of creates all the other stuff for me behind the
scenes and so BICEP is a little better. But one of the things that we're exploring is can we build what we call BISEP modules that actually have a bunch of smart defaults in them so I don't have to describe that for us. Yes, and so I will tell you my team thinks about this all the time. We have a workstream looking at this today. It's like, we don't want to build, you know, another abstraction on top of BICEP. We've already got two abstractions, ARM and BICEP. Let's not build another
one. But is there a way to go at smart default And if you're a customer, if you have the Azure portal and create a resource, you did get a bunch of smart defaults. You didn't answer eighty five question to build an app service, you answered four or five. If you run asy the Azure command line tool. Once again, it's the same kind of thing. You don't specify every single thing. Uh, there's a bunch of smart defaults there, and we'd like to find a way to bring that to the
BICEP thing, which means humans could actually write and understand by SEP. That's a that's a goal that we all have. Yeah, well, and I'm when I'm wearing my enterprise architect hat, it's like reuse BICEP code. We've written, Hey, we've you know, put a bunch of policies into the right way to do this, and it upsets me that we're cut and pasting it between projects. You know. I'm over in Belgium right now, and on the plane over here, my colleague Paul wrote six hundred lines of BICEP
on the plane and I'm like, I couldn't do that. I could write sixer lines of C sharp, but I can't write six under lines of bytep. It would mine would It would not work? Yeah? Do I want to be good at that? Right? Like the area lies the problem? Like if you're at a place where you've gotten good at that, Like, what do you do with your time? You charge lots of money Richard, Yeah, I guess so, you know, because most people don't want to do it, and the one person who knows how to do it is very
busy. Right. But you know, back to the tooling that we talked about for Aspire, I think there's two other aspects that are pretty cool. Is with AZD if you want in the case of these dot net projects. These are spire projects. You don't have any BICEP. There's no biceps sitting out there for you to see. You do that AZD up, we actually
generate BICEP behind the scenes. We run it and we kind of get rid of it and then goes away, which you know, this is the same stuff we started doing with databases, where we would generate you, here's the state of your database, here's the state you want to get to. The script to do the transformation is generated for you, and then it's gone. But we do know some folks are going to care about that stuff, and
so we did we did put tooling in for that as well. You can run AZD infrasynth right, and what that tells it is to synthesize the infrastructure. At which point what will happen in your Aspire project is you'll get a infra folder I n f R A and inside of that you'll get the BYSEP that we're going to run to publish your app to Azure. This is the
same thing we did with dba's when they were anxious about this automation. It's like, I will let you validate each one of these scripts and he could, and after a while they just get tired of reading it because it's better code than they could write. It's good, it's good code. I was actually I'm using an alpha feature of Aspire right now that I think it'll probably
be available with the general release of Aspire later this month. And in my case, because I have to run this in an early access data center, I actually have to generate the bi SEP and then I need to go change the region of one of the components because all the components that I need I need from my Inspire app can't run in that special data center, and so I need to go flich one of them to west US, and so I just have to go search for log analytics and then where it says location,
I just put hard code that to west US right and bang. So there are cases and valid reasons you might want to go edit this stuff. Yeah, I mean, is that the right way to go about it? Or is it? When you do the generation, say, and when you have to decide this make it this like this seems like a parameter in that call it technically is a parameter. Today, when you when you filled in the location you wanted your app to be in, you actually use the parameter.
But in my case, I had just had to choose an early access preview area which doesn't have all the services, and so in my case, I had to make a bad choice and then I had to go fix my my my bad choice right just because it was a very specific case. Yeah, I'm running alphabets of even the services, and that's why in my case it's But the point is you didn't have to hand craft all this stuff. You
still cold use generated code, edit it, then run it exactly. That's my point is if you if you want, you know, BICEP that you want to hand off to somebody that so they can see the actual bits of how this work, then it's all there for you as well. The cool thing about Aspire is, you know, let's say I started off with two projects. I've gotten my web front end, my web back end, and
I decide I want to add a red as cash. The cool thing is I can also go run that ACD infracynth again and we'll look at the project folder again and we'll see, oh, you added something new, and that new resource will just show up in there. And so you can rerun the tools as you add things or add projects to your solution and they update the final piece that I think is really exciting for me. On the Inspire cases, let's talk about we just talked about a cash or a Postgres database or
a SQL database. What do all these things have in common? Connection strings. Connection strings suck as well because well, if you're doing local development, you probably have a connection string to something on your local machine, and then when you push this thing to the cloud, you need a connection string to something in the cloud. And Aspire supports this mechanism as well. So just like we talked about service discovery, when I write an Aspire application, I
don't ever see a connection string anywhere ever if I don't want to. So in the case of I can go back to that you know, that app host project, and I could say, hey, I don't have a project. I have a reddest cash, and then I can keep that red ast cash as available, and I can say my web front end has a has a with reference to that reddest cash, which then tells the Spire make sure you boot the API up and the reddest cash up first. But even better
to add that reddest cash. I went to my app host, I write clicked, and I said add an Aspire component and it gives you all of the cloudy you know, back end kind of component you can add there. I add that that same with reference also takes the connection string information and injects it into the web front end project. And so when I'm in the web front end project, I write click and I add an Aspire component there, and I would select like I could do output cash with Rettis, I could
just do stack overflow rettus. I could either of those things. But when I add them, I don't have to add the connection string. All I do is when I when I when I create the API there, I just give it the name. And if I called my cash cash in the app host, I call it cash in my front end. And once again, Aspire is doing all the magic to share the connection strings across those boundaries, and so I never see a connection string. And even better, I can
embed it in my code by access exactly nowhere in your code. You have this dangerous connection string embedding that you're going to check into source control, get yourself in trouble. If you're in public repos, it's just all gone and well, because in the end it is plumbing. So just make it for me. Make it for you exactly. And so I've had more fun the last couple of months as we built the tooling for Aspire and using Aspire and just seeing my apps and I'm like, you know, I don't see it.
I don't see courts, I don't see IP addresses, I don't see connection strings. And you think this is trivial, But all of us building aspnt net core projects have opened up the launch settings dot Jason file and copy and pasted these things around your application. Or worse, you probably put a connection string in source code somewhere and you said, I'm not going to check it in, but you did. I mean, we have you know, we have user secrets, which is a mechanism in ASPNT core to hide these
things. But I'm in Microsoft. We have tools that scan our repos and tell us when we make mistakes like this, and they go off more than you would expect. Now I've had I've had get hub barf back at me and say, this looks like an extra string. I'm not checking this in the way that gets even cooler is if you're in the Azure space. In many cases, one of our one of our goals in Azure right now it's been there forever. We're doubling down it right now. Is you shouldn't even
have a connection string. We have a ability and Azure called managed identity and the let me let me explain the idea behind managed identity. Uh. In the idea of managed identity, I created managed identity resource, and I tell my web front end that via not via code, via either the portal or via command line tools, I say that the web front end can talk to the reddest cash and so there's nothing to steal because we've just codified or or
we've used infrastructure to say these two things can talk to each other. You'd have to break my log in. Yeah you can't even Yeah you can't. If you, if you, if you even got to the portal, there is no connection strength, there is no there's nothing. All you do is is reference to the redest database and we just make that happen. And so, uh, that's the point we really want to get to in the Azure space. We're going to get to a place where there is no thing to
steal. There is nothing that could be checked in because they just don't ex
exist. One step above key vault. Yes, you know, key vault is our solution if you have to have a connection string right, and that this is one of the coolest aspects of the Azure components for Aspire is if the service that you're using supports managed identity, when you publish that app to Azure, the Aspire published tech will actually create the managed identity, set the roles correctly, the permissions correctly for you on that managed identity and there is
no there is no connection string at all. If the service you're using does not support managed identity yet and I don't think there'll be meaning services by end of this year that don't support managed identity, we will then go and take that connection string, shove it into a key vault, and create the key vault for you. And you know, once again, as a developer, I don't have to think about that no, and you can't get it wrong
either. Aspire is abstracted all that away from me, and so you know, I I'll kind of end on. We don't think this Aspire tech is necessarily just a dot net thing, you know, it's it's a Chris Harris on my team works on Python and he has used the same Aspire host project for some of his Python applications. So he can get some of these same capabilities of being able to have the tech, you know, build the infrastructure, set up all security the right way, and do all those types of
things. And so I do think you'll see us. You know, this is this is we're past one on one, maybe we're at two oh one now at least for dot net. But we want to make sure that this multi project run, this ability to create the resources unpublished and have resources locally, all of that. I would love to find ways to make that work for all developers in all languages, because, as we said, very likely
I've got a view front end talking to a dot net back end. People mix all these technologies today already, and so you know, Aspire needs to be more than just dot net island. It needs to be a technology that runs everywhere. And you might have heard we talked about it probably on a podcast. In the past. There was something called Project Tie that was the predecessor to this. Project Tie was to dot netty. The stuff we're talking
about now, like the multi project Runner. That's a that's a thing called DCP. That tech was actually built independent of a spire on purpose. So we could actually take all this tech and make it work for all languages. A c D obviously was built. You know, it's not it was not. It's not a dot net thing. It's built for all languages, and so the building blocks that were building. Uh, hopefully we'll let us take this experience and make it, make it cross language, you know, a
cross platform. If there's somebody out there listening thinking that they're not quite convinced that, you know, using dot net a spy or won't pigeonhole them and give them sort of these high level abstractions over things they can't manage or understand. Can you that person? Yeah? I I The reality is you know, if you if you look at a Aspire project, when I say a couple of things we talked about the defaults. Those defaults are codified and so
there's nothing. What I would say, the biggest thing is when when people first see Aspire, the first thing is they, oh, this is magic. No, actually it's not. You know, there's a file that contains all the defaults. And what's cool is we make that a project that you own. You can change those defaults, you can add your own new defaults, you can remove our defaults if you don't like those things. If you
don't want to use our service discovery, take it out. If you go look at how service discovery actually works behind the scenes, there's nothing magic there.
The cool thing is when I demo this, I would normally run the app and I would go in and show the environment variables to the front end, and inside the environment variables to the front end, what you're going to find is we injected the same local host port number stuff as an environment variable, and all we're doing is actually reading that environment variable and using that in
place of a hard coded string. And what the host is is the thing in checking this, and so what you as you dive deeper into this, what you're going to find is there's nothing locking you into anything here at all. In fact, crazily enough, if you want to take an Aspire app and you just have your own container, that's another feature of the host. I can go point it at any random container image and I can give it the port numbers and all the stuff required to talk to that, and we
can run that. In fact, that's how we do some of the JavaScript stuff. We actually can run and we can run no JS projects. So would one think of this as more like the ultimate visual studio template for creating an application. I think so in the cloud, right, I mean, yeah, yeah, I mean a template that goes beyond your desktop and and solves all the multi app problems that we have today. And they said, the multi app problems are way more than just a dot Net problem. There
everything. But as you what I would tell somebody is go read the Aspire documentation and you're going to find out. You know, we learned this when we built asknet core back in the day. One of the one of the negatives' web forms was we had a whole bunch of automatic stuff that was on by default. And that's also probably why a spire took so long to build. Is we still still have a hangover from you know that. But notice that I said, those defaults are actually in a project that you're referencing,
you own it. The idea is, you know, you can change you know, unlike web forms where or I guess webforms is the right term for that. There was not a good way to change any of these defaults and web forms. You could change some of them in webconfigure, you could change modules and stuff like that, but you really had to know what you were doing. And I think this is just it takes the askinet core mechanism of codifying the whole pipeline and just continues that. It gives you control over the
what's and the details as data. Yeah, yeah, I love it. And by the way, it won't be perfect and Willship a v two. Yeah, it's going to continue to iterate. The infrastructure is going to change and all this is going to get better. But one of the things I'm excited about in this is this means scaling by default, like you're in a structural naturally scale. This means the the the idea of securing each individual component, limiting the number of parts that are open, like limiting the attack surface.
Because we're writing this as a manifest rather than doing it ourselves, and you're generating against it. You can close all that stuff off. You can lock it down as hard as it can be locked. And I don't have to write it like that's the main thing is most importantly right, I don't get this stuff right, or you don't have to go read through six thousand pages of documentation to figure out this stuff's even there. I mean, that's the biggin way is I'm not gonna do not do it. We know if
our customers don't do it too. And that's that's that's why I think these types of things are super important. We have a person whose name is Uli, and I don't think I'm over sharing. He's the person that if you have, you know, if you're a big customer and you're having an agurve problem, you might call him and maybe he parachutes into your organization helps you solve your problem. He gave us a bunch of crap and ASPI net Core.
He was like, He's like, you have all the features, but they're not onned by default, and I have to just go to these customers and turn the features on by default. You know, we also we skipped
over heavily. I think we're almost I don't know. We won't have time to go very deep into this, but you know, a really cool part of the Aspire tech as well is those defaults turn on all the open telemetry work, right, which means now when you run this application, you get a dashboard, and the dashboard is going to show you all the components. It's going to show you your crashes, that's going to show you the traces
in a structured way. You can search for them. You know today you would basically go to the cloud and look at logs, and this this gives you a much better visualization. You can see your call path from the front end to the back end of the database. You can see how long each of those steps took, and so I think the telemetary aspect of this is super cool. One of the demos I've been showing that this is not public yetuntil we ga Aspire later this month, is being able to run that dashboard
in the cloud as well. So you'll be able to take the same Aspire dashboard you can run locally doing interlop development, and when you publish that to the cloud, you're going to see that same dashboard running in the cloud. Now, it won't be perfect because the dashboard doesn't have storage, which means
it's going to show you more real time stuff. If you want full storage, you're going to use something like Azro Monitor, but that's going to hook up to the same open telemetry hooks that we're using for the dashboard, and so you know, I laugh. When we were looking at ASPN at core, we recognized in aspn net web forms we never had any telemetry at all. We fixed that with ASPN at core and then with Aspire we fix that even more by wiring it up by default. All right, real quick,
last question on PREM. I know it's not a question, but yeah, it is a spire cloud only? Is it as are only? Can I do this kind of stuff on prem? You can do it on Prem. I have to think harder about that. I mean, one of the things that as a developer when I'm running on Prem is and you might have already seen this, Carl, in many cases, if I want to run a postgress or a Rabbit MQ or a mysequel or even a SQL server, when you run your app locally on your machine, it can run those technologies and
containers. Ye. You can also decide in your app post that when you reference these things, you can give it connection strings. Those connection streams could be to local resources. Yeah, I mean all this stuff is open source. I'd have to just build a provisioning mechanism that, when it's running, say, generate this stuff on my servers rather than the ones that are going to generate it on the cloud. Right, you wouldn't use AZD to publish
this because an't isn't it is octopus deploy or something like that. Yes, yeah, well cool. But I can imagine somebody's going to build up this code base because they do want to deploy it on prem or some part of it on prem. Yeah, you know, there's no reason. It's just containers. There's no voodoo here, Containers run anywhere. Good stuff, Scott, but I'm afraid we're gonna have to leave it there. Thank you.
It's always great talking to you. I'm glad we got to catch up with you, and I guess it's dinner time where you are now, so yes, enjoy Thanks folks, all right, we'll talk to you next time on dot net rocks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online
at pwop dot com. Visit our website at d O T N E T R O c k S dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you check out our sponsors. They keep us in business. Now, go write some code see you next time you got R Medlevans. The