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, we'll 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: welcome back to dot net rocks. I'm Carl Franklin, an
Speaker 1: amateur Campbell, and we're here again for show nineteen twenty one.
Speaker 2: You're enjoying the twentieth century, are you?
Speaker 1: I am? And you know, I kind of like this
Speaker 1: little history summary that I'm doing. Okay, So I went
Speaker 1: to thepeoplehistory dot com slash nineteen twenty one dot html
Speaker 1: and as you can guess, they have an HTML file
Speaker 1: for every year that where they have data from. So
Speaker 1: here's just a summary. In nineteen twenty one, the US
Speaker 1: passed the Emergency Quota Act, which limited the number of
Speaker 1: immigrants that were allowed to come to the United States.
Speaker 1: The Irish Free State was created as the Irish Republic
Speaker 1: issued their declaration of independence from the UK, and later
Speaker 1: that year, the ira and British forces agreed to a
Speaker 1: cease fire. We all know how that worked out. The
Speaker 1: nineteen twenty one, yeah, twenty one, the Tulsa Race massacre
Speaker 1: happened in the US. An unfortunate event.
Speaker 2: That's the one that was on my mind for nineteen
Speaker 2: twenty one was Greenwood.
Speaker 1: Oh yeah, you know, three hundred or so black Americans
Speaker 1: were killed.
Speaker 2: Not good but also one of the most affluent neighborhoods.
Speaker 2: Like it really tore the culture apart.
Speaker 1: Really did. It was pretty evil. The TWMB of the
Speaker 1: Unknown Soldier was established. That's cool. The Shepherd Towner Maternity
Speaker 1: and Infancy Act became law, making one of the first
Speaker 1: times the United States ventured into social security. The USSR
Speaker 1: and Poland agreed to the Treaty of Riga. The Soviet
Speaker 1: Union also invaded the Democratic Republic of Georgia, and the
Speaker 1: US and Germany signed the Treaty of Berlin, ending World
Speaker 1: War One. For the US. New York Yankees pitcher Babe
Speaker 1: Ruth hit his one hundred and thirty eight home run
Speaker 1: in June, and Crimea was officially brought into the USSR.
Speaker 1: The Crimean autonomous Soviet Socialist Republic is created. Also one
Speaker 1: of the worst famines in modern times, gript Russia due
Speaker 1: to crop failure. That's what I found.
Speaker 2: What would I add? I mean if the Soviet Union
Speaker 2: is still forming, then right, it really only really gets
Speaker 2: its act together another year or so. Oh hofra House Hitler.
Speaker 2: Oh yeah, Hitler's famous speech of the Haffro House that
Speaker 2: leads to the riots, because admittedly, at that point, the
Speaker 2: runaway inflation from the Treaty of Versailles is really taking
Speaker 2: hold of the Warmark Republic. And so this is when
Speaker 2: you had we have a wheelbarrow of Deutsche marks. You
Speaker 2: get biol over bread, right, and Hitler is inciting violence. Yeah,
Speaker 2: stop me if you've heard this one. Yeah, it's a
Speaker 2: kind of ringing a bell for me. Weird.
Speaker 1: Huh, Yeah, it is kind of weird how that happens.
Speaker 1: You know, when somebody comes along and says, it's not
Speaker 1: your fault, it's these people's faulty. You're suffering, Yeah, so much.
Speaker 1: You know, people tend to gravitate towards those people. Yeah. So, anyway,
Speaker 1: enough of nineteen twenty one, let's get on with better
Speaker 1: no framework.
Speaker 3: Awesome, all right, man, what do you got?
Speaker 1: Have you ever heard of Garnet? Maybe, Chris, you have
Speaker 1: well the stone Okay.
Speaker 4: Yeah, So Garnet isn't that the replacement for Reddish or
Speaker 4: something like that, Not replacement, but an option to Reddish
Speaker 4: because of some stuff.
Speaker 1: Yep. So it's a remote cash store for Microsoft Research
Speaker 1: that offers strong performance in both throughput and latency, scalability,
Speaker 1: storage recovery, cluster sharding, key migration, and replication features, and
Speaker 1: it can work, as you said, with existing Reddish clients.
Speaker 1: So it's that's pretty cool. It's just something that's trending
Speaker 1: that I found in. It's Microsoft Research. Who knew, Yes,
Speaker 1: these guys do good work.
Speaker 2: There's smart folks over there from the people who brought
Speaker 2: you F.
Speaker 1: Sharp F sharp and all sorts of goodness.
Speaker 2: And I love that they're using their you know, the
Speaker 2: layer Garnet is the name of the product, and underneath
Speaker 2: is a storage's layer called Svarite, which is a kind
Speaker 2: of Garnet.
Speaker 1: All right, some of these with the naming, yeah, okay,
Speaker 1: I guess dot net does rock.
Speaker 2: Literally.
Speaker 4: The fact that they do release them under a bit
Speaker 4: cooler names now is cool. Though previously that would have
Speaker 4: been released as the Hyper Performance Scalable Cash Enterprise V
Speaker 4: three for Foundation Edition.
Speaker 2: Dang, right, yeah.
Speaker 1: Good. Anyway, Well that's what I got, Richard, who's talking
Speaker 1: to us today.
Speaker 2: I love everything about that.
Speaker 1: Oh.
Speaker 2: I decided to go into the wayback machine and I
Speaker 2: grabbed a Chris Klub show from twenty to fifteen, the
Speaker 2: one where we talked about Solid principles and dot net cool,
Speaker 2: because I'm sure he'll remember this. It was only what
Speaker 2: nine years ago?
Speaker 4: I did remember it.
Speaker 1: I never know.
Speaker 2: We're talking about how Solid worked with dot net, right,
Speaker 2: And there's a bunch of comments that are actually a
Speaker 2: ton some going into detail, some really appreciating your pragmatic
Speaker 2: view of it, Chris, which is something I've always appreciated.
Speaker 2: You know, you're obviously an experienced architect. We've talked about
Speaker 2: some great projects, but you're not an idealist in any ways.
Speaker 2: And we actually make this work. No, it has to work,
Speaker 2: and it has to work oddly enough. If the software
Speaker 2: doesn't work, it's really not that valuable. And Michael Reid
Speaker 2: Smith had this comment and middle nine years ago he said,
Speaker 2: you all need to work with Some younger developers are
Speaker 2: really old legacy systems. They violate Solid all the time.
Speaker 2: Some younger developers don't even know what SOLID is. We
Speaker 2: teach classes where I work. That helps us older, more
Speaker 2: experienced developers teach the younger you developers what school did not.
Speaker 2: And I love the show We also go with this.
Speaker 2: I don't think you can teach solid to someone and
Speaker 2: have it stick until they've written some code, until they've
Speaker 2: been in a project or two. Like, you've got to
Speaker 2: know what the pain is to some degree before you
Speaker 2: really grasp why we need these processes.
Speaker 4: And then you have to go over the line and
Speaker 4: go way too far and then start scaling it back
Speaker 4: when you realize that going too far when solid is
Speaker 4: going to put you in the whole heap of other problems.
Speaker 2: Yeah, different set of problems. I just traded my problems
Speaker 2: at so. Yeah, there is a balance in there, So
Speaker 2: I in that sense, I always say the experienced folks
Speaker 2: like be patient with the youngers. They don't know why
Speaker 2: they should be afraid, right, It's hard to convince them
Speaker 2: other than you're just being mean. Sometimes you just got
Speaker 2: to let them set themselves on fire first, and then
Speaker 2: it's like, hey, hey, would you like to not burn?
Speaker 1: There's a way that's good.
Speaker 2: So, Michael, thank you so much for your comment. At
Speaker 2: A copy of music Code by is on its way
Speaker 2: to you. And if you'd like a copy of music
Speaker 2: Code by, write a comment on the website at dot
Speaker 2: at rocks dot com. Ra on the facebooks. We publish
Speaker 2: every show there and if you comment there and I
Speaker 2: read on the show, we'll send you copy music code by.
Speaker 1: Still selling music to Code, buy music tocode, buy dot
Speaker 1: net and people are loving it, getting break comments every day.
Speaker 1: I still haven't started that next track, however, I'm I'm
Speaker 1: still fixing to think about it.
Speaker 2: It's got to just boil in the back of your head,
Speaker 2: all right.
Speaker 1: It's not that simple, all right, So let us introduce
Speaker 1: Chris Kloague with an older bio. You can tell me
Speaker 1: Chris if anything has changed. But Chris works as a
Speaker 1: developer architect at Active Solution in Stockholm, still yep, still
Speaker 1: working mostly with cloud based solutions for clients and a
Speaker 1: wide range of domains. Lately, his contracts have pulled him
Speaker 1: towards the DevOps area, working almost entirely with build and
Speaker 1: release automation as well as infrastructure as code. Both were
Speaker 1: somewhat uncharted areas to him, which suited him find as
Speaker 1: he loves learning new things. Now I remember this is
Speaker 1: what twelve years ago and figuring out how to make
Speaker 1: them do what he wants them to. I imagine, Chris,
Speaker 1: you're still doing that kind of stuff.
Speaker 4: I am still getting computers to do what I want
Speaker 4: them to, but I'm not so much into Develops anymore.
Speaker 4: I've luckily got myself into other problems nowadays. But it's
Speaker 4: still there, right, Develops has just It's kind of like
Speaker 4: I talked a lot about Asher when Asher was new,
Speaker 4: but then Asher becomes just another tool that you're okay with,
Speaker 4: and then Develops was new, and then all of a sudden,
Speaker 4: Develops is just something that you have and you do
Speaker 4: when you implement in your projects and get pipelines and
Speaker 4: stuff working.
Speaker 1: Just software.
Speaker 4: Yeah, now it's I move around a bit currently doing
Speaker 4: a lot of API development for a client, which is
Speaker 4: fun as such.
Speaker 1: Yeah.
Speaker 2: Well, and we talked about if she should go back
Speaker 2: in the day just a couple of years ago. Is
Speaker 2: exactly that. It's like, how is this stuff maturing out?
Speaker 2: And I knew from I think it was your blog
Speaker 2: post that you had been dabbling in all the different platforms, Like,
Speaker 2: all right, Chris, come and talk to us about the
Speaker 2: different platforms together. But I got to agree with you.
Speaker 2: These days, you don't find anyone who doesn't have some
Speaker 2: kind of pipeline, at least, not that that's the only
Speaker 2: thing in DevOps. Is much more to it than that,
Speaker 2: But that's where a lot of people stop. They just don't,
Speaker 2: let's get a pipeline.
Speaker 4: Yeah, I think that's the kind of the first and
Speaker 4: actually it's the really tangible thing I think with develops
Speaker 4: that you actually automate a bunch of things and get
Speaker 4: things running. But yeah, there's a lot more to the
Speaker 4: process as such, and to the whole area of develops.
Speaker 4: I completely agree. But at least automating your things is
Speaker 4: a start.
Speaker 2: Getting rid of unreliable deployments is a useful part piece
Speaker 2: of the equation. You're not going to suffer for that anyway,
Speaker 2: and it's certainly gotten a heck of a lot easier
Speaker 2: to do that. I mean, goodness knows we do in
Speaker 2: this show long enough that I remember when we were
Speaker 2: talking about the weird add ons you had to put
Speaker 2: into visual studio to even to begin to build something
Speaker 2: we would eventually call a pipeline. It's better now, make
Speaker 2: no mistake, it's definitely better now.
Speaker 4: Well, at least if you're in the cloud. I still
Speaker 4: have clients to deploy to on premis machines, so it
Speaker 4: is still a bit of a tedious process compared to
Speaker 4: just deploying to the cloud.
Speaker 2: Well, just because you can get away without building a
Speaker 2: good enough automation, a cloud kind of forces you down
Speaker 2: a righteous path.
Speaker 1: So you're thinking a lot about cloud native these days.
Speaker 1: Is that a term whose time has come? Do we
Speaker 1: all understand what that means? Does it mean different things
Speaker 1: to different people?
Speaker 4: I think it means different things to different people. I
Speaker 4: think cloud native people are going to attack me for this,
Speaker 4: I know, but it seems like that whole thing has
Speaker 4: been hijacked by kubernaties. If you're not building Kubernatis apps
Speaker 4: or based solutions, you're not cloud native. And it's like
Speaker 4: the cloud native, the CNCF thingy, it's all about Kubernati stuff.
Speaker 4: I think there's more to it. I think it's a
Speaker 4: paradigm or a way of thinking of how you build
Speaker 4: your code, making sure that it is scalable horizontally, and
Speaker 4: it makes use of resources in a good way, and
Speaker 4: all of that stuff that's not necessarily specific. And I
Speaker 4: think we are moving in that direction, and I think
Speaker 4: a lot of people are in the cloud and doing
Speaker 4: sort of cloud native, even if I'm seeing a slight
Speaker 4: pull towards going on prem again, at least for bigger clients,
Speaker 4: because cloud is not necessarily cheap when you go to
Speaker 4: a certain size.
Speaker 1: The term cloud native always rang weird with me because
Speaker 1: I'm like, well, what's the what's the opposite of that
Speaker 1: cloud interpreted?
Speaker 2: Cloud immigrant?
Speaker 1: Cloud immigrant?
Speaker 2: Yeah, migrated on prem native? Hey yeah, what's a virtual
Speaker 2: machine city behind Azure Fireworld like a cloud immigrant?
Speaker 4: Yeah?
Speaker 1: Yeah, okay. So in other words, applying on prem technologies
Speaker 1: and processes to the cloud is not cloud native? Is
Speaker 1: that what you basically getting out?
Speaker 4: I would say, So if you're building on prem, you
Speaker 4: tend to make other assumptions. In my world, things like
Speaker 4: your database you potentially assume is always online, because if
Speaker 4: the database goes offline, your machine, your database server is
Speaker 4: actually having problems and you'll see that in other parts
Speaker 4: and it is probably not going to be an intermittent issue.
Speaker 4: But if you're in the cloud, you have more of
Speaker 4: those intermittent things, so you take it into account when
Speaker 4: you build your application. For example, I think there are
Speaker 4: lots of little niggles here and there that you sort
Speaker 4: of have to change a little bit when you go
Speaker 4: to the.
Speaker 2: Cloud be tolerated of a one minute outage, yeah, something
Speaker 2: like that.
Speaker 4: Yeah, Yeah, pretty much everything can come and go. It's
Speaker 4: going to be gone for a little while, but it's
Speaker 4: hopefully just going to come back. But you have to
Speaker 4: survive that. Whereas that obviously can happen on prem as well.
Speaker 4: But as I said, if a server go that goes
Speaker 4: down on Prem, that's a different story. That's not going
Speaker 4: to be a little blip and it comes back thirty
Speaker 4: seconds later. It's probably going to be somebody running around
Speaker 4: in their center freaking out because power supply is blown
Speaker 4: up or something like that.
Speaker 2: So step one, something is not going to be back
Speaker 2: before you can write up the ticket for it.
Speaker 1: Yeah, so step one is let's let's focus one hundred
Speaker 1: percent on our please wait screen.
Speaker 2: Yeah, I would argue this is all about Polly, right,
Speaker 2: as Polly's everywhere right, so that everything is recovering, then
Speaker 2: you'll be fine.
Speaker 4: Yeah, it still need to take it even if you
Speaker 4: had Pulley. It's it's yes, it's going to do read
Speaker 4: try and you can do gate gates and things like that,
Speaker 4: but it's in the end, you still have to make
Speaker 4: sure that your client gets a decent message as well.
Speaker 4: So I think Carlos is onto it something. It's like,
Speaker 4: if it's down, have a nice screen that says, hey,
Speaker 4: we're actually down for a little while, or find a
Speaker 4: way to just work in a different way. I think
Speaker 4: I read somewhere.
Speaker 1: That while you're waiting read this today in the history paragraph,
Speaker 1: expect me go get a coffee and we'll be right back.
Speaker 4: Yeah, And I think maybe a lot of people are
Speaker 4: missing up and that I think I've read somewhere that's
Speaker 4: sort of like at Netflix where they're doing micro services,
Speaker 4: which is cloud native and all of that, then they
Speaker 4: every service should survive that other services are down. So basically,
Speaker 4: if you want to see the list of movies to
Speaker 4: watch today, maybe it depends on one service to look
Speaker 4: at your latest movies or whatever your ongoing and if
Speaker 4: that service is down, then they can look at another
Speaker 4: service to find the top top ten movies at the moment,
Speaker 4: or if that service is down, maybe there's a hard
Speaker 4: coded list of movies that you can show. So there's
Speaker 4: always fallbacks upon fallbacks if services are down, and I
Speaker 4: think I'm guilty of that. As well. But I think
Speaker 4: a lot of us forget about that. We basically go
Speaker 4: if the service is down, then we just return an error.
Speaker 4: Maybe we can do something more. And I guess that's
Speaker 4: the cloud native way is being better prepared that things
Speaker 4: being unavailable.
Speaker 2: Getting this idea of discovery that I know where I'm
Speaker 2: likely to go, but I'm willing to take a few
Speaker 2: other choices. So, you know, building a maximum says you
Speaker 2: can provide a difference alternative to this as well as
Speaker 2: some of the Here's one it's that I've definitely seen
Speaker 2: on prem do all the time. You just can't get
Speaker 2: away with the cloud IP addresses right like you can
Speaker 2: get it if it's your network, you can get away
Speaker 2: with those are my ips. You don't get away with
Speaker 2: that in the cloud. That is not an option.
Speaker 1: Yeah, all of these things bring to mind, you know
Speaker 1: the difference between more client side technology like web assembly
Speaker 1: and more server side technology like Blazer server. And you know,
Speaker 1: Blazer server is more apt to have those please weight
Speaker 1: screens because of you know, if it's down, it's down, right,
Speaker 1: But in you know, if you've got good caching and
Speaker 1: good messaging and all that stuff, your client can survive
Speaker 1: just about anything as long as you have you know,
Speaker 1: prepared the user for that and have some sort of
Speaker 1: good contingency plan when things are pausing or not completing yet.
Speaker 2: Fallbacks always ways to fall back. And also like not
Speaker 2: that cross dependency thing, like you can different pieces of
Speaker 2: the app can be updated and everything keeps running, like right,
Speaker 2: don't have you don't have that master, we shut down
Speaker 2: at five o'clock, do a big update, It'll be back
Speaker 2: up tomorrow morning. Like that's just not the cloud dated world.
Speaker 2: I started rolling update mindset, which I mean I did
Speaker 2: a lot of that back in the e commerce state
Speaker 2: when we did it far more by hand, just because
Speaker 2: we made money every minute of every day and every
Speaker 2: bit of outage was money loss. So people got grumpy
Speaker 2: and we had to find a way to roll out
Speaker 2: updates without stopping the cash for no.
Speaker 4: Yeah, and it's funny now that we talk about all this,
Speaker 4: I'm like, looking at I've been doing this for twenty
Speaker 4: five years now, and I'm just so happy I'm not
Speaker 4: coming into the industry right now because there's there's it's
Speaker 4: a good time coming as well. I'm just I would
Speaker 4: probably as a person be overwhelmed by everything that you
Speaker 4: kind of need to know because it used to be
Speaker 4: that you could know a bit, you can know code,
Speaker 4: and then the ops team would make sure that it ran.
Speaker 4: But now we develops and asher and cloud Native and
Speaker 4: all of that stuff. All of a sudden, there's the
Speaker 4: whole Oh we need I need to know how networks
Speaker 4: work and how machines are set up, and service discovery
Speaker 4: and a lot of other stuff that as a junior
Speaker 4: you need to get somebody else to help you with
Speaker 4: and basically show you the rogues. But there's a lot
Speaker 4: to learn today if you're new in the business.
Speaker 2: In my mind, I mean, I would argue back, they
Speaker 2: also don't have the baggage like we're doing a lot
Speaker 2: of unlearning too. We have bad habits, we have craft
Speaker 2: we need to scrape off right this you know, the
Speaker 2: pets versus cattle mindset, Yeah, just like you know we don't.
Speaker 2: We don't update servers around here. We build new ones
Speaker 2: and kill the old ones, right because they're all virtual,
Speaker 2: they're ephemeral, and that's a pretty hard thing to get
Speaker 2: into your head when you're used to years and years
Speaker 2: of carrying and feeding of a set of boxes with
Speaker 2: blinky lights.
Speaker 4: I had an argument with a with the developer a
Speaker 4: while back, and it'said the argument spiral Bit said, I've
Speaker 4: been doing it like this for the last fifteen years
Speaker 4: and it's worked fine. And that's to me, that's when
Speaker 4: the argument ends, because if you're doing what you did
Speaker 4: fifteen years ago in the same way, there is probably
Speaker 4: a better way. Things have shifted in fifteen years.
Speaker 2: You have one years of experience. You repeated fifteen times.
Speaker 2: Let's go learn something, man. Yeah, that is tough. I
Speaker 2: mean I don't want to. I understand the resistance to
Speaker 2: kubrinetties because it seems to be all things, but this
Speaker 2: containers just seem like to be a good idea.
Speaker 4: I agree containers is a great idea. My problem with
Speaker 4: kubernet is mostly because you end up having to run
Speaker 4: the cluster. I know that AKS is semi managed, but
Speaker 4: it's not fully managed, and to me it just seems
Speaker 4: like I'm not a Linux person, so running an AKS
Speaker 4: cluster or running a Coubrettes cluster is this a bunch
Speaker 4: of stuff I don't feel comfortable with. And also, when
Speaker 4: stuff happens, they're generally not the most simple thing to fix.
Speaker 4: Either it's very simple or it's some weird network thing
Speaker 4: that happened inside of your Linux servers and then I
Speaker 4: am screwed. I don't know how to fix that, so
Speaker 4: that's why I'm a little bit scared of it. But
Speaker 4: if you have the people that can run your cluster,
Speaker 4: I am more than happy to be building for it.
Speaker 4: But it's a separate skill set in my mind.
Speaker 2: Have you dove into as your container apps as sort
Speaker 2: of the more managed version than AKS.
Speaker 4: I don't know how politically correct I'm supposed to be
Speaker 4: right now, I am page. I probably should be politically correct.
Speaker 1: But honestly, just be honest, man.
Speaker 4: The very honest thing is that, yes, I have been
Speaker 4: on a product where we're using container apps. I am
Speaker 4: not touching it again unless I have to. Because we
Speaker 4: had our dev environment locking up and having to be
Speaker 4: real built like four times since six months. Our production
Speaker 4: environment got locked up for about five days where we
Speaker 4: couldn't deploy because all of a suddenly it said that
Speaker 4: we had no more cores available, and that was basically
Speaker 4: either we had to rebuild production, which is not really
Speaker 4: an option, or we would need to wait for micro
Speaker 4: support to fix that for us, which it did eventually.
Speaker 2: So it was buggy.
Speaker 4: I find it very buggy. And besides that, it kind
Speaker 4: of annoys me because when it starts bugging out, the
Speaker 4: layer that container Wraps ads on top of kubernet is
Speaker 4: for me, is so thin. You can see kubernet is underneath.
Speaker 4: You just scrap a little bit. You can still see
Speaker 4: the ingris stuff and the pods and all the stuff
Speaker 4: that is kubernet is underneath. But when stuff starts failing,
Speaker 4: you cannot go to cube control and start mucking about
Speaker 4: and trying to figure out what's wrong, because you stuck.
Speaker 2: You're waiting on a ticket.
Speaker 1: It's a yeah, it's a glass bottom boat yep with
Speaker 1: a hole in it pretty much.
Speaker 4: So I'm not a huge fan. I'd rather deploy to
Speaker 4: akas if I'm going to go full container style or honestly,
Speaker 4: I still like web baps for containers. Right, I'm old school.
Speaker 1: Did you did you say how long ago this experience was?
Speaker 4: It was, let's see, about six months ago, six months,
Speaker 4: nine months ago or something like that.
Speaker 1: Okay, so still very current.
Speaker 4: Yeah. And the funnly thing is I have a guy
Speaker 4: at the office who's also an MVP, and he was like,
Speaker 4: container Wraps is awesome, and we talked about it, and
Speaker 4: he had never seen the issues that we were having.
Speaker 4: And then very recently their environment went down as well
Speaker 4: because all of a sudden they had intermittent issues talking
Speaker 4: to seql and they filed the ticket and apparently there
Speaker 4: was a network issue in ashure that actually made some
Speaker 4: of the packages to seql Ashure go down, so they
Speaker 4: couldn't talk to Azure, which is a sequel, which caused
Speaker 4: a bunch of problems. It got fixed very rapidly, but
Speaker 4: the fact that things like that happens makes me not
Speaker 4: trust the platform, makes.
Speaker 2: You squirrel down.
Speaker 4: Yeah.
Speaker 2: So, and web apps for containers, I mean, yet another
Speaker 2: strategy for using containers and actually, like you can't blame
Speaker 2: anybody for staring this and going can you make up
Speaker 2: your mind?
Speaker 4: Yeah? No, I know.
Speaker 2: Are we supposed to do this?
Speaker 4: And it's like they're they're pros to Astra container wraps
Speaker 4: in the form of service discovery gets built in and
Speaker 4: it's easy to run Dapper. I'm not a big Dapper fan,
Speaker 4: but that that's plugged in there as well. But your
Speaker 4: t a p R Dapper, not e a p P
Speaker 4: E R No, that is hard yep. But you can
Speaker 4: do most of that stuff with with just v nets
Speaker 4: and container apps as well, or sorry, not gonna webouts
Speaker 4: for containers. So I'd rather go of that route because
Speaker 4: I've seen too many issues we contain wraps today that
Speaker 4: somebody comes and says that it has matured, then I'll
Speaker 4: come back because I really like the idea of container wraps.
Speaker 2: But eventually there'll be a good version. You just don't
Speaker 2: know if it's there yet exactly well, And it's one
Speaker 2: of the you know, we talk about not getting hung
Speaker 2: up on a give implementation, but it seems like it's
Speaker 2: tough to move into or out of as your container apps,
Speaker 2: Like I don't know what it takes to actually pull
Speaker 2: out of that.
Speaker 4: It's fairly easy to pull out of container apps if
Speaker 4: you go into AKS. SoC scaling kind of up into
Speaker 4: AKS beastly mature in your solution to say.
Speaker 2: Which seemed to be the intent right is like here's
Speaker 2: the training wheels versions of orchestrated containers, and when you're
Speaker 2: ready to throw out the training wheels, you go to AKS.
Speaker 4: Yep, okay, And that's a cool idea. And I believe
Speaker 4: that there is an AKAS version on the way that
Speaker 4: is fully managed. I don't know if it's been released
Speaker 4: or think, but I do believe that that's where they're headed.
Speaker 4: I haven't looked at AKS for a while. But once
Speaker 4: you get to the point where I can tick a
Speaker 4: box and say I want an AKS cluster and I
Speaker 4: don't want to see the worker notes, I just want
Speaker 4: to see the API just host everything for me and
Speaker 4: just fix the NOE thing for me, then I'm in love.
Speaker 4: And at that point that would be might go to
Speaker 4: a platform for for astress us.
Speaker 1: So are you saying basically we should just bite the bullet,
Speaker 1: learn yam or figure out how to write these things ourselves.
Speaker 4: Yeah, unfortunately. Yeah, it's it's not that hard.
Speaker 1: It's not You're right, I just don't like it.
Speaker 2: Here's the question, is it necessary? Like why do I
Speaker 2: need this? As Like you said, I could just go
Speaker 2: to app Service. Yep.
Speaker 4: I don't know how much development they're doing on app
Speaker 4: Service anymore. I know it's a very old service, but
Speaker 4: it seems like it does everything I need and done
Speaker 4: some and.
Speaker 2: So for you know, basic websites. Man, that thing just
Speaker 2: works right. It's you know, run and you run two
Speaker 2: instances with a minor load balance con figured on it
Speaker 2: and void the outages are low, Like, it's just I'm
Speaker 2: not saying it's one hundred percent roadways recovers, but it's
Speaker 2: hard to complain.
Speaker 1: Well, we got to talk about what kind of applications,
Speaker 1: you know, what our audience is, and how big it is,
Speaker 1: and how much scalability we want to build in. I
Speaker 1: think that's probably the reason why people went to Kubernetes
Speaker 1: in the first place, is because you know, they picture
Speaker 1: their application being the next you know, Reddit or Facebook
Speaker 1: or whatever that's going to scale to millions of users,
Speaker 1: and oh my gosh, how we have to plan for
Speaker 1: that now.
Speaker 4: So yeah, and I think a lot of that scale
Speaker 4: can be handled by on the web apps as well
Speaker 4: with scaling building, and it's just it's a different miset.
Speaker 4: I guess the fact that you can spin up containers
Speaker 4: faster in akas, and you can play around a bit more,
Speaker 4: and you have more configuration ability with services, so you
Speaker 4: can map around things, you can deploy things and cannery
Speaker 4: builds and things like that. All of that deployment stuff
Speaker 4: of being able to point to different services and deploy
Speaker 4: to a small group of people, all of that is
Speaker 4: easier in akas than it is in web aps. You
Speaker 4: have to build all of that yourself, I guess. But yeah,
Speaker 4: I think there's a maturity part to it as well,
Speaker 4: and people have and understandings like you have to learn
Speaker 4: akas or sorry kubernatis.
Speaker 2: To work with it.
Speaker 4: And it's it's not just the AMO else, it's a
Speaker 4: it's a mind shift of of how you think about
Speaker 4: your deployments that you have to get into as well.
Speaker 1: Sure, and with great power comes great responsibility, right, I mean,
Speaker 1: if you can push a button and launch a million
Speaker 1: web services, you can do that, right, so you better
Speaker 1: be careful about what you're.
Speaker 4: Doing and to be honest developers and lots of responsibilities.
Speaker 4: Like we, we tend to go with the question can
Speaker 4: we and not so much should we?
Speaker 1: Should we?
Speaker 2: That's why you keep SIS admins around. We're the suspicious ones.
Speaker 2: This is actually a good idea. I don't think we
Speaker 2: can do it.
Speaker 1: We can do it?
Speaker 2: No you can't, No.
Speaker 3: You can't.
Speaker 4: It's like we as developers we look at SIS admins
Speaker 4: and DBAs and security people as really boring people who
Speaker 4: say no to everything. There might actually be reason for
Speaker 4: them say it.
Speaker 1: You might want to put some guard around this.
Speaker 2: When you devs do something to build a cool new feature,
Speaker 2: like you can get an A. Like people get really excited.
Speaker 2: They throw parties and stuff when an AMN does their
Speaker 2: job perfectly. Nobody can tell. Like the guest you can
Speaker 2: get is a C. I mean it's easy to get
Speaker 2: an F just turn a server off like that. You're like,
Speaker 2: you're like the sound guys. You're gonna do is a C.
Speaker 1: You're like the sound guy right that if there's no feedback,
Speaker 1: you don't exist. But the minute somebody hears feedback, oh
Speaker 1: that sound guy.
Speaker 2: Exactly where does serverleists fit in this equation for you? Chris?
Speaker 4: So, I this is going to sound weird because I've
Speaker 4: been doing it. I should be doing a lot more
Speaker 4: servilists and more usher functions than I am doing at
Speaker 4: the moment. I've I do mostly API apps, and I
Speaker 4: know that you can build APIs using serverallest functions and
Speaker 4: as your functions and all that stuff, But I actually
Speaker 4: tend to go for a core APIs for that because
Speaker 4: they need to be online anyways. I need to have
Speaker 4: an instance running and they can scale. I think serverlus
Speaker 4: is the astra function stuff is really really neat for
Speaker 4: things like managing ques, so basically being able to send
Speaker 4: things onto the service bus and then have functions pick
Speaker 4: them up and act on that, not having to run
Speaker 4: my own stuff for that. That fits imperfectly. But once again,
Speaker 4: I think it's a mindset. I have colleagues who do
Speaker 4: basically everything using functions, including their APIs, because they're used
Speaker 4: to that, and I think that idea is really good.
Speaker 4: If you can build it like that, then yeah, I
Speaker 4: guess there's money to be made as well. And that's
Speaker 4: the big part. I assume you.
Speaker 1: Said the magic word though, ques right, If you have
Speaker 1: Q and you have retry policies with poly or something
Speaker 1: like that around, the functions make a lot more sense
Speaker 1: because it doesn't matter if they're going to take a
Speaker 1: minute to spin up, they'll eventually get the message and
Speaker 1: passing on. And you know, in asynchronous processes anyway, in
Speaker 1: more synchronous or near synchronous processes where you need to
Speaker 1: reply right away, maybe.
Speaker 4: Yeah, I agree with that well.
Speaker 2: And again I think cloud lends itself to asynchronicity just
Speaker 2: because you can't. You don't want to hold a connection
Speaker 2: longer than absolutely need to. But it is a mindset
Speaker 2: to get into. I push the message to the que
Speaker 2: and I have a separate pipeline for a response, and
Speaker 2: even though that responds maybe a few milliseconds later, it's
Speaker 2: just not actually well.
Speaker 1: Yeah, and to add to that, Richard, you think it's synchronous,
Speaker 1: but it's a synchronous So in those things that there
Speaker 1: are all asynchronous processes, but when you want to show
Speaker 1: the user the result right away, right and you don't
Speaker 1: want them to wait maybe a minute because something is down,
Speaker 1: some function is now needs to spin up, and there's
Speaker 1: cues to handle it, and they'll eventually get there. But
Speaker 1: for those things, I agree with Chris that you know,
Speaker 1: you kind of want to hit those and make sure
Speaker 1: that they come back as soon as possible.
Speaker 4: Yeah, it's kind of exactly where I was going. Is
Speaker 4: we as developers love ACYNC because it makes it resilient
Speaker 4: and it can handle load and all of that stuff,
Speaker 4: But it also needs a shift in the UX because
Speaker 4: all of a sudden, when you press a button and
Speaker 4: you get yes, that's done, it's not actually done. And
Speaker 4: I think for us as developers, a UI like that
Speaker 4: makes sense, but for any other developed user of a
Speaker 4: system that's not a developer. The whole idea of having
Speaker 4: a synchronis process a press a button and the button
Speaker 4: doesn't actually do it. The button just sends a message
Speaker 4: and then it will happen at some point later on.
Speaker 4: Is a hard to understand because they don't understand how
Speaker 4: this technology works and be really hard to do a
Speaker 4: UX that makes sense, and then that conveys that idea
Speaker 4: that yes, we have kind of done what you've asked
Speaker 4: us to do, but it will take time and if
Speaker 4: you refresh the list where you added the thing to
Speaker 4: that list will unless you have somehow cash did client
Speaker 4: side and remember that you have made that thing and
Speaker 4: added on the client, it wi't actually show up in
Speaker 4: that list until X time later, which is confusing.
Speaker 2: I mean I found more users are used to that
Speaker 2: now because Facebook, right, yeah, because eventual consistency is part
Speaker 2: of their lives now.
Speaker 1: And if you want to understand the asn QI process,
Speaker 1: go order something on Amazon.
Speaker 2: Yeah, because it doesn't immediately it says, okay, I've taken
Speaker 2: your order. But then if thank you for your order. Yeah,
Speaker 2: you know, we learned this in e commerce a long
Speaker 2: time ago. Just feed them emails. Hey, you know now
Speaker 2: I send you emails I got your order, yeah, and
Speaker 2: I'm like, hey, I picked your order, We've packed your order,
Speaker 2: we're shipping your order. Here's a tracking number like people
Speaker 2: like that. But you said it's a sense of progress.
Speaker 4: You still kind of need and a sink part of
Speaker 4: the ordering as well, because you need you need to create.
Speaker 4: In my opinion, you need to create the order synchronously
Speaker 4: in a sort of a created state, so that when
Speaker 4: you refresh your orders page, it actually finds the thing.
Speaker 4: Even so, it becomes a combination of a synchronous thing
Speaker 4: that goes back and says here is your order ID,
Speaker 4: and then a message that goes away and does the
Speaker 4: rest of it. That makes that makes sense, But there's
Speaker 4: still a sink a part in that, because if you
Speaker 4: were just to say at order and then you go
Speaker 4: to your orders page and there's no order in there
Speaker 4: that says that you have made.
Speaker 2: It, it should it should definitely appear the fact the
Speaker 2: issues that I have received the order. That's as much
Speaker 2: as I'm saying, I've just gotten your message, I haven't
Speaker 2: done anything else.
Speaker 1: And that's a fairly low low costing, low cost API call,
Speaker 1: isn't it.
Speaker 2: It's like it's an insert and inserts are easy.
Speaker 1: Yeah, it's an insert. Right, here's the customer ID, here's
Speaker 1: the order I D here's the data and time, and
Speaker 1: here are the products. Boom put it in the database.
Speaker 2: I mean in the end, all you're doing is showing
Speaker 2: the chain of messages.
Speaker 1: Yeah, so it is.
Speaker 2: I think it's more to do with the way we
Speaker 2: need to think to separate the flow of data from
Speaker 2: the flow of the product. But you know, we fall
Speaker 2: back on the e commerce scenario because the async works
Speaker 2: really well there. I think it's far more challenging and
Speaker 2: people understand it working in an info worker space with
Speaker 2: some kind of custom app where you want to use
Speaker 2: asynchronosy for performance, but it does frustrate the user to
Speaker 2: see when does my changes actually appear?
Speaker 4: Yeah, but there's also scenarios where asynchros doesn't work at
Speaker 4: all like I've used I've worked a little bit with
Speaker 4: online auctioning. Asynchronous auction bids is a bad IDEA.
Speaker 2: Little tricky, little tricky. Yeah, And Chris, we got interrupt
Speaker 2: for one moment with this very important set of messages,
Speaker 2: and we're back is dot net Rocks. I'm Richard Campbell.
Speaker 2: Let's call Franklin. Hey talking to Frank Chris Kluck and
Speaker 2: a little a little bit about this whole cloud native thing,
Speaker 2: and hey, if these ads aren't something you want, you
Speaker 2: can go to Patreon and sign up and get an
Speaker 2: ad free version of Dona.
Speaker 1: Rocks absolutely five bucks a month Patreon dot dot net,
Speaker 1: rocks dot com.
Speaker 2: Should we talk about Aspire? How does Aspire fitness equation?
Speaker 1: Chris?
Speaker 4: Yeah, So aspires is an interesting thing because it's actually
Speaker 4: a few different things.
Speaker 2: How do you define it? Because that seems to be
Speaker 2: the magic term these days.
Speaker 4: Yeah, I know, so I have a fairly pragmatic view
Speaker 4: on that as well. I like being pragmatic, and so,
Speaker 4: first of all, the spire is three parts in my opinion,
Speaker 4: so you are actually kind of for but I ignore
Speaker 4: the fourth because I don't like it. Very pragmatic view
Speaker 4: on things. The first part is orchestration, so for dev time,
Speaker 4: it gives you orchestration of services on your local machine.
Speaker 4: So basically you get to encode, define what your set
Speaker 4: up looks like, what services you have. If you have
Speaker 4: seql server and read this, and you have three APIs
Speaker 4: and a web app and a few things like that, so.
Speaker 2: It's sort of set up to an infrastructures to service implement.
Speaker 4: Yeah, and you basically it's implemented the cool way because
Speaker 4: it gives you an actual project in visual studio and
Speaker 4: then you set that as your startup and you start
Speaker 4: your project, and then that project launches all the other
Speaker 4: projects for you and make sure that they can organize
Speaker 4: as the service discovery and making sure that it starts
Speaker 4: containing that needs to be running and all of that stuff.
Speaker 2: So this does feel like that pat you would do
Speaker 2: all this by hand. Now you don't need to.
Speaker 4: Yeah, I know people say that, oh, you can do
Speaker 4: that with doctor composed, and yes you can. You can
Speaker 4: do all of that with doctor composed. But there's a
Speaker 4: problem with doctor composed in this case, and that's the well,
Speaker 4: it's not a problem, but it makes it harder. And
Speaker 4: also the cool thing about this is that it goes
Speaker 4: straight into debugging for all of your projects, so you
Speaker 4: don't have to mess about with getting debugging to work
Speaker 4: together with a bunch of doctor composed stuff and all
Speaker 4: of that. It's just it just works on your local machine.
Speaker 4: And I enjoying it a lot. It's very opinionated, definitely,
Speaker 4: and it basically it does run up a bunch of
Speaker 4: containers on your machine and it does set up a
Speaker 4: bunch of yar reverse proxy work and figures out ports
Speaker 4: on your machine and stuff like that, and everything you
Speaker 4: put in can then basically expose a port or a
Speaker 4: connection string. And once a thing exposes a port or
Speaker 4: a connection string, you can then say that service A
Speaker 4: depends on service B, and then automatically a service A
Speaker 4: gets the correct port or the correct connection stream for
Speaker 4: service A and things like that, and.
Speaker 2: That service discovery pattern is a pain in the butt
Speaker 2: to code by hand, but if someone's got to genet
Speaker 2: for me, then thanks very much. But it does mean
Speaker 2: naturally resilient.
Speaker 4: Yes, and it's really cool because it just based it's
Speaker 4: based on environment variables. So I didn't actually know that.
Speaker 4: But there is a there's a new Git package that
Speaker 4: you can install on any core application that basically turns
Speaker 4: your your HP client for example, or your g RPC client,
Speaker 4: so that if you give it your I, it can
Speaker 4: go and look up that your I somewhere else than DNS.
Speaker 4: So the default implementation is DNS, but what they are
Speaker 4: implementing is a service discovery thing that goes and look
Speaker 4: at your look up and then goes, oh, is there
Speaker 4: an environment variable with a pre defined format that gives
Speaker 4: me actual URL, So you go, I want to talk
Speaker 4: to h GPS cal and slash lash products right, and
Speaker 4: then instead of going products as a DNS resolution, it
Speaker 4: goes and looks at an environment variable Aspire has injected
Speaker 4: for you, and that just works.
Speaker 1: Yeah, that's nice, which.
Speaker 4: Also means that you can use that in production as
Speaker 4: well if you want to. Yeah, because older A Suddenly,
Speaker 4: as long as the environment variable is there, you're good
Speaker 4: to go.
Speaker 2: This is the stuff that makes this admits happy folks
Speaker 2: developers too, the fact that I can go, oh, we
Speaker 2: need to move that, and we need to move it
Speaker 2: right now, and I can just change that environment variable
Speaker 2: and the app continues running. Just can't find the old one,
Speaker 2: redoes discovery, finds a new one and goes, yeah, no
Speaker 2: rebooting servers. You know, that's amazing.
Speaker 1: So I deployed my app to Azure and get this
Speaker 1: error message that it can't find HDPS local host colon
Speaker 1: five three nine seven and I don't know what to
Speaker 1: do about that, and I need to open a tech
Speaker 1: support ticket.
Speaker 4: Yes. Yeah, So that's that's kind of one part of
Speaker 4: and that's why I really enjoy Aspire because it makes
Speaker 4: that very easy for me to get multiple services, And
Speaker 4: even if you're just running and I spent that web
Speaker 4: with a Sequel database or postcars database or something like that,
Speaker 4: or you just read this, it makes sense to connect
Speaker 4: that anyway, because it also means that it can actually
Speaker 4: spin up your sequel server as a container for you instead,
Speaker 4: So if you don't want to have seql server installed,
Speaker 4: it will download and run the container through Doctor or
Speaker 4: Podman for you, which is really really nice. So I'd
Speaker 4: use it for basically anything I can think of. The
Speaker 4: second part is I guess the tooling. You do get
Speaker 4: a bit of tooling in Vicious Studio that helps you,
Speaker 4: but honestly, the tooling is minute. It When you add
Speaker 4: a new project into an Aspire enabled solution, it basically
Speaker 4: asked you during the create new project part, It says
Speaker 4: do you want to enroll this in Aspire? And you
Speaker 4: go yes, and it basically configures Aspire for you with
Speaker 4: like two lines of code. Not a huge deal. It
Speaker 4: does give you some extra options of like add Aspire
Speaker 4: component and a few little menu items like that, but
Speaker 4: nothing huge from a tooling point of view in my opinion.
Speaker 4: And then the third part that I like is Aspire components.
Speaker 4: So Aspire components are basically nugit packages, but they're defined
Speaker 4: to work with Aspire, which means that they actually have
Speaker 4: open telemetry for example, pre configured and sensible defaults for
Speaker 4: Azure or sorry, cloud native stuff configured. So if you
Speaker 4: add sql server, for example, say that you want to
Speaker 4: use antiity framework with sql server, if you do that
Speaker 4: through the Aspire component, it will make sure to set
Speaker 4: up retry policies and things like that for your sequel connections.
Speaker 4: It will add I think context pooling for your dB context,
Speaker 4: and it will also configure so that all of your
Speaker 4: sequel queries and all of that goes into open telemetry
Speaker 4: so you can get telemetry on your database connections and
Speaker 4: things like that, and it just works out.
Speaker 3: In the box.
Speaker 2: Nice. It's just cloud native defaults, yes.
Speaker 4: And it's all something you can configure on your own.
Speaker 4: But honestly, how many of you know how to configure
Speaker 4: the HTTP client correctly for a cloud native solution. It's like,
Speaker 4: there are a few things that you need to set
Speaker 4: up Aspire component versions, and Aspire basically does all of
Speaker 4: that sensible defaults.
Speaker 2: For you, yes, right every time?
Speaker 1: Please?
Speaker 4: And then I guess the last thing, the one that
Speaker 4: I dislike is there is a deployment story, so you
Speaker 4: can you can form your Aspire project, go and get
Speaker 4: a manifest file that basically defines how your things are connected,
Speaker 4: which is adjacent file. I think that says that I
Speaker 4: have some compute and I have some environment variables and
Speaker 4: they point to other compute blah blah blah, and then
Speaker 4: that manifest can then be used by other tools to
Speaker 4: generate and deploy environment. So, for example, if if you
Speaker 4: want to deploy your Aspire solution to Azure, right, you
Speaker 4: can go to the AZD and say ACD up, give
Speaker 4: it a Spire project. ACD will generate the manifest and
Speaker 4: based on the manifest, generate a bunch of bicyp files
Speaker 4: or armed template things that will go and create an
Speaker 4: environment for you in Azure and deploy your application to
Speaker 4: an Azure container app set up in Azure for you automatically.
Speaker 1: Okay, you do the same in Polumi or terror Form
Speaker 1: for example.
Speaker 4: It's it's well, the thing is you don't see any
Speaker 4: of the arm stuff underneath is just magically generated by
Speaker 4: the manifest.
Speaker 1: Right. Yeah.
Speaker 2: I would also argue you're the one person most qualified
Speaker 2: to criticize that because you've written all those different forms,
Speaker 2: like you strongly opinionated I how Coach would be built.
Speaker 4: The thing is, I really don't care too much about
Speaker 4: the code as such. That the thing that irks me
Speaker 4: about it is that people have now spent years upon
Speaker 4: years telling us that as professional developers, friends don't let
Speaker 4: friends right click publish. And having spent a couple of
Speaker 4: years doing develops and building both Terra forum and Polumi
Speaker 4: and BICEP templates for a bunch of as your resources,
Speaker 4: the idea of going ACD up and then basically have
Speaker 4: an environment generated for me by with the faults in there,
Speaker 4: I don't know. It feels like a command line version
Speaker 4: of right click publish, which I'm not a big fan
Speaker 4: of having. That said, you can also go and get
Speaker 4: the bicsep files from your thing, so you can there's
Speaker 4: a command, it's.
Speaker 2: Just a generator. You don't have to die yes no.
Speaker 4: So you can go and ask for the biceps specifically,
Speaker 4: and then you can go and look at the bicet
Speaker 4: files and you can make modifications to them. But every
Speaker 4: time you make a change to your Aspire project, you're
Speaker 4: going to have to create new biset templates and you're
Speaker 4: going to have to reapply all of your modifications that
Speaker 4: you added to them. I like the idea of giving
Speaker 4: me a foundation so that I know what environment variables
Speaker 4: I need to set up and what it needs to run.
Speaker 4: But I want to do it myself. But that's because
Speaker 4: I'm old school and meticulous in the way that I
Speaker 4: want my things to work.
Speaker 1: Did you use Octopus deploy back in the day? Are
Speaker 1: you still I have still like it?
Speaker 4: I have used Octopus deploy back in the day. I'm
Speaker 4: torn because I've always come in with it already pre configured,
Speaker 4: and the systems I've been involved in with Octopus are
Speaker 4: a bit too complicated. There's been lots of the pipelines
Speaker 4: and this thing does that thing, and it deploys this
Speaker 4: thing here, and there are four different versions of this
Speaker 4: thing over here, and it was hard to figure out.
Speaker 4: I think Octopus is a very powerful tool and can
Speaker 4: do more than your regular as your pipe develps pipeline
Speaker 4: or gettub pipeline as such. But yeah, I guess that
Speaker 4: the acd up thing tries to make it as simple
Speaker 4: as possible, to make the simplest release possible. So if
Speaker 4: you have a little blog or a little personal website.
Speaker 4: It can do it for you. But honestly, if I'm
Speaker 4: doing something that simple, I.
Speaker 2: Don't need this probably not. Yeah, I mean it's a
Speaker 2: problem is when you go simple, it's like, why are
Speaker 2: you worried about being cloud native? You could have just
Speaker 2: been in app service. As soon as you're complex enough,
Speaker 2: this is a struggle yep. And I don't know, as
Speaker 2: soon as you're in a significant environment with a team
Speaker 2: that's working on it, it's not up to you to
Speaker 2: run those deployment files. No, I mean I would suggest
Speaker 2: you generate them and then you hand them to the
Speaker 2: service engineers who now can look at them and say,
Speaker 2: what's the difference is from the one we're currently running,
Speaker 2: like and sort of can talk through it like it's
Speaker 2: a talking point for what the new deployment looks like. Yeah,
Speaker 2: but should probably never directly run them.
Speaker 4: Or if somebody can build a framework on top of
Speaker 4: the manifest so that I can plug in and say
Speaker 4: what I want to generate based on the manifest, because
Speaker 4: I know that AWS has done a bunch of work
Speaker 4: for as Fire as well, so it's not asture only.
Speaker 4: And as far as I understand, they are going to
Speaker 4: have where they probably already have a way to run
Speaker 4: the manifest to generate the AWS resources, so if I
Speaker 4: should plug into that. Yeah, so if I could plug
Speaker 4: into that and find a way for my develops team
Speaker 4: to basically say, okay, so you need some compute, but
Speaker 4: we're not running contained reps, I'm going to go and
Speaker 4: create AKS pods or I'm going to go and create
Speaker 4: a web app environment or whatever for it. But currently
Speaker 4: there is no I haven't seen anything like that, but
Speaker 4: I think early days so hopefully there will be other
Speaker 4: deployment scenarios that can use the manifest file to do
Speaker 4: a more sort of configured deployment of what you want.
Speaker 2: Yeah, if I think if I were on the inside
Speaker 2: of this, I would want those files, but I'd be
Speaker 2: diffing them against the existent deploy as a talking point
Speaker 2: for how are we utilizing cloud? Like now I can
Speaker 2: start making estimates for your utilization like that sort of thing,
Speaker 2: and then ask questions about why stuff has changed. Although
Speaker 2: arguably half the time the devs are going to go
Speaker 2: I don't know, because I just that file is just
Speaker 2: magically made for me, right yep. But I associate your
Speaker 2: concern there that it is odds are that's going to
Speaker 2: work the first time you do it, it'll never work again.
Speaker 4: Yeah, I think there's a risk of that. Yes, and
Speaker 4: as I said, it's early, it might get a lot better.
Speaker 4: But and also to be honest, once your product matures,
Speaker 4: the infrastructure might not change as much Anymore's like at
Speaker 4: the beginning of the project, you get new service twitch,
Speaker 4: you get yeah, there's oh we need that. I read
Speaker 4: this cash as well, and oh, by the way, we
Speaker 4: need a couple of cues and we need But after
Speaker 4: a while, I think from what I've seen that the
Speaker 4: environment tends to stabilize and you you change the features.
Speaker 1: You know.
Speaker 2: What it reminds me of is sql compare back in
Speaker 2: the day, Yeah, right, where whereas the dev now I
Speaker 2: could use tools like you compare her to say, here's
Speaker 2: the delta of the changes I need to make to
Speaker 2: the database for the new version, and no DBA like that.
Speaker 2: But I'd at least give them the script so they
Speaker 2: could see what the change, what we're proposing for the changes,
Speaker 2: as opposed to here's the new database. Figure it out
Speaker 2: like you save them a lot of work actually, but
Speaker 2: it was taken on slowly, like it was a battle
Speaker 2: to get that. But the only thing I can say
Speaker 2: in favor of it was sometimes you could revert like that,
Speaker 2: you could apply those changes in reverse, and normally databases
Speaker 2: we could never revert. But the fact that even occasionally
Speaker 2: became possible was an astonishing thing. And I wonder, I mean,
Speaker 2: this is less of that problem because you're not persisting
Speaker 2: data from instance to instance per se, but eventually that
Speaker 2: those engineers are getting overwhelmed with changes anyway, So anything
Speaker 2: that makes it easier for them to at least see
Speaker 2: the changes and move ahead.
Speaker 4: Yeah, Yeah, I guess that's kind of the develops way right.
Speaker 4: As a developer, I should take an interest in the
Speaker 4: part as well and work with the OPS team to
Speaker 4: make their lives as easy as possible. And if we
Speaker 4: can do that nicely, that would be cool.
Speaker 2: Well, and more importantly, with no attention by me because
Speaker 2: it's automated.
Speaker 4: Yeah, but I guess there's some work to be done
Speaker 4: on the manifest for you. For now, I keep saying
Speaker 4: that I believe that Aspire is awesome. It's part of
Speaker 4: my new workshop that I'm looking on. I'm using it
Speaker 4: for everything in there, but I'm not doing anything with
Speaker 4: the deployment because it's well in fact, it deploys to
Speaker 4: container apps as well. And I've already told you what
Speaker 4: I think about Yeah.
Speaker 2: Well it said there's that you get that other problem
Speaker 2: is h and they ought to have more options there,
Speaker 2: like could I deploy this as functions? Could I deploy
Speaker 2: this as as web afric containers.
Speaker 1: So Chris to you is to Aspire a green field
Speaker 1: only no tool or is it something that you can
Speaker 1: retrofit into your existing app?
Speaker 4: You can definitely retrofit. That's actually part of the tooling
Speaker 4: in Visual Studio for Aspire is that if you have
Speaker 4: an existing solution, you can right click a project and
Speaker 4: say AD or Aspire Orchestration spiify.
Speaker 1: I think that's.
Speaker 4: AD Aspire Orchestration and it basically if you do that
Speaker 4: in a in a brown field project, it will it
Speaker 4: will create the Aspire app posts for you, It will
Speaker 4: create the service default project that you also need, and
Speaker 4: it will plug it in for you so you can start.
Speaker 4: So you can definitely add it to any solution more
Speaker 4: or less that's out there. And a really cool feature
Speaker 4: is that it can also being that it can run
Speaker 4: not just projects or containers. It can go and run
Speaker 4: NPM project for example. So if you're running NPM in
Speaker 4: the front end for React stuff, you can go and
Speaker 4: tell it that, hey, I have an NPM project is
Speaker 4: located in this folder, go and run that for me. Hey,
Speaker 4: I have a pre existing image that's in Azure or ACR,
Speaker 4: or I have locally run that for me. Or by
Speaker 4: the way, I have a project over here that has
Speaker 4: a doctor file. So go and build an image for
Speaker 4: me and run that image for me automatically. Because well,
Speaker 4: as soon as you do that, you can't debug it.
Speaker 4: But if you just want to run it, for example,
Speaker 4: then you can go and do that. So for example,
Speaker 4: in my course, I use I have a UI that's
Speaker 4: already built, which is an MPM app, and I run
Speaker 4: that as a Docker file, and then I run Identity
Speaker 4: Server as a supporting thing, as just a pre existing
Speaker 4: image as well. So all of these things just plug
Speaker 4: in nicely, and all of a sudden they start talking
Speaker 4: to each other, which is really cool.
Speaker 1: So we have a customer that has a Blazer server
Speaker 1: application and they wanted to aspire ify their existing app,
Speaker 1: and so one of our guys did the work and
Speaker 1: they found that there was you know, the typical stuff
Speaker 1: when you're doing migrations or whatever that Aspire kind of
Speaker 1: over wrote, not overwrote, but re implemented things that were
Speaker 1: already implemented. And so now you have namespace clashes and
Speaker 1: stuff like that, and you have to make decisions if
Speaker 1: you're going to continue using your code or you're going
Speaker 1: to use the Aspire code. And I can't remember exactly
Speaker 1: what that was, but I remember that was a sticking point.
Speaker 1: It got fixed, of course, but.
Speaker 4: Yeah, I think there might be there might be jagged
Speaker 4: just when you start doing it on ground films for
Speaker 4: obvious reasons. But I think the goal for it is
Speaker 4: to be as much as possible out of the way
Speaker 4: of your actual application code. Even though as I said,
Speaker 4: there are Aspire components that you want to use. So
Speaker 4: even if you do if you do it on a
Speaker 4: brand field, for example, you do want to go and
Speaker 4: change the way that you register your dB context for
Speaker 4: anti the framework, for example, because the one that comes
Speaker 4: through Aspire has the the open telemeter stuff plugged in,
Speaker 4: for example. And you do want if you use Sequel
Speaker 4: connections for example, there's a package for that, and if
Speaker 4: you're using reddis you might want to use the reddis
Speaker 4: core or Aspire component and so on. So there's a
Speaker 4: bit of a walkthrough of upgrading your things, but I
Speaker 4: definitely think it could be worth it for existing projects
Speaker 4: as well, just so that it makes the dev experience
Speaker 4: better because the idea of being able to press F five,
Speaker 4: run the thing, and oh yeah, I forgot to mention.
Speaker 4: You do get an aspired dashboard as well, so when
Speaker 4: you start the application, it starts up a nice uy
Speaker 4: that shows you what services you have, if they're online
Speaker 4: or offline, what ports they're on. You get all the
Speaker 4: logs in one place, filtered by the different applications. You
Speaker 4: get structured logging, you get open telemetry, tracing support, and
Speaker 4: things like that. So it's just that is worth so
Speaker 4: much to me of being able to go and say, oh,
Speaker 4: something went wrong when I talk to Identity server. Sweet,
Speaker 4: I'm just going to look at the logs specifically for
Speaker 4: Identity server, and it's easy for me to go and say, oh,
Speaker 4: that's the thing that went wrong in Identity server. I
Speaker 4: need to go and reconfigure this for example.
Speaker 1: Yeah, right, and this aspiification, if you call it, that
Speaker 1: was very successful and the customers happy. And I love
Speaker 1: the term that you use jagged edges. I mean, I
Speaker 1: know I've heard I've heard that before, but man, it
Speaker 1: really just hits home right here.
Speaker 4: Well, it's that or there'll be dragons.
Speaker 1: There's a few jagged edges you need to yeah, yeah,
Speaker 1: you need to file them down.
Speaker 4: Yep.
Speaker 3: Yeah, it's fine.
Speaker 4: It's tough, and there's always going to be jagged edges
Speaker 4: or dragons at the beginning of a project. And yes,
Speaker 4: the Spire was released quite a while ago now, but
Speaker 4: it's still early days and some of the things, funnily enough,
Speaker 4: is still in beta. There is a there's a thing
Speaker 4: that's commented out if you want to do g RPC telemetry,
Speaker 4: it says, just just removed this comment and you can
Speaker 4: get EUROPC come. And basically that extension method that they're
Speaker 4: calling is not in the actual project. And when you
Speaker 4: need to go and add the NuGet package for it,
Speaker 4: there's only a pre release version of it available. So,
Speaker 4: as I said, early days, but it looks really really promising.
Speaker 2: Mm hmm. That's great, and it's I said, this is
Speaker 2: only came in the in the in New Existence a
Speaker 2: few months ago, like they've been racing to figure it out,
Speaker 2: like it's going to twitch a lot for the first
Speaker 2: couple of versions for sure and already has boy I
Speaker 2: was I did another year from now, who knows well.
Speaker 4: I did a I've done a couple of talks on it,
Speaker 4: and I did my first talk prepped it, and then
Speaker 4: when I was about to do the talk at the conference,
Speaker 4: I ran my code and it didn't work because apparently
Speaker 4: between the two preview versions that I was running, they
Speaker 4: actually read did a lot of the API. I think
Speaker 4: the API now with version one being released is fairy
Speaker 4: is stable, but there are things that can be better.
Speaker 4: And I can also see that the way that components
Speaker 4: work mean and the way that the whole provider model
Speaker 4: for resources and Inspire works means that the community is
Speaker 4: going to start adding things to it. So you're going
Speaker 4: to be able to as I said today, you can
Speaker 4: see a bunch of ASK stuff, but there's also AWS
Speaker 4: stuff that's coming out or has come out there. People
Speaker 4: have added their own things to it already, so we're
Speaker 4: going to see more and more things plug in and
Speaker 4: make your life easier to work with when it comes
Speaker 4: to Aspire than doing it without Aspire.
Speaker 1: I think absolutely very good Chris. You know, pleasure talking
Speaker 1: to you as always. We really enjoy having you on
Speaker 1: the show and thanks for your insight.
Speaker 4: Well, thank you for having me. It's always a pleasure
Speaker 4: to be on the show. So I'm willing to come
Speaker 4: back whenever you feel like it.
Speaker 1: Thanks very yeah, or whenever you have something new to say.
Speaker 1: Don't hesitate to reach out. I will all right, and
Speaker 1: we'll talk to you, dear listener next time on dot
Speaker 1: net rocks. Dot net Rocks is brought to you by
Speaker 1: Franklin's Net and produced by Pop Studios, a full service audio,
Speaker 1: video and post production facility located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online at pwop dot com.
Speaker 2: Visit our website at d.
Speaker 5: O T N E t R O c k S
Speaker 5: dot com for RSS feeds, downloads, mobile apps, comments, and
Speaker 5: access to the full archives going back to show number one,
Speaker 5: recorded in September two thousand and two.
Speaker 1: And make sure you check out our sponsors. They keep
Speaker 1: us in business. Now, go write some code. See you
Speaker 1: next time.
Speaker 3: You got j middlevan
Speaker 1: To that bed is hard, then my texas a lie
Speaker 1: vole