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 dot com. Hey guess what, it's
dot net rocks. This is Carl Franklin and this is Richard Cavill. Back
with you for another awesome show. And this is going to be an amazing
show. Oh but I'm sure. Well, we're gonna have some fun.
But this is momentous news momentum. Joel Hewen and Martin Costello are here.
We're going to talk to him about Polly. But first we have some things
to do, right, like better no framework? All right, hit me,
let's roll it? All right? Did what do you got? So?
I know last week I talked about the AI Bought Show. Yeah yes,
but since last week, Brian McKay and I have started a podcast version
of it. Oh so, if you go to Theaibotshow dot com now episode
twelve, you will see has a little podcast label on it and it's audio
only and when you click it, you'll go to another page that has the
player and all the links. We basically decided to turn it into a news
oriented AI podcast, right and as such because things are changing so fast,
and you know, our videos get a limited lifespan because oh you know,
by the time it goes out, the responses you might get from chat GPT
will be completely different, right, right, and you may want to do
things completely differently because there are new features and new things. So we just
decided to go all news. Yeah, yep, try and keep up good
luck, fast moving problem. Yeah, the news is good. And you
could see by the number of links there on episode twelve that we had plenty
to talk about. So that's it. Yeah, go to the iBOT Show.
Oh and by the way, by now it should be in Apple Podcasts
and Google. It's already on Stitcher and in Spotify, so you'll be able
to find it wherever you get your podcast. It's the ai Bot Show podcasts.
Cool, that's it. Who's talking to us? Richard grabbed a comment
top of show fifteen fifty six, which is a long flipping time ago.
That's the one we did with Dylan Raisenberger talking about Paul in twenty eighteen.
Wow, time does fly. Yeah, And this comment comes from Mike,
who says, I thought dylan shout out for up for grabs was pertinent,
so I thought i'd share the link in case anyone comes looking for it.
And it's up dash for dash grabs dot net, which I think most people
know about. And so I went and checked it, went to up for
grabs and looked for Polly, and sure enough it's there. And there are
still several up for grabs I'm in there, including one Martin put in like
a week ago. So, you know, just making it very clear that
even though years ago we talked about up for grabs and getting more people involved
in open source projects, this is still an ongoing thing, and Polly is
certainly part of it. Yep. And Mike finishes up with his comment saying,
and thanks to app v Nex, to Microsoft and everyone else involved with
Polly. Yeah. Yeah, it's a good thing. It's a good thing.
When and here and here you go, Mike, we're gonna talk about
version eight because somehow you guys got to version eight. I'm concerned. You
know, that's a large version of her. It's you know a momentous update.
Yeah, so, Mike, thank you so much for your comment,
and copy of music Koba is on its way to you. And if you'd
like a copy of music Cobe, I write a comment on the website at
Donna Rocks dot com or on the facebooks. We publish every show there,
and if you comment there and I read it on the show, we'll send
you copy of music Koba. And you can follow us on X if you
want. But I just can't get used to saying X. I don't want
the social media formally noticed. Twitter. Yeah, yeah, exactly, But
the cool kids are hanging out. I'm mastered on It's extremely much less polluted
than X. And I'm at Carl Franklin at tech hub dot social, and
I'm Rich Campbell at masdon do social send us a tute. That's another way
you can win a copy of music to code by absolutely all right, So
let's introduce Joel and Martin. Joel Hewan, of course, has been on
the show before. He's one guy that I discovered through app VX and now
has more than twenty six years probably twenty seven or twenty eight years of experience
in the IT field, gaining expertise and a variety of disciplines, ranging from
systems engineering to cloud based computing and everything in between. Joel's an international speaker
focusing on such topics as cloud architecture, server lists, data engineering, and
AI. He also creates and delivers training on these to Microsoft employees and partners,
and is also a major contributor to Polly. Martin Costello, one of
the Polymartins. We'll talk about that in a minute, because there are at
least two, is a dot net developer and tester as well as a Microsoft
MVP and developer Technologies. Based near London in the UK, he currently works
for Just Eat Takeaway dot com as a principal software engineer. He's a big
fan of open source software and as well a maintainer of Poly. He's a
community triagre for the asp net core project in GitHub. And I just got
to tell you that grammarly does not recognize the word triazure or serveralists for that
matter. That not actually a word trioger, but I mean somebody's got to
do the trioge that's true. He's a triozer. Welcome guys, thank you
guys. Welcome Choel, Welcome Martin I've got to say I'd rather be a
triager than a triage, absolutely, especially not in the medical field as well.
Yeah, exactly. The worst thing you can hear as a triage is
this one can wait? Yeah, we'll just cut it off. Get me
a saw or I've never seen this before, Martin. There are other Martins
in the poll project, right, how many are there? So there's another
two, which creates lots of confusion when there's a very populated call because the
Martin you mentioned earlier tagging issue wasn't me right? Nice? Yeah, Martin
right there kind of figured that. So there are no greater or lesser Martins.
They are all unequal footing, and Martin Costello is the Martin that we
have right here today. So Joel, I guess, well you are Martin
who wants to give us the basic elevator pitch As to the first of all,
what Polly is and why version eight is so momentous, I'll let Joel
all right, fine, I'll take that one. Yeah sure. So,
Polly, I know that you referenced the show that Dylan was on back in
twenty eighteen. I mean that feels like forever ago because it kind of was
now it's a whole pandemic ago. It was a whole pandemic ago, and
we were already making some major improvements to Polly at that point. So if
we back all the way up, Polly was originally developed by a fellow named
Michael Wolfenden, and I think it started probably around twenty thirteen. And by
and large, it is a library that is meant to help you in a
very fluent way, to be able to address transient issues, you know,
transient type of errors. Think of things like I've got to make a rest
based call to this service and that service could be down. How do I
gracefully handle that? How do I retry it or do some other strategies?
And so essentially, anywhere you can run dot Net, you can run Polly.
And so Polly is, like I said, it's a library. So
it does have a lot of dependencies, a lot of projects out there.
And so back in twenty fifteen, Michael Wolfenden, for whatever reason, he
wanted to find somebody to take over the project. He just didn't have time
for it anymore. Nobody responded. Finally, I said, okay, I'll
see what I could do to help. And so at that time I think
I'd been with app v next for about a year and I talked to Carl
and I said, hey, what do you think about us bringing this instead
of under me, bring it under app v next. So it's under an
organization, and you thought that was a great idea. I'm putting words in
your mouth maybe, but I believe that's what you said. No, No,
absolutely what happened. Yeah, I was using Polly and I loved it.
And you could see the downloads of Polly just exponentially growing year after year
after year. Yep, yeah, yep. And so we made a concerted
effort to look at what are the features that the community is asking for,
how do we make this better? And Dylan who was on that call,
he was one of our primary architects on that project, and he really kept
moving things forward, right, and so we jumped a bunch of versions.
And so fast forward to December of last year, we are on Paully v
seven. You know, I think we had like three hundred and something million
downloads at that point. And by the way, it is part of the
dot net framework. It is in the HDDP client factory. Yes, And
the HDDP client factory came about a few years ago as a collaborative effort with
Microsoft. But Emo Landworth from the dot Net Team reached out to me on
x previously Twitter December of last year, TwixT and yeah, and so what
he was saying is that, uh, it is Polly is a library that's
used by a lot of the engineering teams. It's used by the dot Net
team, it's used by the Azure teams for a lot of services. It's
used by teams. And they were the Team team, and so what they
what they wanted to do was to figure out, Okay, we want to
make some potential breaking changes along with your help, you know, as the
poly maintainers, and really focused on making improvements to performance, right because what
they were seeing is the performance has been okay, you know, it's a
library that that's that shouldn't add too much latency to your applications, but until
you hit a certain scale. And what they're finding is with some of the
cloud scale type of stuff that they were doing the way that Polly was structured
at the time, with a lot of overloads, a lot of excess allocations
and things tasks, it did start Yeah, it did start having some performance
implications at certain scale I'd say ninety something percent of people would never see this,
but they were seeing it. Stuff happens in the class, stuff happens,
stuff happens in the cloud. That is not normal. Yeah, that
is true. Who knows hundreds of thousands of requests like it could be millions
of requests and suddenly every cycle matters. Yeah, I seem to remember they
said something. So they've been doing some performance profiling work on like one of
the either as your the team's services, and they got to the point where
we were the bottleneck, Like they'd hacked away everything they possibly could to just
get that last process or instruction out and get more bang for their buck,
and we were the biggest problem. Now yeah, wow, so that's always
fun. And they didn't just propose like performance tweaking. It required an architectural
change at the lowest level, right, Yeah, And some of these were
things that I think we just had as open issues for forever because they weren't
prioritized. And you also have to have time to get to these things.
Yeah. Well, and they probably weren't be normal problems like there, it's
like everybody's working. Fine, this would be a good idea, but it
doesn't buy anybody anything until it finally did. You just need to look at
them all like together, because if you just have lots of individual issues where
each one is breaking, you just go, oh, that isn't important enough
to create a breaking change, and you don't look at any of the others.
But I think the Microsoft team looked at it at a bit of a
higher level than us, and they were like, if we put all this
stuff together, there's a release, right, and it's a re architecting.
Yeah, absolutely, And we there's some cruft in there that you know,
technical debt, whatever you want to call it, that we were well aware
of, you know, like all the overloads. Hey we need to add
something. Let's just overload this existing method again. Yeah, more overloads.
And it was it was starting to get out of hand, I mean,
and we knew it, but again, you know, think about priorities and
the like. So so what we got with with EMO and the dot net
team really wanting to rally around this with a stated goal of, hey,
we want to take down the number of allocations to zero if we can,
that's probably the biggest performance impact, and they had certain goals in mind.
A couple of weeks ago, what was announced is the Resilient App Development Library.
So the Microsoft dot extension is that Resilience and then Microsoft at Extensions dot
http dot Resilience and so these are two new GET packages that are built on
top of poly and there's some internal stuff in the dot net framework that they
wanted to use Polly for. Rather than hey, let's let's go off as
Microsoft and create a resilience framework on our own that's not already adopted and well
known by the community, they didn't want to go that route. So props
to them for first reaching out to a very active community project and seeing can
we collaborate together? Right, And so they had certain goals in mind where
they needed to get this work done, so they were willing to allocate a
couple of developers on this project. So Martin Tomka is one of the Martins.
He was one of the guys who did most of the work, you
know, over the last several months, and he was dedicated to getting these
features pushed forward. And so that was a huge boost for us, right,
And so we had a lot of design meetings leading up to that.
We had regular meetings scheduled with the team to go through the API changes,
making decisions, so it was a really interesting and fun kind of collaboration.
Earlier on, you said there was going to be some breaking changes, but
I think correct me if I'm wrong, but I think we overcame those and
we're able to create a compatibility layer. Is that true? That sort of
happened and sort of didn't happen. So Poly itself depends on poly dot core,
which is the new assembly that contains all the new low allocation bits,
and we didn't change any of the API surface from the original POLY library,
so people can upgrade to it and it shouldn't break anything, but they don't
get the new high performance mode in like big air quotes. Okay, there
was some investigation to create a compatibility layer, so we'd effectively gout the old
POLY and rooted through the new POLY. But because of the like the fundamental
design problems that Microsoft tried to solve, there was no real way to bridge
the two APIs without actually making the performance worse than it was already. I
say worse, not as good. Yeah, that as good. And the
new architecture involved interfaces, right, whereas we didn't really have those before,
and that that is a fundamental difference in the way you handle approach a programming
problem is that is that part of the reason why the compatibility. There's some
interfaces in the design, but a lot of it is also like concrete types
because the downsides you get to let's interface everything is that as soon as you
want to change anything, it's a breaking change because you need to extend the
interface, especially because we have compatibility for dot Net framework and not all versions
of that support extension in spaces. I've forgotten the proper name for them,
default interface ethods. That's what I'm thinking of. So, Joe, when
you said they wanted to use stuff in the dot Net framework, you meant
the dot Net Framework, not dot Net Core or dot Net as it stands
today, right right, Yeah, So Polly has been backward compatible for the
dot Net Framework for a while, ever since Core came out. We intentionally
tried to make sure that we brought forth, you know, the capabilities to
the dot Net framework as well, and so there as you can imagine,
there's some long term implications. You know, that's something Martin hint hinted at
here in keeping that compatibility. So if you wanted to just upgrade right now,
you know, without the super high power new stuff. Are you going
to see any performance increase or, for that matter, any performance degradation.
So I think anything you get without doing a code upgrade and just changing your
package references is just going to be the delta of noise of whatever you're running
on top of. So, in essence, no, you won't get any
significant change either way if you just pop the version numbers and do nothing else.
And that's that's okay. I think, yeah, that's completely acceptable.
The docs we do have, we're using GitHub io GitHub pages to generate a
site called polydocs dot org and so you can get to those docks from the
normal repo as well. But there is a migration document in there for okay,
you are wanting to use the new poly dot core and take advantage of
everything, including the performance improvements. Here are some code snippets and ways that
you can migrate your old policies to the new strategies, which, by the
way, is a change. Before everything was just called a policy. Now
they're called strategies. But we're not going to change a product to straty.
I mean, I'm not a marketing person, but I'm thinking that would not
be very good. You can change the logo to a stratocaster. That's not
so bad. I don't know, man, I kind of like the parrot.
I just like the riff on the guitar when you do something right,
but play the guitar. Yeah, you get the parrot to play the guitar.
Now Martin's on it, he's got to figure Okay, okay, okay,
I think we can concede. That's the strat right there. Oh man,
that thing's only as big as your finger, I know, right,
How do you play that? Visual gags on a podcast? There you go?
Visual gags? Now? Wait a second. So you had a Microsoft
employees focus full time on Polly for months? Yeah, I don't know how
full time, but in our meetings it sounded like it was fairly full time
is focus at least for some period of that, and he was working on
it a lot. So I'd say, yeah, sure, because because you've
got a regular job too, I mean both of you do. Yeah,
So I mean how much pressure is put on you to make time for all
of this? I think in some ways I got more of the pressure than
Joel, because Martin Tomka is based in a check here, so I'm a
lot more in the right time zone for code reviews than Joel, But my
company as well is like we try to embrace open source as well because we
use lots and lots of things. We use sure, poly x, unit,
you name it. So my line manager was very supportive in like giving
me time on the sort of company time to contribute to the project. So
it wasn't all just being done in my spare time. Right. So,
as this came down that Microsoft wanted to focus on it, that wanted to
be an important part, you were able to share it with your leadership and
they're like, well, this is a good thing for everybody, so do
what you got to do. Yeah, because I think I think I don't
have any concrete numbers, but I imagine poly is right up there in terms
of popularity within our internal Gethub enterprise instance of what we use in our own
applications to power our services. M Yeah, and that's I mean, this
is a debate, a discussion we've had around open source for a while.
It's like what happens when an employee is assigned to your volunteer driven project,
you know. So it feels to me like this is a good news story,
but it sounds like he was a very collaborative person too, like it
was easy to get in and chat through things and keep everybody on board one
hundred percent. And that was one thing that when when Emo first brought this
to me as a potential thing, he was very sensitive about the fact that
this is an open source, community driven project and he did not want this
to be to feel like it's a takeover. He didn't want to feel like
we're just kind of on the sidelines observing from the outside, but rather being
a part of the whole process and making sure that we are still involved in
decision making as far as where it's going, you know, all the different
design decisions and stuff. So because they had the alternative was that they write
something themselves, right right, I think they could have done that and to
say, hey, you know what they could have Yeah, this is a
special case for us because it's cloud scale and we're going to do something totally
different as opposed to what they did do. I'd like to talk some more
about the whole open source thing after the break, but before the break,
we got to get back to the outcome, like what were the performance gains?
Do you have any metrics in terms of scalability and performance gains of poly
eight. We do have as part of the build process benchmarks that run every
time, so we get updated benchmarks and that way we can make sure we're
not degrading in any way as we make changes. Okay, so I've just
randomly looked at one of the benchmark results that we've got checked into the repository
at the moment from the last time they were run, and as a as
an example for the timeout policy in version seven, this benchmark was four hundred
and thirty seven nanoseconds and seven hundred and twenty eight bytes allocated, and then
polyv eight's equivalent is three hundred and forty nine nanoseconds, So that's a twenty
percent improvement and zero allocations. So wow, one hundred slash infinite. Yeah,
congratulations, that's fantastic. But that was the goal was to get to
zero allocations. That wash. Yeah. I don't think we ever put it
in stone as a like it must be zero, forever be zero. No,
but it's like, can we get there? It's an interesting thing,
Like it seems bizarre to me that you've got to zero allocations, Like how
do you make that work? Well? I can tell you one way.
In wherever there's a task, there is now a value task, which is
a value type rather than a reference type. It's like most of the API
most of the breaking changes to the API surface were changing to value task.
And there's also various changes that are in support of you being able to like
use static landers for like the code you want poll to call for you,
so you can still code it the way with the old poly but you don't
get as much improvement. But then if you really want to shave things down,
like there's slight readability degradation in some cases, but if you really want
that performance, you can sort of switch into like a slightly different mode and
then you'd lose all the allocation from the closures as well, and then you
get even even more memory allocations. Dropped on the floor, not dropped on
the floor, you know what I mean, M shaved. Well, it
speaks to me of this code as an open source project is an example of
how to build really high performance cloud code. Then, like zero allocation code
is kind of a big deal. Yeah, and I guess as well.
It's one of those doesn't always work for everyone. Is like if you've got
something that's used at the scale Polly is like when you multiply up those savings
to everyone who uses it, If everyone adopts the new stuff, that's quite
a big chunk into like CO two emissions and things like that. Whereas if
you've got a project that you maintain yourself, it's got like kind of a
couple of thousand downloads, it's probably not worth the effort putting all of this
engineering into it to just like save a few CP cycles every other month.
Yeah, I was. I was going to mention the same thing. You
know, it's sort of like green code in a way, because if you
look at the scale overall, you know, saving energy and cycles and all
that kind of stuff, it's it's worthwhile at certain levels of scale. But
again that's not everybody you got to get there for. To make sense,
you don't want to build that way off the bat. But was that what
they came to you with. I thought they came to you with performance and
resource consumption, not so much specifically, Hey, we're trying to cut the
CO two consuming Oh no, not at all, not at all. That's
just a nice spike product of it. Yeah. Yeah, I think part
of the use case for all the savings to not speak for Microsoft, but
try and badly remember what they might have said at the time was with all
the pandemic growth in the cloud and things like teams, like, it was
costing them a lot more to run the service because they needed more stuff.
But they didn't want to pay the same percentage extra of how much stuff they
had for how much traffic they had. So it was all about how can
we run more on less? Right, It's certainly been a theme over on
the sissipmin world and run as Radio about how to do more with less,
and some of it has been conversations about moving up the stack, like getting
off the VMS and into platform and they were just consuming less resources you get
the same workloads done. And this is at the developer level saying, I
mean optimizing code, you're saving nanoseconds, which seems insane like that that would
matter until you think about millions running simultaneously. Yeah, if someone's got like
a tiny little command line tool where they had polly in just to do a
few retries, yeah, like they're not they're not going to notice this kind
of thing. But when you got yeah, but when you've got like a
multi tenant application used by thousands of people at the same time. It all
starts to add up. So start to add up is they're looking at this
large statistical model and saying, Okay, well this is showing up in the
graph. Now is a meaningful level of consumption? Yeah, it's fascinating.
Hey, guys, hold that thought while we pause for these very important messages
and we're back. You're listening to Dot and Rocks. I'm Carl Franklin.
That's my friend Richard Campbell. Hey, and that's Joel Hewen and Martin Costello,
and we're talking about poly version eight, which dropped, oh what a
month or two ago, Yeah, end of September, end of September,
and just sort of talking about the whole open sourceiness of it. As Richard
said, it's sort of a model project for how to collaborate with a bigger
company. I mean, Microsoft was very very cooperative, mostly I think because
they were incentivized too, right. I mean they're running it in Azure,
and they're running it in teams and in all these big scale things sites,
so they had a reason to do that. Other projects may not be so
lucky. Is to have a big corporate sponsor that has invested interest in their
project. Yeah, that's very true, And yeah, I would say that
that was what impressed me a lot. This This is not the first time
we've collaborated with Microsoft on this. You mentioned it that in the past we
worked with Glenn Condron, and I remember Ryan Noak, one of the developers
on the team. Actually, you guys know Ryan. He's worked on sure
on the Humanitarian Toolbox and other things. But that was when we brought in
the the Microsoft Http Resiliency Extension right and and which which made it a very
simple way to take the hdt B client factor and then be able to add
any number of at that time policies, poly policies for retrying those HDP calls
on the clients that get created from that. And so at that point even
I think they were very conscientious about I remember specifically one of the things that
Glenn said, Hey, we're thinking of two things. One you guys just
got added to the dot net Foundation at that time, and number two,
if we use this and then Polly becomes a dependency of this other library that
we're building that millions of people are going to use. We know that some
open source maintainers are very concerned about a huge uptick in having to resolve issues
that the community submits and having to keep up with that, and that frankly
scares a lot of people who just this is a side thing. They don't
want to involve too much time man. And so even at that point they
were very conscientious about that, and it's something we discussed and it ultimately didn't
become a big issue. We never really saw huge uptick in issues, and
that library had its own repo anyway where they can log that. But so
I would say that's this is twice now that I think the experience has been
good with Microsoft. I can't speak for other organizations as far as open source
projects go like this, but I would also say, you guys are interacting
with the dot net dev team who are working get hub every day like that
is that is their normal workspace, and I think they've learned the culture and
work in the culture as much as they've also affected the culture. That's fair,
but it's also good to see to you know, this has been an
ongoing conversation for the past few years about can you have a good experience with
this, and you guys are saying yes, it's been years of good experience
indirectly as well. It's like the previous engagement was how I ended up getting
involved with poly because I was sort of like interested in what was going on
with the htt B client factory stuff, and I think Dylan was as well,
and we sort of interacted in the dot net repos through that stuff.
And then I think it was through that that sort of Dylan became aware of
me and being interested in Polly, and then I think sometime later that was
when he approached me. He was like, Hey, do you want to
help maintain poly? Yeah, you want to make your life more complicated?
Guys? What is I know that we made a pledge when we started dot
net Rocks not to actually read code on the on the audio podcast, right,
We're not going to recode to you, but give us a sense of
what the learning curve is like when if we have if we're using POLYB seven
or earlier, and now we want to use the high performance stuff. So
one example of how little work it could be is if you're using the HDP
Client Factory integration, you can swap it out for the new one and you
can possibly even delete code. Because I spent an hour this afternoon taking out
the old one putting in the new one, and I and my GIT diffs
were mostly lots of red, not much green. No, okay, and
you just have to swap in like assuming you want to use all the defaults,
you can like swap a one extension method with one name form with another
name and then just change a few cause lights. So we're talking about names,
not necessarily like the patterns are still pretty much the same. Yes,
I think the thing that's the biggest change is configuring it, So setting up
what the policies are that's got the biggest change to it. But once you've
got your policy, which is now a resilient strategy, then the core site
where you actually use them to do something interesting, the changes you have to
do at those sites are minimal. Okay. Wasn't this always the claim to
fame for Polly as this idea of I set up a bunch of recovery strategies
or policies, and then you just apply them to the things that matter.
So you're not writing that boilerplate over and over and over again, but you
might be writing the response differently, Like you know what you're going to tell
the user happened if something happens and you finally have to fail back. That
message might be different, or the code that you write in the policy is
probably going to change because your URL may change. But things like that.
Yes, the real work is done in the policy and now in the resilience
strategy. So it's really good to hear that that pattern doesn't really change all
that much. But what is it about the configuration that's so different now?
So I would say the biggest change, which Joel alluded to earlier, was
we had all these overloads and adding another one, adding another, and it
got to the point where I don't know about Joel, but I was any
time anyone opened to PR went, oh, I'm just adding another overload,
but like I'm a bit scared to add that break it. So how many
overloads are too many? So what we tried to do with the eight was
like having a configuration object, So you have an object of options, and
if there's a new option comes along, we just add a new property to
that objection. So there's a couple of convenience overloads in some places, so
like retry as you can just do too well, whatever the API is,
I don't have the doctor in front of me right now. But In most
cases you have an object and you just set whatever it is you need on
the object. So the theory is that we can keep extending it without having
to make breaking changes now, which isn't necessarily the case with V seven low
the JSON file phasers on stunt kirk out we come from. I would say,
you know, for some people, they were using some features like the
policy wrap was very common, and that was sort of like a nesting egg
approach where you take a policy and then you nest another one and another one
and another one, and then it would apply those policies backwards when you go
to execute it. And so if you're using that, then you're already going
to be pretty familiar with the resilience pipeline, which that's how we're just setting
these strategies now, is through that pipeline, and so it gives you still
a nice fluent way to be able to add additional strategies layer them in there,
right, and so there's there's a lot of similarity as for as that
goes. And then we also had the concept of the registry before, and
one thing that you could do is the you can have a strategy configuration by
name and say you're loading that from some sort of you know, app can
figure or something like that. You can set an option to automatically reload the
policy if the configuration changes, right, So then that way, within a
live running environment, you could tweak the configuration, apply it in your configuration
service or settings wherever that is, and then it'll reload that policy for it
to pick up those changes without having to deploy new code. Nice. Nice,
Yeah, that's something we used at my workplace. But because previously we're
using v seven, we had to hand code all of the layers to sit
on top of poly for the reloads to actually work, and we'd effectively have
to throw away all of the policies whenever the configuration and change and rebuild it
all from scratch. So you could change home when you retrays or something like
that. But with polyv eight, most of that's they built into it.
So again there's a first class citizen within one of the surfaces. Where I
did the upgrade, most of it was taking a hatchet to it and throwing
code away, right, always fun. I love throwing code away. What
does the dot net eight uh landscape look like? I mean, Microsoft is
still using the HDP client factory. So I imagine that moves over to dot
net eight without any breaking changes, yep. And that's where you want to
use that new Microsoft dot Extensions HTTP dot Resilience library. Yeah, right,
where the one that we collaborated with years ago is the Microsoft Extensions HTTP POLY
and so it's just swap out that old one for this new library that's built
on top of POLY. You're still using the HDP client factory is the best
practice for managing the life cycles of those clients. And again I think Martin
said this, You're not going to get any performance benefit or degradation either way
if you just swap it out. So if you switch to the new resilience
package, you will because the internals that Microsoft are written in the dot Neet
Extensions repository where all of these libraries are coded. They're built on top of
our new primitives and wrap into the HDDB client, whereas the old package uses
the old primitives. So Microsoft have effectively done the work for you to do
the migration. So at a high level, you're just going, hey,
HDDB client, make it do resilience with poly, okay, and one package
does it one way, and one package does it the other way, and
the new one is the more performance one. So but there is an any
breaking change. You just changed the package name and you're after the races,
so you need to make a few co changes like new method name games.
But also the more you have customized things, the more work it will be
to migrate. If you've got some really custom stuff going on, you'll have
to read the migration guide and take that into a vex, Whereas if you
were just doing a simple just add some retries to my services. In case
weird stuff happens, the changes should be relatively minimal. Weird stuff never happens.
Yeah, and if you're using dependency injection to set all that up,
that should hopefully minimize the number of places you have to make changes. Yeah.
Of course I was looking at that because I'm planning on swapping out those
two libraries and a big project of mine today, so I expect it to
be smooth cool. Part of the reason why with some of the changes I
made today had so many deletes was because the old way of doing it had
the code, had the infrastructure code for you to go. If I have
a poly registry, there's some registries in it, put it in the HTTP
request, but you have to tell the application what to put in the registry.
We're not going to do that for you. But the new library has
a method. It's called something like add standard resilience or something like that,
and it has like your common or Garden ninety percent case sensible defaults built into
it, so it automatically does retrise, it automatically does circuit breakers, it
automatically takes a time out into account. So if you don't know much about
having resilience at all, if it maybe if you write a new application which
doesn't have anything in it, with like one extension method added to your HTTB
client setup, you get sensible defaults for free. That's a complete pipeline stuff
you used to have to assemble. Yeah, so like most of the stuff
I deleted today was all my manual curation of retry one second, then two
second, and five seconds. Now that's all baked in, And I just
deleted all black code and went for my hobby stuff. I'm not leading engineering
enough to be you find tweaking everything, so I just do the defaults.
It's fine, will be better. What I like about that is that most
people don't know what policies to make. Most people don't know, Oh,
should I do an exponential backup? Nobody's going to say, well, what
are you calling? Nobody knows what you know. That doesn't matter. So
I love the idea of sensible defaults falling into the pit of success and all
that. Yeah, I take the cloud guys, like the pit of success
thing with seven I thought that was always tricky, was okay, I want
to do circuit breakers and retries and timeouts, putting them in the right order.
Yeah, so you're not like circuit breaking over your retries or the other
way around it. Like I always have to look at the documentation to get
them in the right order, whereas with the sensible defaults, someone else solved
that problem for you. They'll be in the right order. Is that a
sensible defaults property equals true kind of thing? Or is it just done by
default? You don't even have to do that. You don't even have to
do that, you just set fut to false. Hey I noticed the docs
here you have a section on chaos engineering. I'm delighted. Yes, Yeah,
so that was semi Simmy was one of our poly Contribe projects that came
about a few years ago, and that was by Giovanni and what we're doing.
I think the next version of Polly eight point two, I believe we're
going to have that fully integrated into the poly core. So your chaos engineering
will be a foundational piece of Polly. You don't have to pull in an
external dependency now. It's going to be developed alongside Polly itself going forward.
So that's the perfect place to put the chaos monkey. It's like, hey,
make this fail randomly. Yeah, it's great. I just like the
idea of chaos as a policy. I love everything about that chaos is out
policy, this meaning will come to order. I would like to discuss our
chaos policy. This is an old it's an old reference, but it reminds
me of get smart. You have control. There's the good guys, the
chaos, the bad guys of course, yes, yes, the old chaos.
So there's one other thing, another goal that Microsoft had going into this
to meet their needs, but I think benefits the all of us is now
there's built in telemetry and metrics that is part of Polly. So uh,
this is very important to say you've got maybe a large micro services sort of
project, which means you've got all these deployed services deployed everywhere, each of
them are implementing strategies hopefully, and you need to be able to make sense
of a Okay, where am I seeing failures? How often are these failures
happening? What are the metrics involved? So then I can try to tweak
these settings as Martin does, you know, within his project, and the
built in telemetry and metrics components will help you do that. And there's a
whole document on that now too. Wow. It's certainly one of the challenges
on the operations side to discern the difference between a successful retry and a failed
retry, Like if they're just log entries, you see all these failures,
but he's like did it work or not? Like how do you associate?
And then eventually it succeeded in delivering the package and everything was fine. But
you know, just being able to combine that down well and say, okay,
well this was this with multiple retries was a success. It's also one
of those things, like Joe mentions the telemetry, it's again, it's a
thing we had in our applications custom written to see when our circuit breaker is
firing, when our retri is happening all deleted again. Yeah, because now
there's a set of policy around all of that, and I presume integrates with
open telemetry, works with all the Azure bits monitor and such. It will
by virtue of it's built on top of the like the the primitives in the
framework, and it's event source. Maybe not that one that there's a there's
a type baked into it. I've forgotten the name of. Now that you've
got the lagger the lagger factory. Yeah, so I think it uses the
logger to do to like create the events. Then there's something cooked into the
logger which then hooks into the I think it's the event source. And then
because dot net is now instrumented, if you're then using open telemetry, it
will indirectly go through into open telemetry without so probably doesn't directly integrate with open
telemetry, but it does indirectly through Why he's integrated into Okay, it's important
to know because it means we don't have another place to look. It feeds
into their existing instrumentation. Not that I know anything about that. Well,
guys, I mean, congratulations, this is a great story, an exciting
product, very much good to finally get it out after ten months roughly.
Wow, yeah, something like that. Ten months. It was definitely a
whole good question. And there's a bunch of new as you mentioned, well,
there's a bunch of resources that we're going to go to, but polydocks
dot org is probably where you should start, is that right? Yeah?
Yeah, And also give a give a little shout out to Peter Sala,
who's done so many poor requests to make the polydocumentation better. It's like,
yes, and I've forgotten the name of who it was now I'll see if
I can quickly look it up. But someone set up the polydoc site for
us, and then we wrote a bit of documentation to fill it in,
and then Peter has added more and more and more on top of it,
so it's even better. One obsessed individual. Yeah, no, it's great.
He also added a lot of patterns and anti patterns within the documentation,
which is excellent, and he also updated the poly samples project to use all
the new V eight goodness as well. Y I looked at the name it
was Adam Nova built the new docs site template for us. Oh yes,
and Martin, you also have a poly sandbox that you published. What's that
all about? So I mentioned a couple of times we have internal applications using
poly and doing things like metrics and configure it dynamic configuration and things like that.
So I took all of the poly scaffolding out of an internal application and
put it into a public application. So we had something that wasn't proprietary that
I couldn't share in the open with the other Martins and Joel. So it
sort of it took the poly relevant bits out, just put some boring,
you know, to do app type end points on top of it, and
then went right, we do this sort of thing with poly We want these
use cases to work with polyvas and that's where things like the configuration reload.
We tested that that worked properly. And it was also like we had another
feature where if we knew our system was down for some reason, like poly
doing the circuit breaking the retries can create a lot of noise in like opening
the circuits, closing the circuits again and again again. It's like, we
know it's broken stuff. So we had functionality where you could just like preemptively
just flip the switch and turn it off. Is like it's sort of started
broken just so its short circuits immediately, and that was a feature that didn't
used to be in poly and sort of brought through through just using the sandbox
app. Nice. Yeah, and some of that. There's a new strategy
called hedging, and that sort of replaces the bulkhead strategy or policy that we
used to have, right, and so hedging it can make several requests the
same thing at the same time. You could do it in parallel, you
could do it in cereal or whatever, and it will take the fastest response.
You could also do things like put a rate limitter on and that's also
new. Rate limitter will allow you to say, Okay, I want to
limit this to one hundred calls to this database, you know, per minute.
You know, maybe it's a very small database and you know it can't
handle more than that, and so you don't want to flood it, and
so you can add that just says if that's the only thing you do,
if you don't have any other strategies and you just want to rate limit stuff,
you could add that on, or you could layer on retries and circuit
breakers and other things too. Wow. Yeah, I could also see I'm
calling an external API that has rules around how hard I'm allowed to hammer it,
and I don't want to get locked out, so I'll put the rate
limit. And within that strategy too, you can also look for a lot
of those services will have a retry after header. You can look for something
like that and then you could tell it, okay, time out for this
long before trying again. Right, So there's a lot of flexibility in there
strategy to take that on. And the new rate limiting strategy as well,
is built on top of the new rate limiting functionality that shipped with dotten at
seven. So it's yet more code we don't have to maintain, we don't
have to do the smarts of rate limiting. We just built on top of
it. The team did that and continue to make Yeah, because we talked
about doing this way before that feature came out, or you know, just
before it came out, and so there was that whole thing of hey,
we need this, but we could just wait and this is going to be
part of dot net seven and let's just build on top of that. Very
good well, guys, thanks congratulations. As Richard said before, and uh,
here's too many more years of success with Polly light On. Thank you
all right, and we'll talk to you next time on dot net rocks.
Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios,
a full service audio, video and post production facility located physically in New
London, Connecticut, and of course in the cloud online at pwop dot com.
Visit our website at d O T N E t R O c ks
dot com for RSS feeds, downloads, mobile apps, comments, and access
to the full archives going back to show number one, recorded in September two
thousand and two. And make sure you check out our sponsors. They keep
us in business. Now go write some code, See you next time.
You got JAD Metal vansc