WEBVTT 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