1 00:00:01,080 --> 00:00:04,799 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05,360 --> 00:00:09,480 Become a patron for just five dollars a month. You get access to a 3 00:00:09,480 --> 00:00:14,279 private RSS feed where all the shows have no ads. Twenty dollars a month. 4 00:00:14,279 --> 00:00:18,440 We'll get you that and a special dot net Rocks patron mug. Sign 5 00:00:18,519 --> 00:00:35,960 up now at Patreon dot dot NetRocks dot com. Hey, welcome back to 6 00:00:36,000 --> 00:00:39,719 dot net rocks. This is Carl Franklin and it's Richard Campbell. Steve Smith 7 00:00:39,759 --> 00:00:42,280 is with us. We'll be talking to him in a minute. But hey 8 00:00:42,320 --> 00:00:44,200 man, how are you doing. I haven't talked to you in a while. 9 00:00:44,320 --> 00:00:46,640 Uh, you know, we had a burst of shows and now we've 10 00:00:46,719 --> 00:00:49,000 you know, caught back up, so it's time to get back to work 11 00:00:49,039 --> 00:00:53,119 again. And I happen to be in Mexico. So okay, coming coming 12 00:00:53,159 --> 00:00:59,079 to you from the Grand look at the Vedanta Resort. How's your bandwidth good 13 00:00:59,159 --> 00:01:00,520 enough? You know, everybodybody else is at the pool, you know, 14 00:01:00,560 --> 00:01:06,200 because they're on vacation, right, so hopefully it holds together. But I'm 15 00:01:06,239 --> 00:01:08,439 recording locally. We'll be okay. All right, good, Well, let's 16 00:01:08,519 --> 00:01:19,640 start things off the right way with better no framework all right, all right, 17 00:01:19,640 --> 00:01:23,760 well Google is at it again, Yes they are. They now have 18 00:01:23,959 --> 00:01:27,239 this deep you know, Google Deep Mind, their AI thing, Yeah, 19 00:01:27,280 --> 00:01:32,480 the original, the original AI guys, the reason that Open AI was made. 20 00:01:32,799 --> 00:01:36,359 Yeah. So they have this Genie team, and they came out with 21 00:01:36,439 --> 00:01:42,920 Genie, which is a generative interactive environment creator. It's so no wishes, 22 00:01:42,519 --> 00:01:49,879 yeah yeah, and you can't wish for more wishes. So we introduced Genie, 23 00:01:49,920 --> 00:01:56,840 a foundation world model trained from Internet videos that can generate an endless variety 24 00:01:56,920 --> 00:02:02,840 of playable action controllable worlds from synthetic images, photographs, and even sketches. 25 00:02:04,560 --> 00:02:07,960 So the idea is that you can sketch some things, or find some things, 26 00:02:08,080 --> 00:02:12,680 or just say, give me something that looks like this, and you 27 00:02:12,719 --> 00:02:17,319 can make side scrolling games, you know, like Mario Brothers kind of thing 28 00:02:17,599 --> 00:02:23,879 awesome from them automatically. At least that's what I think it is. I 29 00:02:23,879 --> 00:02:29,039 haven't done it, and it looks like the Really the only application is sort 30 00:02:29,039 --> 00:02:34,039 of controlling and animating sprites and a background in a two D scrolling world. 31 00:02:34,400 --> 00:02:37,439 Perhaps, yeah, but to do it with regular text just means a whole 32 00:02:37,439 --> 00:02:38,879 lot of other people think they can be video games. Now. Yeah, 33 00:02:38,960 --> 00:02:44,479 well I'm not really sure if it's well, it's a text image generation model, 34 00:02:44,520 --> 00:02:47,479 so you're right there. Yeah, but I don't know. I'm not 35 00:02:47,560 --> 00:02:53,360 really that much of a video game guy to think that this is something I 36 00:02:53,360 --> 00:02:55,080 want to look at now. But I also like the idea of just generating 37 00:02:55,080 --> 00:02:59,960 animations. Of course, we just recently had the announcement of Open AI Sorrow, 38 00:03:00,719 --> 00:03:05,479 which was more like thirty second generated video. Clearly we're on a path 39 00:03:06,280 --> 00:03:10,240 of exploring more capabilities with generative AI. Yes, we are fun fun So 40 00:03:10,280 --> 00:03:13,599 anyway, that's what I got know and learned it loves He was talking to 41 00:03:13,639 --> 00:03:15,599 us Richard Campbell. Hey, I grabbed a comment off a show eighteen thirty 42 00:03:15,599 --> 00:03:19,800 one, the one we did with Steve back in February of last year twenty 43 00:03:19,800 --> 00:03:22,960 three, when we talked about clean architecture, because he's a clean kind of 44 00:03:23,000 --> 00:03:24,439 eye, and Ken had this comment by a year ago. He said, 45 00:03:24,439 --> 00:03:29,759 this is a great episode, but what about new Get Hell, I love 46 00:03:29,800 --> 00:03:32,120 they of putting things into new Get packages, but I can see it will 47 00:03:32,120 --> 00:03:35,599 get out of hand as well. You know, only if you update them, 48 00:03:35,680 --> 00:03:38,159 Ken, Right, as long as you just leave it with the original 49 00:03:38,159 --> 00:03:44,240 bugs, everything will be fine. An example is asp asp dot version ing. 50 00:03:44,520 --> 00:03:46,319 It's a great asp dot net versioning package. But the new get libraries 51 00:03:46,360 --> 00:03:49,759 have changed, so now the developers could be making a bunch of changes to 52 00:03:49,800 --> 00:03:52,800 the new new get packages, but they did two months ago, and then 53 00:03:52,840 --> 00:03:55,319 other developers would never get the new changes. Nothing against new Get. But 54 00:03:55,360 --> 00:03:59,080 it seems like anything you do in this monster programming world is not perfect. 55 00:03:59,240 --> 00:04:02,240 Yeah. True, it's just a question how difficult, right, And in 56 00:04:02,280 --> 00:04:05,280 the area of testing, because we talked about testing on that show too, 57 00:04:05,319 --> 00:04:09,319 the world changes and developers still need to learn on the fly. Who is 58 00:04:09,360 --> 00:04:13,960 testing my Cobald world that I was running back in ninety four or inherited DELFI 59 00:04:14,080 --> 00:04:18,920 from in nineteen ninety or that four point six dot two And he says in 60 00:04:18,959 --> 00:04:21,519 two thousand, which you know was in two thousand, It was like twenty 61 00:04:21,600 --> 00:04:26,199 fourteen, twenty fifteen. What about the C plus plus code the nineties? 62 00:04:26,360 --> 00:04:30,439 What testing framework should I use? X unit? What about Java? You 63 00:04:30,480 --> 00:04:33,519 know? Testing frameworks for everything? Ken case in point in the enterprise world. 64 00:04:33,800 --> 00:04:36,959 None of the programming world is perfect. I would include programming training as 65 00:04:38,000 --> 00:04:41,000 that as well, But without you guys doing this show, I'd be way 66 00:04:41,000 --> 00:04:44,360 more lost so thanks. Wow. Cool, that's very kind. Yeah, 67 00:04:44,360 --> 00:04:46,160 it's very kind, Thanks, Ken, miel No. I think it's an 68 00:04:46,160 --> 00:04:50,600 interesting problem. And you know, often these tools become an issue primarily because 69 00:04:50,639 --> 00:04:54,240 they've been successful. You know, if nobody was using new Get, it 70 00:04:54,240 --> 00:04:57,360 were great. I remember in the early days of NEWGAT there was such a 71 00:04:57,399 --> 00:05:02,040 thing as new Get hell quite literally, and it was very hard to manage, 72 00:05:02,199 --> 00:05:06,879 just as it was to manage without Newgat. But then they quickly fixed 73 00:05:08,040 --> 00:05:11,240 things up and ever since it's been really great. I think. Yeah, 74 00:05:11,279 --> 00:05:14,759 I think Newgat's amazing. Packet managers always have their challenges, like that's not 75 00:05:14,800 --> 00:05:16,839 going to go away, especially with visual studio tooling. You know, you 76 00:05:16,879 --> 00:05:21,839 can just update everything, which can be a problem also, you know, 77 00:05:21,920 --> 00:05:26,319 but at least you'll know which ones are the problem. Well, inevitably you'll 78 00:05:26,360 --> 00:05:28,720 know the most important thing, which is it is your fault. Yeah, 79 00:05:28,759 --> 00:05:30,560 of course, yeah, yeah, I blame you all right. Ken, 80 00:05:30,680 --> 00:05:33,600 Thanks for thanks for your comment, and a copy of music Coba is on 81 00:05:33,639 --> 00:05:35,639 its way to you, and if you'd like a copy of music co buy, 82 00:05:35,639 --> 00:05:39,160 I write a comment on the website at don at Ross dot comma on 83 00:05:39,160 --> 00:05:41,920 the facebooks you publish every show there and if you comment there and a reading 84 00:05:41,920 --> 00:05:44,319 on the show, we'll send your copy of music Coba and you can follow 85 00:05:44,399 --> 00:05:46,319 us on the twitters or the exes or whatever the hell is today. But 86 00:05:46,759 --> 00:05:49,560 that's all cool. But we've been there for a long time. The cool 87 00:05:49,639 --> 00:05:54,959 kids are hanging out on Macedon. I'm at Carl Franklin at tech Hubsocial and 88 00:05:55,040 --> 00:05:59,199 I'm Rich Campbell at macedon dot social and send us a two and for all 89 00:05:59,240 --> 00:06:01,839 the ways you can attact me anyway, you can find that at Carlfranklin dot 90 00:06:01,879 --> 00:06:08,560 com. All right, let's get into this conversation with Steve Smith. Will 91 00:06:08,560 --> 00:06:11,920 bring him back. I probably don't need to introduce him, but I will 92 00:06:11,920 --> 00:06:16,240 anyway. Steve, otherwise known as our Dallas on all the social networks, 93 00:06:16,800 --> 00:06:21,839 is an entrepreneur and software developer where they passion for building quality software as effectively 94 00:06:21,879 --> 00:06:28,319 as possible. He provides mentoring and training workshops for teams with the desire to 95 00:06:28,439 --> 00:06:32,839 improve. Steve has been recognized as a Microsoft MVP for over ten consecutive years 96 00:06:32,879 --> 00:06:38,839 and as a frequent speaker at software developer conferences and events. He enjoys helping 97 00:06:38,839 --> 00:06:45,759 others write maintainable, testable applications using Microsoft's developer tools. Steve has just published 98 00:06:45,800 --> 00:06:51,560 a zero to hero course on modular monoliths at dometrain dot com, and you 99 00:06:51,600 --> 00:06:56,839 can connect him with him at Steve at our Dallas dot com. Welcome back, 100 00:06:56,879 --> 00:06:59,560 See hey Carl, he Richard. How's it going all as well? 101 00:06:59,600 --> 00:07:01,720 Friend? Well, I'm not in Mexico, so I don't know where you 102 00:07:01,759 --> 00:07:05,480 are, Steve. But Richard and I were just talking that it's the same 103 00:07:05,480 --> 00:07:11,560 temperature in Mexico and Ohio. It's twenty eight degrees right, Ah, okay, 104 00:07:11,639 --> 00:07:16,519 you know one celsius and one is appearan something like that. I like 105 00:07:16,680 --> 00:07:26,800 mine better. Yeah, just saying right. So we did recently did a 106 00:07:26,839 --> 00:07:30,439 show on the you know, the monolith, the modular monolith. Yeah, 107 00:07:30,560 --> 00:07:35,160 Leila Porter but yeah, that's right with Leila. But it was not really 108 00:07:35,160 --> 00:07:39,800 dot net centric, and we thought we'd bring you back to, you know, 109 00:07:40,040 --> 00:07:45,199 give us the dot net developers perspective on modular monoliths. So what you 110 00:07:45,240 --> 00:07:48,199 been thinking about, Buddy, Well, the focus of the industry for the 111 00:07:48,279 --> 00:07:53,600 last five or maybe ten years even has been on micro services and how micro 112 00:07:53,639 --> 00:07:58,519 services are the end all be all. And what I've found is that a 113 00:07:58,519 --> 00:08:03,360 lot of teams take their existing monolithic code that's that usually doesn't have a lot 114 00:08:03,399 --> 00:08:07,519 of modularity to it. You know, generally everything is is kind of in 115 00:08:07,560 --> 00:08:09,759 a big ball of mud, and they don't know what to do to fix 116 00:08:09,800 --> 00:08:13,920 that, and it keeps getting worse over time, and so you know, 117 00:08:13,040 --> 00:08:16,279 micro services is right, there is this shiny new toy that if nothing else, 118 00:08:16,319 --> 00:08:20,360 will improve their resume. And they're like, you know, if we 119 00:08:20,439 --> 00:08:24,560 had these separate micro services, they couldn't possibly be tightly coupled with one another 120 00:08:24,600 --> 00:08:30,160 because they're supposed to be independent. So they convince their their their boss, 121 00:08:30,199 --> 00:08:33,360 their their job, whatever, that that's the way to go as a means 122 00:08:33,399 --> 00:08:37,200 of you know, following the buzz and getting the other benefits of micro services, 123 00:08:37,200 --> 00:08:41,240 like you know, independence and you know, separate scalability of individual services. 124 00:08:41,440 --> 00:08:45,279 So I got a question, how does giant ball of mud one talk 125 00:08:45,320 --> 00:08:48,440 to giant ball of mud two that because that seems to be the fundamental problem, 126 00:08:48,480 --> 00:08:52,120 doesn't it that that can be an issue between micro services? Yes, 127 00:08:52,799 --> 00:09:00,080 but it's like this this fundamental thing where the teams I've seen, not MYI 128 00:09:00,080 --> 00:09:03,159 it's necessarily but just like social media and folks I talk to a conference is 129 00:09:03,200 --> 00:09:07,519 like almost two of every one of them. They are, you know, 130 00:09:07,639 --> 00:09:13,200 thinking that moving to the micro service approach solves the problem of lack of modularity 131 00:09:13,200 --> 00:09:15,639 in their monolith, right, And if you do it right, it certainly 132 00:09:15,720 --> 00:09:18,919 does. But it introduces a whole lot of additional problems because now you're dealing 133 00:09:18,919 --> 00:09:22,399 with a distributed application, and you know, rather than trying to figure out 134 00:09:22,440 --> 00:09:28,440 how to introduce modularity into your code and become experts at you know, building 135 00:09:28,519 --> 00:09:31,679 and operating a distributed application, like, maybe you could just do those one 136 00:09:31,720 --> 00:09:35,919 step at a time, Yeah, and avoid the possibility of building a distributed 137 00:09:35,960 --> 00:09:39,639 monolith, which is what you get, Carl, if you have, you 138 00:09:39,639 --> 00:09:41,639 know, these these two different things that are actually talking to each other as 139 00:09:41,679 --> 00:09:45,840 if they were still in process, right, but now they're distributed. Yeah, 140 00:09:45,879 --> 00:09:50,120 exactly. And it seems a little sarcastic. I'm just saying I had 141 00:09:50,159 --> 00:09:54,080 a problem. I used microservices, and now I have multiple problems that talk 142 00:09:54,159 --> 00:09:58,240 to each that can't talk to each other. Yeah. Yeah, there's there's 143 00:09:58,240 --> 00:10:01,200 an image out there, a meme that, you know, the Pooh emoji. 144 00:10:01,440 --> 00:10:05,279 As like before I had my big monolith at a giant Pooh emogi and 145 00:10:05,320 --> 00:10:11,080 now I've got micro services a dozen pooh emojis. It just multiplied. Yeah, 146 00:10:11,159 --> 00:10:15,559 but this seems like, you know, once upon a time it was 147 00:10:15,600 --> 00:10:20,120 service oriented architectures, right, I think that microservices was going to fix Like, 148 00:10:20,200 --> 00:10:22,360 are we just going through an oscillation here? Yeah? Yeah, microservices 149 00:10:22,360 --> 00:10:26,080 grew grew out of that. The thing is is it's not a bad pattern, 150 00:10:26,279 --> 00:10:33,720 right, I mean too big basically a single responsibility idea among different silos. 151 00:10:35,279 --> 00:10:37,440 But then you know, you can take that, you can do that 152 00:10:37,519 --> 00:10:43,240 all within a single project and still have separation and still only update one DLL 153 00:10:43,279 --> 00:10:46,519 at a time, if you know, just if you're using DLLs, but 154 00:10:48,080 --> 00:10:52,879 one little bit of it at a time, and still get all the benefits 155 00:10:52,879 --> 00:10:58,399 of that, but without the complexity of this huge distributed mess. That's right, 156 00:10:58,480 --> 00:11:01,080 that a lot of people don't understand. There's a bunch of reasons why 157 00:11:01,120 --> 00:11:05,080 folks move toward micro services, and some of it's because they want that independent 158 00:11:05,159 --> 00:11:09,039 scalability. Some of it's because they see that, you know, the Amazons 159 00:11:09,039 --> 00:11:13,960 and Netflixes and whatever are using it, and and folks say, hey, 160 00:11:13,960 --> 00:11:16,600 if that big successful company is using this pattern, I have to use that 161 00:11:16,639 --> 00:11:20,639 pattern so I can become big and successful It's like, that's not really how 162 00:11:20,639 --> 00:11:22,960 it works. And you ask him, how many customers do you have, 163 00:11:22,120 --> 00:11:24,679 oh, one hundred two hundred yeah, ok, yeah, do you need 164 00:11:24,720 --> 00:11:28,159 infinite scale on your you know, one feature of your of your application? 165 00:11:28,960 --> 00:11:35,000 Maybe not? Yeah, So you know there's there's that issue. And distributed 166 00:11:35,000 --> 00:11:39,639 applications are much harder, right, Like Martin Fowler's got an article from like 167 00:11:39,679 --> 00:11:43,080 twenty fourteen that basically says, if you're trying to build a micro services application, 168 00:11:43,159 --> 00:11:46,840 instead of building micro services, first, build a monolith. First, 169 00:11:46,919 --> 00:11:52,200 figure out how the design works, and then you know, split off individual 170 00:11:52,240 --> 00:11:56,080 micro services as and when and if it makes sense to do so. Right, 171 00:11:56,159 --> 00:11:58,320 that's much less risky. There's fewer dragons. He's got an image with 172 00:11:58,399 --> 00:12:03,039 dragons. Sounds exactly like the usual scaling issues, right, It's like, 173 00:12:03,080 --> 00:12:05,440 we've got to build the site scalable. It's like, well, what parts 174 00:12:05,559 --> 00:12:09,639 need to be scaled? Right? Yeah? And sometimes for you know, 175 00:12:09,679 --> 00:12:13,519 medium sized to large organizations, part of what they need to scale is their 176 00:12:13,559 --> 00:12:16,200 teams. Right. They've got an application that's so big that they're trying to 177 00:12:16,200 --> 00:12:20,720 put multiple teams working on it, and they're running into a Conway's Law problem 178 00:12:20,759 --> 00:12:24,679 and they're hoping to fix that with micro services. But you can build modular 179 00:12:24,840 --> 00:12:28,879 monoliths and have multiple teams collaborating just fine. Also, it's just a matter 180 00:12:28,919 --> 00:12:33,360 of how you structure your solution and break those things up when I think that's 181 00:12:33,360 --> 00:12:37,960 something that Lailah brought up as well, which is like Conway's loss certainly applies 182 00:12:37,000 --> 00:12:43,159 to micro services and the idea being that all software reflects the team that's built 183 00:12:43,159 --> 00:12:46,440 it. So it's like, if you're building an app with three different teams, 184 00:12:46,679 --> 00:12:50,799 you're gonna have three feature sets, right, So you know, whatever 185 00:12:50,879 --> 00:12:54,120 points was. Unless you've got a team that large, why would you bother 186 00:12:54,200 --> 00:12:58,279 with micro services because they really come down to granular elements that can be worked 187 00:12:58,279 --> 00:13:01,360 on simultaneously hopefully. So if it's only if it's only six people work on 188 00:13:01,360 --> 00:13:03,759 the thing in the first place, you're really creating a lot of plumbing for 189 00:13:03,840 --> 00:13:07,600 no good reason. Yeah, it does. If you're building this modular monolith 190 00:13:07,799 --> 00:13:11,799 and you do determine that you know there is a bottleneck in one of your 191 00:13:11,840 --> 00:13:18,919 projects or you know one of your silos, you should probably know how to 192 00:13:18,919 --> 00:13:24,000 be ready to carve that off into its own service and communicate with it, 193 00:13:24,120 --> 00:13:26,639 not in process, but you know, through some other mechanism, whether it's 194 00:13:26,679 --> 00:13:35,200 APIs or gRPC or however. So it's it's beneficial to you to figure that 195 00:13:35,360 --> 00:13:41,559 out and be at the ready to either generate the code around that or be 196 00:13:41,720 --> 00:13:45,919 able to do that and have experience with it before it becomes a problem, 197 00:13:46,440 --> 00:13:48,159 you think for sure. Yeah, and and like so in my course that 198 00:13:48,200 --> 00:13:54,240 I just finished, the starting point for most monoliths is a single project. 199 00:13:54,559 --> 00:13:58,720 If I'll do whatever console, ESPNT core, and that you almost always have 200 00:13:58,720 --> 00:14:05,399 to start with a monolith in anything you're building. And in a typical you 201 00:14:05,480 --> 00:14:07,320 know, just monolithic application, it just never splits from there, right, 202 00:14:07,320 --> 00:14:09,639 it just grows and grows and grows. And you know, whether you're using 203 00:14:09,799 --> 00:14:13,200 MVC or raisor pages or whatever it might be in the dot net world, 204 00:14:13,559 --> 00:14:16,399 like you just keep adding them to that same project, and it just keeps 205 00:14:16,440 --> 00:14:20,799 getting bigger. And if you have separation, like if you're following clean architecture 206 00:14:20,799 --> 00:14:24,840 and you have multiple projects, they aren't split vertically, they're not split per 207 00:14:24,879 --> 00:14:28,600 feature, they're split per technical concern. Right. I love clean architecture. 208 00:14:28,600 --> 00:14:31,480 We've talked about it here before. It's a great way to keep your domain 209 00:14:31,480 --> 00:14:35,320 model from becoming tightly coupled to your database. But when you only have you 210 00:14:35,360 --> 00:14:39,799 know, primary projects of user interface, all your infrastructure concerns, and your 211 00:14:39,879 --> 00:14:46,360 domain model, you don't have any type of separation vertically between, like here's 212 00:14:46,399 --> 00:14:50,360 the the product's feature and here's the order's feature, and here's the customer's feature, 213 00:14:50,480 --> 00:14:52,240 right, and then all those things can talk to each other, and 214 00:14:52,279 --> 00:14:56,720 so they do. And that's what makes it a tangled mess. At the 215 00:14:56,759 --> 00:14:58,480 domain model level, at the UI level, and all the way into the 216 00:14:58,559 --> 00:15:03,600 data model. It becomes very difficult to carve those out into a separate service 217 00:15:03,600 --> 00:15:07,080 that you'd want to split out for for whatever reason, because of performance or 218 00:15:07,120 --> 00:15:11,799 maybe security or data isolation, all kinds of reasons why you might want to 219 00:15:11,799 --> 00:15:15,039 split part of that out, And it's hard to do that if you don't 220 00:15:15,039 --> 00:15:18,799 have a plan for that going in. Ree've all Lowe talking about areas of 221 00:15:18,960 --> 00:15:24,159 resonance. You know, basically the idea is that if I make a change 222 00:15:24,159 --> 00:15:26,919 here, does the whole app resonate with the change, like you have to 223 00:15:26,919 --> 00:15:31,600 go check for impacts everywhere, or if I make a change in this particular 224 00:15:31,639 --> 00:15:33,879 spot, there is everything directly related that the only thing that resonates. You 225 00:15:33,919 --> 00:15:37,639 know, if you're messing with payment systems, only payment system stuff is affected. 226 00:15:39,200 --> 00:15:41,519 Right. Yeah. I was in the military, so I use the 227 00:15:41,600 --> 00:15:46,960 term blast radius, And you know when I break this, what all is 228 00:15:46,000 --> 00:15:50,519 into blast radius that I'm gonna have to say blast I usually measure the quality 229 00:15:50,600 --> 00:15:58,240 by meals that way. But I think that was here joke originally Richard deference 230 00:15:58,279 --> 00:16:00,399 to you. No, No, I think I think the ex military guy 231 00:16:00,480 --> 00:16:07,559 using blast radius has a whole other impact than I do. But yeah, 232 00:16:07,600 --> 00:16:11,879 the idea obviously is to limit the blast radius of certain types of changes. 233 00:16:12,000 --> 00:16:17,360 Right. If it's something that should only affect, like how orders are processed, 234 00:16:17,399 --> 00:16:21,679 then you would hope that making that change doesn't require you to redeploy everything 235 00:16:21,679 --> 00:16:23,840 that has to do with you know, customers or you know, the search 236 00:16:23,919 --> 00:16:26,960 engine of the site or whatever it might be. Well, I'm just thinking 237 00:16:27,000 --> 00:16:30,200 in terms of merge conflicts, man, Like, yeah, okay, he 238 00:16:30,240 --> 00:16:33,159 was busy working over on payments here, and then somebody went and made some 239 00:16:33,240 --> 00:16:37,639 changes to product, and now I have a merged conflict. Really like that 240 00:16:37,639 --> 00:16:41,480 that shouldn't happen, right, But you also have the problem of inner activity 241 00:16:41,519 --> 00:16:47,919 between all your projects, right, so one project might have references to two 242 00:16:48,000 --> 00:16:52,720 or three or four other projects. So now if that one project needs to 243 00:16:52,759 --> 00:16:55,600 go into a micro service, what do you do with the other ones? 244 00:16:56,279 --> 00:17:02,480 Are you? Are you now committed to splitting everything up and that just increases 245 00:17:02,519 --> 00:17:07,039 complexity? Right? Yeah, well, even adding the modularity increases complexity of 246 00:17:07,079 --> 00:17:10,759 the whole solution. But the point of it, or one of the points 247 00:17:10,799 --> 00:17:12,119 of it, especially if you have a large team you're hoping that you can 248 00:17:12,160 --> 00:17:17,599 have different teams take on different modules, is that things become simpler in that 249 00:17:17,759 --> 00:17:21,119 module. So if you look at the whole solution, yeah, like your 250 00:17:21,240 --> 00:17:25,400 four project solution now has fifteen projects because you've broken it up into four modules. 251 00:17:25,839 --> 00:17:29,319 But when you're working on just the order processing module, you still only 252 00:17:29,359 --> 00:17:33,319 care about two projects and you don't care about all the other modules. So 253 00:17:33,359 --> 00:17:37,000 your actual area of concern on a day to day basis is simpler. True, 254 00:17:37,319 --> 00:17:42,240 everybody has that shared project, right where all the things go, like 255 00:17:42,359 --> 00:17:48,960 models and all of those things. Yeah, oftentimes yes, and it might 256 00:17:48,960 --> 00:17:51,599 be shared or it might be a per module. You'll probably have both. 257 00:17:51,640 --> 00:17:53,880 You'll have some that are global and some that are per module. But like, 258 00:17:55,319 --> 00:17:57,079 this is just a pattern like the modular monolith is a pattern. It's 259 00:17:57,119 --> 00:18:02,240 not a totally prescriptive thing. But the way I have built it and the 260 00:18:02,240 --> 00:18:06,240 way I show it to do in my course, is to have a single 261 00:18:06,440 --> 00:18:11,440 entry point, host, process or project. And so that's my ASPNT core 262 00:18:11,039 --> 00:18:15,079 project that enters in and it literally has nothing in it except program dot c 263 00:18:15,279 --> 00:18:21,559 s and appsettings dot Jason, and its job is to load the modules from 264 00:18:21,559 --> 00:18:26,720 the other projects. And then a given module in the solution is basically just 265 00:18:26,759 --> 00:18:30,160 a solution folder, because we don't have better artifacts for that in dot NetWorld, 266 00:18:30,440 --> 00:18:34,119 at least at the moment. And inside of that solution folder, there's 267 00:18:34,240 --> 00:18:38,200 there's two or three additional projects. Right, there's the actual code for the 268 00:18:38,240 --> 00:18:42,799 module, which includes all of its UI and all of the domain model logic 269 00:18:42,839 --> 00:18:45,319 and however talks to a database, and then all the logic for it is 270 00:18:45,319 --> 00:18:49,400 in there, and they're separated just in folders. Right, there's not you 271 00:18:49,400 --> 00:18:53,440 know, it's not a clean architecture thing with with separate projects in there. 272 00:18:53,519 --> 00:18:56,960 You know, all those different pieces are there, but they're just separated by 273 00:18:56,000 --> 00:19:00,799 folders. And the reason is that I want them all to be internal. 274 00:19:00,200 --> 00:19:04,119 I don't want other modules to be able to access those of compile times. 275 00:19:04,160 --> 00:19:08,799 I'm using the internal keyword heavily anywhere I can to keep that module locked down 276 00:19:08,839 --> 00:19:14,279 and encapsulated. And then another project it'll have as tests because I like tests. 277 00:19:14,480 --> 00:19:15,920 Now, how the tests work against that project, Well, we can 278 00:19:17,039 --> 00:19:21,079 use the internals visible to attribute on the assembly to make it so the tests 279 00:19:21,119 --> 00:19:25,000 at least can get to those files. We encourage everybody listening to pause and 280 00:19:25,079 --> 00:19:30,359 rewind and listen at half speed because you just unloaded a whole bunch of pile 281 00:19:30,400 --> 00:19:33,359 of wisdom there, Steve. Yeah, yeah, sorry, you might want 282 00:19:33,359 --> 00:19:36,279 to you might want to listen to a little slower, but but by all 283 00:19:36,279 --> 00:19:40,599 means continue at this pace because I think it's great. That's a consequence of 284 00:19:40,640 --> 00:19:42,519 listening to YouTube and podcasts at one and a half speed, as I think, 285 00:19:42,599 --> 00:19:45,960 like this is how people are supposed to talk, is like this fast. 286 00:19:45,079 --> 00:19:49,559 Yeah, yeah, yeah, but I mean just a whole bunch of 287 00:19:49,599 --> 00:19:53,200 stuff. You just you just gave us advice to do, you know, 288 00:19:53,319 --> 00:19:59,319 using internal and the way that projects are scoped and solutions are scoped. So 289 00:19:59,559 --> 00:20:03,279 yeah, there's a lot to it, and it's a lot as we're obviously 290 00:20:03,359 --> 00:20:07,039 figuring out right now. It's a lot more complex than people think, even 291 00:20:07,079 --> 00:20:11,160 in a monolith, to be prepared, to be prepared to go, yeah, 292 00:20:11,240 --> 00:20:15,359 I mean to give it the initial structure. There is a little bit 293 00:20:15,359 --> 00:20:18,680 more complex, a little bit more work. It's really not that bad. 294 00:20:18,759 --> 00:20:22,559 And probably like I've done with clean Architecture, I've published a template that you 295 00:20:22,559 --> 00:20:25,920 can install off of new get that's on getthub and you can just do a 296 00:20:26,079 --> 00:20:29,279 you know, dot that new clean arc and it gives you the solution all 297 00:20:29,319 --> 00:20:32,440 set up. I'll probably do something similar for modular monoliths. I just haven't 298 00:20:32,440 --> 00:20:34,759 gotten there yet. But once you have it set up, like adding another 299 00:20:36,160 --> 00:20:40,400 module is pretty straightforward. It's like add a solution folder, add these two 300 00:20:40,519 --> 00:20:45,640 or three projects, and you know you're off and running. The third project 301 00:20:45,640 --> 00:20:49,079 that's typically in that module that I haven't mentioned is a contracts project, and 302 00:20:49,119 --> 00:20:53,200 the whole idea of the contracts project is that's where the shared stuff goes. 303 00:20:53,279 --> 00:20:57,880 That's where the DTOs or the messages or things that you need in order to 304 00:20:57,920 --> 00:21:03,640 communicate with that model from another module where those would live. That's great, 305 00:21:03,960 --> 00:21:07,920 Yeah, very important. It just really quick. I don't mean to change 306 00:21:07,920 --> 00:21:11,039 the subject because we've got to get back to this. But what's dome Train 307 00:21:11,240 --> 00:21:15,200 and why haven't I heard about it? Dome Train is Nick Chapsis's training company, 308 00:21:15,359 --> 00:21:18,839 and so Nick Chapsis is a real popular YouTuber talks about dot net a 309 00:21:18,839 --> 00:21:22,799 couple of times a week, and so he has initially published his own courses, 310 00:21:22,839 --> 00:21:26,039 but in the last year or so, he's brought in a bunch of 311 00:21:26,039 --> 00:21:30,160 additional authors on there, and so you'll find my modular Monolith course there as 312 00:21:30,200 --> 00:21:34,200 well as a bunch of other courses. And I still have a relationship with 313 00:21:34,240 --> 00:21:37,400 plural Site, and I have a bunch of courses on plural site as well. 314 00:21:37,440 --> 00:21:42,039 But I'm trying dome Train out for the modular Monolith topic. Cool because 315 00:21:42,039 --> 00:21:45,680 I think that, you know, people are like, Okay, you've convinced 316 00:21:45,720 --> 00:21:49,279 me, I want to go check out this this workshop here, great stuff. 317 00:21:49,359 --> 00:21:52,640 Yeah. I don't know if it'll still be good when people listen to 318 00:21:52,640 --> 00:21:53,680 this show, because I know that could be in the far future, but 319 00:21:53,680 --> 00:21:56,920 at least for now, if they use our Dallas when they check out one 320 00:21:56,920 --> 00:22:02,079 of those courses, they get twenty percent off. Very good. Uh So 321 00:22:02,279 --> 00:22:04,279 you're when you were talking about contracts, you're not talking about contracts as in 322 00:22:04,680 --> 00:22:08,039 something that's a part of the domain for this business, but contracts, as 323 00:22:08,079 --> 00:22:12,119 in the contracts between elements of the application interfaces, et cetera. Exactly. 324 00:22:12,200 --> 00:22:18,400 Yes, not not contracts like legal contracts, but the the public messages, 325 00:22:18,440 --> 00:22:22,680 they're they're classes, their records, they're they're dt os. They could be 326 00:22:22,759 --> 00:22:26,640 queries, they could be events, they could be commands. Those are typically 327 00:22:26,920 --> 00:22:30,480 the three types of messages that your application will use, and then you will 328 00:22:30,519 --> 00:22:33,519 have dt os that represent the actual things in your domain, right, Yeah, 329 00:22:33,599 --> 00:22:37,880 And so that and that's just basically a way to maintain that reliability from 330 00:22:37,960 --> 00:22:42,640 update to update. The old DTOs are still supported, so that I mean, 331 00:22:42,640 --> 00:22:47,039 we did a lot of this with the old in service bus approaches just 332 00:22:47,039 --> 00:22:51,359 because I had so many different teams working and in different languages. So you 333 00:22:51,440 --> 00:22:52,480 know, there's no way you're going to get everybody to move to V two. 334 00:22:52,799 --> 00:22:56,559 Like it just wasn't a thing, right you, backward compatibility. Yeah, 335 00:22:56,599 --> 00:23:00,480 the bigger celebration was when did you get to retire account if ever? 336 00:23:02,400 --> 00:23:06,720 Yeah, And the other key reason why that separate project exists is to touch 337 00:23:06,759 --> 00:23:07,880 on what Carl was mentioning, which is, you know, what if these 338 00:23:07,920 --> 00:23:11,880 two things need to talk to each other, right, not just one not 339 00:23:11,000 --> 00:23:14,319 just in one direction. Right. So in dot net, if you as 340 00:23:14,319 --> 00:23:17,440 soon as you split out two things into two different projects. Let's say we've 341 00:23:17,480 --> 00:23:19,599 got customers and orders, right, and so I want to go and get 342 00:23:19,599 --> 00:23:22,880 a customer with all their orders for this page I need to show. Okay, 343 00:23:22,880 --> 00:23:26,759 Well, then I guess customer needs to have a reference to orders so 344 00:23:26,799 --> 00:23:29,279 it can get all the order stuff. All right. Well now I'm like, 345 00:23:29,319 --> 00:23:30,759 I'm on an order, but I want to show all the customer details 346 00:23:32,599 --> 00:23:33,960 with it, right. Well, okay, well, now that order endpoint 347 00:23:34,039 --> 00:23:37,559 needs to have some way to go call customer. Well, as soon as 348 00:23:37,599 --> 00:23:40,799 you try and add a project reference in both directions and visual studio, it's 349 00:23:40,880 --> 00:23:44,079 it's not going to let you. Circular references aren't allowed. But you could 350 00:23:44,119 --> 00:23:48,319 certainly have the customer's module depend on order dot contracts, and you can have 351 00:23:48,359 --> 00:23:52,640 the orders module depend on customer dot contracts, and that's perfectly fine, and 352 00:23:52,640 --> 00:23:56,920 then you can use those messages to communicate with one another. So you know, 353 00:23:56,160 --> 00:24:03,319 one of the byproducts of splitting up all these silos into individual things when 354 00:24:03,359 --> 00:24:10,599 when they're distributed is it's almost like the sequel join problem right right, when 355 00:24:10,640 --> 00:24:15,599 you have when you follow doctor cod and everything's in like all these fully normalized 356 00:24:15,599 --> 00:24:19,400 tables, and then just to pull one set of data out of the database 357 00:24:19,480 --> 00:24:23,279 requires fourteen points. I mean, you have the same kind of thing here, 358 00:24:23,359 --> 00:24:30,680 right with microservices if they're too complex and so walking that line between you 359 00:24:30,720 --> 00:24:33,839 know where how what's the granularity that we need? Right? And that is 360 00:24:33,880 --> 00:24:38,000 tough and if you get it wrong with micro services, it is fairly expensive, 361 00:24:38,079 --> 00:24:42,039 but mostly in terms of time and effort. Sometimes there's money to refactor 362 00:24:42,079 --> 00:24:47,359 a distributed application in order to fix something like that, where like these two 363 00:24:47,359 --> 00:24:49,759 concepts really should have been together, but we split them and now everything is 364 00:24:49,759 --> 00:24:52,279 harder. Yeah. Yeah, now now we're being punished for it. I 365 00:24:52,319 --> 00:24:56,000 mean, we've got to have a whole conversation just about debugging micro services in 366 00:24:56,039 --> 00:25:02,000 the first place, because that's hard to Yeah. The beauty of the modular 367 00:25:02,039 --> 00:25:07,000 monolith approach is that you're not distributed. All these communications that we're talking about, 368 00:25:07,000 --> 00:25:10,599 they're all in process right right. You can use a tool like mediator 369 00:25:10,680 --> 00:25:14,880 and the mediator pattern to make it so that one module can talk to another. 370 00:25:15,559 --> 00:25:18,119 Just by using those contracts, you can new up a command and say, 371 00:25:18,160 --> 00:25:22,640 you know, mediator dot send this command, and some other module that 372 00:25:22,799 --> 00:25:25,960 knows about that command is the one that's going to process the work. And 373 00:25:26,000 --> 00:25:27,680 if you're stepping through in a debugger, you just step right from module to 374 00:25:27,720 --> 00:25:32,359 module. Everything just works in process. It's fast. Right, there's not 375 00:25:32,640 --> 00:25:36,480 a distributed message bust or anything involved unless you need one. But just you 376 00:25:36,480 --> 00:25:40,440 know, by default, your monolith, which is now a modulith if you 377 00:25:40,480 --> 00:25:44,920 will, a modular modelith module, is still what it was before. Right, 378 00:25:44,960 --> 00:25:48,440 It's still simple to deploy, simple to debug, all runs in one 379 00:25:48,519 --> 00:25:53,640 process. Just all we've done is logically separate things into these different modules. 380 00:25:55,599 --> 00:26:00,400 But Steve, what about Kubernetes. You never have to worry about it with 381 00:26:00,400 --> 00:26:04,160 this approach. That's the beauty of it. I think. I think Kubernetes 382 00:26:04,240 --> 00:26:07,599 is a way for cloud vendors to make more money. Well, it's working, 383 00:26:10,319 --> 00:26:14,279 but I mean, it's just an interesting point about this that the deployment 384 00:26:14,400 --> 00:26:18,799 or the implementation and the architecture are separate things. You certainly can can push 385 00:26:18,839 --> 00:26:23,039 out a model if in a contater, just as well as you can push 386 00:26:23,039 --> 00:26:26,119 it a push out as out of microservice. As a good table we have 387 00:26:26,160 --> 00:26:29,160 a friend who listens to the show, and he knows who he is if 388 00:26:29,160 --> 00:26:33,319 he's listening, who I'm friends with, and I've been friends with him for 389 00:26:33,359 --> 00:26:38,400 a long time. And his boss, you know, at his company, 390 00:26:40,359 --> 00:26:44,680 is sold on you know, Kubernetes and micro services and all these things and 391 00:26:44,839 --> 00:26:48,599 the you know, domain driven design and all the things that go with it. 392 00:26:49,200 --> 00:26:52,920 And you know, when you talk to them, it's like they only 393 00:26:53,000 --> 00:26:57,880 have a handful of customers. But so it doesn't make sense and he can't 394 00:26:59,000 --> 00:27:03,720 talk and any sense into his boss in terms of you know, trying to 395 00:27:03,759 --> 00:27:10,880 simplify this and going monolithically modular, and it's just painful. It's very painful. 396 00:27:10,960 --> 00:27:12,160 And you know, I guess, as you said, I think it 397 00:27:12,240 --> 00:27:15,160 might be a little bit hubrious, like, oh, well, we need 398 00:27:15,160 --> 00:27:21,319 to anticipate the day, right, when are you know, when we suddenly 399 00:27:21,400 --> 00:27:25,839 have millions of customers and blah blah blah. But you really need to ask 400 00:27:25,880 --> 00:27:29,839 yourself, is is that going to happen? And can we prepare for it 401 00:27:29,920 --> 00:27:36,680 now and serve those five hundred thousand, ten thousand customers, serve them well 402 00:27:36,880 --> 00:27:41,839 and be ready for the next for one hundred thousand customers? Right And it's 403 00:27:41,119 --> 00:27:45,319 there are challenges even with this architecture. Right. What is one of the 404 00:27:45,440 --> 00:27:49,920 nicest, easiest things you get out of a monolithic architecture is that typically you 405 00:27:49,960 --> 00:27:55,559 have a single database and anybody can querry that database for anything they want at 406 00:27:55,559 --> 00:27:59,440 any time, from anywhere, right, And that's a blessing and a curse. 407 00:27:59,519 --> 00:28:02,200 Right later on, if you do decide to try and split this up 408 00:28:02,240 --> 00:28:06,240 into different modules or micro services like that is usually one of the hardest things 409 00:28:06,279 --> 00:28:07,960 to do because you look at your database and you're like, hey, let's 410 00:28:08,000 --> 00:28:11,200 let's create an enerity relationship diagram and see all the foreign keys, and it's 411 00:28:11,240 --> 00:28:15,279 just tangled web. It's like, well, everything is related to everything, 412 00:28:15,279 --> 00:28:19,440 how do I start? And it's easier to just write a query with a 413 00:28:19,440 --> 00:28:23,359 bunch of joints in that scenario. If you move to micro services, every 414 00:28:23,359 --> 00:28:27,799 micro service should have its own database. If you've moved to a modular monolith, 415 00:28:27,839 --> 00:28:32,799 the same is true, although typically you can just use schema, not 416 00:28:32,839 --> 00:28:36,480 the whole sequel schema, but the schema type in SQL server or database, 417 00:28:36,880 --> 00:28:38,960 so that every table is prefixed by the schema, so you'll have you know, 418 00:28:40,119 --> 00:28:44,759 orders dot order and orders dot order, item for example, and then 419 00:28:44,799 --> 00:28:47,839 you just make it a rule that you follow as a team that when I'm 420 00:28:47,880 --> 00:28:49,640 in the orders module, I only work with things that are in the orders 421 00:28:49,680 --> 00:28:52,480 schema. I don't go reach out and find other, you know, things 422 00:28:52,480 --> 00:28:56,359 that are in the database. Right, But you know you can if you 423 00:28:56,359 --> 00:29:00,200 want to. And that's that's one nice thing is you've got that escape out 424 00:29:00,200 --> 00:29:03,599 if you need it. But there are other patterns that you can use when 425 00:29:03,640 --> 00:29:07,880 you need data aggregation, Like I really want to run this report and I'd 426 00:29:07,880 --> 00:29:11,319 like to be able to join across the orders and the customers and the addresses 427 00:29:11,319 --> 00:29:15,039 and the products. And you know that is difficult to do in a micro 428 00:29:15,119 --> 00:29:18,279 services scenario where you've got four different separate databases that might even be running on 429 00:29:18,319 --> 00:29:22,960 different database technologies. But there are patterns that you can use to make that 430 00:29:23,000 --> 00:29:26,920 happen, and I show how to do that in my course. Also, 431 00:29:27,079 --> 00:29:30,720 guys, let's take a break. We'll be right back after these very important 432 00:29:30,720 --> 00:29:37,680 messages, and we're back. You're listening to dot net rox. I'm Carl 433 00:29:37,720 --> 00:29:41,680 Franklin. That's my friend Richard Campbell in Mexico, somewhere where it's nice and 434 00:29:41,720 --> 00:29:45,480 warm and sunny, goddamn it, nice and warm and full of palm trees. 435 00:29:45,559 --> 00:29:49,400 Yes, And that's Steve Smith. And we're talking about modular monoliths. 436 00:29:49,920 --> 00:29:55,799 And Richard made a joke, but what about Kubernetes. And you know, 437 00:29:55,920 --> 00:29:59,079 it's kind of bittersweet because a lot of people use it, and a lot 438 00:29:59,079 --> 00:30:03,160 of people are very good at it. But eventually, you know, if 439 00:30:03,200 --> 00:30:08,599 your monolith, your modular monolith does become a set of microservices. It's not 440 00:30:08,640 --> 00:30:12,240 that Kubernetes is going away, right, It's just that, you know, 441 00:30:12,279 --> 00:30:15,599 we don't want to start with it, right, And I mean the main 442 00:30:15,640 --> 00:30:19,680 thing you get with Kubernetes is managing all these different services in a way that 443 00:30:19,759 --> 00:30:26,519 allows for independence and independent scale. And in your monolith initially you can still 444 00:30:26,559 --> 00:30:30,680 scale that, right if you're just using a simple app service or you're hosting 445 00:30:30,720 --> 00:30:34,319 your own VMS or whatever. Right, you can always have more instances of 446 00:30:34,359 --> 00:30:40,079 that and scale, you know, horizontally that way, not to mention vertically. 447 00:30:40,160 --> 00:30:44,039 I mean, you can add more horsepower to that instance for quite a 448 00:30:44,039 --> 00:30:45,960 while, especially if you're playing in cloud Land. Yeah, you know, 449 00:30:47,039 --> 00:30:49,720 the cloud Land machines are just getting more and more powerful, so you don't 450 00:30:49,759 --> 00:30:52,960 have to distribute across multiple instances. Yeah, you just spin up the dial 451 00:30:53,000 --> 00:30:56,559 and say, well I need ten of these if need be for horizontal, 452 00:30:56,680 --> 00:30:59,960 or you spin up the dial and say well I need an E or an 453 00:31:00,200 --> 00:31:03,640 F or whatever labels they have for the higher. Uh, there'll be a 454 00:31:03,759 --> 00:31:07,039 Q one of these days. Yeah, that'll be the quantum computers. There 455 00:31:07,039 --> 00:31:11,839 you go. The stack Overflow is not using micro services, right, I 456 00:31:11,880 --> 00:31:15,039 mean, if you ever read anything about their architecture, they just have some 457 00:31:15,160 --> 00:31:19,039 really powerful servers that run the entire site, and most of our apps were 458 00:31:19,039 --> 00:31:22,720 building don't have anywhere near the traffic of stack overflow, or the response time 459 00:31:22,759 --> 00:31:26,680 for that matter. Right. Yeah, So, I mean there is some 460 00:31:26,759 --> 00:31:30,000 software side of this. They What I appreciate about your hater is not just 461 00:31:30,359 --> 00:31:33,119 that mechanism scaling and they're relatively small, but it's also a unit of update 462 00:31:33,799 --> 00:31:40,519 like you get. The containers give you a habit of treating software like cattle, 463 00:31:40,599 --> 00:31:44,960 not pets, where you don't modify anything, you just make a new 464 00:31:45,000 --> 00:31:51,279 one. Tendency listeners just shuddered in horror when you call them cattle, because 465 00:31:51,319 --> 00:31:56,519 those are sacred. What do you mean cattle? I didn't say what kind 466 00:31:56,519 --> 00:32:01,119 of animal yeah, yeah, that's a good metaphor for the point being that 467 00:32:01,519 --> 00:32:07,759 you tend not to update and create unique states that you you design. The 468 00:32:07,839 --> 00:32:13,079 update is a new manifest. The manifest creates new instances of containers if you 469 00:32:13,079 --> 00:32:15,039 want to management Kubernetes, to knock yourself out, whatever makes you happy. 470 00:32:15,640 --> 00:32:20,200 And then you shift workloads over to the new implementation and the old ones can 471 00:32:20,240 --> 00:32:23,319 be shut down. That that's that's the magic of cloud right that that you 472 00:32:23,359 --> 00:32:28,559 don't have to update servers anymore. You just make new ones and kill the 473 00:32:28,559 --> 00:32:31,759 old ones. Right and and the beautia ASP do a core. It works 474 00:32:31,799 --> 00:32:37,319 with Linux, it works across platforms. So you could certainly take this modular 475 00:32:37,400 --> 00:32:42,119 monolith deployable you know the DLLs that you're going to deploy, uh and and 476 00:32:42,240 --> 00:32:46,119 send that into a doctor image and then host that container and then as part 477 00:32:46,160 --> 00:32:50,680 of your c I c D pipeline, publish a new container, push that 478 00:32:50,799 --> 00:32:52,880 up there, have a blue green deployment or you know, whatever you want 479 00:32:52,920 --> 00:32:55,839 to do, uh and and you know when it when you vetted it and 480 00:32:57,000 --> 00:33:00,160 verify that's good to go. You know, replace the existing one with that 481 00:33:00,200 --> 00:33:01,680 one or with ten of that one. If if that's how you want to 482 00:33:01,680 --> 00:33:06,279 scale, yeah, uh, and you don't necessarily need to have micro services. 483 00:33:06,440 --> 00:33:08,039 But let's say you do. Right, Let's say that you've got this 484 00:33:08,240 --> 00:33:13,559 modular monolith that you've built, and it's you know, been easier to build 485 00:33:13,599 --> 00:33:15,720 along the way because you didn't have to deal with Kubernetes yet, you didn't 486 00:33:15,720 --> 00:33:21,079 have all the you know, distributed application effort yet. And now you realize 487 00:33:21,119 --> 00:33:24,839 this piece, this one module, really needs to be separate for reasons because, 488 00:33:25,240 --> 00:33:29,160 yeah, it's it's a bottleneck in some way. It's a performance bottle 489 00:33:29,200 --> 00:33:30,519 neck or a feature bottle neck, like what is it that? Yeah, 490 00:33:30,559 --> 00:33:32,960 it could be any of those things, right, it could be a bottleneck, 491 00:33:34,000 --> 00:33:36,039 could be there's a different team that's in a different time zone that you 492 00:33:36,039 --> 00:33:38,160 want to work on it. It could be h you know, there's GDPR 493 00:33:38,240 --> 00:33:42,480 requirements that the data can't leave the you know, Germany, so you need 494 00:33:42,480 --> 00:33:45,039 to host it somewhere else, any any number of reasons. Right, Well, 495 00:33:45,079 --> 00:33:49,799 if it's been built as a module, it's fairly easy for you to 496 00:33:49,799 --> 00:33:52,880 pull that out and put it in a separate process. Right, And now 497 00:33:52,000 --> 00:33:54,319 you know that can be you know, you know, you're not necessarily on 498 00:33:54,359 --> 00:33:58,720 a micro services architecture, but you do have you know, now one module 499 00:33:58,759 --> 00:34:02,039 that's separate from the rest of your modules that are all bundled together. And 500 00:34:02,079 --> 00:34:06,599 so you take the logical separation that you already have and you turn it into 501 00:34:06,599 --> 00:34:09,000 physical separation on a case by case basis. You don't have to, you 502 00:34:09,000 --> 00:34:12,880 know, do all of it at once. But this isn't free either. 503 00:34:12,960 --> 00:34:17,840 You're adding an authentication layer there, then in a transport layer because you're not 504 00:34:19,079 --> 00:34:22,000 part of the same thing for sure. Yeah, there's a host of things 505 00:34:22,039 --> 00:34:23,480 that you'll have to figure out, at least for that first one, like 506 00:34:23,559 --> 00:34:27,280 how are you going to communicate it with it now that it's out of process. 507 00:34:28,239 --> 00:34:32,199 And the nice thing about the modular monolith approach is if you're using you 508 00:34:32,199 --> 00:34:37,079 know, messages like I've described as contracts approach, is those messages all have 509 00:34:37,239 --> 00:34:42,199 handlers that in a monolith can just do the work right in the handler, 510 00:34:42,239 --> 00:34:44,800 it goes and makes a database call and gets the stuff it needs and returns 511 00:34:44,840 --> 00:34:46,599 back your dto and that's that. Right Now, you suddenly say, well, 512 00:34:46,679 --> 00:34:51,079 actually you're you're across the wire from me, You're somewhere else, and 513 00:34:51,400 --> 00:34:54,440 so you can't just do that anymore, right now you've got to transport it 514 00:34:54,519 --> 00:34:58,639 over a message queu or a message bus. You've got in service bus in 515 00:34:58,679 --> 00:35:00,800 between, or there's an a layer between, and we have to have you 516 00:35:00,840 --> 00:35:04,960 know, token based security flow all the way through. Like all of those 517 00:35:05,000 --> 00:35:08,400 things can still be done just in that handler. Now you're going to add 518 00:35:08,400 --> 00:35:12,400 that additional work, probably as a decorator, as another handler that sits in 519 00:35:12,400 --> 00:35:15,079 front of that one, so that the original one doesn't even necessarily have to 520 00:35:15,199 --> 00:35:19,559 change, but you'll add that new responsibility in its own class that sits in 521 00:35:19,559 --> 00:35:22,239 front of the existing one. Okay, yeah, that makes sense. But 522 00:35:22,320 --> 00:35:24,639 I also appreciate the idea of like, you only do this because you need 523 00:35:24,679 --> 00:35:30,519 to. You're adding complexity and overhead and impacting performance, I would think to 524 00:35:30,639 --> 00:35:32,960 a little to some degree. Yes, but you know, as a guy 525 00:35:32,960 --> 00:35:36,400 who's done a lot of scaling over the years, is like, I'm going 526 00:35:36,400 --> 00:35:42,840 to reduce the single use performance so the multi use performance stays consistent. That's 527 00:35:42,960 --> 00:35:45,599 not necessarily fast per se, but at least is as the number of instances 528 00:35:45,760 --> 00:35:49,960 go up, it doesn't change. Because that's the only thing that makes people 529 00:35:50,000 --> 00:35:53,800 sad is that this one took five minutes where the other one took four seconds. 530 00:35:54,000 --> 00:35:59,199 Yeah, right, right, Yeah, just trading for scalability will almost 531 00:35:59,239 --> 00:36:02,639 always make individual performance worse, right, because if you just have your entire 532 00:36:02,679 --> 00:36:07,440 application on one box and either it doesn't have a database, or that database 533 00:36:07,519 --> 00:36:10,119 is also on that box, right, then all of your calls are on 534 00:36:10,159 --> 00:36:13,400 the same box, right, there is no network hop, and so you're 535 00:36:13,440 --> 00:36:15,159 going to come back in you know, milliseconds, you know, very very 536 00:36:15,159 --> 00:36:20,239 small milliseconds on every request. But how do you scale that? Well, 537 00:36:20,400 --> 00:36:22,000 that's the trick, right, And so as soon as you start scaling it 538 00:36:22,039 --> 00:36:27,280 and you have multiple servers involved in network hops, everything is orders of magnitude 539 00:36:27,320 --> 00:36:30,559 slower, but still generally fast enough. And now it scales you know, 540 00:36:30,880 --> 00:36:35,320 linearly at least up to some point. Yeah, yeah, there's always there's 541 00:36:35,519 --> 00:36:38,679 nothing's for forever, but it should be enough at least, right, And 542 00:36:38,920 --> 00:36:42,559 an architecture, everything is a trade off. So it's just a question of 543 00:36:42,599 --> 00:36:46,400 what is the right architecture for your application for today and for the next you 544 00:36:46,440 --> 00:36:50,880 know, whatever period of time you anticipate in media, Yeah, for fishent 545 00:36:50,920 --> 00:36:52,400 amount of time. All right, Steve, here's this scenario for you. 546 00:36:52,480 --> 00:36:55,960 So people are listening to this and they're about to embark on a new project 547 00:36:57,000 --> 00:37:00,239 and realizing that they're going to get in over their heads the upfront architecture if 548 00:37:00,239 --> 00:37:06,000 they're going to make this right. Maybe they've watched your your your workshop, 549 00:37:06,039 --> 00:37:10,760 here your course and they want to hire a consultant, right, So they 550 00:37:10,760 --> 00:37:15,400 bring in these consultants. And as we know consultants, uh, many of 551 00:37:15,400 --> 00:37:22,000 them can talk a great talk and you want to they're on the lookout for 552 00:37:22,119 --> 00:37:27,639 smells, right, So what smells should we be looking out for when we're 553 00:37:27,679 --> 00:37:30,360 hiring consultant. Then they sit down and they say, all right, here's 554 00:37:30,360 --> 00:37:32,239 what we think I think you should do. Blah blah blah. What are 555 00:37:32,280 --> 00:37:37,719 the smells that say Nope, this guy is not does not understand. Well, 556 00:37:37,719 --> 00:37:43,199 first you should just call nimble Pros because that's us, uh and we 557 00:37:43,239 --> 00:37:46,000 can help you. So go to nimblepros dot com. You know plug that 558 00:37:46,039 --> 00:37:50,119 you set me up for. Sorry, but no. If you're looking for 559 00:37:50,639 --> 00:37:52,719 things to watch out for in your modular model, well in your monolith or 560 00:37:52,760 --> 00:37:58,280 in your architecture, the biggest thing if you're if you're hoping to have modularity, 561 00:37:58,639 --> 00:38:01,519 right, whether it's micro services or modules within a monolith, the thing 562 00:38:01,519 --> 00:38:06,440 that will kill modularity is things that will kill independence, right, things that 563 00:38:06,480 --> 00:38:09,760 add tight coupling between modules. So, if it's micro services or modules, 564 00:38:09,760 --> 00:38:14,320 if they're sharing the same database, that's a red flag. That's a code 565 00:38:14,320 --> 00:38:16,320 spill. If and I mean the actual tables in that data so they have 566 00:38:16,320 --> 00:38:20,920 separate schema then and they're on the same database server, that's that's fine. 567 00:38:21,480 --> 00:38:23,159 You know, you can always break that apart later. But if they're literally 568 00:38:23,199 --> 00:38:28,880 just sharing one data model between multiple modules or micro services, then that's going 569 00:38:28,960 --> 00:38:30,960 to make them tightly coupled and you're going to lose that. So if the 570 00:38:31,039 --> 00:38:36,039 consultant says, so here's module one, it's going to talk to our central 571 00:38:36,079 --> 00:38:37,880 database, and module two and three are also going to talk to our central 572 00:38:37,960 --> 00:38:44,079 database, you say, there's the door. You ask them a question of 573 00:38:44,159 --> 00:38:45,880 you know, hey, doesn't that make them less independent from one another? 574 00:38:45,960 --> 00:38:49,119 And then you hope they have a good answer. Maybe there's a good reason 575 00:38:49,159 --> 00:38:52,639 why they don't want to split the data model. That is complicated, or 576 00:38:53,000 --> 00:38:55,599 it does add complexity to split the data mode. And there is such a 577 00:38:55,639 --> 00:39:00,840 thing as we know as too much separation. Sure, yeah, so I 578 00:39:00,840 --> 00:39:07,079 guess yeah, right, Like Michelle, my wife and partner at Nimblepros is 579 00:39:07,280 --> 00:39:12,239 a veterinarian by by education, and and they kind of have a thing where 580 00:39:12,239 --> 00:39:15,360 they don't talk badly about how another veterinarian diagnose something. Right if somebody comes 581 00:39:15,400 --> 00:39:17,320 in and they took it to another clinic and then they bring it to you, 582 00:39:17,719 --> 00:39:21,159 like, you don't know what that that saw. You don't know what 583 00:39:21,239 --> 00:39:22,559 the animal was doing at that time. So I'm not going to talk badly 584 00:39:22,599 --> 00:39:28,079 about some consultant or or architect or whatever that makes certain decisions because I don't 585 00:39:28,119 --> 00:39:30,960 know what they were thinking, what what what what they were seeing at that 586 00:39:30,039 --> 00:39:34,760 moment and how the you know, requirements were given to them. I will 587 00:39:34,760 --> 00:39:37,679 only assess it based on the information I get at the point in time where 588 00:39:37,679 --> 00:39:39,920 I am introduced to the problem. So maybe if I could throw in an 589 00:39:39,960 --> 00:39:45,719 answer here. If you hear them say always or never, you know only 590 00:39:45,719 --> 00:39:51,800 as Seth speaks an ye, try and be practical and remember that everything is 591 00:39:52,480 --> 00:39:58,679 is a trade off. Is always saying it depends gets old too. It's 592 00:39:58,760 --> 00:40:01,599 true. It only is helpful to say it depends if you immediately follow that 593 00:40:01,639 --> 00:40:06,920 with what it depends on and how your decision will be different based on that 594 00:40:07,800 --> 00:40:09,960 again in a healthcare field, if you're diagnosing something and you say, you 595 00:40:09,960 --> 00:40:12,760 know what's the treatment going to be, and you say, well, it 596 00:40:12,800 --> 00:40:17,000 depends. Everybody is waiting on what on your test results. It depends on 597 00:40:17,079 --> 00:40:20,960 the test results, and then you know, based on that we'll do X 598 00:40:21,119 --> 00:40:30,599 or y like that depends should sure, all right? So anything else that 599 00:40:30,639 --> 00:40:34,000 I mean that the type of other flags. Other red flags for sure would 600 00:40:34,039 --> 00:40:38,360 be direct calls between modules, right, and direct I mean that they are. 601 00:40:38,679 --> 00:40:42,039 You know, on a modular monolith, you can get away with synchronous 602 00:40:42,039 --> 00:40:45,159 communication using the mediator pattern and I show that in my course and it works 603 00:40:45,239 --> 00:40:47,960 fantastic. And the reason why that is allowed in my opinion, why that 604 00:40:49,039 --> 00:40:52,280 works in a modular monoth and it doesn't work in micro services. And what 605 00:40:52,320 --> 00:40:57,679 I'm what I'm describing is in micro services, if you have a direct synchronous 606 00:40:57,679 --> 00:41:02,000 call from micro service A to microservice be using RPC or web APIs or whatever 607 00:41:02,000 --> 00:41:06,079 you want, that means that they both have to be up at the same 608 00:41:06,159 --> 00:41:09,039 time. And so now they have a dependency that you know, they are 609 00:41:09,079 --> 00:41:12,519 not independent. You know, if one goes down, the other goes down. 610 00:41:13,199 --> 00:41:15,840 And so if you want to have availability of these services even when one 611 00:41:15,880 --> 00:41:19,039 of them is down, one of them is being updated, or one of 612 00:41:19,039 --> 00:41:22,880 them crashed or whatever. Right, then you can't have those direct synchronous dependencies 613 00:41:22,880 --> 00:41:24,800 between them, so you want to use some kind of message queue or service 614 00:41:24,840 --> 00:41:29,400 bus or something like that. Yeah, exactly, exactly right. So for 615 00:41:29,800 --> 00:41:32,760 commands you can usually get away with just throwing a command on a queue and 616 00:41:32,800 --> 00:41:36,519 then when that other service gets around to it, it does the work. 617 00:41:36,719 --> 00:41:40,079 But for queries you usually have a conundrum, a different problem, like I 618 00:41:40,159 --> 00:41:44,480 need this data from that other service, how do I get it? And 619 00:41:44,559 --> 00:41:49,239 so for that the easiest approach is data duplication. Right, you have a 620 00:41:49,320 --> 00:41:52,960 cash and that's called the materialized view pattern, and I cover that in my 621 00:41:52,000 --> 00:41:57,400 course also, But the general idea is that instead of you asking service B 622 00:41:57,679 --> 00:42:00,280 for its data with a query over the network, you just get the data 623 00:42:00,360 --> 00:42:05,679 out of your own local copy of service b's data, and Service B is 624 00:42:05,760 --> 00:42:08,719 updating that copy constantly with events. Right, so every time there's a new 625 00:42:08,760 --> 00:42:13,360 record added or removed or updated, an event is fired and you update your 626 00:42:13,360 --> 00:42:17,239 cash. And so if that other service is down or communication between you is 627 00:42:17,280 --> 00:42:21,960 down, you always still have your cash to work from data might be a 628 00:42:21,960 --> 00:42:23,800 whole idea, right, but the data might not be up to date exactly, 629 00:42:23,840 --> 00:42:28,320 So it's a cap theorem your training consistency for availability. Right. And 630 00:42:28,320 --> 00:42:32,679 what about CQRS that comes to mind, where you have a separate pathway for 631 00:42:32,760 --> 00:42:38,119 querying than you do for writing data, right, And it's exactly this type 632 00:42:38,119 --> 00:42:40,960 of thing I just described that. It's one of the reasons why you want 633 00:42:42,000 --> 00:42:45,559 to have that separation of commands and queries. So CQRS, if you don't 634 00:42:45,559 --> 00:42:50,960 know, the acronym is command query responsibility segregation and the benefit of it. 635 00:42:51,000 --> 00:42:52,079 There's a bunch of benefits, but one of them is that you can use 636 00:42:52,079 --> 00:42:59,280 different patterns and different architectural approaches for your commands versus your query's. So, 637 00:42:59,360 --> 00:43:01,079 like I was saying, you could throw a command on a queue and forget 638 00:43:01,079 --> 00:43:04,360 about it, you can't do that with a query, right. You can't 639 00:43:04,440 --> 00:43:07,639 just throw it on a queue and continue on because you need that data and 640 00:43:07,679 --> 00:43:10,440 so you have other patterns that you use to respond to those. And so 641 00:43:10,559 --> 00:43:15,719 in a modular architecture, whether it's going to turn into micro services or remain 642 00:43:15,760 --> 00:43:19,960 a modular monolith, it does make sense for you to define your messages in 643 00:43:20,039 --> 00:43:23,920 terms of queries and commands and events. Those are the three messages you should 644 00:43:23,920 --> 00:43:30,159 have explicitly defined and then use those as your mechanism for communication, and then 645 00:43:30,159 --> 00:43:34,360 put those in the contracts project for each module. And just to illustrate how 646 00:43:34,400 --> 00:43:37,360 complex these things are, I saw a great tweet by Greg Young, who 647 00:43:37,599 --> 00:43:40,800 was the first one to do CQRS. I think he might even coin the 648 00:43:40,880 --> 00:43:45,360 term in the pattern, but that he was turned down at a job offer 649 00:43:45,519 --> 00:43:52,320 because they said he didn't know enough about CQRS. You don't know anything about 650 00:43:52,360 --> 00:43:58,400 CQRS. It's like saying Steve Smith, you don't know anything about nimble pros. 651 00:43:59,679 --> 00:44:01,280 Go, yeah, Like did you even google it? You know, 652 00:44:01,559 --> 00:44:06,760 yeah, google that phrase and you know his name, right, So what 653 00:44:06,800 --> 00:44:10,760 have we missed? Is there anything else that people should be on the lookout 654 00:44:10,800 --> 00:44:16,079 for? Maybe maybe when investigating and existing architecture, right, and you're you 655 00:44:16,159 --> 00:44:22,599 obviously things that are tightly coupled. But how does one begin to take a 656 00:44:22,719 --> 00:44:25,800 monolith that might not be modular and modularize it. There's a few different ways 657 00:44:25,800 --> 00:44:29,719 that you can start. Like one of them is you look at the data 658 00:44:29,719 --> 00:44:32,159 model or the object model and you try and figure out where there's some isolation, 659 00:44:32,280 --> 00:44:36,679 there's some things that could stand alone. And it might be that your 660 00:44:37,000 --> 00:44:39,039 your hand is forced. It might be that there are constraints like this is 661 00:44:39,079 --> 00:44:42,400 the one that's not performing well enough, or this is the one that needs 662 00:44:42,440 --> 00:44:45,000 to be in a separate region, and so you have to start there. 663 00:44:45,599 --> 00:44:49,920 But if you're not forced, it's usually best if you can pick something that's 664 00:44:50,400 --> 00:44:52,360 low hanging fruit, that is, you know, sort of the Hello World, 665 00:44:52,519 --> 00:44:57,800 of of the of the various modules, right, something easy and so 666 00:44:58,039 --> 00:45:00,320 you know, sometimes it's something like how we send emails, right, take 667 00:45:00,400 --> 00:45:04,960 all the email sending functions and put them in a module and figure out a 668 00:45:05,000 --> 00:45:07,119 way to send communication to that module to say, hey, here's everything you 669 00:45:07,119 --> 00:45:10,559 need to send this email, and then it can do that work right, 670 00:45:10,599 --> 00:45:14,280 And that could also be spun off as a micro service if you want it. 671 00:45:14,320 --> 00:45:16,920 I've I've done that many times for clients as their first micro service. 672 00:45:17,000 --> 00:45:21,760 Like here's your micro service that just sends emails. Like it's it's really small, 673 00:45:21,760 --> 00:45:23,039 it's micro, it's only got one thing it has to worry about, 674 00:45:23,280 --> 00:45:27,519 and you do it from all over the place inside your various applications. So 675 00:45:27,679 --> 00:45:31,000 like it makes a good first micro service, and then likewise is an easy 676 00:45:31,000 --> 00:45:34,000 thing to pull out, you know, some type of thing like that. 677 00:45:34,559 --> 00:45:37,800 It could be an easy thing to pull out for a module in a modulate 678 00:45:37,880 --> 00:45:40,400 model. The reason for it is that once you've done something simple and easy 679 00:45:40,440 --> 00:45:45,280 like that, you've you've figured out where all the dragons are, you figured 680 00:45:45,280 --> 00:45:49,440 out what all the problems are. It's a nice easy vertical slice that you 681 00:45:49,440 --> 00:45:51,639 know, you have to answer all those questions like well, how do I 682 00:45:51,679 --> 00:45:52,679 communicate with it? And how do I you know, separate it, and 683 00:45:52,679 --> 00:45:55,119 how do I deploy it separately? If it's a micro service, all those 684 00:45:55,159 --> 00:45:59,320 questions have to be answered, but you're not, you know, bogged down 685 00:45:59,400 --> 00:46:02,079 by the This is this huge, massive, complicated thing that's tied into everything 686 00:46:02,079 --> 00:46:06,280 else. Like no, do a simple thing that you can solve all the 687 00:46:06,320 --> 00:46:08,880 distributed problems or all the modularity problems. And then once you have that as 688 00:46:08,880 --> 00:46:14,360 an example, now you can just take that example and use that same approach 689 00:46:14,440 --> 00:46:16,800 for the next one that's more challenging. Do we have to know DDD in 690 00:46:16,880 --> 00:46:20,719 order to do this? Do I have to take a course on demand driven 691 00:46:20,719 --> 00:46:22,760 design? You don't have to, but it probably helps because of some of 692 00:46:22,760 --> 00:46:27,920 the patterns that are involved. Right, Each one of these modules or each 693 00:46:28,000 --> 00:46:30,559 micro service should be its own bounded context. Right, And if you have 694 00:46:30,639 --> 00:46:35,119 never heard of that, then that's add a little bit about DDU would probably 695 00:46:35,119 --> 00:46:38,039 go a long way, right. Okay, So you know, I'm basically 696 00:46:38,440 --> 00:46:44,000 hearing of voices of the listeners out there going all right, you guys are 697 00:46:44,280 --> 00:46:49,199 sort of pooping on micro services. But does that mean all these other technologies 698 00:46:49,199 --> 00:46:53,599 and patterns and strategies that we use are are invalid? And you know the 699 00:46:53,639 --> 00:46:59,360 answer over and over again is no. It's just that the modules exist in 700 00:46:59,400 --> 00:47:05,559 a single problem first, right, Yeah, if there's a good reason to 701 00:47:05,639 --> 00:47:07,440 go to micro services, by all means you. I'm not saying don't do 702 00:47:07,519 --> 00:47:10,519 that. I'm just saying don't do it without a good reason, right, 703 00:47:10,719 --> 00:47:15,519 And don't necessarily do it out of the gate like you're if you're building a 704 00:47:15,559 --> 00:47:21,400 brand new application, you will go orders of magnitude faster building a modular monolith. 705 00:47:21,760 --> 00:47:23,639 Then you will if you're having to try and have a bunch of different 706 00:47:23,679 --> 00:47:28,760 services that all communicate to each other like debugging and deploying, and you know, 707 00:47:28,800 --> 00:47:30,679 reckoning with that and then changing that design later. Yeah, that's the 708 00:47:30,719 --> 00:47:35,519 thing you be most likely to get defensive. Yeah. I mean the only 709 00:47:35,519 --> 00:47:37,599 place I've seen this makes sense, and you know we addressed this before, 710 00:47:37,800 --> 00:47:42,400 is oh, we have one hundred people working on this, and they're actually 711 00:47:42,480 --> 00:47:45,960 breaking it into these pieces and creating all the communication layers because it allows everybody 712 00:47:45,000 --> 00:47:50,000 to work at once and hopefully and you've got a contract team that's sitting over 713 00:47:50,000 --> 00:47:52,559 top of that that's making sure that the APIs are consistent and nobody gets surprised. 714 00:47:52,599 --> 00:47:57,760 Like, so you're already paying the overhead to make that many people productive, 715 00:47:57,840 --> 00:47:59,960 right, I just don't know how many folks are in that situation, 716 00:48:00,800 --> 00:48:02,960 right, Like really, you know, there's an upside to Conways law, 717 00:48:04,039 --> 00:48:07,639 which is if the app is architectured to the size of the team, and 718 00:48:07,639 --> 00:48:09,159 the team generally has their hands around it, like they know what they're looking 719 00:48:09,199 --> 00:48:15,159 at, right. Yeah, and this subsequent you know, break breaking a 720 00:48:15,199 --> 00:48:21,159 part of things because of performance or other constraints is more reflective of how the 721 00:48:21,199 --> 00:48:24,400 software is being used rather than the initial architecture. Yeah. And why do 722 00:48:24,440 --> 00:48:27,880 you have one hundred people working on this? Usually it's because you want to 723 00:48:27,920 --> 00:48:30,400 achieve some level of velocity, right, Well, I would argue that you 724 00:48:30,400 --> 00:48:34,679 could have half as many people working on it, and you know, build 725 00:48:34,719 --> 00:48:39,480 it as a single repository modular monolith, and you would go faster than having 726 00:48:39,480 --> 00:48:44,679 one hundred people working on it in a dozen different repositories and all trying to 727 00:48:44,679 --> 00:48:46,719 figure it out, with a separate team responsible for contracts, and another one 728 00:48:46,920 --> 00:48:51,960 responsible for making sure everybody does everything right, and two more teams responsible for 729 00:48:52,119 --> 00:48:53,760 figuring out how to deploy it all. Well, Steve, is there anything 730 00:48:53,800 --> 00:48:57,760 else besides here? Of course you want to pitch or talk about or do 731 00:48:57,880 --> 00:49:00,519 we miss anything before we sign off? Probably mentioned since we've been talking about 732 00:49:00,519 --> 00:49:07,840 micro services and monoliths that I do have another course coming. I think it'll 733 00:49:07,880 --> 00:49:13,000 be ready first of April or so on. From micro services to modular monoliths, 734 00:49:13,480 --> 00:49:16,000 which is the backward direction from most of the books in literature that's been 735 00:49:16,119 --> 00:49:21,119 rud for the last ten years. But if you've found yourself in a mess 736 00:49:21,159 --> 00:49:23,760 with your micro services and you want to get back to a monolith but still 737 00:49:23,840 --> 00:49:28,039 keep your modularity that you've worked so hard to get, that's what this course 738 00:49:28,079 --> 00:49:30,320 will cover. Very cool, Steve, I can't thank you enough for being 739 00:49:30,320 --> 00:49:32,920 with us. It's always enlightening to talk to you, and we always learned 740 00:49:32,960 --> 00:49:37,400 something and take the course. Get out there, check it out. Thanks 741 00:49:37,400 --> 00:49:40,000 again, Steve, Thanks Carl Richard. All right, always Bud. We'll 742 00:49:40,039 --> 00:50:04,880 see you next time on dot net rocks. Dot net rocks is brought to 743 00:50:04,920 --> 00:50:08,960 you by Franklin's Net and produced by Pop Studios, a full service audio, 744 00:50:09,079 --> 00:50:15,039 video and post production facility located physically in New London, Connecticut, and of 745 00:50:15,079 --> 00:50:20,880 course in the cloud online at pwop dot com. Visit our website at d 746 00:50:20,960 --> 00:50:24,239 O T N E t R O c k S dot com for RSS feeds, 747 00:50:24,480 --> 00:50:30,000 downloads, mobile apps, comments, and access to the full archives going 748 00:50:30,000 --> 00:50:34,599 back to show number one recorded in September two thousand and two. And make 749 00:50:34,639 --> 00:50:37,280 sure you check out our sponsors. They keep us in business. Now go 750 00:50:37,320 --> 00:50:49,880 write some code, See you next time. You got Jamtlevans and