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