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