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