WEBVTT 1 00:00:01.080 --> 00:00:04.799 How'd you like to listen to dot net rocks with no ads? Easy? 2 00:00:05.360 --> 00:00:09.480 Become a patron for just five dollars a month. You get access to a 3 00:00:09.480 --> 00:00:14.279 private RSS feed where all the shows have no ads. Twenty dollars a month. 4 00:00:14.279 --> 00:00:18.440 We'll get you that and a special dot net Rocks patron mug. Sign 5 00:00:18.519 --> 00:00:35.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