October 15, 2025 • 55 mins
Aspire has been around for almost two years. How do you use it effectively? Carl and Richard talk to Chris Klug about his experience with .NET Aspire. Chris discusses thinking cloud natively, whether you are going to the cloud or not - it's not just a place, but also an architecture. The conversation digs into the role of containers and Kubernetes, deployment strategies, telemetry, security, testing, and more. You can use as much or as little Aspire as you wish!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
How'd you like to listen to dot net rocks 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 net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
(00:21):
dot com. Hey, welcome back to dot need rocks. I'm
Carl Franklin, an amateur count And although dev Intersection has
(00:41):
hopefully come and gone, if the world hasn't ended, uh,
we haven't been there yet. We're recording this on September thirty.
Speaker 2 (00:48):
Time shifting is a wonder, but yeah, we're we're headed
there in a few days and then yeah, by the
time this is published, it'll have happened. Actually, I think
I'll be in Lizbeon on the week this is published
for the Azure dev.
Speaker 1 (01:00):
So that's also appropriate because we're talking about Aspire and
by this time, hopefully you'll have done the crazy gotten
at rocks dot com should have been a spirified.
Speaker 2 (01:09):
A spirified because that's a word.
Speaker 1 (01:13):
But we don't know as.
Speaker 2 (01:17):
We can't just because you're going to build it on
stage doesn't mean you're going to deploy it. That's right,
that's right.
Speaker 1 (01:25):
Anyway, Chris Klug is here, we're going to talk to
him about Aspire, and let's start with nineteen seventy two,
which is our show number.
Speaker 2 (01:34):
Yeah, there's a.
Speaker 1 (01:35):
Bunch of stuff happened. The Watergate scandal.
Speaker 2 (01:38):
Yes, I think that's the single biggest piece of news,
although you can always look at everything. Vietnam during seventy two.
Speaker 1 (01:44):
Oh yeah, yeah, significant stuff, the Easter offensive by North Vietnam,
the US response with Operation Linebacker. Nixon went to China.
Speaker 2 (01:55):
Yeah, that's big news.
Speaker 1 (01:56):
Probably probably to take his mind off of water Well,
it was a big breakthrough and it had been worked
on for really a few years. Your Kissinger had been
involved and so forth, like that's the beginning of the
opening of China. That kind of helped lead us to
where we are right now. And we got some beautiful
cherry trees out of it, and they're still there.
Speaker 2 (02:13):
It's pandace. Don't forget the pandits.
Speaker 1 (02:15):
And the pandas, right, the Munich massacre during the Summer
Olympics terrorist attack not good, and the troubles in Northern Ireland.
Speaker 2 (02:26):
Yeah, bloody Sunday.
Speaker 1 (02:27):
The troubles such a whitewashed version. Yeah, description of that troubles.
A bunch of stuff. Like I said before the nineteen
seventy two Winter Olympics, a lot of entertainment things happening.
But I'm gonna let you take it from here with
science and tech.
Speaker 2 (02:47):
Let's do space first, Okay, Big Year. Of course, Mariner
nine arrives at Mars. We always think the Mariners are
all the same, and they weren't. They were a class
of planetary explorer. Some failed, some succeed and so forth.
But Marina nine was a very large mariner was twice
the size of the predecessors. Mariner eight didn't launch especially,
(03:11):
but six and seven did. And this one's literally a
thousand kilos where six and seven were about five hundred.
Why because it carried enough fuel and power plant to
go into orbit around Mars, the first time humans ever
put something in orbit around another planet. Wow, And then
spent about It's spent three hundred and forty nine days
in orbit around Mars operational, taking pictures of the majority
(03:33):
of Mars. Those photos used to plan the Viking landings,
as well as giving us our first detailed photographs it.
Speaker 1 (03:40):
Looks like Gene Roddenberry's you know, Scape of External Planets
was pretty spot on in terms of what of what
Mars actually looks like.
Speaker 2 (03:51):
Yeah, Mars had you know, the problem we had with
Mars was there was a year long dust storm in
the earlier marindim missiones of the good and getting good
pictures and like, what's going on? I just have no
idea that it was this crazy dust him. But Mariner
nine stuck around, was able to orbit rather than just
to a flyby. It's difficult to get into orbit of
on the planet. You think about the threading of the
needle to pull that up. Exceptional achievement, good stuff. How
(04:15):
about in computers? The last two Apollo missions, Okay, Paulo
sixteen Young Duke Mattalie, which is the second rover mission
secually called the J class missions the real science missions,
and the final one of Paulo seventeen with Sernaan, Evans
and Schmidt Harrison Schmidt being the only scientist to set
foot on the Moon. He was a geologist. He had
(04:36):
helped train the other test pilots. There are eleven test
pilots that had walked on the Moon to try and
find good rocks, and needless to say, he was better
at than everybody else. He's the only human face ever
photographed on the moon because he broke all the rules.
He kept flipping up the visor to see the rocks
better because he's a geologist. And it is actually a
(04:56):
photograph of him with the visor flipped because that goldvisor
stopped their eyes from burned out of their heads. But
that didn't matter to rish Schmid. He really wanted to
look at rocks, and he found easily the most important rock.
He found this unshocked chocolatedite, which is a synthesis of
olivine that showed that they rock formations were partially volcanic,
and it spoke to the actual formation of the moon.
(05:17):
Wow Incerning ended that mission with the we leave as
we came, and God willing we shall return with peace
and hope for all men.
Speaker 1 (05:27):
There is one thing we haven't talked about that happened
in nineteen seventy two, and that's Richard Campbell and Carl
Franklin started kindergarten because we were five. We were five
thru and isn't that the year that you went from
New Zealand to Canada?
Speaker 2 (05:48):
No, I just a couple of years before.
Speaker 1 (05:49):
And then oh okay, I thought you said, Oh no,
you were five when you went to your uncle's house
and had prairie dog target.
Speaker 2 (05:57):
Practice five, five or six. Yeah, it's you know, that's
hard to when you're young, The Great Prairie Dog story.
The microcomputer has been invented, or the CPU has been
invented a couple years before, but the first scientific calculator,
the HP thirty five, comes out in nineteen seventy two,
although it does not use a four thousand and four. Now,
this is the time when trigonometry and exponents were done
(06:19):
with slide rulers, so the idea we had an electronic
device that could do Trigg and exponents was a big deal.
It also use the first implementation of a thing called
a reverse polish notation or called postfix notation, where you're
loading registers, so you go one enter to enter and
then plus to add them together. And so if you
were into those old calculators, that's where it began. Nineteen
(06:41):
seventy two. Wow, as another from the previous show or
another reference to Alan Shoeguard, he has now left IBM,
gone to MEMORYX where he makes the shoe guard floppy
drive or read write drive for MEMORYX called the six fifty,
with one hundred and seventy five kilobits a storage on
an eight inch piece of plastic.
Speaker 1 (06:57):
They weren't asking the question about is it live yet?
Speaker 2 (07:02):
No, I think that's an ad A little later on
for cassette daves, well, that's.
Speaker 1 (07:06):
When they got into audio. It's probably later, but we'll
probably get there in a couple of weeks.
Speaker 2 (07:10):
And I'd be remiss not to mention the C programming
language Dennis Richie being released in nineteen.
Speaker 1 (07:15):
Seventy two currently get in Richie.
Speaker 2 (07:16):
And finally in video game history, the Magnavox Odyssey is
released in nineteen seventy two in the US for one
hundred US dollars that'd be about seven hundred bucks to day.
And it was you know, basic screen Pong and you
had two little knobs. It was Pong. Yeah, they had
a few variations on the game, but essentially it was
just Pong. They sold three hundred and fifty thousand units
(07:38):
by nineteen seventy five. This is also the same year
that one Nolan Bushnell makes a video game console called
Pong and forms the company Atari, and is promptly sued
by Magnavox and Settles.
Speaker 1 (07:51):
We would encourage our listeners to search the archives, the
dot Rocks archives for Nolan Bushnell because we talked to him,
yeah a few years ago.
Speaker 2 (08:00):
Yeah, one of one of Yeah, one of my heroes
from back in the day. And it was interesting to
actually meet the man, yeah, in his seventies and drink
whiskey with him.
Speaker 1 (08:09):
Yep. And I just remember him saying at the end
of it was an NBC, No, it was at dev
it was it was or DEEV. Yeah, he was addressing
the group and he said, you know, there's some very
very smart people in this audience, arguably the biggest collection
of smart people in Sweden right now in one room.
(08:32):
And I have some advice. Go have babies.
Speaker 3 (08:36):
Because the stupid people are over popularly and you need
to go home, talk to you significant other and say, honey,
we're going to take one for the team.
Speaker 2 (08:47):
Yeah. He was a grandpa. No two ways about that.
Absolutely funny. That's what I got seventy two crazy year.
Speaker 1 (08:55):
All right, so I guess we should get going with
better no framework.
Speaker 2 (08:58):
Awesome, all right, what do you got?
Speaker 1 (09:07):
Our good old friend Simon Crop is working on this
tool called Excelsior and it's an Excel spreadsheet generation library
with a distinctive data driven approach.
Speaker 2 (09:20):
Oh okay, so is he using l MS.
Speaker 1 (09:24):
I don't think so. And it's pretty pretty much just
you know, driven by Jason data and classes and you
can save it to a stream and you can do
custom headers and ordering and do some styling with with code.
You know, it's all it's all code and Jason data.
Speaker 2 (09:48):
So just a tooling library to dump data into Excel
with some formatting and exactabilities.
Speaker 1 (09:54):
Cool exactly. And there's lots of third party libraries that
do this, you know, the big ones do.
Speaker 2 (10:00):
You can cut your paste, your Brain's out or CSV
all the way, but it's nice to have a code
driven way.
Speaker 1 (10:04):
Well, like I'm saying, there are third party libraries, you know,
from dev Express and Telerating, those guys that have you
know in Grape City, the original spread they have libraries
that you can do this too as well. But this
is an open source, free library from Simon Beautiful. Yeah,
thanks Simon, Yeah, thanks Simon. No I learned it.
Speaker 4 (10:26):
LOVI it.
Speaker 2 (10:27):
Who's talking to us today? Richard grabbed Commentaler Show eighteen
eighty one. The moment we did with when David Fowler
talking a little bit about dot Net Aspire back in
those very early days where I think they were just
trying to figure out what the heck they were making,
and Noel Anderton had this comment. He says, I would
really like to hear them talk about Dapper. That's DAPR
and Aspire. There seems to be a major overlap between
(10:48):
these two projects that look to be mutually exclusive. Aspire
seems to be a dot net centric view, where Dapper
is more technologically agnostic. Less importantly, I'd also like to
know where you see this in relation to intern Ol
Developer Portal's IDP. You have to start an IDP dashboard
and you have the creation of a new component. Scaffolding
uses tooling being used by I DPS. Do you see
(11:08):
Microsoft building and IDP and considering we've really not heard
about IDPs again, so I don't know that it really
took off right. Everybody's got their own approach to doing
these things. But I do appreciate the term scaffolding, which
is certainly the way I've looked at Aspire as code
you use to generate other code that doesn't actually continue.
(11:31):
Can you on from there of certainly will Luke Crisen
on the whole Dapper versus Spire side, I do think
they overlap to some degree, because in the end, it's
trying to make cloud native code in whatever language you want.
In this case we're talking specifically dot Net. I do
think that Thespire goes deeper into the dot Net stack
the Dapper's capable doing it. But I've been interested to
(11:53):
do a Dapper show at some point in the future.
Show we'll pay attention to that. So Noel, thank you
so much for your comment, and a copy of music
Coba is on it even if you'd like copyes to code.
But I read a comment on the website at dot
netroocks dot com or on the facebooks we publish every show.
There a new comment there, and I read in the show.
We'll send you copymies to go by.
Speaker 1 (12:08):
I was just using music to code by yesterday while
I was working on a difficult problem. And uh yeah,
it's still going strong. Twenty two tracks, MP three, flak
and wave formats at musicdocode by dot net. All right,
Chris Klug, let's bring you in here. I'm reading a bio.
(12:29):
I'm reading a bio from the last show and stop
me if I get anything wrong. Chris Klug works as
a developer architect at Active Solution in Stockholm. That's right,
working mostly with cloud based solutions for clients in 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
(12:52):
somewhat uncharted areas to him, which suited him fine, as
he loves learning new things and figuring out how to
make them do what he wants them to do. Obviously,
these days he's working with that that aspire. So welcome back, Chris,
thank you, thanks for having me, thanks for being here.
Speaker 4 (13:06):
I can say that the intro is not really correct anymore.
I haven't done devils for quite a while now, but
I'm not actually touching cloud at this point either, because
I'm at a bank that has everything in house. But yeah,
it's I'm still a developer at least, so that part
was correct.
Speaker 1 (13:22):
You were a full stack guy, right, I mean touch everything.
Speaker 4 (13:26):
I don't defront them anymore, so I don't call myself
a full stack developer anymore. I I personally dislike the
idea of full stack developer because I think there's too
much in front end and back into note to actually
know both of them really well. But that's me at least.
I've decided to focus more on the back end side
(13:46):
of things in the last few years.
Speaker 2 (13:49):
Right, Do you have any thoughts on on no One's
comment about the relationship between Dapper and Aspire.
Speaker 4 (13:54):
I see them as very different things. So Dapper work
as far as I understand, Dapper works pretty well with Aspire.
I'm just I'm not a Dapper person. I've only used
that on one project, and personally in that scenario it
didn't give us very much. But I think Dapper is
more of a way of abstracting away your environment, right,
(14:16):
being able to plug and play different parts and replacing
things in your environment by giving you pre defined interfaces
that people can implement and then provide, whereas I think
Aspire is more of a we will host your services
for you. We're not going to give you any abstractions,
but we will give you a bunch of hosting stuff
(14:38):
for you instead. So they actually work pretty well together
because you can use Aspire to spin up the different
services you need, like reddish and seql and all the
things that you would do and service buses and stuff
like that, and then you use Dapper in your application
to configure how they fit together. So yes, there's a
bit of an overlap with the how it fits together
(15:00):
kind of thing, but they are very.
Speaker 2 (15:02):
I don't know if this is true yet, but I
could see Aspire being able to deploy Dapper as APIs
in front of the services it just configured.
Speaker 4 (15:09):
For in theory. Yes, yeah, I think that would work.
Speaker 2 (15:12):
Yeah, I buy that. And of course there is the
overlap on like the workflow side and things, and they
both generately a dashboard, but yeah, I see there's difference.
The main thing I see with Dapper is it's a
set of building block APIs that Aspire seems to avoid.
Speaker 4 (15:27):
Doing, which I personally kind of like. But that's made
because unless you have a very specific reason where you
actually do switch out your services, then I personally am
not a big fan of the least common denominator thing
for all of the services you want to use. I
don't mind pulling in an SDK for a specific service
(15:49):
that I use, And I also feel like in ninety
nine percent of my cases, the services I use are
the same during development and during production. Because we use
Sequel server, we use Cosmos, we use a bunch of
services that you can run locally using emulators and things instead.
So I haven't run into that porb currently for anything
that we need, but maybe sometime in the future.
Speaker 1 (16:13):
So, in your opinion, what is the most essential service
that dot net Aspire gives you. I mean, there's a
whole bunch of things in there, but what's the most
essential one.
Speaker 4 (16:24):
Oh, the most essential one for me is the ability
to actually it's not a service as such, but it's
running your own projects because you don't necessarily need any
external services to make Aspire really useful. For me, the
biggest thing that makes Aspire something that I really love
having is the fact that I can take multiple of
my services locally and just spin them up and debug
(16:45):
them all at the same time in an easy to
do way. And then on top of that, yes, you
have all of the other services that they can help you
out with, and those are just getting so many it's
ridiculous by now.
Speaker 1 (16:58):
Right Well, in that family of services, when you say
start a project and Aspire, what's the first thing that
you turn on?
Speaker 4 (17:09):
The first thing I probably put put into everything I've
built so far as a sequel, So for instance, yeah,
because I use sequel server.
Speaker 2 (17:16):
How old school of you, right.
Speaker 4 (17:18):
Yeah, I know everybody's moving to postgrists and document databases
and things, but the sequel has always been the foundation
and background of what I've been building. It's very natural
for me to go there. And the fact that is
that easy just spin up, that's what I'm putting in
there is my first thing in most cases.
Speaker 1 (17:37):
Yeah, about the red as cash, I know that that's
something that a lot of maybe a lot of developers
do know about it, but I think there's a huge
sloth of the development community of dot net development community
that is neither either never needed it or didn't know
they needed it. But that can make a huge difference
(17:59):
in performance and scalability.
Speaker 4 (18:02):
It can, and I think it's useful for a lot
of scenarios. We're currently looking at it for my current project,
but we're for we're doing a hybrid cash solution at
the moment with in memory while actually using the met
core hybrid cash with in memory and a sort of
a semi permanent store as well. And we looked at readies,
(18:24):
but we ended up going old school sequel again. Mostly
because we're hosting on prem at a bank that's using Kubernetes, right,
and we can't touch too much of the stuff there,
and trying to get them convinced that hey, we want
to run read this as well was not really an option.
Speaker 2 (18:40):
But you got to talk to it about standing up
a new service. That's an interesting battle to have at
a bank.
Speaker 4 (18:46):
That is a very interesting conversation to be had.
Speaker 2 (18:49):
I promise you, dude, I've done the mineral right. It's okay.
It's one thing to stand it up. It's another thing
to back it up, monitor it and like I know
all of that stuff.
Speaker 4 (19:00):
He's equal they had so that was aacy, But yeah,
I do. I agree with your carlab. I think reddis
is the simplest and by far fastest way to gain
performance out of your APIs and your services if you
know not how to use it.
Speaker 1 (19:13):
I'm doing a manual cash of the dot net rocks data.
So basically, we have a database to keep all this
stuff in, and then we generate JSON files and put
them in a storage account, and then we pull them out,
but only on a timer, you know, like a couple
of times a day or on an hour time or whatever.
(19:35):
So everything's cashed in memory pretty much all the time,
but it is a roll your own cash kind of thing.
And I think that's probably the first thing that Maddie's
going to want to tear out of there, and the
place with redd is when I get on stage with her.
Speaker 2 (19:49):
And again with time shifting, Maddy has already torn out
of there. Well she may or she may not have,
but it will. See it's I got to feel in
that's the first thing to go. I'm kind of excited
to see Chris talking about cloud related stuff on an
on prem implementation, like this is cloud as architecture versus
cloud as a deployment location.
Speaker 4 (20:09):
Yep, yeah, so it's yeah, I don't know why. Well,
it's funny because cloud native or cloud based development always
indicates Kubernatist. For most people, that's fine, there's a and
in this case it happens to be that we are
actually running Kubernatis, but we're doing it on prem. But
for me, the cloud native stuff is slightly different and
(20:31):
it doesn't need to be Kubernetes. But that's where we're
at the moment. But Aspire then has this interesting concept
of deployment where it doesn't need to go to Kubernates
even though you're doing a cloud ish solution.
Speaker 2 (20:46):
Although it certainly can. We did a whole show just
talking about Aspire being a way to get to containers.
If you're not already comfortable with it.
Speaker 1 (20:54):
Ye, is there Docker without Kubernetes in your opinion, not.
Speaker 4 (20:59):
Really too perfect? Honest. If I was going to run
something for local, yes, but for production, no, I wouldn't
run docer, Well, no, I wouldn't depending on how it well, okay,
that's now you got it depends on how you look
at it, right. If I was going to use Ashure,
which is my native home for most of them stuff
I do normally do. I believe in the idea of
(21:21):
having container images in my web apps, for example, to
do web aps for containers and hosting containers instead of
running my applications natively on web apps for example, That
makes sense. But using docer in a way where I
touch docer and do docer run and everything like that,
that's not.
Speaker 2 (21:41):
No.
Speaker 4 (21:42):
I would never do that.
Speaker 1 (21:43):
You're not.
Speaker 4 (21:44):
I'm not going to say it never because there will
be a scenario, right, but right now I haven't seen
that need as such. And if if I was going
to go in that direction. Yeah, kubernet Is an akas
would probably be better at choice.
Speaker 1 (21:54):
So imagine I'm a psychiatrist and you're on my couch,
tell me about Yamo.
Speaker 4 (22:02):
About Yamo.
Speaker 1 (22:04):
What is your relationship to Yamo.
Speaker 4 (22:07):
It's the it's the shitty replacement for Jason because it's, oh,
it doesn't have curly braces, but instead we make it white, white, white,
space sensitive. So a minor little change causes everything to
break down and it's really hard to debug. I don't
like Yamo whatsoever.
Speaker 1 (22:25):
God, I feel so vindicated, Richard Nice. You know here
I was thinking, I was like the you know, the
odd man out saying I don't like Yamo, but apparently
really smart people like Chris don't like it either.
Speaker 4 (22:36):
I wouldn't call myself very sad.
Speaker 2 (22:38):
Listen, anybody who says it like Yamo has Stockholm syndrome.
Let's be clear, right, Like, I get.
Speaker 4 (22:45):
The point, I really do. And if you pull up
a Yamo file that somebody has written that's already there,
it's definitely a lot easier to read than than Jason
because you don't have all of the curly bras and everything.
But authoring them is a different story because offering them,
all of a sudden you do a tab in the
wrong place or a space in the wrong place, and
all of a sudden, oh, you have now modified the
(23:07):
entire thing. I'm not a huge fan.
Speaker 2 (23:09):
Well, ps code helps you by letting you know everything
is read now and it's your fault.
Speaker 4 (23:13):
Yeah.
Speaker 2 (23:13):
True, Yeah, but I appreciate your thinking. YAML should be generated,
should and then should be read only when you look
at it.
Speaker 1 (23:23):
Yeah, it's kind of like assembly language, do not edit,
you are not quality, should be treated as such. When
you said Stockholm syndrome, it's funny because Chris is from Stockholm.
Speaker 2 (23:34):
Yep.
Speaker 1 (23:36):
The jokes just keep coming, just keep coming. Oh man,
all right, So we talked about Reddish. Where are some
of the other hidden gems in Aspire?
Speaker 4 (23:47):
Well, actually, I think there's there are hidden gems in
Aspire that's not really about services like that. There are
features I think that people are missing out on potentially
an Aspire that I find to be really little gems.
It's like being able to add customer commands to the
dashboard is one of those things that just on the
surface is like why would you need that? And then
(24:10):
we're doing it in the current project where we have
a little receive the database. So if somebody pulls it
up and they need to restore the database back to
a database that we can work with. It's not a
manual task. It's not a script that needs to be run.
You go into dashboard, you click the button and you say, hey,
reseve the database, and it sets the database for us.
It's nice, a nice way of doing it. We also
(24:32):
have an export from SQL to Neo for j for
some graph stuff, and we can redo that export using
a command as well. It's just those little things that
make it easier for people to use the dashboard as well.
Speaker 1 (24:44):
It's nice, I think, yeah, plumbing.
Speaker 2 (24:47):
Yeah, and you speak to doing more with how important
a dashboard is in the dev cycle versus in the insductions.
Speaker 4 (24:53):
Well, that's the thing in the production cycle. It's I
think to me currently Aspire kind of is a development
time kind of thing. Once it's deployed, I don't seem
as well deploying the Aspire dashboard or anything like that
into a production environment, even though you can do that now.
(25:14):
I mostly, as I said, look at it as a
dev tool and that's where it can with things like
little commands like that or maybe being able to look
at different durls and actually have them properly describe what
they do. Means that when you do a get pull
F five to start the thing, you actually get everything.
(25:34):
And now with the new support that they have where
if you don't define parameters, it will actually ask you
for missing parameters so you can get it down. You
press have five and the first thing that says is
the dashboard goes up and says, hey, there are missing
parameters here. Can you give me the database password? Can
you give me these other things? And then it stortes
it to your user secrets automatically. Means that getting a
(25:57):
new developer onto a project is so much easier, which
I think is a massive benefit.
Speaker 1 (26:02):
Is yeah nice sharing. Configuration has always been an issue
with me on the different teams that I worked on.
Not not insurmountable, but you know you, like you said,
you do a get pull and it doesn't work because
of some configuration issue and oh you got to add
this little section to your app settings whatever. So let's
(26:25):
talk telemetry here. So open telemetry is everywhere and Aspire
and in Azure, and you have that dashboard but once,
once it's deployed, does that dashboard still work for you
in terms of telemetry or do you go over to
another kind of run time telemetry monitoring thing and Azure.
Speaker 4 (26:46):
Unfortunately, right now, I've been on my bank project for
so long that it's actually been around the time that
Aspire came out, so I haven't been able to do
anything with Aspire with Azure, but I can know the
dashboard that comes with a Spire would not be enough
in my opinion, especially since it's as far as I know,
in memory only right, so it doesn't persistent, So I
(27:10):
would prefer having it offloaded to something else. As I said,
I see the Spire dashboard as a nice thing for
dev and then for production going to something like Honeycomb
for example, or a third party system that is built
specifically for that is probably the better solution. Or yeah,
you can do application insights or monitoring.
Speaker 2 (27:34):
I mean, odds are your administrators already have a telemetry
solution they need you to add too, And that's why
they like open telemetry because they probably have an input
feed for that. It's a good aim your app here
at this endpoint. Now our telemetry adds to our existing
monitoring solution. Yeah, Yep.
Speaker 1 (27:52):
It's a beautiful thing.
Speaker 2 (27:53):
Now, you hope, and then they'll complain about the crappy
feed you've given them.
Speaker 4 (27:59):
But it's also I really like that because it's it's
hard to get away from the fact that whatever dashboard
day or solution they have solutions chosen for telemetry is
a thing that's built purposely full for that thing. So
it's going to be really good for that thing's not
having to focus on that, not having to build your
own telemetry monitoring system, which I've done over and over
(28:23):
again for other clients, it's now really nice just shove
it off and then do some own of your own
custom hotel integrations instead, if you want to have your
own metrics and your own spans and things like that.
Speaker 2 (28:34):
But if the new app is using Kubernetes, they already
have an instrumentation pack for Kubernatores. They know how they
want to look at the state of containers, so that's good.
It's another part of why I don't want you to
add redicity equation, because I now have to tune episode
of telemetry for how do I know if Redis is
happy or not? Yep.
Speaker 4 (28:48):
Yeah, Which that's actually an interesting point where you're saying that, Richard,
that when you deployed, the ops guides will already have
a thing for you, right, Yeah, And I think that's
the way it works in and in most enterprises I've
been involved in, there's always an obstavision that have very
strict opinions, which then is interesting combining that with a
(29:10):
spire's way of thinking about deployments. I know I've been
on the show before and we talked about Infrastructure's code
and some options that were out there and pollumium things
like that, which I think was a cool idea, but
it moved infrastructure into the developers region, and I think
that is honestly a bit of a problem because most
(29:33):
enterprises don't want their developers to mess about with infrastructure.
Speaker 2 (29:37):
Yeah. Now, you're right. If an organization has a deployment
strategy already, and I'm telling you not all of them do,
then they will be concerned. If they want to own
that piece, then they want to understand that piece. And
when you introduce other languages know the tuning around, they're
going to get jumping about it, just like they jumping
about ratus. But sometimes they don't have that. But they
(30:00):
also get into trouble that way. Like, one of the
issues you have when you have a lot of systems
running in VMS are on against services in a shared
infrastructure is badly behaved apps being introduced to the equation. Like,
part of wanting to control the deployment is to know
what it's impacting, to have better security controls on it.
When you leave that too loose, you get surprised. Sometimes,
(30:23):
you know, a new version of that app gets deployed,
breaks this other thing over there, or gets a new
security acount of that, or you know, lights off the
seam right Like I've seen this happen where we didn't
tell it that it's going to message this way, and
suddenly it looks like a Dodos attack. The app operating normally,
like the whole security system just goes berserk because we
did this deployment.
Speaker 1 (30:42):
Like I love Poalumi, especially when you fry it, you know,
because it doesn't melt so fast. It's really good. Geez.
And on that happy note, let's take a little break.
We'll be right back after these very important messages stick around.
Did you know that you can work with AWS directly
(31:02):
from your ide AWS provides toolkits for visual Studio, Visual Studio,
Code and jet Brains Rider. Learn more at aws dot
Amazon dot com, slash net, slash tools.
Speaker 2 (31:19):
And we're back. It's Donna Rocks. I'm Richard Campbell. That's
Carl Franklin. Hey, hey here with our friend Chris and
I seem to have fallen into the grumpy Sisaben role
for this show, which I'm okay with because I know
how to say no is good A where anyway?
Speaker 1 (31:32):
My friend?
Speaker 2 (31:34):
But I think, you know, we speak to this really
challenging dynamic of you're building this complex software at the
point where you have a tool like Aspire to help
you with its construction and deployment, and your administrators need
to understand it and you need to know where to
interface with them, and it's obviously that deployment piece of
telemetry piece, that services piece, Like that's a lot of
(31:55):
conversations to have, like do you try and have that
in advance or you just build some Aspire and see
how it go.
Speaker 4 (32:01):
I would probably recommend having a conversation ahead of time
because it kind of sucks when you spend a year
building something and then you try to deploy it and
opskys goes Nope, no, that's where I think, I'm not
one hundred percent sure that I enjoy your I think
that Aspire is going in the right direction of pushing. Hey,
(32:22):
the configuration of the publishing goes to the developer. Once again,
that doesn't work in a lot of areas unless your
company then is big enough to build their own custom publishers.
Because they now with the experimental stuff in aspires, it
makes it possible for you for an organization to actually
build something that is custom for their organization, which I
(32:43):
guess would be a thing. But then the ops team
needs to spec spence that specify that very well, and
then the dev team has to build it for them
and everything. But then if you you can then reuse
that in theory at least.
Speaker 2 (32:56):
Yeah, I mean, I can see this being a real
battle for the first deploy of the app. But once
we get to an agreement, all that on that. Like you,
you know, we're back to those old agile mindsets. If
I want to be able to iterate quickly, so if
I'm living within the constraints that have passed through the administrators.
Once that the security contest is going to remain the same.
(33:18):
Telemetry context is the same, the deployment pipeline is the same. Hey,
deploy away. You know, don't interrupt me constantly with your
next weird deploy Like I want to be highly involved
in the first couple and after that, I'm kind of
keen to let you guys iterate and get your features
out without having a fight with us too much, or
that we only talk about the delta. Hey, new telemetery here.
(33:43):
You know, you need a new plumber in here. Oh
my goodness, we need new service here. Yeah, I would hope.
I mean, I just and buy me pizza and we
can talk right, like honestly.
Speaker 4 (33:57):
Yeah, if you're that Adamin guy, I'd have to buy
you a pizza. I my current or my current client is.
It's not that idea. Uh, it's it's a very strict
it's the every single application in the whole enterprise needs
to be deployed using the same pipeline in Jenkins oh boy,
(34:19):
Jenkins boy, and mostly focused on Java as well, so
getting in there was kind of an interesting little way
as well. So yeah, we've tried to fly under the
radar and get our stuff done without having to talk
too much to it and sorted it out, and like
I said, reusing sequel for as much as possible because
that's already there and needs to use.
Speaker 2 (34:42):
Yeah, you're literally doing staying within the guardline so you
don't have to talk to them make it easier. Yeah,
I appreciate that.
Speaker 1 (34:49):
I think I told this story before when we were
talking about Aspire, but one of my customers wanted to
aspireify their Blazer server application. So the only real issue
they had was we're using poly and you know, the
the stuff for for that is the HTTP Client Factory
(35:15):
I think, and that's what Aspire uses. So there was
like two you know systems going on there for for
dealing with network outages and things. But that was right.
Speaker 4 (35:30):
Yeah, and that that can be fixed as well because
all of that retry policy stuff for the client factories
in the services default project, so you can you can
either in case, you can either move the police stuff
that you have built in the previous system through there,
or you can remove your police stuff and use the
services to fault and you should be good to go. Yeah,
(35:51):
and I really I must admit I love that approach
of having the Services default project where hey, here is
everything we're doing and it's in C sharp format, where
it's not a gazillion configuration things you need to plug into.
We will give you the C sharp code. It just
makes everything so much easier and exactly Yamo. Yeah, and
(36:13):
it's not even Jason.
Speaker 2 (36:15):
Yeah right, it's its own thing.
Speaker 4 (36:17):
Yeah, the configuration code is always preferable in my world.
It just makes it easier to have it in one
place when you're a developer. I guess it's it makes
it harder when you and admin and you need to
maintain it afterwards, but it's don't know, I like having
it as much as possible in code.
Speaker 2 (36:34):
Yeah, me too. What about testing? Like, what's your testing
strategy for these apps in this style? Like? Is there
anything special? Once you're scaffolding like this, I have.
Speaker 4 (36:43):
A very very specific way of testing. Actually, an Aspire
unfortunately doesn't help with that in any way, shape or form.
So there is a there is a test So there's
the NBC test server thingy, which has got nothing to
do with MBC at all. It's just a new GET
package just named that unfortunately. But it runs your API
in memory, and there's a there's a similar version for
(37:06):
Aspire that can run you to do smoke tests and
things like that. The problem is that you can't do
any mocking. You can't fake any services because of the
way that Aspire works, and that means that to me,
it doesn't really work for testing. So what we're doing,
and I do in most of my project is for
all of the API projects, I use I tested those individually,
(37:30):
and then I use the in memory test server for
those and I verify that all of the Jason stuff
comes back as I expected to. And I also like
doing it integration style all the way down to the
database and not back up again, so I know that
it really works with all the layers.
Speaker 2 (37:44):
Nice. Yeah, yeah. And the main thing is you want
it automated as part of the pipeline as well, or
at least you know so you're always checking.
Speaker 4 (37:52):
YEP, and currently we don't have that in my project.
But it's funny because I've been building the APIs for
our system and I've only done tests. So I have
all my integration tests and they go green, and I
say it works. And then I have front end people
building a React front end and they come and complain
but it doesn't work. But I haven't actually fired up
(38:13):
the front end on my machine for about a year
and it's actually worked. It's worked pretty well because I
we agree on the contract of what they want to
get from the end point the end point, I write
the test to verify that the endpoint. It does what
it says and comes back in the right format and
it looks right, and then it.
Speaker 1 (38:32):
Doesn't show up on the browser. That's your problem.
Speaker 4 (38:34):
Yeah, pretty much like that. Yeah, it does break once
in a while, but it works nice. And I like
the fact that you can go to and from API
to database and verify the jobs or the Jason that
comes back because you know that that really works. It's
not I'm not a big fan of unit tests as
(38:54):
such because they don't show you your system actually working.
Speaker 2 (38:58):
In my opinion, Well, that's yeah, that's not what unit
tests are really for, right, Like you need you need
a more than kind of tests. Tests are for you
running locally as you're doing builds.
Speaker 4 (39:09):
And it's it's mostly if you to me, unit tests
are great if you have really complex code like that
does a lot of complex stuff, but ninety percent of
our systems don't do very complex stuff. You can look
at the code and go, I know that this is
going to work because I can see the code, and
then I don't feel like writing a gazillion unit test
(39:30):
on that because it's that simple.
Speaker 2 (39:32):
It's plumbing.
Speaker 1 (39:33):
I think a lot of the things that were complex
that we used to use, uh, you know, test first
for a test driven development for is all the stuff
that the browser does now that we used to have
to hand code. Like you know, me as a Blazer developer,
(39:53):
I don't do any of that old crazy Ajax stuff,
you know anymore. And the way that architecture has evolved,
it's just, you know something's too complex, you just break
it apart, and then you have two or three pieces
where you had one, and you put unit tests around them,
and Bob's your uncle. So yeah, I think the whole
(40:16):
idea of complex code in general is, you know, things
have gotten simpler.
Speaker 4 (40:23):
I think, yeah, I think in most cases you can
break it down. And like I said, I don't do
a lot of unit test, but I spent the entire
day to day writing actually unit tests on a serialization
stuff that we're building. But I don't care about the
unit test ask tests. To be perfectly honest, I don't
care about them verifying my code. I care about being
(40:43):
able to write click and say run tests so that
I can run it without having to spin it up,
so I can make a change, I can run the
test and also going, hey, I want to debug this
to see what this value is. Right now, debug test
is just so much simpler than having to run an application.
So I believe that there are definitely cases unit tests
are nice, but they're not for finding bugs or checking
(41:04):
my code in most cases because that gets checked by
the integration tests.
Speaker 2 (41:08):
There's a whole there's a whole conversation yet to be
had here about the structure of testing in these cloud
apps now, like even how you break down testing a
given service or testing your end against a mock of
a service like this has all gotten really complicated, it has,
and I'm just impressed with just how much people just
(41:30):
test in production now because you can always roll back,
you know. It's like you can fight for a long
time to find a way to test is independentally or
you could ship and see you and roll back if
you must, And.
Speaker 4 (41:42):
I think some were some were in I prefer not
to test it in production if I can get a
get away from it. But yeah, the closer you can
get to production tests, the better it is, obviously, because
it's it's going to be what the users are going
to use.
Speaker 1 (41:58):
Right.
Speaker 4 (41:59):
Yeah, we've I've done several different iterations. I think all
developers have done that over the years, trying to figure
out what works for you and how do we make
this work. And especially in a service oriented architecture where
we've got HTV services, if you can just define the
interfaces and basically document how they work, then I think
(42:22):
it works pretty well even if you're distributed, because you
can verify one service individually from another one. And even better,
to be perfectly honest, is don't let other teams use
your service. Give them an SDK style project. Instead, give
them a new gift package that has methods on it
that you control that calls your API, which means that
(42:43):
they can just add your SDK client to their system
and call it like a c sharp thing. And you're
in control of the API, but you're also in control
of the thing calling the API, which means that it's
easier for you to verify that it works and it's
easier for you to make changes.
Speaker 2 (42:59):
Yeah, for sure. And plus you know the incremental updating
instead of change model and a B testing. All these
strategies about not needing a huge testing framework that the
little things that you could trial, and even dark featuring
in the field is ways to test stuff without having
to build a huge test infrastructure and limiting your impact
(43:22):
if you do make mistakes, so that often you can
just feature switch something back off again and then the
next bill will try and make another iteration.
Speaker 1 (43:30):
On it or feature switch it on for just the
admin users you know, or or you the tester, so
you can test it without giving the feature everybody.
Speaker 2 (43:41):
Mm hmm. Yeah, I think it's.
Speaker 1 (43:43):
Just using the old nag.
Speaker 4 (43:44):
And there's an interesting thing as well with if we
go back to the Aspire stuff and testing is as
I said, I don't do a lot of testing like
with Aspire, but I kind of like with the service
discovery built into Aspire, it actually allows you to mock
external resources as well, very very easily. So in tests
(44:05):
you can go and say, hey, I have this external resource,
but it's your own mocked service, and then for production
you go and say, I have this service over here
that we want to use. That's actually a very nice
feature to do as well, because it means that you
don't have to mock everything in your code. You can
actually mock the API that you're using instead, which is
a nice little benefit of having Aspire in place.
Speaker 2 (44:26):
Nice, So what's missing from Aspire at this point, Like,
we haven't really dug into the latest version nine point
five at all. I'm going to do a separate show
on that, but you know.
Speaker 4 (44:37):
Yeah, I haven't looked at it either.
Speaker 2 (44:39):
To be honest, it's moving for relatively rapidly. We think
we did that original nine to oh show with David
in January of twenty four, so you know, here we're
not We're just over a year and a half on
and we've had incremental updates. I don't think they're going
to increment from nine until dot net ten ships obviously
(45:00):
would be my guess, but they have pushed out a
dot change every few months. But do you stuff see
things that are missing from it? Still?
Speaker 4 (45:11):
The thing is, it's really hard because I know I
use the things that are in there, and I have
a really hard time saying like, well, this is really missing. Yes,
I think the testing part is missing, and I've talked
to the David and Damien about that and they know
it's missing. But there's also not a very easy fix
(45:31):
for it as such. Unfortunately, the thing about them shipping
very rapidly on the other hand is also that some
of the things are under experimental as well, so you
actually or the mark experimental, so you actually have to
go and say, if I want to use this feature,
I need to turn off a bunch of warnings and things.
I don't know. I get that they want to get
(45:52):
it out there, but I'd rather have experimental things in
a non released version. So basically you had a release
vers non release version of it before and then not
put it into the release version until it's not experimental anymore,
because you can't really take a dependency on everything that
is in there, even if it's not a release candidate
or sorry, even if it's a if it's a release version.
(46:16):
But that's just them iterating quickly, I guess. So we're
going to have to live with that for a while,
and that's that's good. They are iterating that quick rappily,
and it's really hard to actually follow along with everything
that's going going out because there's new stuff, but they're
also there's most of this stuff that comes out is
in my opinion, a lot of little edge cases, a
(46:39):
little scenarios that they're trying to figure out that's missing
that I haven't run into in other cases. I think
the last thing they did was the publisher's stuff, which
is undocumented and experimental at the moment. That is going
to be interesting if they can get it into a
non experimental state and maybe make it a bit easier
for you to build a publisher, and also maybe document
(47:02):
how to build a publisher because it's undocumented at the moment,
So I had to build one for a demo I'm
doing for one of my talks, and the only way
to figure out how it works is to look at
the open source versions one of the other open source
versions and copy the code from there and then start
messing with it. And that's Yes, they're releasing quickly, but
(47:25):
it's not documented either, so it can be a bit
hard to pick up the new stuff as well.
Speaker 2 (47:30):
Yeah, yeah, I don't extend. All these things are moving
so quickly, so they think it's challenging to try and
step in there and aspire. To me, has always been
a brown fieldy kind of thing, like you're not really
starting apps from scratch in this class. It's pretty rare,
So you're trying to get more cloud centric on an
existing application and you can interspend it aspire into it,
(47:52):
or are you getting a chance to start from the
beginning with Aspire.
Speaker 4 (47:56):
I start everything from scratch with Aspire to perfect honest,
But I I work in a world where I only
do I normally only do three to six months of
the project because of well, I guess ADHD or something
like that. I can't. It's I'm happy that I have
my employer active solution that supports that, because I actually,
(48:20):
if I get into a project that isn't fun, I
actually get depressed and it goes bad sometimes. So being
that I only go onto projects very very rapidly like that,
it also means I often go on new stuff. So
I will come in, I will build the foundational stuff,
and then once the foundational stuff is up, I will
move on to something else. So I'm one of those
(48:41):
lucky people that actually do get to do Aspire new
and then start from scratch.
Speaker 2 (48:46):
Very nice.
Speaker 4 (48:47):
We didn't do it quite in this project. We actually
worked and had two services up and running before we
put Aspire in place, but it was still very very
early days as such.
Speaker 2 (48:59):
Right.
Speaker 4 (49:00):
But I'm also saying, like you say, brown Field stuff,
I say that to everybody. It's if you've got a
solution that has more than one project in it. See
if you can get aspired to work, because it's going
to make everything easier to work with. And honestly, if
you only have one project but it's slightly complex, put
a spire onto and anyway, so you get the dashboard,
(49:21):
you get the open telemetry. No, you don't need the
retripolsies and all the stuff that you get for free,
but just the open telemetry dashboard and the ability to
plug into that and being able to see your logs
in a nicer way, that's worth it for a single,
single project solution in my opinion, right.
Speaker 2 (49:39):
Right, Yeah, I bet that.
Speaker 1 (49:40):
Well, I'm going to keep that in mind as I
go into this. We're doing this live, you know, aspire
ify dot net rocks dot com.
Speaker 2 (49:48):
Yeah, and you're living the dream and the adventure man
like I hope that's as well. Well, and again time
shifting it'll have already happened.
Speaker 1 (49:57):
We hope, we hope.
Speaker 2 (50:01):
But I mean, I was appreciate Chris. You haven't done
one project, Inspire, You've done a bunch. You wouldn't keep
using this if it wasn't actually helping you.
Speaker 4 (50:09):
No, no, no, no, it's it's awesome. It's also I'm
not an AI person at least Richard, you know that
we've had conversations about that, and I have opinion it's
about AI and everything. If you're sort of wanting to
be a bit bleeding edge in the Microsoft sphere, it's
either AI or Aspire. There's nothing else to actually look
(50:30):
at at the moment the thing that comes out. But
having that stat I actually love Aspire. I've loved the
idea of it since I saw the first like release
version that they've showed to the m v P s,
and there's I don't know, it just solves so many
little little things. It's not overwhelmingly wow, this is awesome,
(50:52):
it will change revolutionize my world, but it solves a
bunch of little things that annoy you every day and
every time you press F five to start your application.
It's I don't know, it's it's hard to say about
those little things make it a little more more enjoyable.
It's actually right code, and I think.
Speaker 2 (51:11):
It does strike me as a strategy to get gradually pregnant.
All in this case, we're talking a gradually cloud native
that yes, you you know, as you learn more about
what it is to live in the cloud. ASPIRER was
already there and ready to help you with the next problem. Yeah,
that's it. I appreciate that he had. Davids did a
good job of letting us gradually get involved and think
(51:34):
more cloud dative. You don't have to jump out climb
up this huge cliff before anything works, right.
Speaker 4 (51:39):
No, because that's kind of like you said, like it
started off talking about a bit about Kubernetes, because I've
been into the Kubernetes area as well for a while,
and it's that's a that's a steep hill to climb
before you get anything done. And then once you understand
Kuberneties and you have to start doing helm charts and
deployment pipelines for that, it's it's a pain, and it
(51:59):
does and solve your local development in any way either.
So it's I don't know. I think this is a
nice way to make your day to day job easier.
If you don't want to use it for deployment or whatever,
that's going to have to completely fine, But your daily
work is more enjoyable.
Speaker 2 (52:18):
I appreciate that.
Speaker 1 (52:19):
What's in your inbox, Chris, what's on your to do list?
Speaker 2 (52:23):
Sleep?
Speaker 4 (52:26):
I'm currently actually spending a lot of time working on
I've done two new presentations that I'm working on or
have have worked on, and we'll have to refinal a
little bit after NBC Copenhagen working on a two day
really wonky workshop on Microsoft Web Development where they attendees
(52:49):
get to play with a spinnet Core minimal APIs, NBC
g RPC, your project or lanes as identity server and
some other stuff, so they basically get a little tour
of everything. A lot of things you can find in
acenet core. So that's kind of cool.
Speaker 1 (53:08):
That's very cool.
Speaker 4 (53:10):
Yeah, it's interesting going into so many different things and
sniff around like what can we do here, what can
we do there, and show people that acenet core is
more than mbassy.
Speaker 2 (53:22):
Yeah, yeah, it certainly is and always have been. But
you know, yes, it's basically the same thing you just
did in this past hour. Chris is like, there's more
to aspire than you know, and you can there's a
bunch of different points to grab at it. So I
appreciate that that you break down the pieces and say
you could use this, and you could use this, and
did you know about this? And there's lots of ways
to help.
Speaker 4 (53:41):
And it's also I think like most people are stuck
in not stuck, but most A lot of people work
in enterprise environments where there's you're working on the same
thing all the time and you get kind of shoved
into this corner of this is the way that it works,
and you don't have time to look at everything else.
So that was kind of the idea behind my workshop
was let's take people that work on maybe not so
(54:03):
cool enterprise projects and show them what else is out there,
so that if they come up with something new that
needs to be built, maybe Project or Leans can help them,
or building a new service using DRPC, you might be
easier for some things and things like that. So that's
the idea behind it.
Speaker 2 (54:18):
Nice, very good, I appreciate it.
Speaker 1 (54:20):
Chris. Thanks for spending an hour with us. It's been great.
Speaker 4 (54:23):
Well, thank you for having me again. It's it's always
awesome to be on the show.
Speaker 1 (54:26):
Ye all right, go get some sleep. We'll talk to
you next time on dot net rocks.
Speaker 5 (54:54):
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud. Online at PWOP dot com.
Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
(55:16):
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two thousand
and two. And make sure you check out our sponsors.
They keep us in business. Now, go write some code.
See you next time.
Speaker 4 (55:31):
You got jam Vans
Speaker 1 (55:35):
And
How'd you like to listen to dot net rocks 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 net Rocks
patron mug. Sign up now at Patreon dot dot NetRocks
(00:21):
dot com. Hey, welcome back to dot need rocks. I'm
Carl Franklin, an amateur count And although dev Intersection has
(00:41):
hopefully come and gone, if the world hasn't ended, uh,
we haven't been there yet. We're recording this on September thirty.
Speaker 2 (00:48):
Time shifting is a wonder, but yeah, we're we're headed
there in a few days and then yeah, by the
time this is published, it'll have happened. Actually, I think
I'll be in Lizbeon on the week this is published
for the Azure dev.
Speaker 1 (01:00):
So that's also appropriate because we're talking about Aspire and
by this time, hopefully you'll have done the crazy gotten
at rocks dot com should have been a spirified.
Speaker 2 (01:09):
A spirified because that's a word.
Speaker 1 (01:13):
But we don't know as.
Speaker 2 (01:17):
We can't just because you're going to build it on
stage doesn't mean you're going to deploy it. That's right,
that's right.
Speaker 1 (01:25):
Anyway, Chris Klug is here, we're going to talk to
him about Aspire, and let's start with nineteen seventy two,
which is our show number.
Speaker 2 (01:34):
Yeah, there's a.
Speaker 1 (01:35):
Bunch of stuff happened. The Watergate scandal.
Speaker 2 (01:38):
Yes, I think that's the single biggest piece of news,
although you can always look at everything. Vietnam during seventy two.
Speaker 1 (01:44):
Oh yeah, yeah, significant stuff, the Easter offensive by North Vietnam,
the US response with Operation Linebacker. Nixon went to China.
Speaker 2 (01:55):
Yeah, that's big news.
Speaker 1 (01:56):
Probably probably to take his mind off of water Well,
it was a big breakthrough and it had been worked
on for really a few years. Your Kissinger had been
involved and so forth, like that's the beginning of the
opening of China. That kind of helped lead us to
where we are right now. And we got some beautiful
cherry trees out of it, and they're still there.
Speaker 2 (02:13):
It's pandace. Don't forget the pandits.
Speaker 1 (02:15):
And the pandas, right, the Munich massacre during the Summer
Olympics terrorist attack not good, and the troubles in Northern Ireland.
Speaker 2 (02:26):
Yeah, bloody Sunday.
Speaker 1 (02:27):
The troubles such a whitewashed version. Yeah, description of that troubles.
A bunch of stuff. Like I said before the nineteen
seventy two Winter Olympics, a lot of entertainment things happening.
But I'm gonna let you take it from here with
science and tech.
Speaker 2 (02:47):
Let's do space first, Okay, Big Year. Of course, Mariner
nine arrives at Mars. We always think the Mariners are
all the same, and they weren't. They were a class
of planetary explorer. Some failed, some succeed and so forth.
But Marina nine was a very large mariner was twice
the size of the predecessors. Mariner eight didn't launch especially,
(03:11):
but six and seven did. And this one's literally a
thousand kilos where six and seven were about five hundred.
Why because it carried enough fuel and power plant to
go into orbit around Mars, the first time humans ever
put something in orbit around another planet. Wow, And then
spent about It's spent three hundred and forty nine days
in orbit around Mars operational, taking pictures of the majority
(03:33):
of Mars. Those photos used to plan the Viking landings,
as well as giving us our first detailed photographs it.
Speaker 1 (03:40):
Looks like Gene Roddenberry's you know, Scape of External Planets
was pretty spot on in terms of what of what
Mars actually looks like.
Speaker 2 (03:51):
Yeah, Mars had you know, the problem we had with
Mars was there was a year long dust storm in
the earlier marindim missiones of the good and getting good
pictures and like, what's going on? I just have no
idea that it was this crazy dust him. But Mariner
nine stuck around, was able to orbit rather than just
to a flyby. It's difficult to get into orbit of
on the planet. You think about the threading of the
needle to pull that up. Exceptional achievement, good stuff. How
(04:15):
about in computers? The last two Apollo missions, Okay, Paulo
sixteen Young Duke Mattalie, which is the second rover mission
secually called the J class missions the real science missions,
and the final one of Paulo seventeen with Sernaan, Evans
and Schmidt Harrison Schmidt being the only scientist to set
foot on the Moon. He was a geologist. He had
(04:36):
helped train the other test pilots. There are eleven test
pilots that had walked on the Moon to try and
find good rocks, and needless to say, he was better
at than everybody else. He's the only human face ever
photographed on the moon because he broke all the rules.
He kept flipping up the visor to see the rocks
better because he's a geologist. And it is actually a
(04:56):
photograph of him with the visor flipped because that goldvisor
stopped their eyes from burned out of their heads. But
that didn't matter to rish Schmid. He really wanted to
look at rocks, and he found easily the most important rock.
He found this unshocked chocolatedite, which is a synthesis of
olivine that showed that they rock formations were partially volcanic,
and it spoke to the actual formation of the moon.
(05:17):
Wow Incerning ended that mission with the we leave as
we came, and God willing we shall return with peace
and hope for all men.
Speaker 1 (05:27):
There is one thing we haven't talked about that happened
in nineteen seventy two, and that's Richard Campbell and Carl
Franklin started kindergarten because we were five. We were five
thru and isn't that the year that you went from
New Zealand to Canada?
Speaker 2 (05:48):
No, I just a couple of years before.
Speaker 1 (05:49):
And then oh okay, I thought you said, Oh no,
you were five when you went to your uncle's house
and had prairie dog target.
Speaker 2 (05:57):
Practice five, five or six. Yeah, it's you know, that's
hard to when you're young, The Great Prairie Dog story.
The microcomputer has been invented, or the CPU has been
invented a couple years before, but the first scientific calculator,
the HP thirty five, comes out in nineteen seventy two,
although it does not use a four thousand and four. Now,
this is the time when trigonometry and exponents were done
(06:19):
with slide rulers, so the idea we had an electronic
device that could do Trigg and exponents was a big deal.
It also use the first implementation of a thing called
a reverse polish notation or called postfix notation, where you're
loading registers, so you go one enter to enter and
then plus to add them together. And so if you
were into those old calculators, that's where it began. Nineteen
(06:41):
seventy two. Wow, as another from the previous show or
another reference to Alan Shoeguard, he has now left IBM,
gone to MEMORYX where he makes the shoe guard floppy
drive or read write drive for MEMORYX called the six fifty,
with one hundred and seventy five kilobits a storage on
an eight inch piece of plastic.
Speaker 1 (06:57):
They weren't asking the question about is it live yet?
Speaker 2 (07:02):
No, I think that's an ad A little later on
for cassette daves, well, that's.
Speaker 1 (07:06):
When they got into audio. It's probably later, but we'll
probably get there in a couple of weeks.
Speaker 2 (07:10):
And I'd be remiss not to mention the C programming
language Dennis Richie being released in nineteen.
Speaker 1 (07:15):
Seventy two currently get in Richie.
Speaker 2 (07:16):
And finally in video game history, the Magnavox Odyssey is
released in nineteen seventy two in the US for one
hundred US dollars that'd be about seven hundred bucks to day.
And it was you know, basic screen Pong and you
had two little knobs. It was Pong. Yeah, they had
a few variations on the game, but essentially it was
just Pong. They sold three hundred and fifty thousand units
(07:38):
by nineteen seventy five. This is also the same year
that one Nolan Bushnell makes a video game console called
Pong and forms the company Atari, and is promptly sued
by Magnavox and Settles.
Speaker 1 (07:51):
We would encourage our listeners to search the archives, the
dot Rocks archives for Nolan Bushnell because we talked to him,
yeah a few years ago.
Speaker 2 (08:00):
Yeah, one of one of Yeah, one of my heroes
from back in the day. And it was interesting to
actually meet the man, yeah, in his seventies and drink
whiskey with him.
Speaker 1 (08:09):
Yep. And I just remember him saying at the end
of it was an NBC, No, it was at dev
it was it was or DEEV. Yeah, he was addressing
the group and he said, you know, there's some very
very smart people in this audience, arguably the biggest collection
of smart people in Sweden right now in one room.
(08:32):
And I have some advice. Go have babies.
Speaker 3 (08:36):
Because the stupid people are over popularly and you need
to go home, talk to you significant other and say, honey,
we're going to take one for the team.
Speaker 2 (08:47):
Yeah. He was a grandpa. No two ways about that.
Absolutely funny. That's what I got seventy two crazy year.
Speaker 1 (08:55):
All right, so I guess we should get going with
better no framework.
Speaker 2 (08:58):
Awesome, all right, what do you got?
Speaker 1 (09:07):
Our good old friend Simon Crop is working on this
tool called Excelsior and it's an Excel spreadsheet generation library
with a distinctive data driven approach.
Speaker 2 (09:20):
Oh okay, so is he using l MS.
Speaker 1 (09:24):
I don't think so. And it's pretty pretty much just
you know, driven by Jason data and classes and you
can save it to a stream and you can do
custom headers and ordering and do some styling with with code.
You know, it's all it's all code and Jason data.
Speaker 2 (09:48):
So just a tooling library to dump data into Excel
with some formatting and exactabilities.
Speaker 1 (09:54):
Cool exactly. And there's lots of third party libraries that
do this, you know, the big ones do.
Speaker 2 (10:00):
You can cut your paste, your Brain's out or CSV
all the way, but it's nice to have a code
driven way.
Speaker 1 (10:04):
Well, like I'm saying, there are third party libraries, you know,
from dev Express and Telerating, those guys that have you
know in Grape City, the original spread they have libraries
that you can do this too as well. But this
is an open source, free library from Simon Beautiful. Yeah,
thanks Simon, Yeah, thanks Simon. No I learned it.
Speaker 4 (10:26):
LOVI it.
Speaker 2 (10:27):
Who's talking to us today? Richard grabbed Commentaler Show eighteen
eighty one. The moment we did with when David Fowler
talking a little bit about dot Net Aspire back in
those very early days where I think they were just
trying to figure out what the heck they were making,
and Noel Anderton had this comment. He says, I would
really like to hear them talk about Dapper. That's DAPR
and Aspire. There seems to be a major overlap between
(10:48):
these two projects that look to be mutually exclusive. Aspire
seems to be a dot net centric view, where Dapper
is more technologically agnostic. Less importantly, I'd also like to
know where you see this in relation to intern Ol
Developer Portal's IDP. You have to start an IDP dashboard
and you have the creation of a new component. Scaffolding
uses tooling being used by I DPS. Do you see
(11:08):
Microsoft building and IDP and considering we've really not heard
about IDPs again, so I don't know that it really
took off right. Everybody's got their own approach to doing
these things. But I do appreciate the term scaffolding, which
is certainly the way I've looked at Aspire as code
you use to generate other code that doesn't actually continue.
(11:31):
Can you on from there of certainly will Luke Crisen
on the whole Dapper versus Spire side, I do think
they overlap to some degree, because in the end, it's
trying to make cloud native code in whatever language you want.
In this case we're talking specifically dot Net. I do
think that Thespire goes deeper into the dot Net stack
the Dapper's capable doing it. But I've been interested to
(11:53):
do a Dapper show at some point in the future.
Show we'll pay attention to that. So Noel, thank you
so much for your comment, and a copy of music
Coba is on it even if you'd like copyes to code.
But I read a comment on the website at dot
netroocks dot com or on the facebooks we publish every show.
There a new comment there, and I read in the show.
We'll send you copymies to go by.
Speaker 1 (12:08):
I was just using music to code by yesterday while
I was working on a difficult problem. And uh yeah,
it's still going strong. Twenty two tracks, MP three, flak
and wave formats at musicdocode by dot net. All right,
Chris Klug, let's bring you in here. I'm reading a bio.
(12:29):
I'm reading a bio from the last show and stop
me if I get anything wrong. Chris Klug works as
a developer architect at Active Solution in Stockholm. That's right,
working mostly with cloud based solutions for clients in 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
(12:52):
somewhat uncharted areas to him, which suited him fine, as
he loves learning new things and figuring out how to
make them do what he wants them to do. Obviously,
these days he's working with that that aspire. So welcome back, Chris,
thank you, thanks for having me, thanks for being here.
Speaker 4 (13:06):
I can say that the intro is not really correct anymore.
I haven't done devils for quite a while now, but
I'm not actually touching cloud at this point either, because
I'm at a bank that has everything in house. But yeah,
it's I'm still a developer at least, so that part
was correct.
Speaker 1 (13:22):
You were a full stack guy, right, I mean touch everything.
Speaker 4 (13:26):
I don't defront them anymore, so I don't call myself
a full stack developer anymore. I I personally dislike the
idea of full stack developer because I think there's too
much in front end and back into note to actually
know both of them really well. But that's me at least.
I've decided to focus more on the back end side
(13:46):
of things in the last few years.
Speaker 2 (13:49):
Right, Do you have any thoughts on on no One's
comment about the relationship between Dapper and Aspire.
Speaker 4 (13:54):
I see them as very different things. So Dapper work
as far as I understand, Dapper works pretty well with Aspire.
I'm just I'm not a Dapper person. I've only used
that on one project, and personally in that scenario it
didn't give us very much. But I think Dapper is
more of a way of abstracting away your environment, right,
(14:16):
being able to plug and play different parts and replacing
things in your environment by giving you pre defined interfaces
that people can implement and then provide, whereas I think
Aspire is more of a we will host your services
for you. We're not going to give you any abstractions,
but we will give you a bunch of hosting stuff
(14:38):
for you instead. So they actually work pretty well together
because you can use Aspire to spin up the different
services you need, like reddish and seql and all the
things that you would do and service buses and stuff
like that, and then you use Dapper in your application
to configure how they fit together. So yes, there's a
bit of an overlap with the how it fits together
(15:00):
kind of thing, but they are very.
Speaker 2 (15:02):
I don't know if this is true yet, but I
could see Aspire being able to deploy Dapper as APIs
in front of the services it just configured.
Speaker 4 (15:09):
For in theory. Yes, yeah, I think that would work.
Speaker 2 (15:12):
Yeah, I buy that. And of course there is the
overlap on like the workflow side and things, and they
both generately a dashboard, but yeah, I see there's difference.
The main thing I see with Dapper is it's a
set of building block APIs that Aspire seems to avoid.
Speaker 4 (15:27):
Doing, which I personally kind of like. But that's made
because unless you have a very specific reason where you
actually do switch out your services, then I personally am
not a big fan of the least common denominator thing
for all of the services you want to use. I
don't mind pulling in an SDK for a specific service
(15:49):
that I use, And I also feel like in ninety
nine percent of my cases, the services I use are
the same during development and during production. Because we use
Sequel server, we use Cosmos, we use a bunch of
services that you can run locally using emulators and things instead.
So I haven't run into that porb currently for anything
that we need, but maybe sometime in the future.
Speaker 1 (16:13):
So, in your opinion, what is the most essential service
that dot net Aspire gives you. I mean, there's a
whole bunch of things in there, but what's the most
essential one.
Speaker 4 (16:24):
Oh, the most essential one for me is the ability
to actually it's not a service as such, but it's
running your own projects because you don't necessarily need any
external services to make Aspire really useful. For me, the
biggest thing that makes Aspire something that I really love
having is the fact that I can take multiple of
my services locally and just spin them up and debug
(16:45):
them all at the same time in an easy to
do way. And then on top of that, yes, you
have all of the other services that they can help you
out with, and those are just getting so many it's
ridiculous by now.
Speaker 1 (16:58):
Right Well, in that family of services, when you say
start a project and Aspire, what's the first thing that
you turn on?
Speaker 4 (17:09):
The first thing I probably put put into everything I've
built so far as a sequel, So for instance, yeah,
because I use sequel server.
Speaker 2 (17:16):
How old school of you, right.
Speaker 4 (17:18):
Yeah, I know everybody's moving to postgrists and document databases
and things, but the sequel has always been the foundation
and background of what I've been building. It's very natural
for me to go there. And the fact that is
that easy just spin up, that's what I'm putting in
there is my first thing in most cases.
Speaker 1 (17:37):
Yeah, about the red as cash, I know that that's
something that a lot of maybe a lot of developers
do know about it, but I think there's a huge
sloth of the development community of dot net development community
that is neither either never needed it or didn't know
they needed it. But that can make a huge difference
(17:59):
in performance and scalability.
Speaker 4 (18:02):
It can, and I think it's useful for a lot
of scenarios. We're currently looking at it for my current project,
but we're for we're doing a hybrid cash solution at
the moment with in memory while actually using the met
core hybrid cash with in memory and a sort of
a semi permanent store as well. And we looked at readies,
(18:24):
but we ended up going old school sequel again. Mostly
because we're hosting on prem at a bank that's using Kubernetes, right,
and we can't touch too much of the stuff there,
and trying to get them convinced that hey, we want
to run read this as well was not really an option.
Speaker 2 (18:40):
But you got to talk to it about standing up
a new service. That's an interesting battle to have at
a bank.
Speaker 4 (18:46):
That is a very interesting conversation to be had.
Speaker 2 (18:49):
I promise you, dude, I've done the mineral right. It's okay.
It's one thing to stand it up. It's another thing
to back it up, monitor it and like I know
all of that stuff.
Speaker 4 (19:00):
He's equal they had so that was aacy, But yeah,
I do. I agree with your carlab. I think reddis
is the simplest and by far fastest way to gain
performance out of your APIs and your services if you
know not how to use it.
Speaker 1 (19:13):
I'm doing a manual cash of the dot net rocks data.
So basically, we have a database to keep all this
stuff in, and then we generate JSON files and put
them in a storage account, and then we pull them out,
but only on a timer, you know, like a couple
of times a day or on an hour time or whatever.
(19:35):
So everything's cashed in memory pretty much all the time,
but it is a roll your own cash kind of thing.
And I think that's probably the first thing that Maddie's
going to want to tear out of there, and the
place with redd is when I get on stage with her.
Speaker 2 (19:49):
And again with time shifting, Maddy has already torn out
of there. Well she may or she may not have,
but it will. See it's I got to feel in
that's the first thing to go. I'm kind of excited
to see Chris talking about cloud related stuff on an
on prem implementation, like this is cloud as architecture versus
cloud as a deployment location.
Speaker 4 (20:09):
Yep, yeah, so it's yeah, I don't know why. Well,
it's funny because cloud native or cloud based development always
indicates Kubernatist. For most people, that's fine, there's a and
in this case it happens to be that we are
actually running Kubernatis, but we're doing it on prem. But
for me, the cloud native stuff is slightly different and
(20:31):
it doesn't need to be Kubernetes. But that's where we're
at the moment. But Aspire then has this interesting concept
of deployment where it doesn't need to go to Kubernates
even though you're doing a cloud ish solution.
Speaker 2 (20:46):
Although it certainly can. We did a whole show just
talking about Aspire being a way to get to containers.
If you're not already comfortable with it.
Speaker 1 (20:54):
Ye, is there Docker without Kubernetes in your opinion, not.
Speaker 4 (20:59):
Really too perfect? Honest. If I was going to run
something for local, yes, but for production, no, I wouldn't
run docer, Well, no, I wouldn't depending on how it well, okay,
that's now you got it depends on how you look
at it, right. If I was going to use Ashure,
which is my native home for most of them stuff
I do normally do. I believe in the idea of
(21:21):
having container images in my web apps, for example, to
do web aps for containers and hosting containers instead of
running my applications natively on web apps for example, That
makes sense. But using docer in a way where I
touch docer and do docer run and everything like that,
that's not.
Speaker 2 (21:41):
No.
Speaker 4 (21:42):
I would never do that.
Speaker 1 (21:43):
You're not.
Speaker 4 (21:44):
I'm not going to say it never because there will
be a scenario, right, but right now I haven't seen
that need as such. And if if I was going
to go in that direction. Yeah, kubernet Is an akas
would probably be better at choice.
Speaker 1 (21:54):
So imagine I'm a psychiatrist and you're on my couch,
tell me about Yamo.
Speaker 4 (22:02):
About Yamo.
Speaker 1 (22:04):
What is your relationship to Yamo.
Speaker 4 (22:07):
It's the it's the shitty replacement for Jason because it's, oh,
it doesn't have curly braces, but instead we make it white, white, white,
space sensitive. So a minor little change causes everything to
break down and it's really hard to debug. I don't
like Yamo whatsoever.
Speaker 1 (22:25):
God, I feel so vindicated, Richard Nice. You know here
I was thinking, I was like the you know, the
odd man out saying I don't like Yamo, but apparently
really smart people like Chris don't like it either.
Speaker 4 (22:36):
I wouldn't call myself very sad.
Speaker 2 (22:38):
Listen, anybody who says it like Yamo has Stockholm syndrome.
Let's be clear, right, Like, I get.
Speaker 4 (22:45):
The point, I really do. And if you pull up
a Yamo file that somebody has written that's already there,
it's definitely a lot easier to read than than Jason
because you don't have all of the curly bras and everything.
But authoring them is a different story because offering them,
all of a sudden you do a tab in the
wrong place or a space in the wrong place, and
all of a sudden, oh, you have now modified the
(23:07):
entire thing. I'm not a huge fan.
Speaker 2 (23:09):
Well, ps code helps you by letting you know everything
is read now and it's your fault.
Speaker 4 (23:13):
Yeah.
Speaker 2 (23:13):
True, Yeah, but I appreciate your thinking. YAML should be generated,
should and then should be read only when you look
at it.
Speaker 1 (23:23):
Yeah, it's kind of like assembly language, do not edit,
you are not quality, should be treated as such. When
you said Stockholm syndrome, it's funny because Chris is from Stockholm.
Speaker 2 (23:34):
Yep.
Speaker 1 (23:36):
The jokes just keep coming, just keep coming. Oh man,
all right, So we talked about Reddish. Where are some
of the other hidden gems in Aspire?
Speaker 4 (23:47):
Well, actually, I think there's there are hidden gems in
Aspire that's not really about services like that. There are
features I think that people are missing out on potentially
an Aspire that I find to be really little gems.
It's like being able to add customer commands to the
dashboard is one of those things that just on the
surface is like why would you need that? And then
(24:10):
we're doing it in the current project where we have
a little receive the database. So if somebody pulls it
up and they need to restore the database back to
a database that we can work with. It's not a
manual task. It's not a script that needs to be run.
You go into dashboard, you click the button and you say, hey,
reseve the database, and it sets the database for us.
It's nice, a nice way of doing it. We also
(24:32):
have an export from SQL to Neo for j for
some graph stuff, and we can redo that export using
a command as well. It's just those little things that
make it easier for people to use the dashboard as well.
Speaker 1 (24:44):
It's nice, I think, yeah, plumbing.
Speaker 2 (24:47):
Yeah, and you speak to doing more with how important
a dashboard is in the dev cycle versus in the insductions.
Speaker 4 (24:53):
Well, that's the thing in the production cycle. It's I
think to me currently Aspire kind of is a development
time kind of thing. Once it's deployed, I don't seem
as well deploying the Aspire dashboard or anything like that
into a production environment, even though you can do that now.
(25:14):
I mostly, as I said, look at it as a
dev tool and that's where it can with things like
little commands like that or maybe being able to look
at different durls and actually have them properly describe what
they do. Means that when you do a get pull
F five to start the thing, you actually get everything.
(25:34):
And now with the new support that they have where
if you don't define parameters, it will actually ask you
for missing parameters so you can get it down. You
press have five and the first thing that says is
the dashboard goes up and says, hey, there are missing
parameters here. Can you give me the database password? Can
you give me these other things? And then it stortes
it to your user secrets automatically. Means that getting a
(25:57):
new developer onto a project is so much easier, which
I think is a massive benefit.
Speaker 1 (26:02):
Is yeah nice sharing. Configuration has always been an issue
with me on the different teams that I worked on.
Not not insurmountable, but you know you, like you said,
you do a get pull and it doesn't work because
of some configuration issue and oh you got to add
this little section to your app settings whatever. So let's
(26:25):
talk telemetry here. So open telemetry is everywhere and Aspire
and in Azure, and you have that dashboard but once,
once it's deployed, does that dashboard still work for you
in terms of telemetry or do you go over to
another kind of run time telemetry monitoring thing and Azure.
Speaker 4 (26:46):
Unfortunately, right now, I've been on my bank project for
so long that it's actually been around the time that
Aspire came out, so I haven't been able to do
anything with Aspire with Azure, but I can know the
dashboard that comes with a Spire would not be enough
in my opinion, especially since it's as far as I know,
in memory only right, so it doesn't persistent, So I
(27:10):
would prefer having it offloaded to something else. As I said,
I see the Spire dashboard as a nice thing for
dev and then for production going to something like Honeycomb
for example, or a third party system that is built
specifically for that is probably the better solution. Or yeah,
you can do application insights or monitoring.
Speaker 2 (27:34):
I mean, odds are your administrators already have a telemetry
solution they need you to add too, And that's why
they like open telemetry because they probably have an input
feed for that. It's a good aim your app here
at this endpoint. Now our telemetry adds to our existing
monitoring solution. Yeah, Yep.
Speaker 1 (27:52):
It's a beautiful thing.
Speaker 2 (27:53):
Now, you hope, and then they'll complain about the crappy
feed you've given them.
Speaker 4 (27:59):
But it's also I really like that because it's it's
hard to get away from the fact that whatever dashboard
day or solution they have solutions chosen for telemetry is
a thing that's built purposely full for that thing. So
it's going to be really good for that thing's not
having to focus on that, not having to build your
own telemetry monitoring system, which I've done over and over
(28:23):
again for other clients, it's now really nice just shove
it off and then do some own of your own
custom hotel integrations instead, if you want to have your
own metrics and your own spans and things like that.
Speaker 2 (28:34):
But if the new app is using Kubernetes, they already
have an instrumentation pack for Kubernatores. They know how they
want to look at the state of containers, so that's good.
It's another part of why I don't want you to
add redicity equation, because I now have to tune episode
of telemetry for how do I know if Redis is
happy or not? Yep.
Speaker 4 (28:48):
Yeah, Which that's actually an interesting point where you're saying that, Richard,
that when you deployed, the ops guides will already have
a thing for you, right, Yeah, And I think that's
the way it works in and in most enterprises I've
been involved in, there's always an obstavision that have very
strict opinions, which then is interesting combining that with a
(29:10):
spire's way of thinking about deployments. I know I've been
on the show before and we talked about Infrastructure's code
and some options that were out there and pollumium things
like that, which I think was a cool idea, but
it moved infrastructure into the developers region, and I think
that is honestly a bit of a problem because most
(29:33):
enterprises don't want their developers to mess about with infrastructure.
Speaker 2 (29:37):
Yeah. Now, you're right. If an organization has a deployment
strategy already, and I'm telling you not all of them do,
then they will be concerned. If they want to own
that piece, then they want to understand that piece. And
when you introduce other languages know the tuning around, they're
going to get jumping about it, just like they jumping
about ratus. But sometimes they don't have that. But they
(30:00):
also get into trouble that way. Like, one of the
issues you have when you have a lot of systems
running in VMS are on against services in a shared
infrastructure is badly behaved apps being introduced to the equation. Like,
part of wanting to control the deployment is to know
what it's impacting, to have better security controls on it.
When you leave that too loose, you get surprised. Sometimes,
(30:23):
you know, a new version of that app gets deployed,
breaks this other thing over there, or gets a new
security acount of that, or you know, lights off the
seam right Like I've seen this happen where we didn't
tell it that it's going to message this way, and
suddenly it looks like a Dodos attack. The app operating normally,
like the whole security system just goes berserk because we
did this deployment.
Speaker 1 (30:42):
Like I love Poalumi, especially when you fry it, you know,
because it doesn't melt so fast. It's really good. Geez.
And on that happy note, let's take a little break.
We'll be right back after these very important messages stick around.
Did you know that you can work with AWS directly
(31:02):
from your ide AWS provides toolkits for visual Studio, Visual Studio,
Code and jet Brains Rider. Learn more at aws dot
Amazon dot com, slash net, slash tools.
Speaker 2 (31:19):
And we're back. It's Donna Rocks. I'm Richard Campbell. That's
Carl Franklin. Hey, hey here with our friend Chris and
I seem to have fallen into the grumpy Sisaben role
for this show, which I'm okay with because I know
how to say no is good A where anyway?
Speaker 1 (31:32):
My friend?
Speaker 2 (31:34):
But I think, you know, we speak to this really
challenging dynamic of you're building this complex software at the
point where you have a tool like Aspire to help
you with its construction and deployment, and your administrators need
to understand it and you need to know where to
interface with them, and it's obviously that deployment piece of
telemetry piece, that services piece, Like that's a lot of
(31:55):
conversations to have, like do you try and have that
in advance or you just build some Aspire and see
how it go.
Speaker 4 (32:01):
I would probably recommend having a conversation ahead of time
because it kind of sucks when you spend a year
building something and then you try to deploy it and
opskys goes Nope, no, that's where I think, I'm not
one hundred percent sure that I enjoy your I think
that Aspire is going in the right direction of pushing. Hey,
(32:22):
the configuration of the publishing goes to the developer. Once again,
that doesn't work in a lot of areas unless your
company then is big enough to build their own custom publishers.
Because they now with the experimental stuff in aspires, it
makes it possible for you for an organization to actually
build something that is custom for their organization, which I
(32:43):
guess would be a thing. But then the ops team
needs to spec spence that specify that very well, and
then the dev team has to build it for them
and everything. But then if you you can then reuse
that in theory at least.
Speaker 2 (32:56):
Yeah, I mean, I can see this being a real
battle for the first deploy of the app. But once
we get to an agreement, all that on that. Like you,
you know, we're back to those old agile mindsets. If
I want to be able to iterate quickly, so if
I'm living within the constraints that have passed through the administrators.
Once that the security contest is going to remain the same.
(33:18):
Telemetry context is the same, the deployment pipeline is the same. Hey,
deploy away. You know, don't interrupt me constantly with your
next weird deploy Like I want to be highly involved
in the first couple and after that, I'm kind of
keen to let you guys iterate and get your features
out without having a fight with us too much, or
that we only talk about the delta. Hey, new telemetery here.
(33:43):
You know, you need a new plumber in here. Oh
my goodness, we need new service here. Yeah, I would hope.
I mean, I just and buy me pizza and we
can talk right, like honestly.
Speaker 4 (33:57):
Yeah, if you're that Adamin guy, I'd have to buy
you a pizza. I my current or my current client is.
It's not that idea. Uh, it's it's a very strict
it's the every single application in the whole enterprise needs
to be deployed using the same pipeline in Jenkins oh boy,
(34:19):
Jenkins boy, and mostly focused on Java as well, so
getting in there was kind of an interesting little way
as well. So yeah, we've tried to fly under the
radar and get our stuff done without having to talk
too much to it and sorted it out, and like
I said, reusing sequel for as much as possible because
that's already there and needs to use.
Speaker 2 (34:42):
Yeah, you're literally doing staying within the guardline so you
don't have to talk to them make it easier. Yeah,
I appreciate that.
Speaker 1 (34:49):
I think I told this story before when we were
talking about Aspire, but one of my customers wanted to
aspireify their Blazer server application. So the only real issue
they had was we're using poly and you know, the
the stuff for for that is the HTTP Client Factory
(35:15):
I think, and that's what Aspire uses. So there was
like two you know systems going on there for for
dealing with network outages and things. But that was right.
Speaker 4 (35:30):
Yeah, and that that can be fixed as well because
all of that retry policy stuff for the client factories
in the services default project, so you can you can
either in case, you can either move the police stuff
that you have built in the previous system through there,
or you can remove your police stuff and use the
services to fault and you should be good to go. Yeah,
(35:51):
and I really I must admit I love that approach
of having the Services default project where hey, here is
everything we're doing and it's in C sharp format, where
it's not a gazillion configuration things you need to plug into.
We will give you the C sharp code. It just
makes everything so much easier and exactly Yamo. Yeah, and
(36:13):
it's not even Jason.
Speaker 2 (36:15):
Yeah right, it's its own thing.
Speaker 4 (36:17):
Yeah, the configuration code is always preferable in my world.
It just makes it easier to have it in one
place when you're a developer. I guess it's it makes
it harder when you and admin and you need to
maintain it afterwards, but it's don't know, I like having
it as much as possible in code.
Speaker 2 (36:34):
Yeah, me too. What about testing? Like, what's your testing
strategy for these apps in this style? Like? Is there
anything special? Once you're scaffolding like this, I have.
Speaker 4 (36:43):
A very very specific way of testing. Actually, an Aspire
unfortunately doesn't help with that in any way, shape or form.
So there is a there is a test So there's
the NBC test server thingy, which has got nothing to
do with MBC at all. It's just a new GET
package just named that unfortunately. But it runs your API
in memory, and there's a there's a similar version for
(37:06):
Aspire that can run you to do smoke tests and
things like that. The problem is that you can't do
any mocking. You can't fake any services because of the
way that Aspire works, and that means that to me,
it doesn't really work for testing. So what we're doing,
and I do in most of my project is for
all of the API projects, I use I tested those individually,
(37:30):
and then I use the in memory test server for
those and I verify that all of the Jason stuff
comes back as I expected to. And I also like
doing it integration style all the way down to the
database and not back up again, so I know that
it really works with all the layers.
Speaker 2 (37:44):
Nice. Yeah, yeah. And the main thing is you want
it automated as part of the pipeline as well, or
at least you know so you're always checking.
Speaker 4 (37:52):
YEP, and currently we don't have that in my project.
But it's funny because I've been building the APIs for
our system and I've only done tests. So I have
all my integration tests and they go green, and I
say it works. And then I have front end people
building a React front end and they come and complain
but it doesn't work. But I haven't actually fired up
(38:13):
the front end on my machine for about a year
and it's actually worked. It's worked pretty well because I
we agree on the contract of what they want to
get from the end point the end point, I write
the test to verify that the endpoint. It does what
it says and comes back in the right format and
it looks right, and then it.
Speaker 1 (38:32):
Doesn't show up on the browser. That's your problem.
Speaker 4 (38:34):
Yeah, pretty much like that. Yeah, it does break once
in a while, but it works nice. And I like
the fact that you can go to and from API
to database and verify the jobs or the Jason that
comes back because you know that that really works. It's
not I'm not a big fan of unit tests as
(38:54):
such because they don't show you your system actually working.
Speaker 2 (38:58):
In my opinion, Well, that's yeah, that's not what unit
tests are really for, right, Like you need you need
a more than kind of tests. Tests are for you
running locally as you're doing builds.
Speaker 4 (39:09):
And it's it's mostly if you to me, unit tests
are great if you have really complex code like that
does a lot of complex stuff, but ninety percent of
our systems don't do very complex stuff. You can look
at the code and go, I know that this is
going to work because I can see the code, and
then I don't feel like writing a gazillion unit test
(39:30):
on that because it's that simple.
Speaker 2 (39:32):
It's plumbing.
Speaker 1 (39:33):
I think a lot of the things that were complex
that we used to use, uh, you know, test first
for a test driven development for is all the stuff
that the browser does now that we used to have
to hand code. Like you know, me as a Blazer developer,
(39:53):
I don't do any of that old crazy Ajax stuff,
you know anymore. And the way that architecture has evolved,
it's just, you know something's too complex, you just break
it apart, and then you have two or three pieces
where you had one, and you put unit tests around them,
and Bob's your uncle. So yeah, I think the whole
(40:16):
idea of complex code in general is, you know, things
have gotten simpler.
Speaker 4 (40:23):
I think, yeah, I think in most cases you can
break it down. And like I said, I don't do
a lot of unit test, but I spent the entire
day to day writing actually unit tests on a serialization
stuff that we're building. But I don't care about the
unit test ask tests. To be perfectly honest, I don't
care about them verifying my code. I care about being
(40:43):
able to write click and say run tests so that
I can run it without having to spin it up,
so I can make a change, I can run the
test and also going, hey, I want to debug this
to see what this value is. Right now, debug test
is just so much simpler than having to run an application.
So I believe that there are definitely cases unit tests
are nice, but they're not for finding bugs or checking
(41:04):
my code in most cases because that gets checked by
the integration tests.
Speaker 2 (41:08):
There's a whole there's a whole conversation yet to be
had here about the structure of testing in these cloud
apps now, like even how you break down testing a
given service or testing your end against a mock of
a service like this has all gotten really complicated, it has,
and I'm just impressed with just how much people just
(41:30):
test in production now because you can always roll back,
you know. It's like you can fight for a long
time to find a way to test is independentally or
you could ship and see you and roll back if
you must, And.
Speaker 4 (41:42):
I think some were some were in I prefer not
to test it in production if I can get a
get away from it. But yeah, the closer you can
get to production tests, the better it is, obviously, because
it's it's going to be what the users are going
to use.
Speaker 1 (41:58):
Right.
Speaker 4 (41:59):
Yeah, we've I've done several different iterations. I think all
developers have done that over the years, trying to figure
out what works for you and how do we make
this work. And especially in a service oriented architecture where
we've got HTV services, if you can just define the
interfaces and basically document how they work, then I think
(42:22):
it works pretty well even if you're distributed, because you
can verify one service individually from another one. And even better,
to be perfectly honest, is don't let other teams use
your service. Give them an SDK style project. Instead, give
them a new gift package that has methods on it
that you control that calls your API, which means that
(42:43):
they can just add your SDK client to their system
and call it like a c sharp thing. And you're
in control of the API, but you're also in control
of the thing calling the API, which means that it's
easier for you to verify that it works and it's
easier for you to make changes.
Speaker 2 (42:59):
Yeah, for sure. And plus you know the incremental updating
instead of change model and a B testing. All these
strategies about not needing a huge testing framework that the
little things that you could trial, and even dark featuring
in the field is ways to test stuff without having
to build a huge test infrastructure and limiting your impact
(43:22):
if you do make mistakes, so that often you can
just feature switch something back off again and then the
next bill will try and make another iteration.
Speaker 1 (43:30):
On it or feature switch it on for just the
admin users you know, or or you the tester, so
you can test it without giving the feature everybody.
Speaker 2 (43:41):
Mm hmm. Yeah, I think it's.
Speaker 1 (43:43):
Just using the old nag.
Speaker 4 (43:44):
And there's an interesting thing as well with if we
go back to the Aspire stuff and testing is as
I said, I don't do a lot of testing like
with Aspire, but I kind of like with the service
discovery built into Aspire, it actually allows you to mock
external resources as well, very very easily. So in tests
(44:05):
you can go and say, hey, I have this external resource,
but it's your own mocked service, and then for production
you go and say, I have this service over here
that we want to use. That's actually a very nice
feature to do as well, because it means that you
don't have to mock everything in your code. You can
actually mock the API that you're using instead, which is
a nice little benefit of having Aspire in place.
Speaker 2 (44:26):
Nice, So what's missing from Aspire at this point, Like,
we haven't really dug into the latest version nine point
five at all. I'm going to do a separate show
on that, but you know.
Speaker 4 (44:37):
Yeah, I haven't looked at it either.
Speaker 2 (44:39):
To be honest, it's moving for relatively rapidly. We think
we did that original nine to oh show with David
in January of twenty four, so you know, here we're
not We're just over a year and a half on
and we've had incremental updates. I don't think they're going
to increment from nine until dot net ten ships obviously
(45:00):
would be my guess, but they have pushed out a
dot change every few months. But do you stuff see
things that are missing from it? Still?
Speaker 4 (45:11):
The thing is, it's really hard because I know I
use the things that are in there, and I have
a really hard time saying like, well, this is really missing. Yes,
I think the testing part is missing, and I've talked
to the David and Damien about that and they know
it's missing. But there's also not a very easy fix
(45:31):
for it as such. Unfortunately, the thing about them shipping
very rapidly on the other hand is also that some
of the things are under experimental as well, so you
actually or the mark experimental, so you actually have to
go and say, if I want to use this feature,
I need to turn off a bunch of warnings and things.
I don't know. I get that they want to get
(45:52):
it out there, but I'd rather have experimental things in
a non released version. So basically you had a release
vers non release version of it before and then not
put it into the release version until it's not experimental anymore,
because you can't really take a dependency on everything that
is in there, even if it's not a release candidate
or sorry, even if it's a if it's a release version.
(46:16):
But that's just them iterating quickly, I guess. So we're
going to have to live with that for a while,
and that's that's good. They are iterating that quick rappily,
and it's really hard to actually follow along with everything
that's going going out because there's new stuff, but they're
also there's most of this stuff that comes out is
in my opinion, a lot of little edge cases, a
(46:39):
little scenarios that they're trying to figure out that's missing
that I haven't run into in other cases. I think
the last thing they did was the publisher's stuff, which
is undocumented and experimental at the moment. That is going
to be interesting if they can get it into a
non experimental state and maybe make it a bit easier
for you to build a publisher, and also maybe document
(47:02):
how to build a publisher because it's undocumented at the moment,
So I had to build one for a demo I'm
doing for one of my talks, and the only way
to figure out how it works is to look at
the open source versions one of the other open source
versions and copy the code from there and then start
messing with it. And that's Yes, they're releasing quickly, but
(47:25):
it's not documented either, so it can be a bit
hard to pick up the new stuff as well.
Speaker 2 (47:30):
Yeah, yeah, I don't extend. All these things are moving
so quickly, so they think it's challenging to try and
step in there and aspire. To me, has always been
a brown fieldy kind of thing, like you're not really
starting apps from scratch in this class. It's pretty rare,
So you're trying to get more cloud centric on an
existing application and you can interspend it aspire into it,
(47:52):
or are you getting a chance to start from the
beginning with Aspire.
Speaker 4 (47:56):
I start everything from scratch with Aspire to perfect honest,
But I I work in a world where I only
do I normally only do three to six months of
the project because of well, I guess ADHD or something
like that. I can't. It's I'm happy that I have
my employer active solution that supports that, because I actually,
(48:20):
if I get into a project that isn't fun, I
actually get depressed and it goes bad sometimes. So being
that I only go onto projects very very rapidly like that,
it also means I often go on new stuff. So
I will come in, I will build the foundational stuff,
and then once the foundational stuff is up, I will
move on to something else. So I'm one of those
(48:41):
lucky people that actually do get to do Aspire new
and then start from scratch.
Speaker 2 (48:46):
Very nice.
Speaker 4 (48:47):
We didn't do it quite in this project. We actually
worked and had two services up and running before we
put Aspire in place, but it was still very very
early days as such.
Speaker 2 (48:59):
Right.
Speaker 4 (49:00):
But I'm also saying, like you say, brown Field stuff,
I say that to everybody. It's if you've got a
solution that has more than one project in it. See
if you can get aspired to work, because it's going
to make everything easier to work with. And honestly, if
you only have one project but it's slightly complex, put
a spire onto and anyway, so you get the dashboard,
(49:21):
you get the open telemetry. No, you don't need the
retripolsies and all the stuff that you get for free,
but just the open telemetry dashboard and the ability to
plug into that and being able to see your logs
in a nicer way, that's worth it for a single,
single project solution in my opinion, right.
Speaker 2 (49:39):
Right, Yeah, I bet that.
Speaker 1 (49:40):
Well, I'm going to keep that in mind as I
go into this. We're doing this live, you know, aspire
ify dot net rocks dot com.
Speaker 2 (49:48):
Yeah, and you're living the dream and the adventure man
like I hope that's as well. Well, and again time
shifting it'll have already happened.
Speaker 1 (49:57):
We hope, we hope.
Speaker 2 (50:01):
But I mean, I was appreciate Chris. You haven't done
one project, Inspire, You've done a bunch. You wouldn't keep
using this if it wasn't actually helping you.
Speaker 4 (50:09):
No, no, no, no, it's it's awesome. It's also I'm
not an AI person at least Richard, you know that
we've had conversations about that, and I have opinion it's
about AI and everything. If you're sort of wanting to
be a bit bleeding edge in the Microsoft sphere, it's
either AI or Aspire. There's nothing else to actually look
(50:30):
at at the moment the thing that comes out. But
having that stat I actually love Aspire. I've loved the
idea of it since I saw the first like release
version that they've showed to the m v P s,
and there's I don't know, it just solves so many
little little things. It's not overwhelmingly wow, this is awesome,
(50:52):
it will change revolutionize my world, but it solves a
bunch of little things that annoy you every day and
every time you press F five to start your application.
It's I don't know, it's it's hard to say about
those little things make it a little more more enjoyable.
It's actually right code, and I think.
Speaker 2 (51:11):
It does strike me as a strategy to get gradually pregnant.
All in this case, we're talking a gradually cloud native
that yes, you you know, as you learn more about
what it is to live in the cloud. ASPIRER was
already there and ready to help you with the next problem. Yeah,
that's it. I appreciate that he had. Davids did a
good job of letting us gradually get involved and think
(51:34):
more cloud dative. You don't have to jump out climb
up this huge cliff before anything works, right.
Speaker 4 (51:39):
No, because that's kind of like you said, like it
started off talking about a bit about Kubernetes, because I've
been into the Kubernetes area as well for a while,
and it's that's a that's a steep hill to climb
before you get anything done. And then once you understand
Kuberneties and you have to start doing helm charts and
deployment pipelines for that, it's it's a pain, and it
(51:59):
does and solve your local development in any way either.
So it's I don't know. I think this is a
nice way to make your day to day job easier.
If you don't want to use it for deployment or whatever,
that's going to have to completely fine, But your daily
work is more enjoyable.
Speaker 2 (52:18):
I appreciate that.
Speaker 1 (52:19):
What's in your inbox, Chris, what's on your to do list?
Speaker 2 (52:23):
Sleep?
Speaker 4 (52:26):
I'm currently actually spending a lot of time working on
I've done two new presentations that I'm working on or
have have worked on, and we'll have to refinal a
little bit after NBC Copenhagen working on a two day
really wonky workshop on Microsoft Web Development where they attendees
(52:49):
get to play with a spinnet Core minimal APIs, NBC
g RPC, your project or lanes as identity server and
some other stuff, so they basically get a little tour
of everything. A lot of things you can find in
acenet core. So that's kind of cool.
Speaker 1 (53:08):
That's very cool.
Speaker 4 (53:10):
Yeah, it's interesting going into so many different things and
sniff around like what can we do here, what can
we do there, and show people that acenet core is
more than mbassy.
Speaker 2 (53:22):
Yeah, yeah, it certainly is and always have been. But
you know, yes, it's basically the same thing you just
did in this past hour. Chris is like, there's more
to aspire than you know, and you can there's a
bunch of different points to grab at it. So I
appreciate that that you break down the pieces and say
you could use this, and you could use this, and
did you know about this? And there's lots of ways
to help.
Speaker 4 (53:41):
And it's also I think like most people are stuck
in not stuck, but most A lot of people work
in enterprise environments where there's you're working on the same
thing all the time and you get kind of shoved
into this corner of this is the way that it works,
and you don't have time to look at everything else.
So that was kind of the idea behind my workshop
was let's take people that work on maybe not so
(54:03):
cool enterprise projects and show them what else is out there,
so that if they come up with something new that
needs to be built, maybe Project or Leans can help them,
or building a new service using DRPC, you might be
easier for some things and things like that. So that's
the idea behind it.
Speaker 2 (54:18):
Nice, very good, I appreciate it.
Speaker 1 (54:20):
Chris. Thanks for spending an hour with us. It's been great.
Speaker 4 (54:23):
Well, thank you for having me again. It's it's always
awesome to be on the show.
Speaker 1 (54:26):
Ye all right, go get some sleep. We'll talk to
you next time on dot net rocks.
Speaker 5 (54:54):
Dot net Rocks is brought to you by Franklin's Net
and produced by Pop Studios, a full service audio, video
and post production facility located physically in New London, Connecticut,
and of course in the cloud. Online at PWOP dot com.
Visit our website at d O T N E t
R O c k S dot com for RSS feeds, downloads,
(55:16):
mobile apps, comments, and access to the full archives going
back to show number one, recorded in September two thousand
and two. And make sure you check out our sponsors.
They keep us in business. Now, go write some code.
See you next time.
Speaker 4 (55:31):
You got jam Vans
Speaker 1 (55:35):
And
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Burden
The Burden is a documentary series that takes listeners into the hidden places where justice is done (and undone). It dives deep into the lives of heroes and villains. And it focuses a spotlight on those who triumph even when the odds are against them. Season 5 - The Burden: Death & Deceit in Alliance On April Fools Day 1999, 26-year-old Yvonne Layne was found murdered in her Alliance, Ohio home. David Thorne, her ex-boyfriend and father of one of her children, was instantly a suspect. Another young man admitted to the murder, and David breathed a sigh of relief, until the confessed murderer fingered David; “He paid me to do it.” David was sentenced to life without parole. Two decades later, Pulitzer winner and podcast host, Maggie Freleng (Bone Valley Season 3: Graves County, Wrongful Conviction, Suave) launched a “live” investigation into David's conviction alongside Jason Baldwin (himself wrongfully convicted as a member of the West Memphis Three). Maggie had come to believe that the entire investigation of David was botched by the tiny local police department, or worse, covered up the real killer. Was Maggie correct? Was David’s claim of innocence credible? In Death and Deceit in Alliance, Maggie recounts the case that launched her career, and ultimately, “broke” her.” The results will shock the listener and reduce Maggie to tears and self-doubt. This is not your typical wrongful conviction story. In fact, it turns the genre on its head. It asks the question: What if our champions are foolish? Season 4 - The Burden: Get the Money and Run “Trying to murder my father, this was the thing that put me on the path.” That’s Joe Loya and that path was bank robbery. Bank, bank, bank, bank, bank. In season 4 of The Burden: Get the Money and Run, we hear from Joe who was once the most prolific bank robber in Southern California, and beyond. He used disguises, body doubles, proxies. He leaped over counters, grabbed the money and ran. Even as the FBI was closing in. It was a showdown between a daring bank robber, and a patient FBI agent. Joe was no ordinary bank robber. He was bright, articulate, charismatic, and driven by a dark rage that he summoned up at will. In seven episodes, Joe tells all: the what, the how… and the why. Including why he tried to murder his father. Season 3 - The Burden: Avenger Miriam Lewin is one of Argentina’s leading journalists today. At 19 years old, she was kidnapped off the streets of Buenos Aires for her political activism and thrown into a concentration camp. Thousands of her fellow inmates were executed, tossed alive from a cargo plane into the ocean. Miriam, along with a handful of others, will survive the camp. Then as a journalist, she will wage a decades long campaign to bring her tormentors to justice. Avenger is about one woman’s triumphant battle against unbelievable odds to survive torture, claim justice for the crimes done against her and others like her, and change the future of her country. Season 2 - The Burden: Empire on Blood Empire on Blood is set in the Bronx, NY, in the early 90s, when two young drug dealers ruled an intersection known as “The Corner on Blood.” The boss, Calvin Buari, lived large. He and a protege swore they would build an empire on blood. Then the relationship frayed and the protege accused Calvin of a double homicide which he claimed he didn’t do. But did he? Award-winning journalist Steve Fishman spent seven years to answer that question. This is the story of one man’s last chance to overturn his life sentence. He may prevail, but someone’s gotta pay. The Burden: Empire on Blood is the director’s cut of the true crime classic which reached #1 on the charts when it was first released half a dozen years ago. Season 1 - The Burden In the 1990s, Detective Louis N. Scarcella was legendary. In a city overrun by violent crime, he cracked the toughest cases and put away the worst criminals. “The Hulk” was his nickname. Then the story changed. Scarcella ran into a group of convicted murderers who all say they are innocent. They turned themselves into jailhouse-lawyers and in prison founded a lway firm. When they realized Scarcella helped put many of them away, they set their sights on taking him down. And with the help of a NY Times reporter they have a chance. For years, Scarcella insisted he did nothing wrong. But that’s all he’d say. Until we tracked Scarcella to a sauna in a Russian bathhouse, where he started to talk..and talk and talk. “The guilty have gone free,” he whispered. And then agreed to take us into the belly of the beast. Welcome to The Burden.