WEBVTT 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