Speaker 1: 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.
Speaker 2: Will be at as many NDC conferences as possible this year,
and you should consider attending no matter what. The Copenhagen
Developers Festival happens August twenty sixth through the thirtieth. Tickets
at Cphdevfest dot com.
Speaker 1: Ndcporto is happening October fourteenth through the eighteenth. The early
bird discount ends June fourteenth. Tickets at Ndcporto dot com.
Speaker 2: And we'll see you there.
Speaker 3: We hope.
Speaker 1: Hey, guess what it's dot net rocks again, episode number
nineteen hundred and nine. Yeah, what's up. I'm Carl Franklin.
That's Richard Campbell.
Speaker 2: How do you? How are you? How are you? Hey? Summertime?
I like summertime.
Speaker 1: Summertime is good. And today it's actually the heat lifted
a little bit. Oh good, humidity is low. It's going
to be a nice sunny day here in Connecticut.
Speaker 4: I don't jinx it. Don't jinx it.
Speaker 1: Yeah right, I mean I could. I could say, you know,
the Internet is working, there's no problems with it.
Speaker 2: Don't be crazy now there.
Speaker 1: The reason we're laughing about that is because there is
a major outage this morning, the CrowdStrike problem.
Speaker 2: Somebody pushed out an update on a Thursday, and it
is literally raced around the world and causes machines to
blue screen. And now that they're cleaning it up, of course,
presumably when you actually hear the show two weeks after
we recorded it, everything will be fine, or you'll never
hear the show because the world has collapsed.
Speaker 1: I saw a great meme on Facebook of there's there's
this picture of a little girl turning to a camera
and she's watching a house fire and it might be
from it didn't it didn't look like it was from
fire Starter. Man, It's like meme photo, right, it's a
meme photo. Yeah, with the little girl's looking over her
shoulder at the camera and smiling.
Speaker 2: Riley, Yeah, a bit of a diabolical smile.
Speaker 1: Yeah, and so there's a blue screen of death pasted
over the fire and it said Linux users be like.
Speaker 2: Well, once again we have this reminder of how and
because it's shut down the airlines. Oh yeah, right, like
people use the software everywhere and it's like, once again,
reminder of software runs the world. Maybe we need more discipline.
Speaker 1: We should also dispel that myth that Azure had a
problem too, right, yeah.
Speaker 2: Because clearly it wasn't Azure. It was virtual machines and
virtual pieces that were running CrowdStrike. Yeah, the blue screen,
and then people were complaining that Azure was failing, but
that's not the case at this moment, right right, every
who knows again you're going to hear this two weeks
after we recorded it. We're in the midst of this
thing right now, and I'm like, I have all the
empathy in the world, you know, especially making run as
and collecting all those stories from administrators, like do not
throw stones in your glasshouse, man. We're all got our troubles.
Speaker 1: Right, We won't attempt the gods of vengeance and irony.
They they have a way of smacking us down.
Speaker 2: Yeah, they'll let you know.
Speaker 1: All right, I got a nice one for better no frameworks.
So rowl the crazy and you is it awesome? You know,
somebody actually emailed me. Maybe it was a tweet I
can't remember, but they said, hey, can you publish the
words to the better note of framework theme?
Speaker 4: Uh?
Speaker 1: Really there are no words or something. I don't know,
maybe it was maybe it was that, but you know,
they literally are dude it, dude it, dude it, dude it.
Dude do that's it?
Speaker 2: That's the whole thing.
Speaker 1: Do I really need? Okay, maybe they were just joking,
but so what I have to talk about today is
something near and dear to my heart. It's a Blazer puzzle.
Oh yeah, and I know, yeah, blazer Puzzle dot com.
I know I've talked about it before, but I wanted
to just tell remind people about this. Jeff Fritz and
I do this weekly. This is sort of an offshoot
of Blazer Train. Once blazer Train got saturated with topics,
you know, and it became more about maintenance for new
versions of dot net. We started this new thing. And
the whole idea is that we give you a problem.
Maybe we say, here's a program, a simple Blazer app
and there's an issue, what is the issue and how
do we fix it? Or maybe we say we want
to add this feature, how do you do that? More
nine times out of ten it's a problem, and usually
it comes from real world problems, problems that Jeff and
I have had when we're developing apps or you know
we see junior developers making because they make assumptions. So
it's really much more than just fun and games. And
it is fun, and they're small videos, they're ten minutes.
Speaker 2: I just think it's a good idea, right, A little kata,
you know, coding exercise tackle make you think differently about
the thing you do every day.
Speaker 1: But I actually went I had an issue and I
was like, how do you do that again? And I
went back to the Blazer puzzle, you know, like episode
in the in the first ten or the first twenty.
I found the answer again. So it's not only good
for you know, just fun, but if you have a
problem with Blazer or something you don't understand, it's it's
good to go look at Blazer puzzle dot com and
see if there's a solution, because every episode has a
GitHub repo with a read me that illustrates the problem
and then there's a solution folder that has the you know,
the code that actually works, plus the read me updated
to include the solution. So great idea and stuff. I
love it, Blazer Puzzle dot com. That's what I got.
I was talking to us today, Richard talking about cloud.
I grabbed a coma of AV Show eighteen ninety seven,
which is the one we did with a VP Scott Hunter.
Maybe I heard of him, Yeah, my friend and a
regular keynote for deb Intersection coming up in September. By
your tickets now. And this comment is actually from Serge
from Omega, who said it's not the first time I've
heard Carl saying how much he hates the yamal format,
but not as much as the XML format.
Speaker 2: Richard and Scott seem to also share this sentiment. Nobody
appears to have any problem with Zamal or even Blazer
components that are based on the XML slash htmail format.
So I'm really curious what is it specifically it makes
you dislike XML per se?
Speaker 1: So should I which should I talk about first, Yamal
or XML.
Speaker 2: Well, you actually commented on the comment about that's not
really crazy about examal either. Yeah, I don't know where
do you want to start.
Speaker 1: Well, Yamil is just one of those. It sort of
looks I just don't understand why it has to be
different from Jason.
Speaker 2: Well, they were trying to get rid of the curly
braces essentially. Yeah, But then now the structure comes in
the form of indenting, which is a nightmare, like to
try and remember the indents. If it's working, I find
YAMIL relatively readable. It's somewhat hard to figure out what
actually does, but when you need a debug, it's a bear. Yeah,
And thank goodness for visual studio code and color coding,
indents and things like that to just sort of give
you some cues as to you know what it's about.
But look, it's YAML makes plumbing code. It's why I
end up writing a lot of it because I'm involved
with a lot of infrastructure stuff, and so you never
are in love with it. You're not inventing new things
with it. You're trying to automate stuff to make it repeatable,
and so you got to pick it up and put
it down.
Speaker 1: I'm very used to Jason where I can go in,
you know, switch between code and Jason data. Right, I
can make a class. I can you know, express that
as Jason. I can express a class from Jason, and
I don't really have that with Yama at least I
haven't found a tool that does.
Speaker 2: I don't know that you would. I'd use your Adjason
for that. Definitely different tools for different purposes. You're right,
XML just wordy angle brackets are annoying. Clothing tags are
you know? And then you know there are times when
the structure of XML picks up more space than the
actual data than you're betting in it, right, And don't
even get me started on schemas. Good lord, but yeah,
I mean you grump about your tools at times. Inevitably
it worked.
Speaker 1: At the time, it was good and it worked.
Speaker 2: You get it done. But it's not you know, things
have all it's not delightful. It's necessary stuff. That stuff
you have to do. You know, we've all struggled through
XML annoying anyway, Surge, thank you so much for your comment,
and a copy of Music co By is going out
to you. And if you'd like a copy of Music
co Buy, write a comment on the website at dot
at Rocks dot com or on the facebooks. We publish
every show there and if you comment there at reading
in the show, we'll send you a copy of music.
Speaker 1: Go buy. Music to code by is still very popular.
A lot of people still using it. And if you
don't know what it is, it's twenty five minute instrumentals
that are designed to help you focus, and that they do.
Speaker 2: Yeah so, and if you keep if you use it regularly,
it makes you focus even better because it literally triggers
that in your mind. The only time I play that
music is I need to write yeah, right, and it
just drops you into that state almost immediately, you know,
after all this time.
Speaker 1: Yeah, Okay, Well, you know you can follow us on
the x Twitter if you like. We've been there for many,
many years, but the cool kids are hanging out. I'm mastadon,
I'm at Carl Franklin at techhub dot social.
Speaker 2: And I'm Rich Campbell at macedon dot social.
Speaker 1: Send us a tube. That's another way that you can
get some music to code buy and get a comment
read on the show. Okay, let's get to the actual
content of dot net Rocks. I'd like to introduce our guests.
Jo Chinjiang Jochin is a product the manager on the
Azure Container app team. Previously, they were PM on the
dot net team and worked on products like new get
n any framework in asp net. Welcome Juchin, good.
Speaker 4: To be here, Thanks for having me, Thanks.
Speaker 1: For being here. Wow, we have a lot to talk
first of all, but before we get into your topic,
is there anything that you want to comment on and
what we said already?
Speaker 4: Nah, I'm just an observer for this part.
Speaker 1: Yeah, it's kind of your mo isn't it Like remember
when we were talking before we tried recording this episode
before and you said something like, you know, I'm not
the expert on these things. I've just used them and
I have some opinions and some experiences to share.
Speaker 4: Yeah, that's right. And to give a bit of context there,
I know Hunter and Fowler and you know, all the
big names have said plenty about dot net Aspire and
you know dot net aid in general. And what I'm
bringing in is I don't have a whole lot of knowledge.
All my knowledge has come from screwing around, usually getting burnt,
and asking plenty of questions. So what I'm hoping to
talk about today is more of a big picture of
view on these buzzword topics, not from not as a
person who's built the actual thing. But as someone who's
been using it a bunch, and I've been talking to
a lot of people who've been using it a bunch.
Speaker 2: Great, So, how do you even describe Aspire? Because I
think Fowler struggled with this when we talked to him
back in January, Like, I know he helped make the
thing and he knows it's important, but how do you
tell people about it?
Speaker 4: Yeah? So I've spoken about Aspire at a couple conferences
so far, and I've learned the hard way just how
difficult that particular problem is. Personally, I think you know
a lot of conversation around dotnet, Aspire makes it seem
like this one coherent, concrete thing, right, Like you use
the spire. You don't use a spire where there's really
three functionalities that are part of it that you're not
locked into using all three. Right, you can pick and
choose from what you need. And those three functionalities are
the Aspire dashboard, which you know that's the big everyone sees,
the nice UI for viewing data, and then we have
the library of curated components. So it's nice to be
able to go in and see, all right, this is
something I can use. This is not something I can use.
I don't have to worry about things getting deprecated over time.
Then the last which I think gets brought up front
and center a lot, which is the orchestration capabilities. I
think different members of the dot net community have different
opinions on that one, because it is taking a lot
of existing functionality, things that you can you can do
in darker compose, and really putting it into a different,
hopefully more usable format.
Speaker 1: I like to and I came up with a good
way to, you know, describe it to developers who are
already used to, you know, the process, using visual studio
for example. I think of Aspire like a visual studio
template on steroids. If you think of what a visual
studio template does, it gives you all of the basic
things that you need to accomplish something.
Speaker 4: Right right right now. I think that's a great way
of putting it, because, I mean, let's take a step
back from dot net aspiring, but just talk about the
problem that is trying to solve.
Speaker 3: Right.
Speaker 4: So, micro service's big buzzword of the uh was it
the twenty twenties, even the late twenty tens, there's been
this huge hype. Everyone goes all right, like distributed applications, like,
that's the right way to write my application. Now, I've
seen a lot of people just get real disillusion to
get really just seeing the dark side of micro services
really quickly. I don't know how familiar y'all are with
the Gardner's cycle. M that's right.
Speaker 2: That's been talking about in the context of the AI wave.
Speaker 4: Oh yeah, yeah, So just a bit of additional context
for any viewers who are not as familiar. It's a
sort of you know, anything that comes out to hype
is going to be met with the sort of trough
of disappointment where they realize the reality of things.
Speaker 1: That's why my coffee tastes weird because this is AI coffee.
Oh no, it's AI coffee, and you know it just
started getting a little more bitter.
Speaker 4: That's right, that's right, that's not you Yeah, that's all AI. Right.
But ideally they move after that trough of disappointment is
the slope of the light where you figure out, okay,
this is how I actually make this useful for me,
and hopefully you reach the plateau of productivity. Now, you know,
I was looking at the talks for these conferences I
presented on and you know, half of all the micro
services related talks were about how hard they were and
alternatives and potentially even moving back to monolith architectures. So
I think there's this issue of people have to be
able to try micro services and understand that mental model
that does in a way that doesn't involve diving right
into the complexity of infrastructure and configuration. And what I
see dot net is yor solving is providing that mental model.
I think Carl put in a good way with the
templates on steroids, right, but just letting people think about
it in terms of functionality and code instead of hey,
here's the ten things you need to do in order
to even get started.
Speaker 1: But the good news is when you I want to
use one of those things in the Aspire template, let's
say it's configured correctly, right.
Speaker 4: I like to think of it as you know those
command strips or the hangars where you can just stick
a double sided tape on and just put it on
the wall. You know, you don't have to figure out.
Speaker 1: The structural integrity integration yourself.
Speaker 2: Right, Well, answer there in lies the problem. When you
start experimenting with this stuff, it's like have I just
configured it wrong or is my defective, Like there's too
many moving parts. So exactly, at least having this as
these carls is a template. I've also used the word
scaffolding to put all those right pieces in place, but
what are those right pieces?
Speaker 4: Right? Exactly? And everyone's scenario is different, right, You can't
go to Scott Hunter and say, hey, does this.
Speaker 2: Work for me? Yeah?
Speaker 4: You really have to try and fail as quickly as
you can, iterate as much as you can. Yeah, and
right now, it takes a whole lot of investment in
order to even get there.
Speaker 2: Yeah. It makes me wonder if developers don't get to
a place where they get it to work and don't
touch it.
Speaker 3: Yeah.
Speaker 1: Yeah, here's a story. One of my customers has a
Blazer server application and you know, it's doing very well
in the wild, and they wanted to add Aspire to it,
and so Jeff Fritz did the job and and it worked.
I mean, but that was a totally different, you know,
the brown Field experience, totally different from the Greenfield experience.
And it took a little you know, tweaking and understanding
and you know, duplication of some things, like we were
already using Polly in the application, and so we had
to figure out, you know, which which one we're going
to use the HDP client factory or Polly itself, that
kind of thing. But other than that, it was pretty smooth.
Speaker 4: I don't know how familiar y'all are with I don't
know the FIFA series of video games. You know, they
essentially it's this sports game.
Speaker 2: Where they electronic arts, right, soccer right right.
Speaker 4: It releases constant. It's been around for a while, and
they release new additions, And what I've heard is in
the recent editions they've changed the gameplay so that it's
easier to grasp for new users. But when you get
into the game, you have a choice of, hey, I'm
an existing user, I just want to use what I
already know, right, And then you can say, I'm a
new user and I want to do this potentially easier,
more intuitive method, but just something that would be a
pain for older users to try to grasp, right. And
I think for a spire it's the sort of it's
a similar situation, right where it's trying to give this
newer experience that might be a bit different than what
people are used to. Why offering this opportunity for people
with brown field applications to integrate in a way that's
more similar to what they're already using. So, Carl, I
think you make a good point of you know, you
can just poured everything in and say all right, it works.
Now there are redundancies. There are like choices of where.
Speaker 1: Do I go? Yeap, like any kind of you know,
thing that you're adding on exactly, especially something like Aspire
with many moving parts, you have to be careful not
to step on yourself.
Speaker 4: Yeah, and I think again it comes back to the
is dot now to Aspire one big thing? Is it
a bunch of different functionalities in one right umbrella of
a term? I think sometimes people think they need everything,
so they bring it all in and go, oh, it's
too much.
Speaker 3: You know.
Speaker 1: Here's another fear also that by leaving things out, you
will leave these dangling dependencies because things are dependent on
each other, and so how do you separate those? You know,
It isn't as easy as a wizard that says, oh,
I want to use these four features of Aspire.
Speaker 2: Go or is it right?
Speaker 4: Exactly?
Speaker 2: Yeah? I mean, what are the essential things you have
to use? What is minimal aspire?
Speaker 4: I see again, I think that depends on who you are, right,
If you're a new user, then I mean as let
me speak from my personal perspective as a new user,
And just to give a bit of background there, I
was on the dot net team for about four years,
and before then I hadn't heard of dot net at all.
You know, I was doing Java, I was doing c
and I think I mentioned it last time, but coming
to dot net was the first time I was interacting
with so many normal people who were developers, who are
trying to solve you know, more focused on solving actual
problems and getting two things working than necessarily how pretty
everything is right. And for me, the important thing is
to get to something that's working and to have a
general mental model of why is it working, how do
the pieces fit together? How do I start debugging things?
And for me at least essential Aspire really has to
do with the orchestration process being able to start off
and see, okay, here are my component pieces, here's the
app post that controls how all of these talk to
each other. But for someone who's more experience than I am, right,
who already knows dock or compose, who have done this
at gazillion times, maybe the Aspire dashboard is actually more
important to them. Maybe the library of curated components is
more helpful in.
Speaker 1: That library, I would say the first thing for me
would be open telemetry.
Speaker 4: The cool thing is open telemetry. Again for new people, right,
the observability of an application is not necessarily first and
foremost in their minds. They want to get things working,
and it's when they fall into the deep end with
the debugging that they realize, oh shoot, I actually have
to think about all this stuff. But with a spire,
all that open telemetry is built in. And I think again,
like the whole best practices thing, like what do you
need to think about even if you're not thinking about
it now because you don't know, you have to think
about it well.
Speaker 2: And I appreciate that it's telemetry is different from error logs,
right that you want to see how it's executed, right, right,
you know that you've got more instances piling up, maybe
running out of resources, any number. That's sort of that
landscape before the accident.
Speaker 4: Yeah, exactly right. And I think often you know that
fall into the deep end is because there's no insight
into things before the explosion happens.
Speaker 2: The machinery, it's nice as a new.
Speaker 4: Person to not have their first experience and in an explosion.
Speaker 1: Linux users be like, you know, you know, I don't know.
That just tickled me.
Speaker 2: That's very funny, But I gotta think the dashboard is
the candy part. Like that draws a lot of people
in are all struggling with insight about what's happening with
their software.
Speaker 4: Completely agree with that. And again with micro services, so
many moving parts, so many things that are sending information
to each other doubling back, and any bit of that
integration breaks. You know, the explosion happens, you have no
idea where it came from.
Speaker 2: Like you're just staring at it, like what happened?
Speaker 4: Yeah, right, just looking at the rubble and the yeah, yeah.
Speaker 2: Well that's the sad part is that you go into
the server closet and you look at the server and
it still looks exactly the same. The fact that the
site isn't running is separate. Yes, it's so hard to
tell until you get into this instrutration path. And then
the usual thing I run into with folks who are
trying to do telemetry for the first time is you
collect everything and you're just buried in messages that are irrelevant.
Speaker 1: You asked for it, here it comes, and.
Speaker 4: I want to bring them this and I think Feller
and Damian Edwards had brought it up in the past
around why Aspire was designed as it was. But this
term of progressive disclosure of you know, in English, in
human like lapers in terms, that's just we're not going
to throw all the information at you in the first
second of entering the space, right sure, like needing to
know all these things is important for building micro services
with best practices, making something secure, making something observable, right,
but you know we're still going to include that, but
you get to learn about it when you actually want to.
Speaker 2: Right, yeah, yeah, and appreciate that sort of or it
just looking at like the metric set, how they do
tend to bubble up so you see it from a
macro level and then you can drill down on the
things you care about.
Speaker 4: Yeah, yeah, And I don't know about you guys. I
think whenever I learned something, I need a skeleton of
information first. You know, it's like going on a Wikipedia article.
I don't want to be down to write into that
wall of text. I want to see the overview, right,
Like what am I gonna be learning about and then I'd.
Speaker 1: Be great if there was a podcast episode that you
could just listen to while you're driving or something.
Speaker 4: Ah yeah, yeah, something nice.
Speaker 2: Huh nobody does that? Who would do that? Yeah? And
I appreciate like when we talk about minimal, it's I
want that dashboard, I want that insight. So get the
telemetry working first. I mean, it seems to me like
that would give you the most benefit right away. But obviously,
like the orchestration part is important. Service discovery is one
of those things that once you understand it, I think
it's host. Where has this been all my life? Right?
But it's not obvious when you're just getting into the
space how important discovery is. Oh yeah, it does seem
like a later feature.
Speaker 4: Absolutely. Yeah. At first it just seems like, oh, I
can deal with the local host fine. Yeah, But then
things scale and then yeah.
Speaker 2: And then you've got to move it to another site
you're doing you're doing a rolling update or any of
those sorts of things, and all those hardwired locations make
you sad. Oh yeah, all right. Now I have three
versions of say micro service, because I've got older software
that's still depending on V one and we've got some
clients still using V two and we're now rolling out
V three. Boy, if you don't have service scovery to
handle it for you, you'll make yourself crazy.
Speaker 1: We're just gonna leave it in there and put a
comment that it's deprecated.
Speaker 2: Everything's to be fine. It'd be fine. Fine.
Speaker 1: Let me tell hey, guys, let's pause for these very
important messages and we'll be right back. I said we'd
be back, And here we are, nice and we're back.
It's dot net Rox. I'm Carl Franklin. That's my friend
Richard Campbell, howdy, and we're here with jas Chinjiang, product
manager on the Azure Container Apps team, talking about Aspire,
microservices and all good things. So where were we?
Speaker 2: I want to jump in on the on the microservices
thing because I feel like there's certain folte certainly it's
an all going conversation on DONNAE. Rocks about you know,
the modular monolith minse. It's just like, listen, I got
a monolith. I don't know that I want to go
to microservices, so maybe Aspire is not valuable for me
at all? I mean is that can I add Aspire
to anything running in the cloud? Does it have to
be a micro services And how will I know when
it's micro services? Like what does that even mean?
Speaker 4: Yeah? No, that's a really good point, right because if
you're thinking about it like just having a back end
in a front and like okay, I have two services, right,
like is this microservice? Is it not? And let me
know if you know this is at rocks, it's not
as your container apps Rocks or whatever. But I think
being on this team gave me this insight into microservices.
What is what is not? Like how just vague that
definition really is? It's terrible exactly, And just to give
you some insight, like on context for people around as
your container apps, it's built on Kubernetes. It abstracts away
a lot of the how to get things working with
each other and has a similar to a spire model,
where you're thinking about the big picture and the functionality
instead of the infrastructure and configuration. Right off the bat,
you'll see the majority of people on there are not
working with microservices, so to speak, or at least there
they have a monolith. Maybe they want to move towards
microservices at some point, but they just don't find it
necessary right now. And I think there's that big if
of you have a monolith, how do I make it
better in a way that is efficient and low risk, right, Like,
how do I try this thing out without diving directly
into the deep end of distributed architecture and all that?
And personally, I think Aspire is a way to experiment
with that, Like if someone is at that cusp of
I have a modular monolith, like I don't like, doesn't
need to be in micro services? Is it fine? As is?
You know, I think you can still bring again Like
Aspire is all just code, right, It's not like you
put it in and now everything's different, you know. It's
it's not a whole new game. It's just to tell your.
Speaker 2: Code just added some things to it to.
Speaker 4: Like in theory, right, So it gets right, right, see
if it actually makes your life easier?
Speaker 2: But is it as your container apps and a critical
part of this, do I need to have my app?
Speaker 4: Not at all? So I mean that is very much
built by developers, and like the whole idea of it
really came from the developers, And the idea is we
don't want to force you to use any tool, Like
there's really great integration with AWS. You can deploy it
to your own Kubernetes cluster. I think just I mean, honestly, right,
it's Microsoft, it's Azure like they will have a really
strong road towards as your container apps. And that involves
and I'm happy to talk more about this a little bit,
the as your developer CLI you had a az D,
you had another new acronym to add to the stable
of acronym.
Speaker 1: Before we get into that, I just want to make
a comment here that veteran dot Net developers, like Richard
and myself, we were we went through the whole you know,
series of years there where dot Net was evolving, and
very early on we noticed that dot net developers were
kind of looking at every new feature that came out
as if it was a zero sum game. Right, does
that mean we're never going to use this? I remember
the vb net versus c sharp wars. Does that mean that,
you know, c sharp is no longer the you know,
the language we should use? And you know, after a while,
it became obvious that what you're saying was true, which
is that, no, we're giving you more choices. None of
these new features are prescriptive or exclusive. You know, basically
saying that you should never use this.
Speaker 4: You should use this now, absolutely, And I think it
comes down to the people know the best about their
own projects. And yes, right, just because I work at Microsoft,
just because God Hunter works at Microsoft, doesn't mean we
can come in and say, hey, here's the best way
to build your application, right, Like, we don't we don't
know that. All we can say is we worked on
a thing. It has helped a bunch of people. Maybe
it can help you try it out if it doesn't fit,
and you can always roll back.
Speaker 1: Yeah, And the more you know about these things, the
better informed you are to make decisions architecturally on the
on the beginning of the project end going totally.
Speaker 4: Like if you if you try it and it doesn't fit,
at least now you know, right, as opposed to, oh,
there's so many different options. It seems like a lot
of investment either way. Now I got a question, Right,
you know it doesn't work, You're good, and I.
Speaker 2: Mean you're giving us some choice. But at the same time,
it is opinionated in the sense it's like, hey, if
you're going to do instrumentation, it's open telemetry, right if you.
Speaker 4: Feel strongly otherwise, sure, like you can make things work
for you.
Speaker 1: But if you're using Richard, if you're using ray gun
or some other tool that you know that is perfectly viable,
that's right. Sure, nobody's saying that you should switch to
using open telemetry just because it's.
Speaker 2: New and cool.
Speaker 4: Yeah, And I will say on the opinions piece, I
you know, it's great that dot net has offered so
many options over the year. I will say when I
first started, just seeing like the different versions of dot
Net I had to choose from, and the different you know,
just all the different options without necessarily an opinion on
hey do this do that? That was actually more difficult
to me than if I was presented with a couple
of different options, maybe one option at the beginning, and
then figure things out later on.
Speaker 2: So, I mean, this is the argument of what the
hard thing is opinionating enough that it's clearly useful and
doesn't leave you having to make decisions you don't know
how to make, right, but not so opinionated that you
can't use it because it has no flexibility.
Speaker 4: Yeah, I do.
Speaker 2: Appreciate the idea that you have good hooks into elastic
or read It's just like what cash makes you happy.
Use the one you want.
Speaker 4: M I really like your point about the pain of
being asked to make a decision that you don't know
how to make, because personally, when it comes to development,
I feel like I have to do a lot of
that right, and it's like, oh, you want to do this,
you want to do that. I'm like, I don't know
what either of these things are, right, I'm just rolling
a die and hoping for the best.
Speaker 2: Yeah, here's what I know. The app I started working
on six months ago in the apps but that's on
version four, but it's been around for five years, is
now not able to run fast enough for them reviewsers
I've got, you know, we're now complaining about performance and
they're saying, hey, it's in the cloud, make it scale,
And I don't know how to do that. There's no
make it scale button. So I'm going down this path, right,
And it said how I fire up this Aspire? Thinking okay, well,
if we are, you know, put more cloud architecture into it,
it'll scale. And you're trying things right, I mean, this
is just an experiment.
Speaker 4: An you think to bring up that library of curated
components piece. I know a lot of people who've been
using all these things in the past before I had
an aspired dot you know, before the name are saying hey,
it's just exact same thing. But personally, I, as someone new,
I don't know all my different options within the dotnet ecosystem,
and if I want to find them in the traditional ways,
I just get overloaded. I'm like, Okay, here's seven different
databases that I can choose from and just hap me
oh no, like post grass, like seql, I don't know.
But having a list of just saying look, this is
what is supported and popular and has the most functionality,
and being able to say, okay, maybe I want to
add this thing in now to solve my problem.
Speaker 2: Right.
Speaker 4: Not to go on another digression, but I think people
come in with problems to solve. They don't come in knowing, hey,
here's my exact solution for my problem to solve. Let
me find that solution.
Speaker 2: Yeah, you're exactly right, and so I mean part of
this is having the confidence to experiment exactly right, exactly
spin up a separate instance and play with these changes
and then watch how it behaves, and.
Speaker 4: To have the trust that you're not going to get
screwed over if something goes wrong.
Speaker 1: These days, whenever I'm faced with the decision of what
to use, I go to AI and I ask for
a summary of these different things, and from those summaries
that at least that's something that I can go look
up and make sure that it's validated, and then, you know, further,
have a conversation given that this does that and the
other does something else, you know, which might be a
good solution for me, And I may not end up
going with, you know, the solution suggested by the AI,
but at least it's a good place to start.
Speaker 4: I think I really like that point, because, at least
from my experience, it's always harder to write something from
scratch than to criticize something that already exists, right.
Speaker 2: Like, yeah, yeah, I could see the first few times
I'm using Aspire to generate orchestration code to then ask
a HULB copilot, what do you think of this code?
What does it do you? And see how it responds
to it? Just you're kind of getting another opinion, i'd
mentally from a piece of software.
Speaker 1: Sure, sure, well yeah, but it's it's good at summarizing language,
which is, you know, the language is already to.
Speaker 2: Text, yeah, speak, yeah, that's an interesting angle on this.
You know, new way to write software is now that
I have these generators, because it does spit code out
for me based on what I need. I can you know,
getting a get an evaluation of that from another tool
before I try and push it out into into a
test case.
Speaker 4: Exactly. To think of your AI as like a first
year of college.
Speaker 1: Intern, right, exactly, go find all the info you can on.
Speaker 2: X who occasionally takes inappropriate meds or something.
Speaker 1: Because over they're getting better, aren't they?
Speaker 2: But have I ever looked at its responses? That are
you taking mushrooms like kids?
Speaker 4: These models, this.
Speaker 2: Software is out of control.
Speaker 1: Back in my day, we didn't have no natural stupidity.
Speaker 2: What parts of Aspire we not talked about? I mean
we sort of we said discovery is important, but how
do you explain why discoveries?
Speaker 4: I think, honestly, we talked about it a little bit
before around Personally, I think it's about lessening the barrier
when it comes to scaling up, because right, you can
start off with your randomly generated local hosports, you can
figure out how to discover services, you know, when you
only have a couple, but as people scale up, usually
they realize, oh, this is like exponentially more difficult. Yeah,
And having this mental model service discovery upfront and you
know you don't have to like figure out exactly how
it works and know it backwards and forwards, but you
can see it working and over time it really smooths the.
Speaker 2: Way, especially when you're giving them multiple versions of service all.
That's the kind of stuff where I wrote my own
discovery code back in the day because we had that
exactly that problem, right. We had a big service bus
app running with multiple apps and different languages plugging into it,
all trying to pass message to each other, and we
had multiple versions of everything, and you want it fail over.
You wanted to be able to if it's not running here,
you can get it from there, like that kind of option,
and you don't want to hard code all that stuff.
Speaker 4: That's right.
Speaker 2: You just asked er, You asked the discovery service for
a service, and it says here you go, that's all.
You know. You don't know where it came from. You know,
it's fine, You're good, right, right, but it does feel
like that's sort of that mature piece of Okay, So
you're living in services land and you want to be taller.
You want all those additional capability to scale and fall
tolerant and so forth, and discovery is your friend. Let's
start integrating it now. Yeah. I'm getting flashbacks, man, right
the old way.
Speaker 4: The montage begins.
Speaker 2: Yeah, I just remember how much much battle it is.
So the idea that I now have an opinionated template,
it says, okay, but you're going to discovery approach it
like this, this works.
Speaker 1: Well, just make sure you don't snatch defeat out of
the jaws of victory.
Speaker 4: That's a good way of putting it a moment.
Speaker 2: Yeah, oh yeah, And you do need to get into
containers for this too, right, Like if you're not already
using containers, this is one of the hurdles.
Speaker 1: And also it could be an easy way to get
into containers, couldn't.
Speaker 4: Yeah, well because absolutely.
Speaker 2: Because it's doing a lot of the container plumbing.
Speaker 1: For you absolutely less. YAML.
Speaker 2: Well, I think it's you just didn't write it yourself.
Speaker 4: Yeah right, And I think the fact of all these
you know, the Yamo's still there, the doctor fhile is
still there, Like, yeah, it's there. You don't have to
think about it too much. But when you do want
to you can come back and learn it.
Speaker 2: We haven't invented a new language or a new way
to do this. All you're doing is generating a generally
accepted approach to it, right right, Yeah, that's it's compelling
because it's again it's like figuring that stuff out yourself.
It's doable, but it takes time and you don't know
if you're working on the right thing. Like what I
like about this is a good experiment. Just let's kick
it up and see what we think. Like, does that
make sense?
Speaker 4: Yeah, exactly.
Speaker 2: Okay, let's revert and try it again, do it a
different way, Like you don't have to decide. It's generating
a lot of that code for you.
Speaker 4: Yeah, absolutely. You know, I think with containers, conceptually it
seems kind of you know, straightforward, Oh I put my
code in a box, it works everywhere. But the reality
of it, like getting it in there, making sure that
they're orchestrated correctly, that you know that they're deployed correctly.
And I guess that's where I can bring up a
little bit of AZD where I think there's a lot
of misconceptions around that tool of it's bringing in this
new magic way of doing things you type in two
commands and everything worse. But under the covers. It's similar
to how the spire does it, where it generates the
things that people are familiar with. It generates the BICEP,
but you don't have to think about it until you
want to can your mind.
Speaker 1: So a ZD is again, I mean you talked about
it briefly.
Speaker 4: Yeah, that's right, that's right, yep. So AZD is the
Azure Developer Cli. It is different from the Azure Cli,
which is a z so you can see why there
might be some confusion there. Yeah, But the core of
AZD is it helps you deploy without becoming a BICEP expert.
And it does that by generating BICEP templates essentially based
on the code and the project structure that you have,
and you can expose that using a command so that
you can dive into the actual infrastructure code and you
can edit it manually instead of just hoping for the
best with a CLI command.
Speaker 2: Right, Yeah, I mean, I know the names are correct,
as your CLI, as your developer CLI. It's right and
any and I appreciate that you're generating BICEP right, right,
which ultimately turns into ARM templates under the hood. But
at least it's fairly I find BICEP fairly readable. It
does seem like rational code. I was just right right,
it's still pretty I've never I've never reused BICEP code
between projects. I've used the same code. I have cut
and pasted stuff I figured out and put it somewhere else.
Speaker 1: But sounds like you need a generator.
Speaker 2: Richard's ah, yeah.
Speaker 1: Yeah, maybe.
Speaker 4: I think the what you're saying about BICEP is readable, right,
But the difficulty comes from writing it from scratch. Absolutely,
because I hear a lot of people say, look like
BICEP is fine. As long as I have something to
start with, I can do what the structure is. I know,
I can edit thing.
Speaker 2: I feel like you never write enough of it to
be good at it.
Speaker 4: Yeah.
Speaker 2: Yeah, you need it when you need it, But it's
always a struggle, you know. I'm always looking at a
previous example, like you need another piece of code, and
sometimes take some of that code with you. So it's
kind of like that you're generating it for me rather
than cut and pasting it from elsewhere.
Speaker 4: Mm hmm, that's right, all right.
Speaker 2: Well, I mean, and because this is always the reality
of a quote unquote cloud native application is you do
have to tell the cloud what resources you need, and
you do want that automated to just spit it all
out and then push your code, your compiled code into
the right places and put cook things up, get the
orchestration working. That's right, Like, this is part of the job.
Speaker 4: Right, And for a lot of I mean software engineers,
like they don't necessarily you know, that's not necessarily what
they signed up for, right, They're here to build something.
They're not here to be Yeah, figuring out the deployment
pipeline or so on necessarily, Right.
Speaker 2: Are we waiting on more components? Like I've just went
and grabbed the list off of learn and I've included
it in the show notes, so folks want to look
at it. So, I mean, it's all the ones you'd expect, sure, SEQL, server, service,
bus stuff like that. Yeah, and then yeah, Ratus is there,
but elastic is not.
Speaker 4: Right, right, And I think the thing with the component
library is at least what I'm seeing is it's meant
more as a like app store situation, but without the
buying selling, where it's not just Microsoft or even the
dot net team, right, who gets to create components. The
idea is anyone can say I would love for this
to be a component at Aspire. I'm going to write
it up, I'm going to push it in right, and
if you go into the ad Aspire package, you'll notice
that it's just a filter that looks for the Aspire keyword.
It's not like, hey, here's your special new Get package
manager with only special Aspire packaging. So it's again it
feels like it's taking what's already there. It's just simplifying
the discovery process.
Speaker 2: It's yeah, it's great, and I do like the idea
of this is known to work with a spire scaffold, right,
so you know you're not wrestling with something saying am
I doing it wrong? Or does it not work this way?
Speaker 4: Right? Right?
Speaker 2: That is appreciated because it just makes life a little
bit easier, you know, one less battle to have, that's right.
Speaker 4: And when you're dealing with micro services with a couple dozen,
you know, like so many moving pieces, you want to
make sure that those moving pieces aren't going to fail
on you in the middle of a raise, and yeah,
you want to be able to rely on them.
Speaker 2: Absolutely and generally speaking, this is not about me making
more components for myself running these things. It's me calling
to that service, right, Like I don't want my own
reddisk containers. I want to call a retta service, right right. Yeah,
it's cool like that. That is a whole other thing
set of things you need to learn. Oh yeah, and
look open ai is there. So if you want to
you want to include some ll M in your in
your app, you've got to recognize services.
Speaker 4: We have an option.
Speaker 1: Yeah, So jos Chin, what's in your to do list?
What's next for you?
Speaker 4: Oh gosh, So I think the big question right now
is over on the Agura container app side, like how
do we make this better for developers? So Aspire is great,
we're trying to do like strong integration there, but vast
majority of DOTTNA developers are that are not using Aspire there. Yeah,
and I just think that it's like so far it's
been difficult, but we're really trying to lower that barrier
to entry around containers, recognizing that a lot of DOTNA
developers aren't coming in with like because you know, they
hear about containers as a technology that is new and
efficient and helpful, but they're not experts. And how to
allow them to get started with a low barrier to
entry without saying, hey, like click one button and we
take your code and do all the magic and just
deploy it and you just have to trust in it.
Speaker 2: Right, that only works in demos anywhere else?
Speaker 4: Yeah, exactly, but.
Speaker 2: At least some guidance, right, Okay, you want to start
using containers, well, and again it's like you don't want
to use containers, you wanted to scale your app. I
believe containers can help, and Aspire will help guide you
down the path of doing that.
Speaker 1: Isn't that what Kubernetes was supposed to do? Just one
push a button and everything just sort.
Speaker 4: Of boom emphasis I'm supposed to right.
Speaker 1: Yeah, I mean it turns out to be kind of.
Speaker 5: It.
Speaker 4: Yeah, And Richard, I think you what you said earlier
really gets to that point of let people focus on
the problems that they're solving instead of making them figure
out the solution, right, Like, don't expect people to say, oh, yeah,
I really need containers, but rather what are containers supposed
to do for people?
Speaker 2: Yeah? Yeah, well I really need to allow more people
to use this app at the same time without a
tipping over, right, I really need to know when it
does tip over what went wrong. I really need to
be able to run multiple versions of services. I really
need to be able to have more people communicating with
that and know when they're damaging the system or when
we're creating creating problems make it. One of the things
happens when you get into these bus type apps is
like a bad actor ends up on the on the backbone,
hammering messages inappropriately. It's a bug, Like, it's not actually
an evil person, it's a bad piece of software that's
that could take the whole bus out and diagnosing that
is a pain. Like anything that can help me build
that successfully, that's my friend. So but you got to
think by the time they're looking here, they're already struggling. Yeah,
they're already having They're saying evil words. They're saying, we
need to re architect the application. That's an evil that's
a terrible statement. You know, as the p or as
the owner, I'm kind of like, let me get a
straight You're going to take a piece of software that
more or less works.
Speaker 4: Right now, You're going to try to fix it.
Speaker 2: You're going to do a bunch of things that introduce
no new features but take a lot of time and
very likely break things that currently work.
Speaker 4: Wow, what a great trade deal then?
Speaker 1: Yeah?
Speaker 2: Right, like and oh and if you do your job perfectly,
none of us will be able to tell right the
app will just be running like did you lose a
bet with God? Like that? That's you just drew the
short straw for this problem.
Speaker 1: Well we can talk a lot more, I know, but
time is up, so Josh, and thank you very much
for enlightening us and your perspective is great.
Speaker 2: Yeah, thanks so much for this.
Speaker 4: Yeah, absolutely, thanks for the great conversations. Yeah, it's nice
to start off my Friday with Uh it feels like
a little bit of stand up comedy.
Speaker 2: Well you got to you got a couple of silly
people on the.
Speaker 5: Lines, all right, so much, Thanks again and we'll see
you next time on dot net rocks.
Speaker 1: 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 right A 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.
Speaker 4: You got jad middle vansc