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