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.
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.
Ndcporto is happening October fourteenth through the eighteenth. The early bird discount ends June fourteenth. Tickets at Ndcporto dot com.
And we'll see you there.
We hope.
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.
How do you? How are you? How are you? Hey? Summertime? I like summertime.
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.
I don't jinx it. Don't jinx it.
Yeah right, I mean I could. I could say, you know, the Internet is working, there's no problems with it.
Don't be crazy now there.
The reason we're laughing about that is because there is a major outage this morning, the CrowdStrike problem.
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.
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.
Riley, Yeah, a bit of a diabolical smile.
Yeah, and so there's a blue screen of death pasted over the fire and it said Linux users be like.
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.
We should also dispel that myth that Azure had a problem too, right, yeah.
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.
Right, We won't attempt the gods of vengeance and irony. They they have a way of smacking us down.
Yeah, they'll let you know.
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?
Uh?
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?
That's the whole thing.
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.
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.
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.
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?
So should I which should I talk about first, Yamal or XML.
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.
Well, Yamil is just one of those. It sort of looks I just don't understand why it has to be different from Jason.
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.
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.
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.
At the time, it was good and it worked.
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.
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.
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.
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.
And I'm Rich Campbell at macedon dot social.
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.
To be here, Thanks for having me, Thanks.
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?
Nah, I'm just an observer for this part.
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.
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.
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?
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.
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.
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.
Right.
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.
That's been talking about in the context of the AI wave.
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.
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.
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.
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.
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.
The structural integrity integration yourself.
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?
Right? Exactly? And everyone's scenario is different, right, You can't go to Scott Hunter and say, hey, does this.
Work for me? Yeah?
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.
Yeah. It makes me wonder if developers don't get to a place where they get it to work and don't touch it.
Yeah.
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.
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.
Where they electronic arts, right, soccer right right.
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.
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.
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.
You know.
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.
Go or is it right?
Exactly?
Yeah? I mean, what are the essential things you have to use? What is minimal aspire?
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.
That library, I would say the first thing for me would be open telemetry.
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.
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.
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.
The machinery, it's nice as a new.
Person to not have their first experience and in an explosion.
Linux users be like, you know, you know, I don't know. That just tickled me.
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.
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.
Like you're just staring at it, like what happened?
Yeah, right, just looking at the rubble and the yeah, yeah.
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.
You asked for it, here it comes, and.
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.
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.
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.
Be great if there was a podcast episode that you could just listen to while you're driving or something.
Ah yeah, yeah, something nice.
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.
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.
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.
We're just gonna leave it in there and put a comment that it's deprecated.
Everything's to be fine. It'd be fine. Fine.
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?
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?
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.
Code just added some things to it to.
Like in theory, right, So it gets right, right, see if it actually makes your life easier?
But is it as your container apps and a critical part of this, do I need to have my app?
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.
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.
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.
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.
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.
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.
Feel strongly otherwise, sure, like you can make things work for you.
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.
New and cool.
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.
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.
Yeah, I do.
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.
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.
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.
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.
Right.
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.
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.
To have the trust that you're not going to get screwed over if something goes wrong.
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.
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.
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.
Sure, sure, well yeah, but it's it's good at summarizing language, which is, you know, the language is already to.
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.
Exactly. To think of your AI as like a first year of college.
Intern, right, exactly, go find all the info you can on.
X who occasionally takes inappropriate meds or something.
Because over they're getting better, aren't they?
But have I ever looked at its responses? That are you taking mushrooms like kids?
These models, this.
Software is out of control.
Back in my day, we didn't have no natural stupidity.
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?
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.
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.
That's right.
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.
The montage begins.
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.
Well, just make sure you don't snatch defeat out of the jaws of victory.
That's a good way of putting it a moment.
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.
And also it could be an easy way to get into containers, couldn't.
Yeah, well because absolutely.
Because it's doing a lot of the container plumbing.
For you absolutely less. YAML.
Well, I think it's you just didn't write it yourself.
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.
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?
Yeah, exactly.
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.
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.
So a ZD is again, I mean you talked about it briefly.
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.
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.
But sounds like you need a generator.
Richard's ah, yeah.
Yeah, maybe.
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.
I feel like you never write enough of it to be good at it.
Yeah.
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.
Mm hmm, that's right, all right.
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.
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.
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.
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.
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?
Right? Right?
That is appreciated because it just makes life a little bit easier, you know, one less battle to have, that's right.
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.
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.
We have an option.
Yeah, So jos Chin, what's in your to do list? What's next for you?
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.
Right, that only works in demos anywhere else?
Yeah, exactly, but.
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.
Isn't that what Kubernetes was supposed to do? Just one push a button and everything just sort.
Of boom emphasis I'm supposed to right.
Yeah, I mean it turns out to be kind of.
It.
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?
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.
Right now, You're going to try to fix it.
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.
Wow, what a great trade deal then?
Yeah?
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.
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.
Yeah, thanks so much for this.
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.
Well you got to you got a couple of silly people on the.
Lines, all right, so much, Thanks again and we'll see you next time on dot net rocks.
Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at PWOP dot com. Visit our website 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.
You got jad middle vansc