1 00:00:01,080 --> 00:00:04,799 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05,360 --> 00:00:09,480 Become a patron for just five dollars a month. You get access to a 3 00:00:09,480 --> 00:00:14,279 private RSS feed where all the shows have no ads. Twenty dollars a month. 4 00:00:14,279 --> 00:00:18,440 We'll get you that and a special dot net Rocks patron mug. Sign 5 00:00:18,519 --> 00:00:35,759 up now at Patreon dot dot NetRocks dot com. Hey guess what, it's 6 00:00:35,799 --> 00:00:39,359 dot net rocks. This is Carl Franklin and this is Richard Cavill. Back 7 00:00:39,359 --> 00:00:43,799 with you for another awesome show. And this is going to be an amazing 8 00:00:43,880 --> 00:00:47,640 show. Oh but I'm sure. Well, we're gonna have some fun. 9 00:00:47,679 --> 00:00:52,159 But this is momentous news momentum. Joel Hewen and Martin Costello are here. 10 00:00:52,200 --> 00:00:58,359 We're going to talk to him about Polly. But first we have some things 11 00:00:58,399 --> 00:01:00,560 to do, right, like better no framework? All right, hit me, 12 00:01:00,640 --> 00:01:08,959 let's roll it? All right? Did what do you got? So? 13 00:01:10,000 --> 00:01:12,799 I know last week I talked about the AI Bought Show. Yeah yes, 14 00:01:12,840 --> 00:01:19,359 but since last week, Brian McKay and I have started a podcast version 15 00:01:19,480 --> 00:01:23,920 of it. Oh so, if you go to Theaibotshow dot com now episode 16 00:01:23,959 --> 00:01:29,719 twelve, you will see has a little podcast label on it and it's audio 17 00:01:29,799 --> 00:01:32,719 only and when you click it, you'll go to another page that has the 18 00:01:32,760 --> 00:01:38,560 player and all the links. We basically decided to turn it into a news 19 00:01:38,799 --> 00:01:44,519 oriented AI podcast, right and as such because things are changing so fast, 20 00:01:45,359 --> 00:01:49,959 and you know, our videos get a limited lifespan because oh you know, 21 00:01:51,040 --> 00:01:55,400 by the time it goes out, the responses you might get from chat GPT 22 00:01:55,519 --> 00:01:59,519 will be completely different, right, right, and you may want to do 23 00:01:59,599 --> 00:02:02,719 things completely differently because there are new features and new things. So we just 24 00:02:02,760 --> 00:02:07,319 decided to go all news. Yeah, yep, try and keep up good 25 00:02:07,400 --> 00:02:09,919 luck, fast moving problem. Yeah, the news is good. And you 26 00:02:09,919 --> 00:02:15,639 could see by the number of links there on episode twelve that we had plenty 27 00:02:15,680 --> 00:02:17,319 to talk about. So that's it. Yeah, go to the iBOT Show. 28 00:02:17,319 --> 00:02:22,199 Oh and by the way, by now it should be in Apple Podcasts 29 00:02:22,280 --> 00:02:28,599 and Google. It's already on Stitcher and in Spotify, so you'll be able 30 00:02:28,599 --> 00:02:31,680 to find it wherever you get your podcast. It's the ai Bot Show podcasts. 31 00:02:32,000 --> 00:02:35,360 Cool, that's it. Who's talking to us? Richard grabbed a comment 32 00:02:35,400 --> 00:02:38,560 top of show fifteen fifty six, which is a long flipping time ago. 33 00:02:39,400 --> 00:02:44,800 That's the one we did with Dylan Raisenberger talking about Paul in twenty eighteen. 34 00:02:45,039 --> 00:02:49,240 Wow, time does fly. Yeah, And this comment comes from Mike, 35 00:02:49,280 --> 00:02:52,960 who says, I thought dylan shout out for up for grabs was pertinent, 36 00:02:52,960 --> 00:02:54,199 so I thought i'd share the link in case anyone comes looking for it. 37 00:02:54,199 --> 00:03:00,520 And it's up dash for dash grabs dot net, which I think most people 38 00:03:00,599 --> 00:03:04,120 know about. And so I went and checked it, went to up for 39 00:03:04,199 --> 00:03:07,599 grabs and looked for Polly, and sure enough it's there. And there are 40 00:03:07,680 --> 00:03:09,919 still several up for grabs I'm in there, including one Martin put in like 41 00:03:10,199 --> 00:03:15,400 a week ago. So, you know, just making it very clear that 42 00:03:15,439 --> 00:03:17,759 even though years ago we talked about up for grabs and getting more people involved 43 00:03:17,759 --> 00:03:22,560 in open source projects, this is still an ongoing thing, and Polly is 44 00:03:22,599 --> 00:03:24,560 certainly part of it. Yep. And Mike finishes up with his comment saying, 45 00:03:24,960 --> 00:03:29,840 and thanks to app v Nex, to Microsoft and everyone else involved with 46 00:03:29,960 --> 00:03:31,840 Polly. Yeah. Yeah, it's a good thing. It's a good thing. 47 00:03:32,039 --> 00:03:35,439 When and here and here you go, Mike, we're gonna talk about 48 00:03:35,520 --> 00:03:39,719 version eight because somehow you guys got to version eight. I'm concerned. You 49 00:03:39,759 --> 00:03:44,800 know, that's a large version of her. It's you know a momentous update. 50 00:03:45,039 --> 00:03:46,080 Yeah, so, Mike, thank you so much for your comment, 51 00:03:46,159 --> 00:03:49,280 and copy of music Koba is on its way to you. And if you'd 52 00:03:49,280 --> 00:03:51,719 like a copy of music Cobe, I write a comment on the website at 53 00:03:51,759 --> 00:03:53,639 Donna Rocks dot com or on the facebooks. We publish every show there, 54 00:03:53,639 --> 00:03:55,680 and if you comment there and I read it on the show, we'll send 55 00:03:55,719 --> 00:04:00,360 you copy of music Koba. And you can follow us on X if you 56 00:04:00,400 --> 00:04:03,879 want. But I just can't get used to saying X. I don't want 57 00:04:04,439 --> 00:04:09,280 the social media formally noticed. Twitter. Yeah, yeah, exactly, But 58 00:04:09,319 --> 00:04:14,639 the cool kids are hanging out. I'm mastered on It's extremely much less polluted 59 00:04:14,759 --> 00:04:18,519 than X. And I'm at Carl Franklin at tech hub dot social, and 60 00:04:18,600 --> 00:04:23,040 I'm Rich Campbell at masdon do social send us a tute. That's another way 61 00:04:23,079 --> 00:04:26,680 you can win a copy of music to code by absolutely all right, So 62 00:04:26,839 --> 00:04:30,519 let's introduce Joel and Martin. Joel Hewan, of course, has been on 63 00:04:30,560 --> 00:04:35,800 the show before. He's one guy that I discovered through app VX and now 64 00:04:35,839 --> 00:04:41,199 has more than twenty six years probably twenty seven or twenty eight years of experience 65 00:04:41,199 --> 00:04:45,680 in the IT field, gaining expertise and a variety of disciplines, ranging from 66 00:04:45,680 --> 00:04:50,759 systems engineering to cloud based computing and everything in between. Joel's an international speaker 67 00:04:50,920 --> 00:04:56,600 focusing on such topics as cloud architecture, server lists, data engineering, and 68 00:04:56,800 --> 00:05:01,319 AI. He also creates and delivers training on these to Microsoft employees and partners, 69 00:05:01,720 --> 00:05:08,720 and is also a major contributor to Polly. Martin Costello, one of 70 00:05:08,759 --> 00:05:12,360 the Polymartins. We'll talk about that in a minute, because there are at 71 00:05:12,399 --> 00:05:15,800 least two, is a dot net developer and tester as well as a Microsoft 72 00:05:15,959 --> 00:05:21,279 MVP and developer Technologies. Based near London in the UK, he currently works 73 00:05:21,319 --> 00:05:27,720 for Just Eat Takeaway dot com as a principal software engineer. He's a big 74 00:05:27,720 --> 00:05:30,279 fan of open source software and as well a maintainer of Poly. He's a 75 00:05:30,279 --> 00:05:36,399 community triagre for the asp net core project in GitHub. And I just got 76 00:05:36,399 --> 00:05:44,600 to tell you that grammarly does not recognize the word triazure or serveralists for that 77 00:05:44,879 --> 00:05:47,759 matter. That not actually a word trioger, but I mean somebody's got to 78 00:05:47,759 --> 00:05:53,759 do the trioge that's true. He's a triozer. Welcome guys, thank you 79 00:05:53,800 --> 00:05:57,839 guys. Welcome Choel, Welcome Martin I've got to say I'd rather be a 80 00:05:57,920 --> 00:06:03,959 triager than a triage, absolutely, especially not in the medical field as well. 81 00:06:04,079 --> 00:06:09,360 Yeah, exactly. The worst thing you can hear as a triage is 82 00:06:09,839 --> 00:06:13,959 this one can wait? Yeah, we'll just cut it off. Get me 83 00:06:14,040 --> 00:06:21,839 a saw or I've never seen this before, Martin. There are other Martins 84 00:06:23,000 --> 00:06:27,199 in the poll project, right, how many are there? So there's another 85 00:06:27,279 --> 00:06:31,720 two, which creates lots of confusion when there's a very populated call because the 86 00:06:31,800 --> 00:06:36,839 Martin you mentioned earlier tagging issue wasn't me right? Nice? Yeah, Martin 87 00:06:36,959 --> 00:06:43,160 right there kind of figured that. So there are no greater or lesser Martins. 88 00:06:43,199 --> 00:06:46,959 They are all unequal footing, and Martin Costello is the Martin that we 89 00:06:46,000 --> 00:06:51,360 have right here today. So Joel, I guess, well you are Martin 90 00:06:51,399 --> 00:06:58,360 who wants to give us the basic elevator pitch As to the first of all, 91 00:06:58,399 --> 00:07:02,040 what Polly is and why version eight is so momentous, I'll let Joel 92 00:07:02,879 --> 00:07:06,399 all right, fine, I'll take that one. Yeah sure. So, 93 00:07:08,199 --> 00:07:13,519 Polly, I know that you referenced the show that Dylan was on back in 94 00:07:13,600 --> 00:07:16,720 twenty eighteen. I mean that feels like forever ago because it kind of was 95 00:07:17,160 --> 00:07:21,360 now it's a whole pandemic ago. It was a whole pandemic ago, and 96 00:07:21,879 --> 00:07:27,720 we were already making some major improvements to Polly at that point. So if 97 00:07:27,759 --> 00:07:32,399 we back all the way up, Polly was originally developed by a fellow named 98 00:07:32,399 --> 00:07:40,360 Michael Wolfenden, and I think it started probably around twenty thirteen. And by 99 00:07:40,439 --> 00:07:45,240 and large, it is a library that is meant to help you in a 100 00:07:45,399 --> 00:07:50,759 very fluent way, to be able to address transient issues, you know, 101 00:07:50,879 --> 00:07:56,160 transient type of errors. Think of things like I've got to make a rest 102 00:07:56,199 --> 00:08:00,560 based call to this service and that service could be down. How do I 103 00:08:00,600 --> 00:08:05,079 gracefully handle that? How do I retry it or do some other strategies? 104 00:08:05,360 --> 00:08:09,319 And so essentially, anywhere you can run dot Net, you can run Polly. 105 00:08:11,040 --> 00:08:13,480 And so Polly is, like I said, it's a library. So 106 00:08:13,720 --> 00:08:16,920 it does have a lot of dependencies, a lot of projects out there. 107 00:08:18,519 --> 00:08:26,000 And so back in twenty fifteen, Michael Wolfenden, for whatever reason, he 108 00:08:26,079 --> 00:08:30,319 wanted to find somebody to take over the project. He just didn't have time 109 00:08:30,360 --> 00:08:35,600 for it anymore. Nobody responded. Finally, I said, okay, I'll 110 00:08:35,600 --> 00:08:39,799 see what I could do to help. And so at that time I think 111 00:08:39,840 --> 00:08:43,759 I'd been with app v next for about a year and I talked to Carl 112 00:08:43,799 --> 00:08:48,600 and I said, hey, what do you think about us bringing this instead 113 00:08:48,600 --> 00:08:52,639 of under me, bring it under app v next. So it's under an 114 00:08:52,759 --> 00:08:56,600 organization, and you thought that was a great idea. I'm putting words in 115 00:08:56,639 --> 00:08:58,679 your mouth maybe, but I believe that's what you said. No, No, 116 00:08:58,759 --> 00:09:03,240 absolutely what happened. Yeah, I was using Polly and I loved it. 117 00:09:03,399 --> 00:09:11,600 And you could see the downloads of Polly just exponentially growing year after year 118 00:09:11,639 --> 00:09:16,840 after year. Yep, yeah, yep. And so we made a concerted 119 00:09:16,960 --> 00:09:22,519 effort to look at what are the features that the community is asking for, 120 00:09:22,600 --> 00:09:26,399 how do we make this better? And Dylan who was on that call, 121 00:09:26,480 --> 00:09:33,200 he was one of our primary architects on that project, and he really kept 122 00:09:33,240 --> 00:09:37,519 moving things forward, right, and so we jumped a bunch of versions. 123 00:09:39,039 --> 00:09:43,639 And so fast forward to December of last year, we are on Paully v 124 00:09:43,840 --> 00:09:48,600 seven. You know, I think we had like three hundred and something million 125 00:09:48,639 --> 00:09:52,159 downloads at that point. And by the way, it is part of the 126 00:09:52,200 --> 00:09:58,039 dot net framework. It is in the HDDP client factory. Yes, And 127 00:09:58,200 --> 00:10:03,039 the HDDP client factory came about a few years ago as a collaborative effort with 128 00:10:03,120 --> 00:10:09,639 Microsoft. But Emo Landworth from the dot Net Team reached out to me on 129 00:10:11,159 --> 00:10:18,080 x previously Twitter December of last year, TwixT and yeah, and so what 130 00:10:18,240 --> 00:10:22,399 he was saying is that, uh, it is Polly is a library that's 131 00:10:22,519 --> 00:10:24,279 used by a lot of the engineering teams. It's used by the dot Net 132 00:10:24,279 --> 00:10:28,360 team, it's used by the Azure teams for a lot of services. It's 133 00:10:28,440 --> 00:10:33,639 used by teams. And they were the Team team, and so what they 134 00:10:33,960 --> 00:10:37,960 what they wanted to do was to figure out, Okay, we want to 135 00:10:39,240 --> 00:10:43,200 make some potential breaking changes along with your help, you know, as the 136 00:10:43,600 --> 00:10:50,960 poly maintainers, and really focused on making improvements to performance, right because what 137 00:10:52,000 --> 00:10:56,799 they were seeing is the performance has been okay, you know, it's a 138 00:10:56,840 --> 00:11:03,759 library that that's that shouldn't add too much latency to your applications, but until 139 00:11:03,759 --> 00:11:07,919 you hit a certain scale. And what they're finding is with some of the 140 00:11:09,000 --> 00:11:13,799 cloud scale type of stuff that they were doing the way that Polly was structured 141 00:11:13,840 --> 00:11:18,840 at the time, with a lot of overloads, a lot of excess allocations 142 00:11:18,840 --> 00:11:22,480 and things tasks, it did start Yeah, it did start having some performance 143 00:11:22,519 --> 00:11:28,879 implications at certain scale I'd say ninety something percent of people would never see this, 144 00:11:28,559 --> 00:11:31,799 but they were seeing it. Stuff happens in the class, stuff happens, 145 00:11:31,840 --> 00:11:37,279 stuff happens in the cloud. That is not normal. Yeah, that 146 00:11:37,440 --> 00:11:41,200 is true. Who knows hundreds of thousands of requests like it could be millions 147 00:11:41,240 --> 00:11:45,519 of requests and suddenly every cycle matters. Yeah, I seem to remember they 148 00:11:45,600 --> 00:11:48,559 said something. So they've been doing some performance profiling work on like one of 149 00:11:48,600 --> 00:11:54,080 the either as your the team's services, and they got to the point where 150 00:11:54,120 --> 00:11:58,200 we were the bottleneck, Like they'd hacked away everything they possibly could to just 151 00:11:58,240 --> 00:12:03,360 get that last process or instruction out and get more bang for their buck, 152 00:12:03,919 --> 00:12:07,360 and we were the biggest problem. Now yeah, wow, so that's always 153 00:12:07,399 --> 00:12:13,320 fun. And they didn't just propose like performance tweaking. It required an architectural 154 00:12:13,679 --> 00:12:16,240 change at the lowest level, right, Yeah, And some of these were 155 00:12:16,320 --> 00:12:22,000 things that I think we just had as open issues for forever because they weren't 156 00:12:22,000 --> 00:12:26,799 prioritized. And you also have to have time to get to these things. 157 00:12:26,919 --> 00:12:31,120 Yeah. Well, and they probably weren't be normal problems like there, it's 158 00:12:31,120 --> 00:12:35,240 like everybody's working. Fine, this would be a good idea, but it 159 00:12:35,320 --> 00:12:37,840 doesn't buy anybody anything until it finally did. You just need to look at 160 00:12:37,840 --> 00:12:43,360 them all like together, because if you just have lots of individual issues where 161 00:12:43,360 --> 00:12:46,120 each one is breaking, you just go, oh, that isn't important enough 162 00:12:46,120 --> 00:12:48,879 to create a breaking change, and you don't look at any of the others. 163 00:12:50,360 --> 00:12:54,000 But I think the Microsoft team looked at it at a bit of a 164 00:12:54,039 --> 00:12:56,240 higher level than us, and they were like, if we put all this 165 00:12:56,320 --> 00:13:01,360 stuff together, there's a release, right, and it's a re architecting. 166 00:13:01,639 --> 00:13:05,799 Yeah, absolutely, And we there's some cruft in there that you know, 167 00:13:05,919 --> 00:13:09,679 technical debt, whatever you want to call it, that we were well aware 168 00:13:09,679 --> 00:13:13,519 of, you know, like all the overloads. Hey we need to add 169 00:13:13,559 --> 00:13:20,639 something. Let's just overload this existing method again. Yeah, more overloads. 170 00:13:20,679 --> 00:13:24,320 And it was it was starting to get out of hand, I mean, 171 00:13:24,440 --> 00:13:28,039 and we knew it, but again, you know, think about priorities and 172 00:13:28,039 --> 00:13:33,960 the like. So so what we got with with EMO and the dot net 173 00:13:35,000 --> 00:13:41,399 team really wanting to rally around this with a stated goal of, hey, 174 00:13:41,480 --> 00:13:45,759 we want to take down the number of allocations to zero if we can, 175 00:13:45,919 --> 00:13:50,480 that's probably the biggest performance impact, and they had certain goals in mind. 176 00:13:50,840 --> 00:13:56,720 A couple of weeks ago, what was announced is the Resilient App Development Library. 177 00:13:56,080 --> 00:14:01,320 So the Microsoft dot extension is that Resilience and then Microsoft at Extensions dot 178 00:14:01,480 --> 00:14:09,559 http dot Resilience and so these are two new GET packages that are built on 179 00:14:09,639 --> 00:14:16,480 top of poly and there's some internal stuff in the dot net framework that they 180 00:14:16,639 --> 00:14:20,960 wanted to use Polly for. Rather than hey, let's let's go off as 181 00:14:20,039 --> 00:14:26,120 Microsoft and create a resilience framework on our own that's not already adopted and well 182 00:14:26,159 --> 00:14:28,480 known by the community, they didn't want to go that route. So props 183 00:14:28,480 --> 00:14:35,399 to them for first reaching out to a very active community project and seeing can 184 00:14:35,440 --> 00:14:39,759 we collaborate together? Right, And so they had certain goals in mind where 185 00:14:39,799 --> 00:14:45,120 they needed to get this work done, so they were willing to allocate a 186 00:14:45,159 --> 00:14:50,480 couple of developers on this project. So Martin Tomka is one of the Martins. 187 00:14:50,519 --> 00:14:54,960 He was one of the guys who did most of the work, you 188 00:14:54,000 --> 00:14:58,720 know, over the last several months, and he was dedicated to getting these 189 00:14:58,080 --> 00:15:03,399 features pushed forward. And so that was a huge boost for us, right, 190 00:15:03,440 --> 00:15:07,080 And so we had a lot of design meetings leading up to that. 191 00:15:07,120 --> 00:15:11,080 We had regular meetings scheduled with the team to go through the API changes, 192 00:15:11,200 --> 00:15:16,480 making decisions, so it was a really interesting and fun kind of collaboration. 193 00:15:16,840 --> 00:15:20,679 Earlier on, you said there was going to be some breaking changes, but 194 00:15:22,200 --> 00:15:26,039 I think correct me if I'm wrong, but I think we overcame those and 195 00:15:26,120 --> 00:15:30,320 we're able to create a compatibility layer. Is that true? That sort of 196 00:15:30,399 --> 00:15:35,279 happened and sort of didn't happen. So Poly itself depends on poly dot core, 197 00:15:35,320 --> 00:15:39,679 which is the new assembly that contains all the new low allocation bits, 198 00:15:41,559 --> 00:15:46,200 and we didn't change any of the API surface from the original POLY library, 199 00:15:46,559 --> 00:15:50,000 so people can upgrade to it and it shouldn't break anything, but they don't 200 00:15:50,039 --> 00:15:56,200 get the new high performance mode in like big air quotes. Okay, there 201 00:15:56,240 --> 00:16:02,200 was some investigation to create a compatibility layer, so we'd effectively gout the old 202 00:16:02,279 --> 00:16:07,519 POLY and rooted through the new POLY. But because of the like the fundamental 203 00:16:07,559 --> 00:16:12,200 design problems that Microsoft tried to solve, there was no real way to bridge 204 00:16:12,200 --> 00:16:18,639 the two APIs without actually making the performance worse than it was already. I 205 00:16:18,720 --> 00:16:22,759 say worse, not as good. Yeah, that as good. And the 206 00:16:22,879 --> 00:16:26,399 new architecture involved interfaces, right, whereas we didn't really have those before, 207 00:16:27,240 --> 00:16:33,279 and that that is a fundamental difference in the way you handle approach a programming 208 00:16:33,320 --> 00:16:37,840 problem is that is that part of the reason why the compatibility. There's some 209 00:16:37,960 --> 00:16:44,000 interfaces in the design, but a lot of it is also like concrete types 210 00:16:44,600 --> 00:16:48,480 because the downsides you get to let's interface everything is that as soon as you 211 00:16:48,519 --> 00:16:52,679 want to change anything, it's a breaking change because you need to extend the 212 00:16:52,679 --> 00:16:59,000 interface, especially because we have compatibility for dot Net framework and not all versions 213 00:16:59,000 --> 00:17:03,960 of that support extension in spaces. I've forgotten the proper name for them, 214 00:17:04,319 --> 00:17:07,559 default interface ethods. That's what I'm thinking of. So, Joe, when 215 00:17:07,599 --> 00:17:11,400 you said they wanted to use stuff in the dot Net framework, you meant 216 00:17:11,880 --> 00:17:15,359 the dot Net Framework, not dot Net Core or dot Net as it stands 217 00:17:15,400 --> 00:17:19,319 today, right right, Yeah, So Polly has been backward compatible for the 218 00:17:19,359 --> 00:17:26,519 dot Net Framework for a while, ever since Core came out. We intentionally 219 00:17:26,720 --> 00:17:32,200 tried to make sure that we brought forth, you know, the capabilities to 220 00:17:32,279 --> 00:17:37,759 the dot Net framework as well, and so there as you can imagine, 221 00:17:37,759 --> 00:17:41,960 there's some long term implications. You know, that's something Martin hint hinted at 222 00:17:41,960 --> 00:17:48,240 here in keeping that compatibility. So if you wanted to just upgrade right now, 223 00:17:48,640 --> 00:17:53,039 you know, without the super high power new stuff. Are you going 224 00:17:53,079 --> 00:17:57,160 to see any performance increase or, for that matter, any performance degradation. 225 00:17:57,839 --> 00:18:03,680 So I think anything you get without doing a code upgrade and just changing your 226 00:18:03,720 --> 00:18:10,519 package references is just going to be the delta of noise of whatever you're running 227 00:18:10,519 --> 00:18:15,559 on top of. So, in essence, no, you won't get any 228 00:18:15,720 --> 00:18:22,079 significant change either way if you just pop the version numbers and do nothing else. 229 00:18:22,519 --> 00:18:26,759 And that's that's okay. I think, yeah, that's completely acceptable. 230 00:18:26,519 --> 00:18:33,160 The docs we do have, we're using GitHub io GitHub pages to generate a 231 00:18:33,200 --> 00:18:37,240 site called polydocs dot org and so you can get to those docks from the 232 00:18:37,279 --> 00:18:44,640 normal repo as well. But there is a migration document in there for okay, 233 00:18:44,680 --> 00:18:48,920 you are wanting to use the new poly dot core and take advantage of 234 00:18:48,960 --> 00:18:55,559 everything, including the performance improvements. Here are some code snippets and ways that 235 00:18:55,599 --> 00:18:59,559 you can migrate your old policies to the new strategies, which, by the 236 00:18:59,559 --> 00:19:03,759 way, is a change. Before everything was just called a policy. Now 237 00:19:03,799 --> 00:19:08,960 they're called strategies. But we're not going to change a product to straty. 238 00:19:11,880 --> 00:19:15,359 I mean, I'm not a marketing person, but I'm thinking that would not 239 00:19:15,480 --> 00:19:18,799 be very good. You can change the logo to a stratocaster. That's not 240 00:19:18,920 --> 00:19:23,079 so bad. I don't know, man, I kind of like the parrot. 241 00:19:23,759 --> 00:19:26,720 I just like the riff on the guitar when you do something right, 242 00:19:26,920 --> 00:19:32,519 but play the guitar. Yeah, you get the parrot to play the guitar. 243 00:19:32,640 --> 00:19:34,640 Now Martin's on it, he's got to figure Okay, okay, okay, 244 00:19:36,200 --> 00:19:41,599 I think we can concede. That's the strat right there. Oh man, 245 00:19:41,640 --> 00:19:45,039 that thing's only as big as your finger, I know, right, 246 00:19:45,119 --> 00:19:48,319 How do you play that? Visual gags on a podcast? There you go? 247 00:19:48,799 --> 00:19:53,519 Visual gags? Now? Wait a second. So you had a Microsoft 248 00:19:53,559 --> 00:20:00,519 employees focus full time on Polly for months? Yeah, I don't know how 249 00:20:00,599 --> 00:20:04,160 full time, but in our meetings it sounded like it was fairly full time 250 00:20:06,119 --> 00:20:11,119 is focus at least for some period of that, and he was working on 251 00:20:11,160 --> 00:20:15,359 it a lot. So I'd say, yeah, sure, because because you've 252 00:20:15,359 --> 00:20:18,799 got a regular job too, I mean both of you do. Yeah, 253 00:20:18,839 --> 00:20:22,480 So I mean how much pressure is put on you to make time for all 254 00:20:22,440 --> 00:20:26,240 of this? I think in some ways I got more of the pressure than 255 00:20:26,359 --> 00:20:32,160 Joel, because Martin Tomka is based in a check here, so I'm a 256 00:20:32,200 --> 00:20:37,680 lot more in the right time zone for code reviews than Joel, But my 257 00:20:38,039 --> 00:20:42,880 company as well is like we try to embrace open source as well because we 258 00:20:44,039 --> 00:20:48,279 use lots and lots of things. We use sure, poly x, unit, 259 00:20:48,799 --> 00:20:52,119 you name it. So my line manager was very supportive in like giving 260 00:20:52,160 --> 00:20:57,599 me time on the sort of company time to contribute to the project. So 261 00:20:57,799 --> 00:21:03,079 it wasn't all just being done in my spare time. Right. So, 262 00:21:03,160 --> 00:21:06,039 as this came down that Microsoft wanted to focus on it, that wanted to 263 00:21:06,079 --> 00:21:08,200 be an important part, you were able to share it with your leadership and 264 00:21:08,240 --> 00:21:11,880 they're like, well, this is a good thing for everybody, so do 265 00:21:11,960 --> 00:21:15,079 what you got to do. Yeah, because I think I think I don't 266 00:21:15,119 --> 00:21:19,279 have any concrete numbers, but I imagine poly is right up there in terms 267 00:21:19,319 --> 00:21:25,200 of popularity within our internal Gethub enterprise instance of what we use in our own 268 00:21:25,200 --> 00:21:30,480 applications to power our services. M Yeah, and that's I mean, this 269 00:21:30,519 --> 00:21:33,599 is a debate, a discussion we've had around open source for a while. 270 00:21:33,640 --> 00:21:40,319 It's like what happens when an employee is assigned to your volunteer driven project, 271 00:21:41,000 --> 00:21:44,200 you know. So it feels to me like this is a good news story, 272 00:21:44,240 --> 00:21:48,039 but it sounds like he was a very collaborative person too, like it 273 00:21:48,119 --> 00:21:52,200 was easy to get in and chat through things and keep everybody on board one 274 00:21:52,279 --> 00:21:56,119 hundred percent. And that was one thing that when when Emo first brought this 275 00:21:56,559 --> 00:22:02,079 to me as a potential thing, he was very sensitive about the fact that 276 00:22:02,119 --> 00:22:07,720 this is an open source, community driven project and he did not want this 277 00:22:07,799 --> 00:22:11,119 to be to feel like it's a takeover. He didn't want to feel like 278 00:22:11,440 --> 00:22:18,200 we're just kind of on the sidelines observing from the outside, but rather being 279 00:22:18,319 --> 00:22:22,720 a part of the whole process and making sure that we are still involved in 280 00:22:22,799 --> 00:22:26,039 decision making as far as where it's going, you know, all the different 281 00:22:26,079 --> 00:22:30,079 design decisions and stuff. So because they had the alternative was that they write 282 00:22:30,119 --> 00:22:33,799 something themselves, right right, I think they could have done that and to 283 00:22:33,799 --> 00:22:37,039 say, hey, you know what they could have Yeah, this is a 284 00:22:37,039 --> 00:22:40,640 special case for us because it's cloud scale and we're going to do something totally 285 00:22:40,640 --> 00:22:42,880 different as opposed to what they did do. I'd like to talk some more 286 00:22:42,880 --> 00:22:48,519 about the whole open source thing after the break, but before the break, 287 00:22:48,559 --> 00:22:53,240 we got to get back to the outcome, like what were the performance gains? 288 00:22:53,279 --> 00:22:59,880 Do you have any metrics in terms of scalability and performance gains of poly 289 00:23:00,359 --> 00:23:04,640 eight. We do have as part of the build process benchmarks that run every 290 00:23:04,680 --> 00:23:10,400 time, so we get updated benchmarks and that way we can make sure we're 291 00:23:10,480 --> 00:23:15,000 not degrading in any way as we make changes. Okay, so I've just 292 00:23:15,240 --> 00:23:21,039 randomly looked at one of the benchmark results that we've got checked into the repository 293 00:23:21,039 --> 00:23:23,960 at the moment from the last time they were run, and as a as 294 00:23:25,000 --> 00:23:30,119 an example for the timeout policy in version seven, this benchmark was four hundred 295 00:23:30,119 --> 00:23:36,319 and thirty seven nanoseconds and seven hundred and twenty eight bytes allocated, and then 296 00:23:36,519 --> 00:23:41,359 polyv eight's equivalent is three hundred and forty nine nanoseconds, So that's a twenty 297 00:23:41,400 --> 00:23:47,640 percent improvement and zero allocations. So wow, one hundred slash infinite. Yeah, 298 00:23:47,720 --> 00:23:51,319 congratulations, that's fantastic. But that was the goal was to get to 299 00:23:51,400 --> 00:23:55,880 zero allocations. That wash. Yeah. I don't think we ever put it 300 00:23:55,920 --> 00:24:00,599 in stone as a like it must be zero, forever be zero. No, 301 00:24:00,799 --> 00:24:03,519 but it's like, can we get there? It's an interesting thing, 302 00:24:03,640 --> 00:24:07,359 Like it seems bizarre to me that you've got to zero allocations, Like how 303 00:24:07,400 --> 00:24:10,079 do you make that work? Well? I can tell you one way. 304 00:24:10,319 --> 00:24:15,000 In wherever there's a task, there is now a value task, which is 305 00:24:15,319 --> 00:24:21,079 a value type rather than a reference type. It's like most of the API 306 00:24:21,319 --> 00:24:25,319 most of the breaking changes to the API surface were changing to value task. 307 00:24:25,720 --> 00:24:30,759 And there's also various changes that are in support of you being able to like 308 00:24:30,000 --> 00:24:37,160 use static landers for like the code you want poll to call for you, 309 00:24:37,680 --> 00:24:41,440 so you can still code it the way with the old poly but you don't 310 00:24:41,440 --> 00:24:47,119 get as much improvement. But then if you really want to shave things down, 311 00:24:48,039 --> 00:24:53,200 like there's slight readability degradation in some cases, but if you really want 312 00:24:53,200 --> 00:24:57,000 that performance, you can sort of switch into like a slightly different mode and 313 00:24:57,079 --> 00:25:02,599 then you'd lose all the allocation from the closures as well, and then you 314 00:25:02,680 --> 00:25:07,880 get even even more memory allocations. Dropped on the floor, not dropped on 315 00:25:07,920 --> 00:25:12,680 the floor, you know what I mean, M shaved. Well, it 316 00:25:12,759 --> 00:25:18,279 speaks to me of this code as an open source project is an example of 317 00:25:18,519 --> 00:25:22,519 how to build really high performance cloud code. Then, like zero allocation code 318 00:25:22,599 --> 00:25:26,079 is kind of a big deal. Yeah, and I guess as well. 319 00:25:26,160 --> 00:25:30,160 It's one of those doesn't always work for everyone. Is like if you've got 320 00:25:30,160 --> 00:25:34,839 something that's used at the scale Polly is like when you multiply up those savings 321 00:25:36,119 --> 00:25:38,559 to everyone who uses it, If everyone adopts the new stuff, that's quite 322 00:25:38,559 --> 00:25:45,119 a big chunk into like CO two emissions and things like that. Whereas if 323 00:25:45,160 --> 00:25:48,480 you've got a project that you maintain yourself, it's got like kind of a 324 00:25:48,519 --> 00:25:56,200 couple of thousand downloads, it's probably not worth the effort putting all of this 325 00:25:56,359 --> 00:26:00,559 engineering into it to just like save a few CP cycles every other month. 326 00:26:00,440 --> 00:26:03,359 Yeah, I was. I was going to mention the same thing. You 327 00:26:03,400 --> 00:26:07,799 know, it's sort of like green code in a way, because if you 328 00:26:07,799 --> 00:26:11,400 look at the scale overall, you know, saving energy and cycles and all 329 00:26:11,440 --> 00:26:17,240 that kind of stuff, it's it's worthwhile at certain levels of scale. But 330 00:26:17,400 --> 00:26:21,720 again that's not everybody you got to get there for. To make sense, 331 00:26:21,880 --> 00:26:23,000 you don't want to build that way off the bat. But was that what 332 00:26:23,039 --> 00:26:26,839 they came to you with. I thought they came to you with performance and 333 00:26:26,880 --> 00:26:30,799 resource consumption, not so much specifically, Hey, we're trying to cut the 334 00:26:30,839 --> 00:26:33,599 CO two consuming Oh no, not at all, not at all. That's 335 00:26:33,680 --> 00:26:37,799 just a nice spike product of it. Yeah. Yeah, I think part 336 00:26:37,839 --> 00:26:42,200 of the use case for all the savings to not speak for Microsoft, but 337 00:26:42,400 --> 00:26:47,599 try and badly remember what they might have said at the time was with all 338 00:26:47,680 --> 00:26:52,240 the pandemic growth in the cloud and things like teams, like, it was 339 00:26:52,319 --> 00:26:56,640 costing them a lot more to run the service because they needed more stuff. 340 00:26:56,279 --> 00:27:02,119 But they didn't want to pay the same percentage extra of how much stuff they 341 00:27:02,119 --> 00:27:06,359 had for how much traffic they had. So it was all about how can 342 00:27:06,400 --> 00:27:11,599 we run more on less? Right, It's certainly been a theme over on 343 00:27:11,599 --> 00:27:15,759 the sissipmin world and run as Radio about how to do more with less, 344 00:27:15,400 --> 00:27:18,839 and some of it has been conversations about moving up the stack, like getting 345 00:27:18,880 --> 00:27:23,599 off the VMS and into platform and they were just consuming less resources you get 346 00:27:23,599 --> 00:27:27,160 the same workloads done. And this is at the developer level saying, I 347 00:27:27,160 --> 00:27:33,039 mean optimizing code, you're saving nanoseconds, which seems insane like that that would 348 00:27:33,079 --> 00:27:41,319 matter until you think about millions running simultaneously. Yeah, if someone's got like 349 00:27:41,559 --> 00:27:44,839 a tiny little command line tool where they had polly in just to do a 350 00:27:44,880 --> 00:27:48,799 few retries, yeah, like they're not they're not going to notice this kind 351 00:27:48,839 --> 00:27:52,079 of thing. But when you got yeah, but when you've got like a 352 00:27:52,160 --> 00:27:56,920 multi tenant application used by thousands of people at the same time. It all 353 00:27:56,920 --> 00:28:00,160 starts to add up. So start to add up is they're looking at this 354 00:28:00,319 --> 00:28:04,440 large statistical model and saying, Okay, well this is showing up in the 355 00:28:04,519 --> 00:28:08,920 graph. Now is a meaningful level of consumption? Yeah, it's fascinating. 356 00:28:10,359 --> 00:28:14,759 Hey, guys, hold that thought while we pause for these very important messages 357 00:28:18,039 --> 00:28:21,920 and we're back. You're listening to Dot and Rocks. I'm Carl Franklin. 358 00:28:21,960 --> 00:28:26,680 That's my friend Richard Campbell. Hey, and that's Joel Hewen and Martin Costello, 359 00:28:26,079 --> 00:28:30,279 and we're talking about poly version eight, which dropped, oh what a 360 00:28:30,359 --> 00:28:34,319 month or two ago, Yeah, end of September, end of September, 361 00:28:36,039 --> 00:28:41,279 and just sort of talking about the whole open sourceiness of it. As Richard 362 00:28:41,359 --> 00:28:48,240 said, it's sort of a model project for how to collaborate with a bigger 363 00:28:48,319 --> 00:28:52,920 company. I mean, Microsoft was very very cooperative, mostly I think because 364 00:28:52,920 --> 00:28:56,640 they were incentivized too, right. I mean they're running it in Azure, 365 00:28:56,720 --> 00:29:03,960 and they're running it in teams and in all these big scale things sites, 366 00:29:03,759 --> 00:29:11,200 so they had a reason to do that. Other projects may not be so 367 00:29:11,319 --> 00:29:15,680 lucky. Is to have a big corporate sponsor that has invested interest in their 368 00:29:15,720 --> 00:29:22,480 project. Yeah, that's very true, And yeah, I would say that 369 00:29:22,480 --> 00:29:26,759 that was what impressed me a lot. This This is not the first time 370 00:29:26,799 --> 00:29:33,920 we've collaborated with Microsoft on this. You mentioned it that in the past we 371 00:29:33,039 --> 00:29:38,039 worked with Glenn Condron, and I remember Ryan Noak, one of the developers 372 00:29:38,039 --> 00:29:41,640 on the team. Actually, you guys know Ryan. He's worked on sure 373 00:29:41,880 --> 00:29:47,440 on the Humanitarian Toolbox and other things. But that was when we brought in 374 00:29:47,599 --> 00:29:56,119 the the Microsoft Http Resiliency Extension right and and which which made it a very 375 00:29:56,160 --> 00:30:00,799 simple way to take the hdt B client factor and then be able to add 376 00:30:00,960 --> 00:30:08,920 any number of at that time policies, poly policies for retrying those HDP calls 377 00:30:08,960 --> 00:30:15,240 on the clients that get created from that. And so at that point even 378 00:30:15,440 --> 00:30:22,720 I think they were very conscientious about I remember specifically one of the things that 379 00:30:22,759 --> 00:30:27,559 Glenn said, Hey, we're thinking of two things. One you guys just 380 00:30:27,640 --> 00:30:32,200 got added to the dot net Foundation at that time, and number two, 381 00:30:32,839 --> 00:30:37,119 if we use this and then Polly becomes a dependency of this other library that 382 00:30:37,119 --> 00:30:41,359 we're building that millions of people are going to use. We know that some 383 00:30:41,839 --> 00:30:48,559 open source maintainers are very concerned about a huge uptick in having to resolve issues 384 00:30:48,599 --> 00:30:53,480 that the community submits and having to keep up with that, and that frankly 385 00:30:53,519 --> 00:31:00,279 scares a lot of people who just this is a side thing. They don't 386 00:31:00,279 --> 00:31:03,559 want to involve too much time man. And so even at that point they 387 00:31:03,559 --> 00:31:10,200 were very conscientious about that, and it's something we discussed and it ultimately didn't 388 00:31:10,200 --> 00:31:14,559 become a big issue. We never really saw huge uptick in issues, and 389 00:31:14,920 --> 00:31:19,559 that library had its own repo anyway where they can log that. But so 390 00:31:19,599 --> 00:31:23,599 I would say that's this is twice now that I think the experience has been 391 00:31:23,640 --> 00:31:29,880 good with Microsoft. I can't speak for other organizations as far as open source 392 00:31:29,920 --> 00:31:33,039 projects go like this, but I would also say, you guys are interacting 393 00:31:33,079 --> 00:31:37,839 with the dot net dev team who are working get hub every day like that 394 00:31:37,960 --> 00:31:41,200 is that is their normal workspace, and I think they've learned the culture and 395 00:31:41,279 --> 00:31:45,480 work in the culture as much as they've also affected the culture. That's fair, 396 00:31:47,000 --> 00:31:48,960 but it's also good to see to you know, this has been an 397 00:31:48,960 --> 00:31:53,519 ongoing conversation for the past few years about can you have a good experience with 398 00:31:53,559 --> 00:31:57,039 this, and you guys are saying yes, it's been years of good experience 399 00:31:59,599 --> 00:32:04,319 indirectly as well. It's like the previous engagement was how I ended up getting 400 00:32:04,359 --> 00:32:08,599 involved with poly because I was sort of like interested in what was going on 401 00:32:08,640 --> 00:32:14,160 with the htt B client factory stuff, and I think Dylan was as well, 402 00:32:14,319 --> 00:32:19,200 and we sort of interacted in the dot net repos through that stuff. 403 00:32:19,200 --> 00:32:22,440 And then I think it was through that that sort of Dylan became aware of 404 00:32:22,480 --> 00:32:28,079 me and being interested in Polly, and then I think sometime later that was 405 00:32:28,119 --> 00:32:29,839 when he approached me. He was like, Hey, do you want to 406 00:32:29,880 --> 00:32:36,240 help maintain poly? Yeah, you want to make your life more complicated? 407 00:32:38,720 --> 00:32:43,559 Guys? What is I know that we made a pledge when we started dot 408 00:32:43,680 --> 00:32:47,960 net Rocks not to actually read code on the on the audio podcast, right, 409 00:32:47,960 --> 00:32:51,799 We're not going to recode to you, but give us a sense of 410 00:32:52,480 --> 00:32:58,359 what the learning curve is like when if we have if we're using POLYB seven 411 00:32:58,480 --> 00:33:04,079 or earlier, and now we want to use the high performance stuff. So 412 00:33:05,440 --> 00:33:10,920 one example of how little work it could be is if you're using the HDP 413 00:33:12,000 --> 00:33:16,400 Client Factory integration, you can swap it out for the new one and you 414 00:33:16,440 --> 00:33:21,880 can possibly even delete code. Because I spent an hour this afternoon taking out 415 00:33:21,920 --> 00:33:25,079 the old one putting in the new one, and I and my GIT diffs 416 00:33:25,119 --> 00:33:30,240 were mostly lots of red, not much green. No, okay, and 417 00:33:30,680 --> 00:33:35,480 you just have to swap in like assuming you want to use all the defaults, 418 00:33:35,519 --> 00:33:38,359 you can like swap a one extension method with one name form with another 419 00:33:38,440 --> 00:33:45,000 name and then just change a few cause lights. So we're talking about names, 420 00:33:45,119 --> 00:33:50,480 not necessarily like the patterns are still pretty much the same. Yes, 421 00:33:50,640 --> 00:33:55,480 I think the thing that's the biggest change is configuring it, So setting up 422 00:33:55,519 --> 00:34:00,319 what the policies are that's got the biggest change to it. But once you've 423 00:34:00,400 --> 00:34:07,039 got your policy, which is now a resilient strategy, then the core site 424 00:34:07,079 --> 00:34:12,119 where you actually use them to do something interesting, the changes you have to 425 00:34:12,119 --> 00:34:15,239 do at those sites are minimal. Okay. Wasn't this always the claim to 426 00:34:15,239 --> 00:34:20,280 fame for Polly as this idea of I set up a bunch of recovery strategies 427 00:34:20,360 --> 00:34:22,719 or policies, and then you just apply them to the things that matter. 428 00:34:23,440 --> 00:34:27,719 So you're not writing that boilerplate over and over and over again, but you 429 00:34:27,800 --> 00:34:31,599 might be writing the response differently, Like you know what you're going to tell 430 00:34:31,599 --> 00:34:36,760 the user happened if something happens and you finally have to fail back. That 431 00:34:36,840 --> 00:34:43,320 message might be different, or the code that you write in the policy is 432 00:34:43,519 --> 00:34:47,519 probably going to change because your URL may change. But things like that. 433 00:34:49,199 --> 00:34:52,960 Yes, the real work is done in the policy and now in the resilience 434 00:34:52,000 --> 00:34:58,000 strategy. So it's really good to hear that that pattern doesn't really change all 435 00:34:58,039 --> 00:35:01,199 that much. But what is it about the configuration that's so different now? 436 00:35:01,639 --> 00:35:07,639 So I would say the biggest change, which Joel alluded to earlier, was 437 00:35:07,880 --> 00:35:12,159 we had all these overloads and adding another one, adding another, and it 438 00:35:12,199 --> 00:35:14,960 got to the point where I don't know about Joel, but I was any 439 00:35:14,960 --> 00:35:16,719 time anyone opened to PR went, oh, I'm just adding another overload, 440 00:35:16,800 --> 00:35:22,840 but like I'm a bit scared to add that break it. So how many 441 00:35:22,880 --> 00:35:27,519 overloads are too many? So what we tried to do with the eight was 442 00:35:28,519 --> 00:35:32,519 like having a configuration object, So you have an object of options, and 443 00:35:32,559 --> 00:35:36,480 if there's a new option comes along, we just add a new property to 444 00:35:36,519 --> 00:35:42,039 that objection. So there's a couple of convenience overloads in some places, so 445 00:35:42,079 --> 00:35:45,840 like retry as you can just do too well, whatever the API is, 446 00:35:45,880 --> 00:35:49,280 I don't have the doctor in front of me right now. But In most 447 00:35:49,360 --> 00:35:52,519 cases you have an object and you just set whatever it is you need on 448 00:35:52,519 --> 00:35:57,480 the object. So the theory is that we can keep extending it without having 449 00:35:57,519 --> 00:36:01,440 to make breaking changes now, which isn't necessarily the case with V seven low 450 00:36:01,519 --> 00:36:09,400 the JSON file phasers on stunt kirk out we come from. I would say, 451 00:36:09,519 --> 00:36:13,400 you know, for some people, they were using some features like the 452 00:36:13,440 --> 00:36:20,280 policy wrap was very common, and that was sort of like a nesting egg 453 00:36:20,639 --> 00:36:24,880 approach where you take a policy and then you nest another one and another one 454 00:36:24,920 --> 00:36:30,480 and another one, and then it would apply those policies backwards when you go 455 00:36:30,599 --> 00:36:36,199 to execute it. And so if you're using that, then you're already going 456 00:36:36,239 --> 00:36:43,159 to be pretty familiar with the resilience pipeline, which that's how we're just setting 457 00:36:43,159 --> 00:36:49,639 these strategies now, is through that pipeline, and so it gives you still 458 00:36:49,679 --> 00:36:55,679 a nice fluent way to be able to add additional strategies layer them in there, 459 00:36:57,159 --> 00:37:00,320 right, and so there's there's a lot of similarity as for as that 460 00:37:00,440 --> 00:37:05,320 goes. And then we also had the concept of the registry before, and 461 00:37:05,920 --> 00:37:12,119 one thing that you could do is the you can have a strategy configuration by 462 00:37:12,199 --> 00:37:15,679 name and say you're loading that from some sort of you know, app can 463 00:37:15,719 --> 00:37:22,400 figure or something like that. You can set an option to automatically reload the 464 00:37:22,440 --> 00:37:27,760 policy if the configuration changes, right, So then that way, within a 465 00:37:27,800 --> 00:37:32,559 live running environment, you could tweak the configuration, apply it in your configuration 466 00:37:32,760 --> 00:37:37,639 service or settings wherever that is, and then it'll reload that policy for it 467 00:37:37,719 --> 00:37:43,719 to pick up those changes without having to deploy new code. Nice. Nice, 468 00:37:43,840 --> 00:37:47,400 Yeah, that's something we used at my workplace. But because previously we're 469 00:37:47,480 --> 00:37:52,039 using v seven, we had to hand code all of the layers to sit 470 00:37:52,119 --> 00:37:55,840 on top of poly for the reloads to actually work, and we'd effectively have 471 00:37:55,920 --> 00:38:00,039 to throw away all of the policies whenever the configuration and change and rebuild it 472 00:38:00,079 --> 00:38:04,760 all from scratch. So you could change home when you retrays or something like 473 00:38:04,800 --> 00:38:08,320 that. But with polyv eight, most of that's they built into it. 474 00:38:08,599 --> 00:38:15,760 So again there's a first class citizen within one of the surfaces. Where I 475 00:38:15,800 --> 00:38:19,159 did the upgrade, most of it was taking a hatchet to it and throwing 476 00:38:19,199 --> 00:38:23,000 code away, right, always fun. I love throwing code away. What 477 00:38:23,079 --> 00:38:29,840 does the dot net eight uh landscape look like? I mean, Microsoft is 478 00:38:30,119 --> 00:38:34,320 still using the HDP client factory. So I imagine that moves over to dot 479 00:38:34,360 --> 00:38:38,559 net eight without any breaking changes, yep. And that's where you want to 480 00:38:38,760 --> 00:38:45,880 use that new Microsoft dot Extensions HTTP dot Resilience library. Yeah, right, 481 00:38:45,960 --> 00:38:52,199 where the one that we collaborated with years ago is the Microsoft Extensions HTTP POLY 482 00:38:52,639 --> 00:38:58,719 and so it's just swap out that old one for this new library that's built 483 00:38:58,760 --> 00:39:02,280 on top of POLY. You're still using the HDP client factory is the best 484 00:39:02,320 --> 00:39:07,159 practice for managing the life cycles of those clients. And again I think Martin 485 00:39:07,199 --> 00:39:13,159 said this, You're not going to get any performance benefit or degradation either way 486 00:39:13,280 --> 00:39:17,760 if you just swap it out. So if you switch to the new resilience 487 00:39:17,800 --> 00:39:23,639 package, you will because the internals that Microsoft are written in the dot Neet 488 00:39:23,719 --> 00:39:28,960 Extensions repository where all of these libraries are coded. They're built on top of 489 00:39:29,000 --> 00:39:32,960 our new primitives and wrap into the HDDB client, whereas the old package uses 490 00:39:34,000 --> 00:39:38,360 the old primitives. So Microsoft have effectively done the work for you to do 491 00:39:38,480 --> 00:39:42,559 the migration. So at a high level, you're just going, hey, 492 00:39:42,679 --> 00:39:47,039 HDDB client, make it do resilience with poly, okay, and one package 493 00:39:47,079 --> 00:39:50,280 does it one way, and one package does it the other way, and 494 00:39:50,320 --> 00:39:52,960 the new one is the more performance one. So but there is an any 495 00:39:52,960 --> 00:39:55,199 breaking change. You just changed the package name and you're after the races, 496 00:39:55,599 --> 00:40:00,280 so you need to make a few co changes like new method name games. 497 00:40:00,119 --> 00:40:07,239 But also the more you have customized things, the more work it will be 498 00:40:07,599 --> 00:40:10,960 to migrate. If you've got some really custom stuff going on, you'll have 499 00:40:12,039 --> 00:40:14,639 to read the migration guide and take that into a vex, Whereas if you 500 00:40:14,639 --> 00:40:17,599 were just doing a simple just add some retries to my services. In case 501 00:40:17,800 --> 00:40:24,239 weird stuff happens, the changes should be relatively minimal. Weird stuff never happens. 502 00:40:24,519 --> 00:40:29,320 Yeah, and if you're using dependency injection to set all that up, 503 00:40:29,800 --> 00:40:32,719 that should hopefully minimize the number of places you have to make changes. Yeah. 504 00:40:32,760 --> 00:40:37,079 Of course I was looking at that because I'm planning on swapping out those 505 00:40:37,079 --> 00:40:40,840 two libraries and a big project of mine today, so I expect it to 506 00:40:40,880 --> 00:40:45,719 be smooth cool. Part of the reason why with some of the changes I 507 00:40:45,800 --> 00:40:51,679 made today had so many deletes was because the old way of doing it had 508 00:40:51,679 --> 00:40:54,360 the code, had the infrastructure code for you to go. If I have 509 00:40:54,440 --> 00:40:58,960 a poly registry, there's some registries in it, put it in the HTTP 510 00:40:59,079 --> 00:41:02,800 request, but you have to tell the application what to put in the registry. 511 00:41:02,800 --> 00:41:06,960 We're not going to do that for you. But the new library has 512 00:41:07,000 --> 00:41:10,079 a method. It's called something like add standard resilience or something like that, 513 00:41:10,320 --> 00:41:16,320 and it has like your common or Garden ninety percent case sensible defaults built into 514 00:41:16,360 --> 00:41:20,920 it, so it automatically does retrise, it automatically does circuit breakers, it 515 00:41:20,960 --> 00:41:25,400 automatically takes a time out into account. So if you don't know much about 516 00:41:27,039 --> 00:41:30,679 having resilience at all, if it maybe if you write a new application which 517 00:41:30,760 --> 00:41:34,880 doesn't have anything in it, with like one extension method added to your HTTB 518 00:41:34,920 --> 00:41:39,880 client setup, you get sensible defaults for free. That's a complete pipeline stuff 519 00:41:39,920 --> 00:41:44,239 you used to have to assemble. Yeah, so like most of the stuff 520 00:41:44,280 --> 00:41:49,559 I deleted today was all my manual curation of retry one second, then two 521 00:41:49,599 --> 00:41:52,159 second, and five seconds. Now that's all baked in, And I just 522 00:41:52,199 --> 00:41:59,360 deleted all black code and went for my hobby stuff. I'm not leading engineering 523 00:41:59,440 --> 00:42:01,920 enough to be you find tweaking everything, so I just do the defaults. 524 00:42:01,639 --> 00:42:05,880 It's fine, will be better. What I like about that is that most 525 00:42:05,880 --> 00:42:09,119 people don't know what policies to make. Most people don't know, Oh, 526 00:42:09,159 --> 00:42:13,400 should I do an exponential backup? Nobody's going to say, well, what 527 00:42:13,440 --> 00:42:16,400 are you calling? Nobody knows what you know. That doesn't matter. So 528 00:42:16,480 --> 00:42:21,519 I love the idea of sensible defaults falling into the pit of success and all 529 00:42:21,559 --> 00:42:25,000 that. Yeah, I take the cloud guys, like the pit of success 530 00:42:25,039 --> 00:42:30,360 thing with seven I thought that was always tricky, was okay, I want 531 00:42:30,360 --> 00:42:35,400 to do circuit breakers and retries and timeouts, putting them in the right order. 532 00:42:36,000 --> 00:42:39,440 Yeah, so you're not like circuit breaking over your retries or the other 533 00:42:39,480 --> 00:42:42,960 way around it. Like I always have to look at the documentation to get 534 00:42:43,000 --> 00:42:46,280 them in the right order, whereas with the sensible defaults, someone else solved 535 00:42:46,280 --> 00:42:50,079 that problem for you. They'll be in the right order. Is that a 536 00:42:50,280 --> 00:42:53,159 sensible defaults property equals true kind of thing? Or is it just done by 537 00:42:53,199 --> 00:42:55,960 default? You don't even have to do that. You don't even have to 538 00:42:55,960 --> 00:43:04,760 do that, you just set fut to false. Hey I noticed the docs 539 00:43:04,760 --> 00:43:08,760 here you have a section on chaos engineering. I'm delighted. Yes, Yeah, 540 00:43:08,800 --> 00:43:15,000 so that was semi Simmy was one of our poly Contribe projects that came 541 00:43:15,039 --> 00:43:21,920 about a few years ago, and that was by Giovanni and what we're doing. 542 00:43:22,400 --> 00:43:25,639 I think the next version of Polly eight point two, I believe we're 543 00:43:25,679 --> 00:43:31,800 going to have that fully integrated into the poly core. So your chaos engineering 544 00:43:31,880 --> 00:43:37,000 will be a foundational piece of Polly. You don't have to pull in an 545 00:43:37,079 --> 00:43:45,119 external dependency now. It's going to be developed alongside Polly itself going forward. 546 00:43:45,360 --> 00:43:49,559 So that's the perfect place to put the chaos monkey. It's like, hey, 547 00:43:49,599 --> 00:43:53,280 make this fail randomly. Yeah, it's great. I just like the 548 00:43:53,320 --> 00:43:59,960 idea of chaos as a policy. I love everything about that chaos is out 549 00:44:00,159 --> 00:44:02,800 policy, this meaning will come to order. I would like to discuss our 550 00:44:02,880 --> 00:44:08,519 chaos policy. This is an old it's an old reference, but it reminds 551 00:44:08,519 --> 00:44:12,519 me of get smart. You have control. There's the good guys, the 552 00:44:12,639 --> 00:44:21,079 chaos, the bad guys of course, yes, yes, the old chaos. 553 00:44:24,519 --> 00:44:30,519 So there's one other thing, another goal that Microsoft had going into this 554 00:44:30,599 --> 00:44:35,079 to meet their needs, but I think benefits the all of us is now 555 00:44:35,239 --> 00:44:40,559 there's built in telemetry and metrics that is part of Polly. So uh, 556 00:44:40,679 --> 00:44:46,159 this is very important to say you've got maybe a large micro services sort of 557 00:44:46,199 --> 00:44:53,280 project, which means you've got all these deployed services deployed everywhere, each of 558 00:44:53,280 --> 00:44:59,679 them are implementing strategies hopefully, and you need to be able to make sense 559 00:44:59,679 --> 00:45:04,519 of a Okay, where am I seeing failures? How often are these failures 560 00:45:04,559 --> 00:45:08,079 happening? What are the metrics involved? So then I can try to tweak 561 00:45:08,159 --> 00:45:13,440 these settings as Martin does, you know, within his project, and the 562 00:45:14,079 --> 00:45:17,280 built in telemetry and metrics components will help you do that. And there's a 563 00:45:17,320 --> 00:45:22,119 whole document on that now too. Wow. It's certainly one of the challenges 564 00:45:22,639 --> 00:45:28,360 on the operations side to discern the difference between a successful retry and a failed 565 00:45:28,360 --> 00:45:31,000 retry, Like if they're just log entries, you see all these failures, 566 00:45:31,000 --> 00:45:35,719 but he's like did it work or not? Like how do you associate? 567 00:45:35,760 --> 00:45:38,360 And then eventually it succeeded in delivering the package and everything was fine. But 568 00:45:38,960 --> 00:45:43,440 you know, just being able to combine that down well and say, okay, 569 00:45:43,440 --> 00:45:46,599 well this was this with multiple retries was a success. It's also one 570 00:45:46,639 --> 00:45:51,400 of those things, like Joe mentions the telemetry, it's again, it's a 571 00:45:51,440 --> 00:45:55,320 thing we had in our applications custom written to see when our circuit breaker is 572 00:45:55,400 --> 00:46:00,599 firing, when our retri is happening all deleted again. Yeah, because now 573 00:46:00,639 --> 00:46:04,880 there's a set of policy around all of that, and I presume integrates with 574 00:46:04,920 --> 00:46:10,920 open telemetry, works with all the Azure bits monitor and such. It will 575 00:46:12,840 --> 00:46:19,320 by virtue of it's built on top of the like the the primitives in the 576 00:46:19,320 --> 00:46:25,480 framework, and it's event source. Maybe not that one that there's a there's 577 00:46:25,480 --> 00:46:30,039 a type baked into it. I've forgotten the name of. Now that you've 578 00:46:30,079 --> 00:46:34,159 got the lagger the lagger factory. Yeah, so I think it uses the 579 00:46:34,239 --> 00:46:37,280 logger to do to like create the events. Then there's something cooked into the 580 00:46:37,360 --> 00:46:43,360 logger which then hooks into the I think it's the event source. And then 581 00:46:43,440 --> 00:46:49,079 because dot net is now instrumented, if you're then using open telemetry, it 582 00:46:49,119 --> 00:46:57,239 will indirectly go through into open telemetry without so probably doesn't directly integrate with open 583 00:46:57,280 --> 00:47:02,920 telemetry, but it does indirectly through Why he's integrated into Okay, it's important 584 00:47:02,960 --> 00:47:06,440 to know because it means we don't have another place to look. It feeds 585 00:47:06,440 --> 00:47:12,480 into their existing instrumentation. Not that I know anything about that. Well, 586 00:47:12,519 --> 00:47:15,800 guys, I mean, congratulations, this is a great story, an exciting 587 00:47:15,840 --> 00:47:21,880 product, very much good to finally get it out after ten months roughly. 588 00:47:22,000 --> 00:47:24,920 Wow, yeah, something like that. Ten months. It was definitely a 589 00:47:24,960 --> 00:47:30,840 whole good question. And there's a bunch of new as you mentioned, well, 590 00:47:30,880 --> 00:47:35,280 there's a bunch of resources that we're going to go to, but polydocks 591 00:47:35,320 --> 00:47:37,599 dot org is probably where you should start, is that right? Yeah? 592 00:47:37,679 --> 00:47:43,039 Yeah, And also give a give a little shout out to Peter Sala, 593 00:47:43,440 --> 00:47:49,119 who's done so many poor requests to make the polydocumentation better. It's like, 594 00:47:49,199 --> 00:47:52,760 yes, and I've forgotten the name of who it was now I'll see if 595 00:47:52,800 --> 00:47:55,280 I can quickly look it up. But someone set up the polydoc site for 596 00:47:55,400 --> 00:47:59,920 us, and then we wrote a bit of documentation to fill it in, 597 00:48:00,239 --> 00:48:02,320 and then Peter has added more and more and more on top of it, 598 00:48:02,360 --> 00:48:07,480 so it's even better. One obsessed individual. Yeah, no, it's great. 599 00:48:07,559 --> 00:48:14,440 He also added a lot of patterns and anti patterns within the documentation, 600 00:48:14,639 --> 00:48:22,039 which is excellent, and he also updated the poly samples project to use all 601 00:48:22,119 --> 00:48:25,480 the new V eight goodness as well. Y I looked at the name it 602 00:48:25,519 --> 00:48:30,519 was Adam Nova built the new docs site template for us. Oh yes, 603 00:48:30,840 --> 00:48:36,880 and Martin, you also have a poly sandbox that you published. What's that 604 00:48:36,920 --> 00:48:42,360 all about? So I mentioned a couple of times we have internal applications using 605 00:48:42,360 --> 00:48:46,199 poly and doing things like metrics and configure it dynamic configuration and things like that. 606 00:48:46,559 --> 00:48:52,480 So I took all of the poly scaffolding out of an internal application and 607 00:48:52,519 --> 00:48:58,400 put it into a public application. So we had something that wasn't proprietary that 608 00:48:58,519 --> 00:49:04,039 I couldn't share in the open with the other Martins and Joel. So it 609 00:49:04,119 --> 00:49:07,079 sort of it took the poly relevant bits out, just put some boring, 610 00:49:07,280 --> 00:49:10,440 you know, to do app type end points on top of it, and 611 00:49:10,480 --> 00:49:15,000 then went right, we do this sort of thing with poly We want these 612 00:49:15,119 --> 00:49:21,800 use cases to work with polyvas and that's where things like the configuration reload. 613 00:49:22,119 --> 00:49:25,239 We tested that that worked properly. And it was also like we had another 614 00:49:25,280 --> 00:49:31,960 feature where if we knew our system was down for some reason, like poly 615 00:49:32,119 --> 00:49:36,679 doing the circuit breaking the retries can create a lot of noise in like opening 616 00:49:36,679 --> 00:49:38,199 the circuits, closing the circuits again and again again. It's like, we 617 00:49:38,280 --> 00:49:44,599 know it's broken stuff. So we had functionality where you could just like preemptively 618 00:49:44,880 --> 00:49:47,800 just flip the switch and turn it off. Is like it's sort of started 619 00:49:47,920 --> 00:49:52,000 broken just so its short circuits immediately, and that was a feature that didn't 620 00:49:52,079 --> 00:49:58,400 used to be in poly and sort of brought through through just using the sandbox 621 00:49:58,440 --> 00:50:04,840 app. Nice. Yeah, and some of that. There's a new strategy 622 00:50:04,880 --> 00:50:12,320 called hedging, and that sort of replaces the bulkhead strategy or policy that we 623 00:50:12,440 --> 00:50:19,559 used to have, right, and so hedging it can make several requests the 624 00:50:19,559 --> 00:50:22,159 same thing at the same time. You could do it in parallel, you 625 00:50:22,159 --> 00:50:24,800 could do it in cereal or whatever, and it will take the fastest response. 626 00:50:25,639 --> 00:50:30,400 You could also do things like put a rate limitter on and that's also 627 00:50:30,519 --> 00:50:36,639 new. Rate limitter will allow you to say, Okay, I want to 628 00:50:37,079 --> 00:50:42,719 limit this to one hundred calls to this database, you know, per minute. 629 00:50:43,119 --> 00:50:45,519 You know, maybe it's a very small database and you know it can't 630 00:50:45,559 --> 00:50:49,320 handle more than that, and so you don't want to flood it, and 631 00:50:49,400 --> 00:50:52,679 so you can add that just says if that's the only thing you do, 632 00:50:52,760 --> 00:50:55,280 if you don't have any other strategies and you just want to rate limit stuff, 633 00:50:55,599 --> 00:51:00,480 you could add that on, or you could layer on retries and circuit 634 00:51:00,480 --> 00:51:02,599 breakers and other things too. Wow. Yeah, I could also see I'm 635 00:51:02,639 --> 00:51:07,719 calling an external API that has rules around how hard I'm allowed to hammer it, 636 00:51:07,400 --> 00:51:10,480 and I don't want to get locked out, so I'll put the rate 637 00:51:12,440 --> 00:51:15,800 limit. And within that strategy too, you can also look for a lot 638 00:51:15,840 --> 00:51:20,840 of those services will have a retry after header. You can look for something 639 00:51:20,920 --> 00:51:23,360 like that and then you could tell it, okay, time out for this 640 00:51:23,559 --> 00:51:28,519 long before trying again. Right, So there's a lot of flexibility in there 641 00:51:28,719 --> 00:51:32,440 strategy to take that on. And the new rate limiting strategy as well, 642 00:51:32,559 --> 00:51:37,639 is built on top of the new rate limiting functionality that shipped with dotten at 643 00:51:37,639 --> 00:51:40,719 seven. So it's yet more code we don't have to maintain, we don't 644 00:51:40,760 --> 00:51:44,519 have to do the smarts of rate limiting. We just built on top of 645 00:51:44,559 --> 00:51:49,239 it. The team did that and continue to make Yeah, because we talked 646 00:51:49,239 --> 00:51:52,800 about doing this way before that feature came out, or you know, just 647 00:51:52,840 --> 00:51:57,440 before it came out, and so there was that whole thing of hey, 648 00:51:57,480 --> 00:52:00,840 we need this, but we could just wait and this is going to be 649 00:52:00,920 --> 00:52:05,000 part of dot net seven and let's just build on top of that. Very 650 00:52:05,039 --> 00:52:09,320 good well, guys, thanks congratulations. As Richard said before, and uh, 651 00:52:10,000 --> 00:52:15,239 here's too many more years of success with Polly light On. Thank you 652 00:52:15,480 --> 00:52:38,960 all right, and we'll talk to you next time on dot net rocks. 653 00:52:36,679 --> 00:52:45,960 Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, 654 00:52:45,320 --> 00:52:51,239 a full service audio, video and post production facility located physically in New 655 00:52:51,280 --> 00:52:57,079 London, Connecticut, and of course in the cloud online at pwop dot com. 656 00:52:57,440 --> 00:53:00,639 Visit our website at d O T N E t R O c ks 657 00:53:00,760 --> 00:53:06,280 dot com for RSS feeds, downloads, mobile apps, comments, and access 658 00:53:06,320 --> 00:53:09,760 to the full archives going back to show number one, recorded in September two 659 00:53:09,760 --> 00:53:14,360 thousand and two. And make sure you check out our sponsors. They keep 660 00:53:14,440 --> 00:53:17,039 us in business. Now go write some code, See you next time. 661 00:53:17,960 --> 00:53:22,280 You got JAD Metal vansc