1 00:00:01,000 --> 00:00:04,759 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05,320 --> 00:00:09,400 Become a patron for just five dollars a month. You get access to a 3 00:00:09,480 --> 00:00:14,199 private RSS feed where all the shows have no ads. Twenty dollars a month, 4 00:00:14,240 --> 00:00:18,399 we'll get you that and a special dot net Rocks patron mug. Sign 5 00:00:18,480 --> 00:00:23,679 up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. 6 00:00:24,000 --> 00:00:28,480 As you may have heard, NDC is back offering their incredible in person 7 00:00:28,559 --> 00:00:32,799 conferences around the world, and we'd like to tell you about them. NDC 8 00:00:32,960 --> 00:00:38,840 Copenhagen is happening August twenty seventh through the thirty first. Go to NDC Copenhagen 9 00:00:38,960 --> 00:00:44,679 dot com for more information. NDC Porto is happening October sixteenth through the twentieth. 10 00:00:44,880 --> 00:00:49,000 The early bird discount for ADC Porto ends July twenty first. Go to 11 00:00:49,119 --> 00:00:54,240 Dcporto dot com to register and check out the full lineup of conferences at NDC 12 00:00:54,359 --> 00:00:59,240 conferences dot com. Hey there, this is Jeff Fritz, the purple blazer 13 00:00:59,320 --> 00:01:02,880 guy from like or Soft, letting you in on a little secret about my 14 00:01:02,960 --> 00:01:07,439 friend Carl Franklin. You know, the guy who started dot net rocks. 15 00:01:07,480 --> 00:01:11,280 The first podcast about dot net in two thousand and two. The guy who's 16 00:01:11,319 --> 00:01:17,400 been teaching Blazer on YouTube since twenty twenty, Yeah, that Carl Franklin. 17 00:01:18,280 --> 00:01:22,239 Well, Carl's joined up with the folks from Code in a Castle to teach 18 00:01:22,280 --> 00:01:26,000 a week long hands on Blazer class at Are you Ready Get This? At 19 00:01:26,040 --> 00:01:33,760 a castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer 20 00:01:33,840 --> 00:01:41,159 learning built in. Carl's calling it the Blazer master Class. You'll learn Blazer 21 00:01:41,200 --> 00:01:45,079 from the ground up, finishing the week with the ability to build and deploy 22 00:01:45,239 --> 00:01:49,760 Blazer applications. Since the training happens for only four hours in the morning over 23 00:01:49,879 --> 00:01:53,920 six days, you can bring your significant other, your partner with you and 24 00:01:55,599 --> 00:02:00,920 you should right This part of Italy is absolutely beautiful. There's so much to 25 00:02:00,040 --> 00:02:06,439 see and do, and in Larion Marco from Code into Castle are organizing daily 26 00:02:06,480 --> 00:02:09,879 activities both at the castle and in the area. The castle is in the 27 00:02:09,960 --> 00:02:15,919 Marema, a less touristed region of Tuscany, offering both classic Tuscan hill country 28 00:02:16,120 --> 00:02:21,960 as well as easy access to the Etruscan Riviera, with sublime local food, 29 00:02:22,400 --> 00:02:27,919 wine and olive oil around every corner. Breakfast is included. Every day there 30 00:02:27,960 --> 00:02:31,199 will be two communal dinners at the castle book ending the experience, and most 31 00:02:31,280 --> 00:02:37,479 other meals and all activities are included. And did I mention you'll learn Blazer 32 00:02:37,759 --> 00:02:42,840 in person from Carl Franklin. Listen, space is limited and for very good 33 00:02:42,840 --> 00:02:47,000 reason. This is quality training in a beautiful setting. Go to code in 34 00:02:47,039 --> 00:02:53,759 Acastle dot com slash Blazer twenty twenty three. That's b L A z R 35 00:02:54,240 --> 00:03:00,520 two zero two three to take advantage of this amazing opportunity to join Carl in 36 00:03:00,599 --> 00:03:06,919 Tuscany for an unforgettable week of La dolce vita while advancing your programming skills in 37 00:03:07,000 --> 00:03:23,159 this important new technology. Welcome back to dot and rocks. This is Carl 38 00:03:23,199 --> 00:03:27,280 Franklin and this is Richard cavill Man. You know I got a story for 39 00:03:27,319 --> 00:03:30,560 you. Oh my new studio is coming along. Have you seeing any of 40 00:03:30,599 --> 00:03:34,960 the videos I have seen? You know what I saw? I saw red? 41 00:03:35,439 --> 00:03:38,840 Yes, you do? Like the red walls. I do. And 42 00:03:38,919 --> 00:03:43,759 it's the same exact fabric that I had at Plato point zero. Interesting, 43 00:03:43,879 --> 00:03:46,879 Okay, the same exact stuff and it's that was really two point zero right, 44 00:03:47,520 --> 00:03:51,039 No, No, that was one point well, okay two point oh, 45 00:03:51,080 --> 00:03:53,360 yeah, I guess. I mean that the old State Street place you 46 00:03:53,439 --> 00:03:58,479 had it was the training space first, then it became the studio space, 47 00:03:58,639 --> 00:04:00,599 and then you have built this studios. Yeah, yeah, you're right, 48 00:04:00,639 --> 00:04:04,360 like you definitely went through some iterations. We might as well say studio one 49 00:04:04,520 --> 00:04:10,280 was my basement in Waterford where night arguably community. And now you're staring at 50 00:04:10,319 --> 00:04:13,400 five. Yeah, I just call it. I call it PLoP three point 51 00:04:13,479 --> 00:04:15,960 zero. Okay, I'll buy that. Yeah, we'll buy that. The 52 00:04:15,079 --> 00:04:19,560 third version is the best version anyway, everything you know. Yeah, anyway, 53 00:04:20,160 --> 00:04:25,720 putting in the floor in a couple of weeks. The split HRAC system 54 00:04:25,800 --> 00:04:29,639 is going in on Tuesday. Nice and the band is going to start rehearsing 55 00:04:29,680 --> 00:04:32,439 there in just a few weeks. So I'm really excul that's really great. 56 00:04:33,399 --> 00:04:39,600 Anyway, let's start with better no framework, roll the clar music at awesome. 57 00:04:46,360 --> 00:04:49,079 All right, what do you got? This is um something I know 58 00:04:49,160 --> 00:04:53,000 you're going to be interested. You probably already know this because you know everything, 59 00:04:53,439 --> 00:05:00,560 but it's a It's an article in Electrek Dot and CEO. Sweden is 60 00:05:00,560 --> 00:05:06,800 building the world's first permanent electric road that charges moving evs that's cool, isn't 61 00:05:06,839 --> 00:05:12,680 that cool? Yeah, And there's a picture of a bus and it's driving 62 00:05:12,800 --> 00:05:19,720 over this blue strip of charging some things in it. Magnetic charging, I 63 00:05:19,759 --> 00:05:24,879 don't know, you probably know. Yeah, it's probably cute style charging or 64 00:05:24,959 --> 00:05:29,959 just impedance or field style charging, which is final. They'll only charge so 65 00:05:30,079 --> 00:05:33,120 fast, but you and it's pretty smart because you know, it doesn't have 66 00:05:33,199 --> 00:05:39,600 to charge really powerfully because you're constantly going over it. Right. Yeah, 67 00:05:39,639 --> 00:05:44,000 if every foot you get a little bit of charge, enough to go at 68 00:05:44,040 --> 00:05:47,120 least a foot, then you're positive. Right, Yeah, I don't think 69 00:05:47,279 --> 00:05:50,399 I don't think you're gonna be that net benefit, but hey, anything that 70 00:05:50,439 --> 00:05:55,199 adds a little range, yeah, you know, it stretches a bit further, 71 00:05:55,360 --> 00:05:57,879 so much the better. I mean, clearly, this project is an 72 00:05:57,879 --> 00:06:01,639 experiment. They're talking twenty kilometers, right, so it's one piece of one 73 00:06:01,800 --> 00:06:06,040 thing, and who knows how many more they're going to do. But you 74 00:06:06,079 --> 00:06:09,920 know, obviously after their experiments they said, hey, this piece makes sense 75 00:06:09,920 --> 00:06:14,199 that we're going to keep doing this and we'll see what happens. It's great 76 00:06:14,240 --> 00:06:17,319 to see, you know, infrastructure come into play. Not to derail the 77 00:06:17,360 --> 00:06:21,959 conversation, but you also saw Ford signing on a now GM signing on with 78 00:06:24,480 --> 00:06:30,199 Tesla to do the North American charging standard like this. Here's an interesting point. 79 00:06:31,160 --> 00:06:36,600 The model team released in nineteen o one, first gas station opens nineteen 80 00:06:36,680 --> 00:06:40,279 thirteen. Wow, what do they do for twelve years? Yeah, I 81 00:06:40,319 --> 00:06:46,600 don't know. You bought your gas in containers from the chemist. That's what 82 00:06:46,680 --> 00:06:50,439 you did, chemists. Yes, well you know what we now call a 83 00:06:50,439 --> 00:06:56,399 pharmacy, but basically exactly. But I mean to that point, you know, 84 00:06:56,600 --> 00:07:00,160 watch how these things emerge, the idea of the standard eyes gas filler 85 00:07:00,879 --> 00:07:04,680 that you know, one gas station had different tanks for different kinds of fuel. 86 00:07:04,800 --> 00:07:08,279 Right, you can get diesel, you can get we have to do 87 00:07:08,319 --> 00:07:14,240 a new geek out on electric cars and electric transportation perhaps, but you know 88 00:07:14,360 --> 00:07:15,920 they we're at this point now where it's like, hey, we want standards 89 00:07:15,959 --> 00:07:19,160 around this, we want these things to work correctly. So again, the 90 00:07:19,199 --> 00:07:23,839 experiments continue. This This electro tech article is a great example of that of 91 00:07:24,279 --> 00:07:27,680 more experiments. Well, you know, it's a nice experiment, but will 92 00:07:27,720 --> 00:07:31,399 it scale? That's see what I did there. I like that. I 93 00:07:31,480 --> 00:07:35,839 know it's very clever. Are you're the one trying to stay on subject? 94 00:07:35,879 --> 00:07:41,680 That's weirded out, all right, who's talking to us? Richard grabbed a 95 00:07:41,680 --> 00:07:46,000 comment off a show seventeen seventy eight. That's the one we did back in 96 00:07:46,000 --> 00:07:49,680 twenty twenty two about pro micro services and dot at six. That was Sean 97 00:07:49,720 --> 00:07:56,040 white Cell, Rod Richardson and Matthew Groves. And this comment comes from Mark 98 00:07:56,160 --> 00:07:59,120 Essex, who said, Wow, what a timely podcast. We're in the 99 00:07:59,160 --> 00:08:01,959 early stages of hoarding our monolithic web forms app, which has been in production 100 00:08:03,000 --> 00:08:09,439 for twenty plus years in some form to micro services. I immediately went out 101 00:08:09,480 --> 00:08:11,120 and purchased the book and I will force myself to make time to read all 102 00:08:11,120 --> 00:08:16,000 four hundred and eight pages. Well, I'm sure Sean and Robin Matthew will 103 00:08:15,959 --> 00:08:18,639 be to listen to this show first. Yeah, I thought discussion was so 104 00:08:18,680 --> 00:08:22,240 relevant, really hit on some key points that we've been discussing internally about areas 105 00:08:22,240 --> 00:08:26,480 of concerning issues it might arise. I'm scared to death. I'm about how 106 00:08:26,480 --> 00:08:30,519 to debug this thing, or to test it, or to ensure the same 107 00:08:30,600 --> 00:08:33,600 quality that we've enjoyed with our current application. I mean, if you've running 108 00:08:33,600 --> 00:08:37,320 an app for twenty plus years, like people are pretty used to it, 109 00:08:37,440 --> 00:08:39,840 right, and as somebody else mentioned in the comments. I really hope we 110 00:08:39,879 --> 00:08:43,600 don't have to decide to go back to our monolithic app as that would have 111 00:08:43,679 --> 00:08:48,440 a whole other set of challenges. So thanks so much for a great podcast. 112 00:08:48,919 --> 00:08:52,639 Yeah, with any luck, Mark, you'll be that. You know 113 00:08:52,679 --> 00:08:54,679 that was a year ago admittedly, so you're probably pretty far down the path. 114 00:08:54,840 --> 00:08:58,720 Maybe the show isn't timely enough for you. But here's to hoping. 115 00:09:00,279 --> 00:09:03,639 We're certainly having a conversation about you know, there is no one perfect solution 116 00:09:03,679 --> 00:09:05,120 for anything, and there's a bunch of ways is all of this problem, 117 00:09:05,159 --> 00:09:09,759 and that's certainly what this show will be about. Yes, sir so Mark, 118 00:09:09,799 --> 00:09:11,799 thank you so much for your comment. And a copy of music Go 119 00:09:11,840 --> 00:09:13,759 Buy is on its way to you. And if you'd like a copy of 120 00:09:13,840 --> 00:09:16,720 music Go Buy, write a comment on the website at dot net rocks dot 121 00:09:16,759 --> 00:09:18,799 com or on the facebooks. We publish every show there and if you comment 122 00:09:18,799 --> 00:09:20,759 there and everything in the show, we'll let you a copy of music Go 123 00:09:20,840 --> 00:09:26,000 Buy. And you should definitely follow us on something. You can follow us 124 00:09:26,039 --> 00:09:28,559 on Twitter if you want to, we were there, or Facebook. As 125 00:09:28,639 --> 00:09:33,679 Richard said, but the cool kids are over on Mastodon, right now I'm 126 00:09:33,759 --> 00:09:37,679 at Carl Franklin at tech hub dot social, and I'm Rich Campbell at Mastodon 127 00:09:37,759 --> 00:09:43,960 dot Social send Institute, Rudy Tooty, Fresh and fruity. Okay, let's 128 00:09:43,960 --> 00:09:48,519 bring on Derek. We actually started the conversation before we started recording, so 129 00:09:48,559 --> 00:09:52,879 we'll probably pick up there. But Derek Comartin is a software developer. Over 130 00:09:52,919 --> 00:09:58,919 two decades of professional experience, He's written software for various business domains such as 131 00:09:58,000 --> 00:10:03,960 consumer goods, distribution, transportation, manufacturing, and accounting. Derek has a 132 00:10:05,080 --> 00:10:09,360 very active blog on YouTube channel called code Opinion, which focuses on software architecture 133 00:10:09,440 --> 00:10:13,559 and design. Welcome Derek, thanks for having me. I wanted to say 134 00:10:13,559 --> 00:10:18,200 I'm a first time color longtime listener, but I was not sure if anybody 135 00:10:18,200 --> 00:10:22,120 would realize what that is. Yeah, well we get it. School. 136 00:10:22,320 --> 00:10:28,919 Yeah, longtime listener, first time Yeah, I love it well. And 137 00:10:28,960 --> 00:10:33,879 I'm a longtime reader of your blog, sir. I often tweet out my 138 00:10:35,399 --> 00:10:37,120 favorite of your blog. Yes, yeah, I appreciate that. Yeah for 139 00:10:37,200 --> 00:10:43,840 sure. So scaling in general is seems like an insurmountable task when you know 140 00:10:45,000 --> 00:10:50,480 the boss comes and says we have to talk about scaling. Uh, okay, 141 00:10:50,000 --> 00:10:54,440 because we can't. We can't imagine to what degree we need to scale. 142 00:10:54,840 --> 00:10:58,440 And most companies think, if they're public facing websites, for example, 143 00:11:00,120 --> 00:11:03,240 they think that they're going to be the next Netflix or the next Amazon or 144 00:11:03,279 --> 00:11:09,440 something, and so it may be completely over architected and completely overextended. And 145 00:11:09,720 --> 00:11:15,639 then you have the companies that are small now but think that they will grow 146 00:11:15,759 --> 00:11:18,279 to be these big companies. So we want to be ready to scale, 147 00:11:18,639 --> 00:11:24,320 and that may involve a lot of extra architecture developers don't want. I mean, 148 00:11:24,360 --> 00:11:28,320 there's just so many gotchas in scaling, and I guess that's why we 149 00:11:28,360 --> 00:11:31,360 brought you on to help clear up some of this nonsense. It is like 150 00:11:33,159 --> 00:11:35,320 it's an interesting topic because, like you said, there's this kind of this 151 00:11:35,399 --> 00:11:39,600 notion where right from the get go, we need to decide now in stone 152 00:11:39,720 --> 00:11:43,120 exactly what it's going to be so we can be the next big thing or 153 00:11:43,159 --> 00:11:48,279 that we think we might be. And I think there's just this right now, 154 00:11:48,399 --> 00:11:50,440 even though we've been swinging back, I feel like a last couple of 155 00:11:50,519 --> 00:11:54,519 years worth of this. Okay, we've been doing the kind of getting more 156 00:11:54,519 --> 00:12:00,120 focused on micro services, like we're talking about the comment, and I think 157 00:12:00,120 --> 00:12:05,320 it's just it's viewed the wrong way. I think it's you can go pretty 158 00:12:05,320 --> 00:12:09,639 far for if you have them onolith or if you're starting that way, if 159 00:12:09,679 --> 00:12:15,200 you think about how you're building your app, not necessarily in a physical sense 160 00:12:15,279 --> 00:12:20,240 right away, but more in a logical sense, how you design it that 161 00:12:20,320 --> 00:12:24,759 way, you can then decide how you want to scale. And there's a 162 00:12:24,879 --> 00:12:28,559 variety of different ways to think about scaling. I mean, I think primarily 163 00:12:28,600 --> 00:12:33,480 if you were to stay cheese, I don't know, fifteen twenty years ago, 164 00:12:33,519 --> 00:12:37,639 before a cloud, you would it was a little bit more difficult in 165 00:12:37,679 --> 00:12:39,960 the sense that you were thinking, okay, we got to buy new hardware, 166 00:12:39,080 --> 00:12:43,159 and that was a little bit more difficult to scale up or scale out 167 00:12:43,159 --> 00:12:46,279 potentially. But now it's just a little bit easier. But the kind of 168 00:12:46,279 --> 00:12:50,840 the same thought process is still it's still the same for me. It's thinking 169 00:12:50,879 --> 00:12:54,399 about just so the traditional things of are we scaling up, are we scaling 170 00:12:54,440 --> 00:13:00,360 out? But they all kind of have implications about what I really call moving 171 00:13:00,399 --> 00:13:05,000 the bottleneck. Usually when you're changing one thing down the road, you're likely 172 00:13:05,080 --> 00:13:07,480 changing something else. So it's it's kind of an evolving thing. That's why 173 00:13:07,519 --> 00:13:09,639 I think it's a little bit of a fallacy to think up front, oh, 174 00:13:09,679 --> 00:13:15,960 we're going to create microservices and that's gonna just solve all our scaling problems. 175 00:13:15,960 --> 00:13:18,919 When scaling of water actually we're talking about there, because in most times 176 00:13:18,919 --> 00:13:24,879 that's more of an organizational thing than it was necessarily you said the word microservices. 177 00:13:24,919 --> 00:13:30,360 I could tell that a million sphincters just tightened. I thought I saw 178 00:13:30,399 --> 00:13:33,000 your eye twitch. Actually, carl As, we've got video because of the 179 00:13:33,039 --> 00:13:37,120 sphincter tightening. I think you know, it occurred to me. It's like 180 00:13:37,240 --> 00:13:39,960 we should switch to microservices is like the new version of we should have written 181 00:13:39,960 --> 00:13:45,559 this in Ruby on rails right Like it's it's the hey, we can't fix 182 00:13:45,639 --> 00:13:48,399 this problem, so let's come up with a solution so complicated that you'll leave 183 00:13:48,480 --> 00:13:52,600 us alone for six months. It's interesting because we were kind of alluding to 184 00:13:52,639 --> 00:13:56,080 this before we started, which I was bringing up months ago. I can't 185 00:13:56,080 --> 00:14:01,240 remember how long ago it was. There was Amazon Prime Video had a video 186 00:14:01,559 --> 00:14:09,679 or had a blog post about kind of their transition from using lambda's aws lambda 187 00:14:09,720 --> 00:14:15,399 and a combination of S three and some other things, and they migrated that 188 00:14:15,519 --> 00:14:20,679 to just be containers in ecs, and there was seemingly kind of an uproar 189 00:14:20,960 --> 00:14:24,799 of various opinions, including my own, about what that really was, which 190 00:14:24,840 --> 00:14:28,159 people were saying, well, they went back to a monolith, which even 191 00:14:28,200 --> 00:14:31,159 in their own posts they did, but I kind of said, it really 192 00:14:31,320 --> 00:14:33,399 wasn't And there's a lot of people claiming, oh, well, how does 193 00:14:33,960 --> 00:14:37,600 Amazon doesn't even know AWS doesn't even know really what lambdas are good for, 194 00:14:39,879 --> 00:14:43,440 And it was just a lot of hot takes I guess about Okay, they 195 00:14:43,480 --> 00:14:48,240 had this service specifically for I believe it was for kind of trying to determine 196 00:14:48,279 --> 00:14:52,960 the quality of a stream and letting know the streamer know, like when quality 197 00:14:54,000 --> 00:14:58,799 was degrading, etc. And it initially said in the post that it was 198 00:14:58,840 --> 00:15:01,240 just it wasn't designed for the scale that it ended up becoming, which is 199 00:15:01,519 --> 00:15:05,759 okay, great, I guess, and they evolved it. It's like, 200 00:15:07,240 --> 00:15:11,320 what's so terrible about deciding, Okay, well this worked at one scale, 201 00:15:11,320 --> 00:15:16,639 but it's not currently how it is now in the volume that we need. 202 00:15:16,720 --> 00:15:22,200 Yeah, it's funny how people want the one right way right, like they 203 00:15:22,480 --> 00:15:24,720 well, if it doesn't work for this, and it wouldn't work for anything, 204 00:15:24,840 --> 00:15:28,080 right, I mean I read the original post and what my immediate thought 205 00:15:28,159 --> 00:15:31,519 was, why were you using servi lists here? To me, the reason 206 00:15:31,600 --> 00:15:35,399 you servillists is you you have an elastic load that has to abruptly scale up 207 00:15:35,440 --> 00:15:41,000 a lot and abruptly drop back down. The audio video consumption on Prime Video 208 00:15:41,120 --> 00:15:45,240 is probably pretty high all the time. It probably goes from high to really 209 00:15:45,279 --> 00:15:48,360 freaking high, Like what do they need that, I'm out of elasticity for 210 00:15:48,799 --> 00:15:52,519 well, as LAMB does though they they can shut down, right, Yeah, 211 00:15:52,679 --> 00:15:56,480 that's the whole thing, right is it very elastic? But it also 212 00:15:56,600 --> 00:15:58,720 takes time for them to spin back up again, so that could you know 213 00:16:00,159 --> 00:16:03,240 very few people, you know, the first person that has to wait for 214 00:16:03,320 --> 00:16:07,759 that has to wait. Yeah. And another piece of that was from what 215 00:16:07,840 --> 00:16:11,080 I got from it was just the cost in the issues of moving data back 216 00:16:11,120 --> 00:16:15,519 and forth from those landas two S three like back and forth, like pull 217 00:16:15,559 --> 00:16:18,600 them that data from there. Yeah, so going to ECS and being a 218 00:16:18,600 --> 00:16:22,279 container, you're pulling it once they're running their detectors. It's all at that 219 00:16:22,279 --> 00:16:26,480 point in memory, once they fetched it once, rather than the however many 220 00:16:26,480 --> 00:16:32,320 times they needed to do it. And in theory serverlists should have if you're 221 00:16:32,399 --> 00:16:34,720 used to service properly, it saves you money because you only use instances when 222 00:16:34,720 --> 00:16:40,200 you need them. But it's got to be the shape of the workload, 223 00:16:40,399 --> 00:16:42,240 right, And I guess as they understood the shape of their workload, they 224 00:16:42,279 --> 00:16:48,720 could implement a lower cost solution for that workload exactly. It's just it's I 225 00:16:48,720 --> 00:16:53,159 always say context this king like at the starting of it, maybe I don't 226 00:16:53,159 --> 00:16:56,840 know what their situation was other than what they wrote in the post. It 227 00:16:56,919 --> 00:17:00,480 just it didn't seem like the initially the solution work because it it'sn't at the 228 00:17:00,519 --> 00:17:03,519 scale that they were headed towards, and they had no intention to it. 229 00:17:03,559 --> 00:17:07,480 So it evolved. It's like, yeah, okay, great, you evolved. 230 00:17:07,519 --> 00:17:11,680 It like makes sense to me. This is like saying what you're a 231 00:17:11,680 --> 00:17:18,039 teenager, childhood's a waste of time. Yeah, it's a great point. 232 00:17:18,079 --> 00:17:21,759 And it is really like like you said, it's a hot take and then 233 00:17:21,799 --> 00:17:26,359 and a hot takes in general are incorrect. I think anybody's actually built and 234 00:17:26,359 --> 00:17:30,319 cared for software, Like I spent a lot of time helping people scale, 235 00:17:30,559 --> 00:17:34,119 and you always start the conversation with corridulations. You have a good problem and 236 00:17:34,680 --> 00:17:40,359 enough people are using your stuff that scale matters. If nobody was using it, 237 00:17:40,359 --> 00:17:45,480 it'd worked great, exactly when you kind of in for I would say, 238 00:17:45,759 --> 00:17:48,200 I'm making the assumption here that it's not an abrupt oh oh my gosh, 239 00:17:48,240 --> 00:17:52,039 I need to scale like from zero to one hundred. It's usually kind 240 00:17:52,079 --> 00:17:56,759 of you know, I mean over time as you're gaining traction, if some 241 00:17:56,799 --> 00:18:00,119 type of sas product, whatever the case may be. And usually when that's 242 00:18:00,119 --> 00:18:03,400 coming up, that's when you're trying to determine what needs the scales. So, 243 00:18:03,480 --> 00:18:07,160 like I was mentioning, if it's it could just be scaling up kind 244 00:18:07,200 --> 00:18:11,480 of that app service that you're running. So let's say you're just running some 245 00:18:11,200 --> 00:18:15,680 web app, some ht B API, whatever the case may be. Maybe 246 00:18:15,720 --> 00:18:18,240 that first step is okay, just scaling up, giving it more resources, 247 00:18:18,240 --> 00:18:22,319 giving it more memory, whatever it's kind of starving on. But like I 248 00:18:22,359 --> 00:18:26,039 said, when doing that, usually the next step it might not be instantly, 249 00:18:26,000 --> 00:18:29,759 but it might be okay, well, now we can handle more inbound 250 00:18:29,799 --> 00:18:33,960 requests. So what is that going to affect downstream? Right nowadays, it's 251 00:18:34,519 --> 00:18:40,440 not just usually some app running, it's app running with obviously a database, 252 00:18:40,640 --> 00:18:44,920 some other infrastructure, there's a lot of moving parts, and usually when you 253 00:18:44,960 --> 00:18:48,519 scale, when you fix that one bottleneck, let's say it's at the very 254 00:18:48,519 --> 00:18:53,480 beginning of that app compute, you're likely gonna start seeing a bottleneck somewhere else 255 00:18:53,480 --> 00:18:57,640 and that yeah, in some other infrastructure. So then you're kind of tackling 256 00:18:57,759 --> 00:19:03,519 that piece of the puzzle if you need more performance, right, like, 257 00:19:03,799 --> 00:19:06,599 yes, absolutely, yeah, And there's a lot of ways of handling that. 258 00:19:06,680 --> 00:19:11,640 It's I think it's just it's not immediately. I think when people get 259 00:19:11,680 --> 00:19:14,640 into it, and it's kind of a slow process of having to fix each 260 00:19:14,680 --> 00:19:18,319 individual place that may be experiencing performance issues if you will or you can't handle 261 00:19:18,799 --> 00:19:22,400 that type of load. I think intuitively people start figuring it out of where 262 00:19:23,000 --> 00:19:26,640 what to fix where, or whether it be like it said, scaling up, 263 00:19:26,839 --> 00:19:32,079 scaling out at adding more instances. But I think that a bigger challenge 264 00:19:32,119 --> 00:19:37,920 oftentimes is more related to infrastructure that you don't necessarily like it's not your app, 265 00:19:38,039 --> 00:19:42,000 so that whether that be your database and depending on what type of database 266 00:19:42,000 --> 00:19:45,079 you're using. Right, So it's easy to say, okay, well I'm 267 00:19:45,079 --> 00:19:51,519 just gonna scale up my relational database. It's not so easy to all of 268 00:19:51,519 --> 00:19:55,759 a sudden say Okay, well we're going to introduce a read replica and that's 269 00:19:55,799 --> 00:20:00,240 just gonna be no problem, right, And that's a major re architect Like 270 00:20:00,279 --> 00:20:03,039 that's it can be your data quite differently, you want to talk through a 271 00:20:03,119 --> 00:20:06,839 read replica or folks who haven't dealt with it exactly, Like, it's not 272 00:20:06,880 --> 00:20:08,240 all of a sudden, it's well, I always say this about cashing. 273 00:20:08,759 --> 00:20:12,640 It's like I always get the sense that there's this people talk about it. 274 00:20:12,720 --> 00:20:15,799 I just I mean, add some cashing problem solved, everything'll be fine. 275 00:20:15,880 --> 00:20:21,440 It's like I always like people say that cash invalidation is a hard problem. 276 00:20:21,480 --> 00:20:25,000 I don't think it's like it's it's a hard problem, don't get me wrong. 277 00:20:25,079 --> 00:20:29,039 But in the sense of an application like these types of systems, it's 278 00:20:29,880 --> 00:20:33,279 I find it more of an issue of just dealing with a cash in general. 279 00:20:33,279 --> 00:20:34,759 There's so much that can go wrong with it, sure, right, 280 00:20:34,799 --> 00:20:38,440 so well, and it has direct impact on business, right, Like every 281 00:20:40,759 --> 00:20:45,359 airline consolidation site you've ever used doesn't check with the airlines every time they show 282 00:20:45,400 --> 00:20:49,440 you a flight, they've cashed all of that, And every so often you're 283 00:20:49,480 --> 00:20:52,960 going to click on a flight for a price, and then it's gonna go, 284 00:20:52,079 --> 00:20:56,920 oh, sorry, I don't have that flight. Then maybe it's one 285 00:20:56,000 --> 00:21:02,079 percent of the time they're going to annoy you that way, and they've decided 286 00:21:02,160 --> 00:21:06,759 that's sufficient. I dealt with an inventory system that was too slow and they 287 00:21:06,759 --> 00:21:08,039 wanted to add cashing to it, and I said, that means occasional you're 288 00:21:08,039 --> 00:21:11,440 going to sell stuff you don't have. What do you want to do about 289 00:21:11,480 --> 00:21:15,359 that, right, And the answer was, we put in a back order 290 00:21:15,400 --> 00:21:18,119 system, Like we accept the fact that we don't have it, and so 291 00:21:18,400 --> 00:21:22,480 we now have. We never had back orders before, we'll add back ordering. 292 00:21:22,519 --> 00:21:25,880 So if you've ordered something that wasn't in the we're still in the cash, 293 00:21:25,920 --> 00:21:27,039 but it wasn't on the shelf, it's like, hey, really sorry, 294 00:21:27,200 --> 00:21:30,559 we put you on back order. If they choose to cancel whatever, 295 00:21:30,680 --> 00:21:33,960 but at least we're doing investor can and we literally change the business flow to 296 00:21:34,119 --> 00:21:38,599 compensate for performance exactly trade offs, right, And a lot of the stuff 297 00:21:38,640 --> 00:21:44,519 is usually built into in most cases, like if you're talking about whatever industry. 298 00:21:44,559 --> 00:21:47,440 I love that you brought up that example because I always said that if 299 00:21:47,440 --> 00:21:51,519 you oversell something like in distribution and warehousing, it wasn't a sales problem. 300 00:21:51,599 --> 00:21:55,559 It's a purchasing problem, right, so they usually have stuff in place for 301 00:21:55,640 --> 00:21:59,319 this to begin with. But whether it would be a read replica that you're 302 00:21:59,319 --> 00:22:03,799 introducing a cash when we're talking about something that's hivan stale data and how you're 303 00:22:03,799 --> 00:22:06,960 going to deal with that. But even just like to touch on the cash 304 00:22:07,000 --> 00:22:11,960 again, it's even from a technical point of view, is it always available? 305 00:22:12,279 --> 00:22:17,960 Is it responding to you like you're using a cash typically because you don't 306 00:22:17,960 --> 00:22:19,839 want to reach out, you want to offload some of those requests from your 307 00:22:19,880 --> 00:22:26,240 database. What happens when the cash isn't available or it's not as responses of 308 00:22:26,279 --> 00:22:27,640 you do want it to be right, right, guess what you're doing. 309 00:22:27,680 --> 00:22:33,400 You're usually going back to the database. So right, so if all of 310 00:22:33,480 --> 00:22:38,920 a sudden everything's sailing great one day and then there's hiccups, there's performance issues 311 00:22:38,960 --> 00:22:41,799 with your cash. Now all of a sudden, these requests that we're hitting 312 00:22:41,839 --> 00:22:45,519 the cash or cash misses and they're going back to your database. You just 313 00:22:47,799 --> 00:22:51,799 flood your database with a pile of cash miss is that it normally isn't expecting 314 00:22:51,920 --> 00:22:55,079 Yeah, let's talk through the read replicub model, because I think it's really 315 00:22:55,079 --> 00:22:57,359 interesting for folks, and I don't know, I don't know there's a product 316 00:22:57,400 --> 00:23:00,319 off the shelf that can let you do read replica, Like you have to 317 00:23:00,400 --> 00:23:04,640 code for this, this idea that you're writing to one database that then is 318 00:23:04,839 --> 00:23:11,599 synchronizing to one or more reading databases. Yeah, I mean there's options to 319 00:23:11,680 --> 00:23:18,000 have some type of proxies there so and then rules built around that so you 320 00:23:18,039 --> 00:23:22,799 can be offloading them. But it's just still a matter of if that re 321 00:23:22,000 --> 00:23:29,000 replica is a synchronous and it's eventually consistent, then that's more of the issue 322 00:23:29,039 --> 00:23:32,200 than necessarily like you need to know it. The whole world has been taught 323 00:23:32,240 --> 00:23:36,759 that by Facebook because Facebook clearly uses read replicas, and when you didn't immediately 324 00:23:36,759 --> 00:23:38,720 see your post, you would post it again and then you see them both. 325 00:23:40,519 --> 00:23:44,279 Like everybody knows about that problem now just because they learned Facebook. Yeah, 326 00:23:44,279 --> 00:23:48,839 I think there's definitely something to it in terms of note like people are 327 00:23:48,880 --> 00:23:52,559 a little bit more familiar with with it, whether they're technical or not, 328 00:23:52,599 --> 00:23:57,200 that can sometimes probably guess what's happening. Yeah, but still it's not the 329 00:23:57,279 --> 00:24:02,519 greatest obviously, and I think it's similar whether it's a re replica or whether 330 00:24:02,559 --> 00:24:07,759 it's a cash they're both are potentially stale at any given time. It's like 331 00:24:08,279 --> 00:24:12,839 it's contact specific. Most users, I would think, in your example, 332 00:24:12,839 --> 00:24:17,440 if they performed some right, which they may not know they're doing, but 333 00:24:17,680 --> 00:24:19,839 yeah, if they're performing some right and you're immediately going to provide them with 334 00:24:19,960 --> 00:24:23,799 some read of that right, they're expecting it. Yeah, and you And 335 00:24:23,839 --> 00:24:27,559 there's lots of ways to cheat on that too, absolutely and say I already 336 00:24:27,640 --> 00:24:30,519 you won't You just want to see your data, so I'll keep a copy 337 00:24:30,559 --> 00:24:34,759 of your data around to show you right away while it spends X many milliseconds 338 00:24:34,799 --> 00:24:38,880 getting synchronized on the back end. I mean, we're maybe we're getting a 339 00:24:38,880 --> 00:24:42,240 little nitty gritty here, but I found the bigger thing for performance in the 340 00:24:42,240 --> 00:24:49,200 rereplica model was that the right database A was insert only and B had minimal 341 00:24:49,240 --> 00:24:53,240 indexes on it because you didn't you didn't need them. You were never going 342 00:24:53,319 --> 00:24:56,519 to read from them, and index has caused the law of a blocking and 343 00:24:56,599 --> 00:25:03,640 locking that they then you would later synchronize it later being milliseconds later, would 344 00:25:03,680 --> 00:25:07,079 synchronize to a read replica that was orgoned. It only had one place of 345 00:25:07,440 --> 00:25:12,319 right path coming from the right database, and then did have all that indexing 346 00:25:12,359 --> 00:25:18,599 to optimize for read that as well as which is another option as we're talking 347 00:25:18,599 --> 00:25:23,720 about options for scaling, is creating what I'll call like there's different ways of 348 00:25:23,799 --> 00:25:29,000 determining that calling this is like a materialized view, right, creating some type 349 00:25:29,000 --> 00:25:33,079 of projection where that's specifically for that's something that's query optimized. Right. It's 350 00:25:33,119 --> 00:25:37,440 that kind of separating these concerns of Okay, I have these rights, like 351 00:25:37,440 --> 00:25:41,720 you're saying you want them to be fast or kind of off floating indexes. 352 00:25:41,720 --> 00:25:45,759 There that contention and doing the same thing on that read side, which is, 353 00:25:45,839 --> 00:25:49,480 let's optimize for reads, whether that be indexes, whether that be more 354 00:25:49,599 --> 00:25:55,279 denormalized in regardless of what type of data store, it is just more structured 355 00:25:55,319 --> 00:25:57,160 to the way that you want to fetch that data. Well, it really 356 00:25:57,160 --> 00:26:02,519 salient point. It doesn't all have to be relation databases, like one could 357 00:26:02,680 --> 00:26:07,200 argue, and I have made the argument before and on this show that when 358 00:26:07,240 --> 00:26:11,359 you've received an order, which is basically a glob of objects, now, 359 00:26:11,000 --> 00:26:15,759 making the customer wait while you decompose that in the rows and columns is kind 360 00:26:15,799 --> 00:26:19,640 of daft, like just store the object. It is the source of truth, 361 00:26:21,160 --> 00:26:26,000 send the customer on their way, and do your decomposition into the read 362 00:26:26,119 --> 00:26:30,039 system separately. I'll take it a step further and say where we're going with 363 00:26:30,079 --> 00:26:37,680 this is offloading work. So that offloading of that decomposition to whatever immune secreture 364 00:26:37,799 --> 00:26:42,880 process exactly. But that cannot be just like that view and composing that view. 365 00:26:42,920 --> 00:26:48,480 It's actually composing the work, like actually performing the work. So like 366 00:26:48,559 --> 00:26:51,839 I said, like if you're placing an order, it's I don't necessarily need 367 00:26:51,880 --> 00:26:57,440 to persist the actual order and perform the payment in everything, It's okay, 368 00:26:57,480 --> 00:27:03,880 here's my message dropped a CE. Do this asynchronously where that I can perform 369 00:27:03,920 --> 00:27:07,119 that work. And in terms of scaling, that's like I would say, 370 00:27:07,440 --> 00:27:14,079 kind of the I think it's a way that people immediately can think of in 371 00:27:14,119 --> 00:27:17,400 your system. If you're not using any type of messaging, not using queues 372 00:27:17,559 --> 00:27:19,839 or anything, and you want to start somewhere down the road, that way 373 00:27:22,119 --> 00:27:26,039 is just look at something simple that you know can be asynchronous, like an 374 00:27:26,079 --> 00:27:29,880 email. Right when you click that button that says do something, and it 375 00:27:30,079 --> 00:27:33,839 performs some type of tasks it's say persisting data and then needs to send out 376 00:27:33,880 --> 00:27:38,039 an email, It's like nobody expects that email to be instantly there. Right, 377 00:27:38,079 --> 00:27:42,000 So that's kind of the immediate place you can look at your system. 378 00:27:42,000 --> 00:27:45,319 Where can I offload some of this work? Where can I run this asynchronously? 379 00:27:47,960 --> 00:27:51,960 Yeah? Yeah, And I love the expectation part. Nobody expects it 380 00:27:52,400 --> 00:27:55,799 like they're used to. This is asynchronous. That's and it's going to have 381 00:27:55,839 --> 00:27:59,799 some latency and that's fine, right, And I think it's how you're how 382 00:28:00,000 --> 00:28:03,680 you're providing it to the user. Kind of then I hate to use user 383 00:28:03,720 --> 00:28:07,559 experience, but it is. It's it's how what their expectation is. Like 384 00:28:07,559 --> 00:28:11,359 I said, was reading your right is do they expect to see immediately the 385 00:28:11,480 --> 00:28:17,440 receipt with their transaction number of their credit card? Like not necessarily so that 386 00:28:17,480 --> 00:28:19,000 it's just a lot of this work can happen. It's how you're presenting it 387 00:28:19,039 --> 00:28:22,839 to them. Thank you, We've I mean, we've accepted your orgale. 388 00:28:22,920 --> 00:28:26,480 Will let you know when it's processed. I like e commerce systems like that, 389 00:28:26,599 --> 00:28:30,720 like okay, I've received your order, all right, we've yeah, 390 00:28:30,759 --> 00:28:33,960 we definitely have. All another emails is I've we've picked your product. We 391 00:28:33,039 --> 00:28:37,519 know we have it all. Now I've build your card, here's the receipt 392 00:28:37,599 --> 00:28:41,039 like and that I a lot of ways. Like I like that better because 393 00:28:41,079 --> 00:28:44,759 you see it's clearly a workflow. They're not making anything up, they're validating 394 00:28:44,799 --> 00:28:47,519 as they go, and more importantly, we'll step off if there's a problem 395 00:28:47,559 --> 00:28:52,799 and they're using known methods to communicate email, text, whatever. What I 396 00:28:52,839 --> 00:28:56,640 don't like is when you may want to track your package install this app. 397 00:28:57,759 --> 00:29:02,799 Yeah, no, go away, thanks, no spying, no spying, 398 00:29:02,799 --> 00:29:07,000 thanks very much. Yeah. The queuing model is you talk about a programming 399 00:29:07,039 --> 00:29:11,240 intensive modification to a piece of software, is to go from a synchronous database 400 00:29:11,279 --> 00:29:18,119 connection to a que approach like a takes some time to get your head around 401 00:29:18,160 --> 00:29:21,519 that, but it takes time for the users to get used to the fact 402 00:29:21,559 --> 00:29:25,319 that all of that is now different too. Yes, for sure, an 403 00:29:25,400 --> 00:29:30,640 existing app depending on like what we said, is depending on how you're implementing 404 00:29:30,680 --> 00:29:33,200 it. But like I said, I think there's a lot of places that 405 00:29:33,200 --> 00:29:36,759 you could probably look in your if you think if people are listening or now 406 00:29:36,799 --> 00:29:38,319 thinking of where can I do that, it's it's just trying to find those 407 00:29:38,400 --> 00:29:44,720 natural places that are asynchronous. And I think that's just an easier place to 408 00:29:44,880 --> 00:29:48,839 start, especially, like you said, wrapping your head around at how it's 409 00:29:48,880 --> 00:29:52,960 working in your system. But it's there's more places probably than not that you 410 00:29:52,960 --> 00:29:56,519 can that are really good fits. Yeah, there are some building gotchas with 411 00:29:56,559 --> 00:30:03,440 that kind of system too, such as let's just take a very simple example. 412 00:30:03,559 --> 00:30:08,640 You have a model and you want to add this data to the database 413 00:30:08,720 --> 00:30:12,759 through this model, and the model doesn't have a primary key because there's no 414 00:30:12,880 --> 00:30:17,400 primary key created in the database. Yet. You might have a you might 415 00:30:17,480 --> 00:30:21,440 have an identifier for that model, but it's not a database identifier. But 416 00:30:21,519 --> 00:30:26,839 then you can't really use it until you get that and you get that from 417 00:30:26,880 --> 00:30:30,039 the database, right, the database is going to assign you and tell you 418 00:30:30,079 --> 00:30:33,440 what that unique identifier is. So in the meantime, you can't do any 419 00:30:33,559 --> 00:30:36,920 edits, you can't do any updates, and you can't even do a delete. 420 00:30:36,960 --> 00:30:40,799 I mean you really kind of have to for that record that you're you 421 00:30:40,920 --> 00:30:45,599 just created. Your user is in limbo. Yeah, that is one. 422 00:30:45,640 --> 00:30:48,799 There's a bunch of gotcha's here, for sure. That's probably the one that 423 00:30:48,880 --> 00:30:53,960 I think people run into most. But oftentimes a solution there is depending on 424 00:30:55,000 --> 00:30:59,519 where you're making the requests from, is just providing that identifier from the get 425 00:30:59,519 --> 00:31:03,079 go. It may not be the primary key, but it's some other way 426 00:31:03,119 --> 00:31:07,960 that you can look up separately with what you've generated. Yeah, right, 427 00:31:07,000 --> 00:31:11,400 So if it's some type of guid, I've moved to GUIDs for primary keys 428 00:31:11,480 --> 00:31:14,240 instead of letting the database do it for me. I mean, anybody can 429 00:31:14,279 --> 00:31:17,160 generate guid at any time and it's going to be unique. Yeah, exactly, 430 00:31:17,200 --> 00:31:19,440 It's just you're at the client, and I don't mean the client as 431 00:31:19,480 --> 00:31:22,960 the end user. I mean is wherever that needs to initially make that request 432 00:31:23,640 --> 00:31:29,359 is essentially providing some identifier that wherever else it needs to be doing those lookups 433 00:31:29,359 --> 00:31:32,640 like you said, so it doesn't necessarily need to know when the request was 434 00:31:32,680 --> 00:31:37,160 processed. Right. The example I love to use in terms of visually two 435 00:31:37,400 --> 00:31:41,680 is if you're in AS, you're you're in AWS wherever, and let's say 436 00:31:41,680 --> 00:31:47,680 you go to stop, restart or do something with some type of resource. 437 00:31:48,400 --> 00:31:51,920 You know that's not happening immediately. You're not just like making that request. 438 00:31:52,000 --> 00:31:56,039 Then know this VM is stopping like it just stopped like right, Like it's 439 00:31:56,079 --> 00:32:00,079 an asynchronous process, you know for sure, that that thing behind the scenes 440 00:32:00,640 --> 00:32:04,880 is queuing that up for that request to be process. Now, in terms 441 00:32:04,920 --> 00:32:08,440 of feedback, like we're talking about, if that is a thing where you're 442 00:32:08,839 --> 00:32:13,920 behind the scenes providing some identifier, it may be using i mean some type 443 00:32:13,920 --> 00:32:17,559 of web sockets connection to get pushed back down of that update happening, which 444 00:32:17,640 --> 00:32:21,240 most of them do, so that you kind of get that instant feedback, 445 00:32:21,279 --> 00:32:24,200 but it's not really full proof if you've ever used it before. So you 446 00:32:24,240 --> 00:32:28,319 are refreshing to kind of see the latest, and there's usually your little refresh 447 00:32:28,359 --> 00:32:30,839 button there for that purpose, but you know it's in the indicated to you. 448 00:32:30,920 --> 00:32:35,759 It's like it's stopping, it's restarting and shutting down. It's you know, 449 00:32:35,799 --> 00:32:38,000 it's not instant. Yeah, absolutely, And Derek coming in and run 450 00:32:38,039 --> 00:32:44,400 for one moment for this very important message. There is always something new from 451 00:32:44,400 --> 00:32:47,759 our sponsor, text Control. As a developer, do you need to integrate 452 00:32:47,799 --> 00:32:53,160 PDF generation, document editing, or electronic signatures into your asp net corp or 453 00:32:53,200 --> 00:32:58,960 angular applications, or you want to learn more about the differences between electronic and 454 00:32:59,079 --> 00:33:04,920 digital signatures. Text Control is offering a free consulting service to educate you about 455 00:33:04,960 --> 00:33:08,920 digital document processing and how text control products can help you add these features to 456 00:33:08,960 --> 00:33:15,240 your applications. Go to text control dot com, slash contact and request your 457 00:33:15,279 --> 00:33:23,480 free personal consultation and we're back. It's done at Rocks. I'm Richard Campbell. 458 00:33:23,480 --> 00:33:27,680 That's Carl Franklin, Hey, and talking to our new friend Derek O. 459 00:33:27,759 --> 00:33:30,400 Martin, who writes his great blog posts on Code Opinion and as an 460 00:33:30,400 --> 00:33:37,240 excellent YouTube channel, talking about scaling the monolith. That being said, have 461 00:33:37,400 --> 00:33:40,440 you seen scenarios where micro services were the right choice? I think so. 462 00:33:40,720 --> 00:33:45,200 I think, Oh well, let me start by saying I can't deal with 463 00:33:45,240 --> 00:33:49,960 the micro part of the word there. Yeah, it's just silly. Yeah 464 00:33:50,079 --> 00:33:58,079 it is, but yeah, I know, um, but I think it's 465 00:33:58,200 --> 00:34:01,720 I think it's applicable. I think I wish the industry would get more on 466 00:34:02,759 --> 00:34:09,679 thinking in terms of monolith and micro services, but rather thinking about logical boundaries 467 00:34:09,679 --> 00:34:14,280 and physical boundaries. I wish we could just term it that way. So 468 00:34:14,360 --> 00:34:16,320 I mean by that right is thinking about if you're defining, like if you 469 00:34:16,320 --> 00:34:21,440 have some type of large system, define logical boundaries, which I say are 470 00:34:21,599 --> 00:34:27,400 incredibly important to do, yet they're really difficult to quote unquote get right. 471 00:34:27,480 --> 00:34:30,960 Because of what right kind of changes as things evolved. Sure, but it's 472 00:34:31,000 --> 00:34:37,039 thinking about what does your system do, like what what pieces of functionality? 473 00:34:37,519 --> 00:34:43,599 Where's the value defining those piece of functionality, grouping that altogether logically, and 474 00:34:43,639 --> 00:34:46,599 then deciding, okay, once we have all this, how do we deploy 475 00:34:46,679 --> 00:34:50,639 this? What's the physical aspect of this? Right? Can this all to 476 00:34:50,679 --> 00:34:53,800 be deployed together? Can this be all composed into a single unit? And 477 00:34:53,920 --> 00:35:00,360 maybe this is just deployed as a container, maybe always built separate correcting because 478 00:35:00,360 --> 00:35:05,000 a unit yep, deployed as a unit. Maybe we are using messaging and 479 00:35:05,079 --> 00:35:10,599 queuing and it's still underneath the hood using the same like all that same code, 480 00:35:12,360 --> 00:35:15,920 but the entry points are different rather than let's say we had our first 481 00:35:15,960 --> 00:35:20,400 piece of the puzzle here was an htb API or some web AP, but 482 00:35:20,440 --> 00:35:22,880 there's still a queueing component of that, which could be just a separate container 483 00:35:22,960 --> 00:35:28,559 that's listening to whatever queuing message bus or you know what I mean, broker 484 00:35:28,639 --> 00:35:31,800 that we're using, still using the same underlying code. So there's just this 485 00:35:32,239 --> 00:35:37,800 aspect of we could compose this however physically that we want to. One logical 486 00:35:37,800 --> 00:35:43,199 boundary could be deployed independently if it needs to scale and it has different resources. 487 00:35:43,519 --> 00:35:49,159 That's a certainly situation I've run into where we realized we're scaling this large 488 00:35:49,199 --> 00:35:52,239 set of classes, most of which are not being called in each of the 489 00:35:52,280 --> 00:35:57,039 scale instances. But you know, there's just one problem a child that gets 490 00:35:57,039 --> 00:36:00,960 called a lot, and if we peel it out of that larger ball of 491 00:36:00,039 --> 00:36:05,639 goo, it'll scaree. It's easier to ramp that up, it's lighter weight 492 00:36:05,679 --> 00:36:09,760 to do so, and the rest you don't need is a bunch of the 493 00:36:09,800 --> 00:36:13,800 other stuff. So it's just like pull the too part together in exchange to 494 00:36:13,840 --> 00:36:17,400 the complexity of now we have another security boundary, we have another API boundary, 495 00:36:17,480 --> 00:36:22,079 like all of those things had to be addressed in exchange. Absolutely, 496 00:36:22,079 --> 00:36:24,000 Like it's trade offs, right if you all of a sudden want to decide, 497 00:36:24,000 --> 00:36:27,559 Okay, we're gonna peel out this part, and a lot of this 498 00:36:27,599 --> 00:36:31,960 comes down to how you're coupling between these logical boundaries, right, So that's 499 00:36:32,320 --> 00:36:36,079 kind of a big factor in whether you're going to be able to extract something, 500 00:36:36,800 --> 00:36:38,719 but how you're doing that. But if you decide that is something you 501 00:36:38,760 --> 00:36:43,679 need to do, like you said, for scale, purposes. Then you 502 00:36:43,840 --> 00:36:49,559 have a lot of options about just in terms of how you're communicating with the 503 00:36:49,559 --> 00:36:54,360 other logical boundaries. Whether that's something that you hopefully from the start maybe went 504 00:36:54,480 --> 00:36:58,920 down a more loosely coupled route, but I realized that's not always the case. 505 00:36:59,599 --> 00:37:01,159 But you realize that, Okay, if you weren't, and you were 506 00:37:01,159 --> 00:37:06,840 doing in process calls, say between logical we'll call service A and service B, 507 00:37:07,559 --> 00:37:10,760 and now you're going to do that over HTTP, gRPC, whatever the 508 00:37:10,760 --> 00:37:17,360 case with some request response that's latency. There's a whole lot of that's not 509 00:37:17,639 --> 00:37:22,000 like, oh, we're loosely coupled now because we have two services that communicate 510 00:37:22,039 --> 00:37:27,400 over the network. No, you just created a huge performance bottle, exactly 511 00:37:27,559 --> 00:37:31,480 done, exactly so, thinking that's why I said I don't love the monolith 512 00:37:31,639 --> 00:37:37,320 versus micro services. I'd rather the conversation was around, Okay, let's define 513 00:37:37,400 --> 00:37:42,559 logical boundaries and then separately, let's talk about how these things are deployed. 514 00:37:43,079 --> 00:37:45,280 Right, So, what are the logical boundaries? I mean, scale is 515 00:37:45,400 --> 00:37:49,559 one of them, but I'm sure there's others in well, So the way 516 00:37:49,599 --> 00:37:53,840 I often think of logical boundaries, the way I describe it because I lived 517 00:37:53,920 --> 00:37:59,880 in warehousing and distribution for a long time. And my explanation of this of 518 00:38:00,079 --> 00:38:01,960 how to think about it is, Okay, yes, you have a warehouse 519 00:38:02,000 --> 00:38:07,519 system. It's enormous, right, it does everything, It does a whole 520 00:38:07,599 --> 00:38:10,360 lackload of things. It runs the entire company essentially. So what does that 521 00:38:10,400 --> 00:38:15,280 mean though, Well, it's if you think about it, if you were 522 00:38:15,280 --> 00:38:17,159 just to think about the business itself, there's a lot of departments, like 523 00:38:17,239 --> 00:38:23,159 they're shipping and receiving, there's sales, there's purchasing, accounting, the warehouse 524 00:38:23,199 --> 00:38:27,840 itself, people working in the warehouse, and if you want to think of 525 00:38:27,840 --> 00:38:30,119 it that way, at a sense, that is a logical boundary, and 526 00:38:30,159 --> 00:38:34,400 that would be a logical boundary in your system. And kind of the way 527 00:38:34,440 --> 00:38:37,760 that I like to use to describe this is if you were working in that 528 00:38:37,800 --> 00:38:42,599 system and you're talking to anybody that works in that business, and you're to 529 00:38:42,599 --> 00:38:45,559 go to them and you say, like, what's a product, they would 530 00:38:45,559 --> 00:38:50,559 all give you different answers because each one of them has a different concern about 531 00:38:50,599 --> 00:38:54,199 what a product is. Right, So if you're talking to somebody in sales, 532 00:38:54,280 --> 00:38:59,199 they care about the price. If you're talking to somebody and purchasing they're 533 00:38:59,239 --> 00:39:02,280 talking about like the vendor cost manufacturer. If you're talking to something in the 534 00:39:02,280 --> 00:39:06,800 warehouse, they care none of that. They just care about where's that product 535 00:39:06,880 --> 00:39:12,039 physically in the warehouse or warehouses. They just have different concerns. So I 536 00:39:12,079 --> 00:39:16,079 think that's where the kind of the I think people get in trouble is thinking 537 00:39:16,199 --> 00:39:22,280 of quote unquote entities as there's like one singular like be all end all of 538 00:39:22,320 --> 00:39:27,760 a product, right, But there's not. It's it's logically it's the same 539 00:39:27,960 --> 00:39:30,639 product, but it just exists in different ways, in different logical boundaries. 540 00:39:30,719 --> 00:39:35,159 Yeah, and that's normal. It's always been true. It just becomes more 541 00:39:35,199 --> 00:39:38,079 apparent as you press against these kinds of problems. And that's the thing is 542 00:39:38,079 --> 00:39:42,639 that when you think about when you think about them that way, and you 543 00:39:42,679 --> 00:39:45,079 think, okay, okay, I have this subset of functionality that we're performing 544 00:39:45,119 --> 00:39:49,920 on, like in sales, for example, about how we sell products, 545 00:39:49,920 --> 00:39:53,239 their prices, their discounts, all those types of things, and you have 546 00:39:53,360 --> 00:39:58,719 some other like let's say purchasing. As was using the example and thinking about 547 00:39:58,800 --> 00:40:04,320 vendors. It's kind of liberating in a sense because they're different ways of thinking 548 00:40:04,400 --> 00:40:08,039 about it and not conflating two ideas together, which then in terms of your 549 00:40:08,039 --> 00:40:12,000 codebase, you're starting to think about, okay, well it's not just this 550 00:40:12,280 --> 00:40:16,360 what I call entity services where it has all this mixed behavior about all these 551 00:40:16,400 --> 00:40:22,440 things. It's no. Then you become a little bit more focused on what 552 00:40:21,599 --> 00:40:24,079 the how I say is, like, what the capabilities are of that logical 553 00:40:24,079 --> 00:40:30,719 boundary. The biggest part is usually is inevitably these things need to be composed 554 00:40:30,760 --> 00:40:36,000 in some way. Yeah, that represent a product. Like if some users 555 00:40:36,039 --> 00:40:37,360 on a screen, they might want to see, okay, well what's the 556 00:40:37,360 --> 00:40:42,760 sale price and what's the actual purchase price? Right, So how you're composing 557 00:40:42,800 --> 00:40:46,199 those things if you're in process together, well, maybe you are just making 558 00:40:46,320 --> 00:40:52,599 API calls, I mean in process from as it was. Let's use the 559 00:40:52,639 --> 00:40:55,760 example of you are making these things different projects within a solution. Maybe it's 560 00:40:55,760 --> 00:41:00,480 just some interface that you're calling, some type of class that you're calling to 561 00:41:00,480 --> 00:41:04,119 get that data. But there's still that boundary there physically that you're doing. 562 00:41:04,199 --> 00:41:06,400 It's just how you wanted to then do that. If like you're saying, 563 00:41:06,440 --> 00:41:08,920 if you're kind of ripping it apart, you need to be aware about when 564 00:41:08,920 --> 00:41:12,320 you're going ahead of this, like ahead of time. Okay, we're gonna 565 00:41:12,360 --> 00:41:15,079 rip this out and then we have all these in process calls. That's going 566 00:41:15,119 --> 00:41:16,880 to be a problem. Yeah, where where is it going to? Where 567 00:41:16,920 --> 00:41:19,960 is it going to impact things? You can't just pull it out and hope 568 00:41:19,960 --> 00:41:22,400 for the best. Do You need to have some sense of organization and where 569 00:41:22,960 --> 00:41:29,039 where the code dependencies actually exist and decide if it's actually worthwhile too, Right, 570 00:41:29,039 --> 00:41:31,280 there can be cases where it's like the performance gains just not enough for 571 00:41:31,360 --> 00:41:37,920 the complexity being added. Yeah, that's one of the thing with complexity is 572 00:41:37,920 --> 00:41:40,760 it's it's you're moving. You're getting pretty high when you don't need to if 573 00:41:40,800 --> 00:41:45,280 you don't need to move stuff out of process. Right, It's just I 574 00:41:45,280 --> 00:41:50,119 guess there's this sense that moving stuff out of process, are starting that way 575 00:41:50,199 --> 00:41:58,400 immediately for the sake of scale. Is I'm genuinely curious sometimes that people really 576 00:41:58,440 --> 00:42:02,920 know what they're getting into in terms of all the like just deployment in I 577 00:42:04,079 --> 00:42:08,199 realize things like open telemetry are awesome, but not that simple. It's not 578 00:42:08,239 --> 00:42:13,519 that simple. Well, this is this is the developer credo. We we 579 00:42:14,000 --> 00:42:16,440 did these things not because they're easy, but because we thought they were easy. 580 00:42:16,599 --> 00:42:19,840 Yeah, I want to hear you say that with a John F. 581 00:42:19,960 --> 00:42:29,400 Kennedy accent. Not because they are easy easy, but you know, we 582 00:42:29,440 --> 00:42:32,320 have this terrible disease in software development where we keep calling stuff easy that clearly 583 00:42:32,320 --> 00:42:36,199 has never been easy. Like virtually none of this is easy. You may 584 00:42:36,280 --> 00:42:38,719 know how to do it, but that doesn't make it easy. All everything 585 00:42:38,800 --> 00:42:43,840 is effort, and everything comes with a cost. And and you know, 586 00:42:44,039 --> 00:42:46,719 and you're and you're shifting problems around. There's no free lunch here, not 587 00:42:46,800 --> 00:42:51,360 a bit. I think it's a good way of thinking about as shifting problems 588 00:42:51,360 --> 00:42:54,320 are like just creating I was creating problems you're yeah, I mean you're trying 589 00:42:54,320 --> 00:42:59,360 to come up with solutions. But everything we've mentioned right in terms of cashing 590 00:42:59,719 --> 00:43:05,400 or read replicas and queuing, they all come with a lot of trade offs, 591 00:43:05,440 --> 00:43:08,559 a lot of complexity that you're adding that you need to be like that 592 00:43:08,679 --> 00:43:12,840 it's got to come with value, like you actually need need it. And 593 00:43:12,920 --> 00:43:15,239 if you're unfamiliar with it, some of these things that you're going to get 594 00:43:15,280 --> 00:43:20,440 a root awakening, right, Well, that's an overhead too. If how 595 00:43:20,440 --> 00:43:23,760 long is it going to take to learn this to do it decently. But 596 00:43:23,920 --> 00:43:29,039 also I don't think there's any way to predict the outcome, Like you can't 597 00:43:29,159 --> 00:43:30,280 do a calculus and go, hey, if we do this, we'll get 598 00:43:30,320 --> 00:43:35,880 sufficient performance for effort. In some ways, there's almost no way around putting 599 00:43:35,880 --> 00:43:39,039 out the effort to get to a point to even know this has a return. 600 00:43:39,639 --> 00:43:44,760 And that's certainly the challenge I had was scaling anything was we're going to 601 00:43:44,880 --> 00:43:46,559 try this, well, you do it as quickly as we can, but 602 00:43:46,599 --> 00:43:49,440 we're not really going to know the results to we do it. I mean, 603 00:43:49,440 --> 00:43:52,880 hopefully we measured before we started so that we can measure after we've done 604 00:43:52,920 --> 00:43:55,280 it to say there was a return. The number of times I've seen stuff 605 00:43:55,280 --> 00:44:00,159 people just do things and go does it feel faster to you? LIKEE know, 606 00:44:00,320 --> 00:44:05,559 faster. That's the thing brings up a good point in terms of measuring, 607 00:44:05,599 --> 00:44:08,079 because a lot of this now for me is it's it's purely based on 608 00:44:08,119 --> 00:44:13,039 that of knowing, just having metrics, having some type of visibility, and 609 00:44:13,360 --> 00:44:16,000 how your systems performing. Besides the well, this seems slow, It's like 610 00:44:16,079 --> 00:44:21,519 yeah, is it? It only seems slow because the CTO keeps telling me 611 00:44:21,599 --> 00:44:25,000 it's slow. Yeah, everything seems slow. Nothing's quite fast enough generally. 612 00:44:25,199 --> 00:44:30,719 Yeah, well and is that return right? Like, how much faster can 613 00:44:30,760 --> 00:44:32,639 I make this? Yeah, I'm used to. I'm used to using an 614 00:44:32,639 --> 00:44:37,079 I nine computer that I built myself. That's just the fastest thing I've ever 615 00:44:37,159 --> 00:44:42,239 used in my life. And the other day I set up a webcam using 616 00:44:42,320 --> 00:44:47,719 one of those little Intel Mini stick computers for gigs of RAM or something like 617 00:44:47,760 --> 00:44:52,920 that. And if you know, watching that thing just crawl, you know, 618 00:44:53,079 --> 00:44:58,360 just sit there at a prompt thinking and thinking and thinking, and I'm 619 00:44:58,440 --> 00:45:04,599 thinking, wait for computers like this and we don't even realize it because they 620 00:45:04,599 --> 00:45:07,599 were they were so slow, they weren't realize there's a slow until we've got 621 00:45:07,599 --> 00:45:10,679 something faster. Well, I think when we move back kind of in the 622 00:45:10,679 --> 00:45:15,360 conversation and we were talking about, I mean being elastic and having those options, 623 00:45:15,400 --> 00:45:20,440 it's it really is incredible now to be able to do it in terms 624 00:45:20,480 --> 00:45:23,679 of land as in anything, even if we're talking about just the ability to 625 00:45:23,719 --> 00:45:30,760 scale up quickly with minimal minimal downtime kind of gives you that option when even 626 00:45:30,760 --> 00:45:34,599 if it's just for a moment of time where you don't really know what the 627 00:45:34,639 --> 00:45:37,559 heck's going on and you're having issues, you can do it and at least 628 00:45:37,679 --> 00:45:42,400 kind of weather the storm a little bit so you can investigate what what you're 629 00:45:42,400 --> 00:45:45,000 going to do. But I generally find most of these things they're they're kind 630 00:45:45,000 --> 00:45:49,719 of if you have metrics, if you know what's happening in your system, 631 00:45:49,840 --> 00:45:52,519 you can kind of tell slowly over time where things are going to start going 632 00:45:52,559 --> 00:45:57,320 south, whether like what infrastructure it is, what resources it is it is 633 00:45:57,320 --> 00:46:00,559 it your app compute, is it your day to base, is it your 634 00:46:00,639 --> 00:46:07,639 cash whatever services you're using. Ultimately you can kind of start telling. But 635 00:46:07,679 --> 00:46:09,679 it's I find one of those things that's usually you know the metrics, usually 636 00:46:09,679 --> 00:46:13,760 when it's somewhat too later, you don't have the foresight to know what you 637 00:46:13,800 --> 00:46:16,440 need to measure now. I mean when you really go back and read that 638 00:46:16,559 --> 00:46:22,000 post by Prime Video, you see exactly that. Over time as we measured 639 00:46:22,039 --> 00:46:25,880 it, we saw performance problems, we saw them with problems, and we 640 00:46:25,920 --> 00:46:30,960 saw costs increases. Like they didn't know when they went into this. I 641 00:46:30,960 --> 00:46:34,480 mean one would argue they built it server list because it was quick, it 642 00:46:34,559 --> 00:46:37,760 was an easy way to go, and it's only after it ran for a 643 00:46:37,800 --> 00:46:40,679 while and it got more popular. It's like, huh, now, let's 644 00:46:40,719 --> 00:46:46,159 and they literally say, let's revisit architecture because you have that option and got 645 00:46:46,239 --> 00:46:52,239 great results from the revisit, Like this is actually a good news story. 646 00:46:52,599 --> 00:46:54,960 I think it was, And especially at the end of it, I believe 647 00:46:55,000 --> 00:46:58,920 at the end of that post they were saying how most of the code was 648 00:46:59,000 --> 00:47:01,679 reused. It was it's basically pulling it out of landas that were howard they 649 00:47:01,719 --> 00:47:06,960 were being invoked, and it's putting it into that process that's being executed in 650 00:47:07,239 --> 00:47:10,480 as a container in ECS, like they did a platform shift, like this 651 00:47:10,559 --> 00:47:15,800 is actually wicked cool that a lot of this code was just fine, but 652 00:47:15,840 --> 00:47:17,800 when you shifted the platform around, and if you shifted the platform around, 653 00:47:19,000 --> 00:47:22,599 you got rid of a bunch of contention, it reduced costs, Like there 654 00:47:22,679 --> 00:47:25,719 was all these benefits as different architecture. Would it work for you? Done? 655 00:47:25,719 --> 00:47:30,599 O, You got to go measure what you're doing right now to try 656 00:47:30,599 --> 00:47:34,360 and compare against other architectures. I think that's the most difficult thing. I 657 00:47:34,360 --> 00:47:37,480 think you alluded to you earlier. It's just like we want this cookie cutter 658 00:47:37,559 --> 00:47:39,159 solution that this is just going to work all the time, and it's just 659 00:47:39,320 --> 00:47:43,280 not the case. It's just like the one right way. Please. Yeah, 660 00:47:43,320 --> 00:47:46,840 it's just not the case. It doesn't exist. It's very it's very 661 00:47:46,880 --> 00:47:51,960 funny just that. Yeah. I wish it was that simple, but there's 662 00:47:52,000 --> 00:47:54,239 too many different kinds of workloads, and there's too many different ways at things 663 00:47:54,280 --> 00:47:58,159 evolved. You know, I wonder if this was a great solution when they 664 00:47:58,199 --> 00:48:02,159 started. I think it was. I how I remember it correctly is like 665 00:48:02,199 --> 00:48:07,039 I think their exact kind of message was we never intended it to be at 666 00:48:07,079 --> 00:48:12,239 the scale that it was. Yeah, so when and I dealt with lots 667 00:48:12,239 --> 00:48:14,440 of e commerce sites like that, we thought it was only going to have 668 00:48:14,440 --> 00:48:16,079 this many customers, and then it got all this much bigger. It's like, 669 00:48:16,119 --> 00:48:21,840 wow, great problem, Like part of this is his whole You ain't 670 00:48:21,880 --> 00:48:25,280 gonna need it. Like how do you go into a complex architecture having no 671 00:48:25,440 --> 00:48:29,679 idea if the product's really going to take off or not? To build it 672 00:48:29,719 --> 00:48:34,400 as simply as possible, because delivering it is an important value too, you 673 00:48:34,440 --> 00:48:37,280 know. One way to make sure it never provides value is never finished the 674 00:48:37,400 --> 00:48:39,679 darn thing, because you made an architecture is so complicated it takes forever to 675 00:48:39,679 --> 00:48:43,320 get it built. Yeah, it is. And when we go back to 676 00:48:43,360 --> 00:48:46,480 the kind of the one way that this is going to work is it is 677 00:48:46,519 --> 00:48:52,880 it's it's starting simply based on what you're aware of kind of that space. 678 00:48:52,079 --> 00:48:54,519 But like I said, if you if you focus to me, if you 679 00:48:54,599 --> 00:48:59,840 focus on defining logical boundaries, trying its best you can to understand the coupling 680 00:49:00,000 --> 00:49:02,360 between them, You've got a lot of options about why you can choose. 681 00:49:02,480 --> 00:49:05,599 Then you can choose how you want to do this stuff. Like you said, 682 00:49:05,599 --> 00:49:09,840 if there's one particular part of your system that is heavily overloaded, yeah, 683 00:49:09,880 --> 00:49:14,920 maybe that's where you choose to remove it and peel it off and scale 684 00:49:14,960 --> 00:49:16,039 it on its own and see if that's sufficient. You know. The other 685 00:49:16,039 --> 00:49:21,679 thing about that good architecture, that separation and concerns is the experiments are easier 686 00:49:21,719 --> 00:49:24,880 too. Yeah, well, I to based on experiments. I would also 687 00:49:24,880 --> 00:49:29,960 say that not everything needs to be created the same way, right right, 688 00:49:30,000 --> 00:49:34,400 So that means that if each if each boundary has defines how it wants to 689 00:49:34,400 --> 00:49:37,679 do a storage and that could be still the same underlying physical database. Instance, 690 00:49:37,920 --> 00:49:40,320 Let's say it like, hey, we're using this relational database for the 691 00:49:40,440 --> 00:49:44,920 entire thing, the exact same data we got it. Yeah, we're not 692 00:49:44,960 --> 00:49:47,719 gonna like split these things up more costs also just to use the exact same 693 00:49:47,800 --> 00:49:52,119 instance. It could be in the same physical database. But hey, these 694 00:49:52,239 --> 00:49:57,559 particular tables are owned by this particular boundary. Don't go start muddling in my 695 00:49:57,679 --> 00:50:00,440 stuff, right, Like, defind some type of API we want to exchange 696 00:50:00,440 --> 00:50:05,440 this if we need to. Yeah, but just define those boundaries and then 697 00:50:05,639 --> 00:50:08,880 from there maybe you decide later on, you know what, like this particular 698 00:50:08,880 --> 00:50:14,639 boundary that relational just wasn't a good choice here isn't needed. So yeah, 699 00:50:14,679 --> 00:50:17,599 so like when you're staying like experiment, it's like you get that option, 700 00:50:19,000 --> 00:50:22,920 right, It's and it's not like you're doing this because you want that option. 701 00:50:22,960 --> 00:50:25,000 It's just you're getting it kind of. It kind of is a little 702 00:50:25,000 --> 00:50:29,079 free lunch. And that's it comes at the complexity of you have to define 703 00:50:29,079 --> 00:50:32,320 these boundaries. It's not just one massive thinks about it. Yeah, but 704 00:50:32,400 --> 00:50:36,360 also now that you have that boundary, it's like, hey, would this 705 00:50:36,440 --> 00:50:39,599 be better served in an object store instead of a relational database. Well, 706 00:50:39,679 --> 00:50:43,639 let's let's see what it takes to do that. You know, maybe a 707 00:50:43,679 --> 00:50:45,639 little spike on it to do some experimentation, and it's like, hey, 708 00:50:45,639 --> 00:50:49,119 this works pretty good. I'll finish implementing it, and then let's do some 709 00:50:49,159 --> 00:50:52,039 benchmarks. You know, I've added that they you know, then we'll maybe 710 00:50:52,079 --> 00:50:55,360 deal with some of the complexity around it. Like it is. These are 711 00:50:55,440 --> 00:51:01,719 fun explorers too, right, Like I found I had pretty good patterns for 712 00:51:01,760 --> 00:51:05,960 scaling websites because I did a ton of them, and I was often right. 713 00:51:06,559 --> 00:51:09,480 But you'd get into more esoteric systems, more interior type architectures, you're 714 00:51:09,559 --> 00:51:13,760 like, yeah, I see that this is likely the bottleneck. I see 715 00:51:13,800 --> 00:51:15,920 three ways for us to try and scale us. I can't tell you which 716 00:51:15,920 --> 00:51:21,960 one's gonna win, Like, we've got to try exactly. And I think 717 00:51:22,239 --> 00:51:25,880 kind of my point when I wrote this post even some of the videos is 718 00:51:25,920 --> 00:51:30,559 just there's just you have different ways of dealing with it, right, So 719 00:51:30,599 --> 00:51:34,760 whether that be scaling up, scaling out, knowing where you're going to kind 720 00:51:34,800 --> 00:51:38,719 of move that ballneck move that problem, whether you're off floating work with queues, 721 00:51:38,840 --> 00:51:44,800 messaging, whether it be materialized views for queries, and the other point 722 00:51:44,840 --> 00:51:47,960 I want to make is, at least in my experience, is generally there's 723 00:51:49,000 --> 00:51:52,360 hot paths. Right, Like, especially in big systems, I always kind 724 00:51:52,360 --> 00:51:55,880 of use eighty twenty rule, is that you're going to have the twenty percent 725 00:51:55,960 --> 00:52:01,199 that's causing all your havoc basically right, and just being able to optimize those 726 00:52:01,239 --> 00:52:06,079 So whether that be never mind from an infrastructure point of view, but just 727 00:52:07,280 --> 00:52:09,360 let's look at where those routes are, Like, let's look at those code 728 00:52:09,360 --> 00:52:13,840 pass What can we be doing there? Specifically? Are we making too many 729 00:52:13,880 --> 00:52:15,800 round trips in the database? Maybe we're just doing something absurd where we're just 730 00:52:16,000 --> 00:52:21,280 hitting our database and fetching able to a whole lot of nonsense that we don't 731 00:52:21,320 --> 00:52:24,719 need. You'd be surprised how much that happens. So it's even just and 732 00:52:24,760 --> 00:52:29,320 it can be cost effective, as crazy as sounds. Sometimes it's like, 733 00:52:29,679 --> 00:52:32,320 let's just spend some time doing this, Like, let's just look at what 734 00:52:32,320 --> 00:52:37,360 we're actually doing. The question is do you know what twenty percent or do 735 00:52:37,400 --> 00:52:39,599 you have to get out of the field and run it for a while ago, 736 00:52:39,639 --> 00:52:44,039 Oh, this is the twenty percent that's the problem shelves. I think 737 00:52:44,079 --> 00:52:46,400 metrics, but I think intuitively in a large system, least in my experience, 738 00:52:46,719 --> 00:52:52,159 you know what that core part of functionality is generally I think even from 739 00:52:52,199 --> 00:52:54,760 if you were to ask, say, people on the business side, like 740 00:52:54,800 --> 00:52:59,199 hey, and the app, where do you think the most action is at 741 00:52:59,280 --> 00:53:01,400 the because that's what they're in most of the time, right, Like it's 742 00:53:01,639 --> 00:53:04,960 I would say, there's kind of the core part of your system as well 743 00:53:05,000 --> 00:53:12,199 as that fringe supporting more generic stuff. So like when I was talking about 744 00:53:12,320 --> 00:53:15,280 distribution, say let's say like CRM or something like that, maybe you're like, 745 00:53:15,280 --> 00:53:17,280 you know what, that's not a big part of our business. We 746 00:53:17,280 --> 00:53:21,400 have some rudimentary thing for dealing with customers. It's really not that big a 747 00:53:21,400 --> 00:53:23,079 deal. Like our bread and butter is warehouse management, and that's where all 748 00:53:23,079 --> 00:53:27,599 the complexity is, right, so you kind of know to a degree, 749 00:53:27,639 --> 00:53:30,320 I think even on the business side, they could probably give you some hints. 750 00:53:30,840 --> 00:53:35,079 Well, in the web world, nobody ever went wrong tuning a landing 751 00:53:35,119 --> 00:53:37,239 page, you know, because it just had so much traffic, like it 752 00:53:37,280 --> 00:53:40,199 was pretty much a guaranteed win. It spends some time in there or usually 753 00:53:40,199 --> 00:53:43,880 it was just you got to a point where it's like, hey, the 754 00:53:43,920 --> 00:53:49,320 incremental improvement left is so small you can't justifind more time on it. There 755 00:53:49,320 --> 00:53:53,239 are easier winds elsewhere, but they may not be as important. Ah, 756 00:53:53,280 --> 00:53:57,639 it's a fun battle, you know. It's not like there's any simple solution 757 00:53:57,639 --> 00:54:00,280 to this. You've got to go out measure and feel an ound and hypothesize 758 00:54:00,320 --> 00:54:04,559 and build some tests and push a little further. But I wonder if we're 759 00:54:04,559 --> 00:54:07,000 speaking heresy here, because last time I look, there's a cloud and I 760 00:54:07,039 --> 00:54:09,639 just have a knob I have to turn up right, Like, isn't there? 761 00:54:09,639 --> 00:54:13,440 They go faster knob of everything related to the cloud. You just spend 762 00:54:13,480 --> 00:54:17,519 more. I mean too, I like we're joking, but like somewhat yea 763 00:54:17,840 --> 00:54:22,719 in this sense, right, it's at least being able to scale up in 764 00:54:22,760 --> 00:54:25,280 a lot of circumstances, like I can always shift to a larger VM, 765 00:54:25,360 --> 00:54:30,280 and they are perfectly willing to sell you a bigger and bigger VM these days. 766 00:54:30,280 --> 00:54:34,480 And seeing two is that you can do that with at least with app 767 00:54:34,519 --> 00:54:37,800 services on Azure you can. You can. It's really trivial to add and 768 00:54:38,280 --> 00:54:42,480 scale it up exactly like if you if you already are in the situation where 769 00:54:42,480 --> 00:54:46,320 all we we scale out, say maybe our web app and we're running three 770 00:54:46,360 --> 00:54:51,400 instances, but all of a sudden things are going south, and we'll just 771 00:54:51,440 --> 00:54:53,760 add more instances. But like I said, and that may work. You 772 00:54:53,800 --> 00:54:58,840 had one instance and then all of a sudden, you start noticing, like 773 00:54:58,880 --> 00:55:02,039 I said, downstream start suffering, and then it just bottleneck and you get 774 00:55:02,039 --> 00:55:06,199 a back end bottleneck. Like well, yeah, okay, you also have 775 00:55:06,280 --> 00:55:10,400 to be your code has to be able to handle multiple spanning, multiple machines. 776 00:55:12,000 --> 00:55:14,639 That's an old talk I used to do from one server to two. 777 00:55:14,800 --> 00:55:17,840 Yeah, you know, it's a pretty hard leap just to get to that 778 00:55:17,880 --> 00:55:22,800 point, you know what I mean. With Blazer server anyway, which is 779 00:55:22,800 --> 00:55:28,360 sort of like in my wheelhouse now that if you're using their um the signal 780 00:55:28,480 --> 00:55:34,119 ar service, it's pretty trivial. You there's affinity is turned on by default, 781 00:55:34,159 --> 00:55:37,679 so whatever, the first server that you logged into, that's the one 782 00:55:37,679 --> 00:55:40,320 that you're going to use for the rest of your session. And that's that's 783 00:55:40,440 --> 00:55:45,559 nice to not have to worry about that. Yeah, I think I think 784 00:55:45,559 --> 00:55:51,239 the scale ups scale out just with cloud just making it so much easier is 785 00:55:51,280 --> 00:55:54,559 great, and I leverage it quite often when things start going south. But 786 00:55:55,119 --> 00:55:58,559 I guess in experience, I kind of okay, well, like we got 787 00:55:58,599 --> 00:56:00,800 some thresholds here where I know, okay, if this is scaling out, 788 00:56:01,920 --> 00:56:06,760 this is when it's a little bit too far. I just can't infinitely scale 789 00:56:06,760 --> 00:56:09,280 out and everything's going to be going to be great. And to that effect 790 00:56:09,280 --> 00:56:14,480 too, A lot of it is things that aren't even in your control. 791 00:56:15,000 --> 00:56:20,559 So if you're leveraging, say some external services, and you're making requests to 792 00:56:20,599 --> 00:56:23,840 them, I don't know the examples, like say you're making a call to 793 00:56:24,639 --> 00:56:29,679 being Maps or Google Maps or any other service, some type of payment gateway, 794 00:56:29,679 --> 00:56:32,440 and you expect that to on the happy time, it only takes like 795 00:56:32,519 --> 00:56:37,480 hunter milliseconds, it's fine, and all of a sudden that thing starts taking 796 00:56:37,320 --> 00:56:40,199 seconds. Yeah, right, like all of a sudden. It's so, 797 00:56:40,360 --> 00:56:45,079 what the heck's going on? Where what we were mentioning with metrics that comes 798 00:56:45,079 --> 00:56:47,320 into play because you know, how matter how much you scale out, you 799 00:56:47,360 --> 00:56:52,360 ain't going to help that. Yeah, yeah, the simple So what's next 800 00:56:52,400 --> 00:56:58,960 for you, Derek? What's in your same old thing of just creating videos 801 00:56:59,000 --> 00:57:01,679 and blogs at all? Kind of pertain to everything we just talked about pretty 802 00:57:01,760 --> 00:57:06,519 much for the most part. Well, I'm going to urge our listeners to 803 00:57:06,639 --> 00:57:14,159 go check out your blog and continue reading it. Thanks so much for spending 804 00:57:14,159 --> 00:57:16,360 a time with us. It's been enlightening. Yeah, I appreciate this was 805 00:57:16,519 --> 00:57:19,960 this was really cool, all right, and we'll see you next time on 806 00:57:20,159 --> 00:57:45,119 dot net rocks. Dot net Rocks is brought to you by Franklin's Net and 807 00:57:45,239 --> 00:57:50,559 produced by Pop Studios, a full service audio, video and post production facility 808 00:57:50,880 --> 00:57:54,800 located physically in New London, Connecticut, and of course in the cloud online 809 00:57:54,800 --> 00:58:00,639 at pwop dot com. Visit our website at dt nt R o c ks 810 00:58:00,719 --> 00:58:07,239 dot com for RSS feeds, downloads, mobile apps, comments, and access 811 00:58:07,239 --> 00:58:10,719 to the full archives going back to show number one, recorded in September two 812 00:58:10,719 --> 00:58:15,280 thousand and two. And make sure you check out our sponsors. They keep 813 00:58:15,360 --> 00:58:19,039 us in business. Now go write some code, See you next time. 814 00:58:19,920 --> 00:58:21,519 You got a vand