WEBVTT 1 00:00:01.000 --> 00:00:04.759 How'd you like to listen to dot net Rocks with no ads? Easy? 2 00:00:05.320 --> 00:00:09.880 Become a patron For just five dollars a month you get access to a private 3 00:00:10.000 --> 00:00:14.400 RSS feed where all the shows have no ads. Twenty dollars a month will 4 00:00:14.400 --> 00:00:18.800 get you that and a special dot net Rocks patron mug. Sign up now 5 00:00:18.839 --> 00:00:24.199 at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As 6 00:00:24.239 --> 00:00:29.519 you may have heard, NDC is back offering their incredible in person conferences around 7 00:00:29.559 --> 00:00:33.960 the world, and we'd like to tell you about them. NDC Copenhagen is 8 00:00:34.000 --> 00:00:39.600 happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com 9 00:00:39.799 --> 00:00:45.039 for more information. NDC Porto is happening October sixteenth through the twentieth. Go 10 00:00:45.159 --> 00:00:50.119 to Dcporto dot com to register and check out the full lineup of conferences at 11 00:00:50.200 --> 00:00:54.840 NDC Conferences dot com. Hey there, this is Jeff Fritz, the purple 12 00:00:54.880 --> 00:00:59.280 blazer guy from Microsoft, letting you in on a little secret about my friend 13 00:00:59.439 --> 00:01:03.560 Carl Franklin. You know, the guy who started dot net Rocks, the 14 00:01:03.640 --> 00:01:07.439 first podcast about dot net in two thousand and two. The guy who's been 15 00:01:07.480 --> 00:01:14.599 teaching Blazer on YouTube since twenty twenty. Yeah that Carl Franklin. Well, 16 00:01:14.959 --> 00:01:18.640 Carl's joined up with the folks from Code in a Castle to teach a week 17 00:01:18.760 --> 00:01:23.120 long hands on Blazer class at Are you ready to get this? At a 18 00:01:23.239 --> 00:01:30.200 castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer learning 19 00:01:30.280 --> 00:01:37.359 built in. Carl's calling it the Blazer master Class. You'll learn Blazer from 20 00:01:37.359 --> 00:01:41.680 the ground up, finishing the week with the ability to build and deploy Blazer 21 00:01:41.719 --> 00:01:47.120 applications. Since the training happens for only four hours in the morning over six 22 00:01:47.200 --> 00:01:51.680 days, you can bring your significant other, your partner with you and you 23 00:01:51.719 --> 00:01:57.319 should right This part of Italy is absolutely beautiful. There's so much to see 24 00:01:57.400 --> 00:02:02.159 and do and in Larry and Marco from Code into Castle are organizing daily activities 25 00:02:02.200 --> 00:02:07.760 both at the castle and in the area. The castle is in the Marema, 26 00:02:07.840 --> 00:02:13.319 a less touristed region of Tuscany, offering both classic Tuscan hill country as 27 00:02:13.319 --> 00:02:17.759 well as easy access to the Etruscan Riviera, with sublime local food, wine 28 00:02:19.039 --> 00:02:23.120 and olive oil around every corner. Breakfast is included every day. There will 29 00:02:23.120 --> 00:02:28.919 be two communal dinners at the Castle book ending the experience and most other meals 30 00:02:29.080 --> 00:02:34.439 and all activities are included. And did I mention you'll learn Blazer in person 31 00:02:34.520 --> 00:02:38.159 from Carl Franklin. Listen, space is limited and for very good reason. 32 00:02:38.439 --> 00:02:45.000 This is quality training in a beautiful setting. Go to code in Acastle dot 33 00:02:45.000 --> 00:02:52.240 com slash Blazer twenty twenty three. That's bla z o R two zero two 34 00:02:52.400 --> 00:02:57.759 three to take advantage of this amazing opportunity to join Carl in Tuscany for an 35 00:02:57.840 --> 00:03:04.080 unforgettable week of led dulce vita while advancing your programming skills in this important new 36 00:03:04.159 --> 00:03:22.159 technology. Hey guess what it's doing at Rocks. I'm Carl Franklin and I'mmateur 37 00:03:22.199 --> 00:03:25.199 Campbell, And you're here again. Isn't that cool? They're here again? 38 00:03:25.840 --> 00:03:30.039 They show up. This keeps happening. I don't know, I don't know 39 00:03:30.120 --> 00:03:35.080 why. I'm beginning to get an idea why. Yeah, maybe how you 40 00:03:35.120 --> 00:03:38.680 been, mister Campbell? How's how's moving going? I'm packing mostly right, 41 00:03:39.560 --> 00:03:43.199 And the problem, of course, is that we're not moving into a new 42 00:03:43.280 --> 00:03:49.080 place. We're moving into a place that we've already furnished. So we have 43 00:03:49.319 --> 00:03:53.240 entirely too much of everything. Not the least of which is a downsize. 44 00:03:53.280 --> 00:03:57.199 So twenty something years have been in this house. It's a lot of purging. 45 00:03:57.759 --> 00:04:00.960 Yard sale. Um no, not a yard sale kind of guy. 46 00:04:00.159 --> 00:04:04.000 You know. That's the thing. I admit. I will Facebook Marketplace like 47 00:04:04.039 --> 00:04:09.639 good bits of electronics and things that we but it's only good for free. 48 00:04:09.759 --> 00:04:12.240 Yeah, if you as soon as there's a price forget it, you're wasting 49 00:04:12.280 --> 00:04:14.400 your time. Yeah. But if you want to get rid of something on 50 00:04:14.439 --> 00:04:16.519 a weekend quickly, you can stick it in the driveway and throw it on 51 00:04:16.560 --> 00:04:18.920 Facebook Marketplace. It will be gone in an hour. And if you say 52 00:04:19.040 --> 00:04:21.639 you want ten bucks for it, somebody's going to offer you too. Well, 53 00:04:21.680 --> 00:04:26.120 they won't even do that. All they'll do is waste time after that. 54 00:04:26.199 --> 00:04:29.759 If you give it away, it's gone and that's fine unless there's something 55 00:04:29.879 --> 00:04:32.079 nice, in which case they go, oh it's a scam. So is 56 00:04:32.120 --> 00:04:35.600 there any if there are any dot net rocks listeners in your area, can 57 00:04:35.639 --> 00:04:39.360 they contact you and see what you got? Do you have a list somewhere? 58 00:04:39.480 --> 00:04:41.879 I don't really have a list. Which kind of stuff comes along and 59 00:04:42.720 --> 00:04:45.800 it goes out the door pretty quickly, but yeah, okay, yeah, 60 00:04:45.800 --> 00:04:48.040 it's not that organized. Too much stuff, man, too much stop and 61 00:04:48.399 --> 00:04:51.680 but a lot of what's happening right now is and you know, my wife 62 00:04:51.720 --> 00:04:56.959 will enough to know that she purchased a particular size of plastic bin with locking 63 00:04:57.040 --> 00:05:00.160 lids and stacking mounts. Oh yeah. And so we are our packaging up 64 00:05:00.199 --> 00:05:03.360 the things that need to stay into these bins. We have measured off the 65 00:05:03.399 --> 00:05:06.879 space in the garage up on the coast, and so we know how many 66 00:05:06.920 --> 00:05:11.120 bins were allowed to have and we're sort of making it fit to the space. 67 00:05:11.160 --> 00:05:15.000 And so I keep doing runs in the truck up there and continuing to 68 00:05:15.040 --> 00:05:18.040 pile up a monolith, you know, something out of pink floids the wall, 69 00:05:18.759 --> 00:05:23.040 and eventually will be done. Wait a minute, that's part of what 70 00:05:23.079 --> 00:05:30.240 we're talking about monoliths today, right with Leila? You like that? All 71 00:05:30.360 --> 00:05:33.120 right? Well, before we get Leila on, let's uh do better, 72 00:05:33.120 --> 00:05:36.800 no framework, because I got something really kind of interesting to share, all 73 00:05:36.879 --> 00:05:51.079 right. So this is a story reported by the verge right. Millions in 74 00:05:51.199 --> 00:06:00.240 quotes of sensitive US military emails were reportedly sent to the country of Mali to 75 00:06:00.279 --> 00:06:03.439 a typo right for over ten years, millions of I won't read the whole 76 00:06:03.439 --> 00:06:06.480 thing but here's the gist. For over ten years, millions of emails associated 77 00:06:06.519 --> 00:06:11.759 with the US military having getting sent to Molly, a West African country allied 78 00:06:11.759 --> 00:06:15.639 with Russia, due to a typo. According to a report from The Financial 79 00:06:15.680 --> 00:06:20.279 Times, instead of appending the military's dot mil domain to their recipient's email address, 80 00:06:20.879 --> 00:06:28.319 people frequently type dot mL, the country identifier for Mali. I mean, 81 00:06:28.360 --> 00:06:31.839 presumably all these emails bounce. Well, here's the story. So this 82 00:06:31.879 --> 00:06:39.519 guy, a Dutch entrepreneur, Johannes Zubier probably something like that, contracted to 83 00:06:39.600 --> 00:06:43.480 manage Molly's domain, tells the Financial Times. This has been happening for over 84 00:06:43.560 --> 00:06:47.800 a decade, despite his repeated attempts to warn the US government, and when 85 00:06:47.800 --> 00:06:54.000 he began noticing requests for non existent domains like Army dot mL and Navy dot 86 00:06:54.120 --> 00:06:58.600 mL, he set up a system to catch the misdirected emails, which was 87 00:06:58.759 --> 00:07:06.680 quote rapidly overwhelmed and stopped collecting messages. He reportedly intercepted a hundred and seventeen 88 00:07:06.720 --> 00:07:14.040 thousand misdirected emails, some of which contained sensitive information. Oh my goodness, 89 00:07:14.519 --> 00:07:17.319 yep, that's a good one. Attention to detail, kids, it's really 90 00:07:17.319 --> 00:07:20.720 important. Well, and any I mean again, I guess they mostly bounced. 91 00:07:21.000 --> 00:07:24.240 Yeah, but the real the real point, I think he's at the 92 00:07:24.319 --> 00:07:28.160 end of this story where it's like that now the Defense Department has set it 93 00:07:28.240 --> 00:07:31.920 up so that when any dot mL domain email address tries to said to dot 94 00:07:32.040 --> 00:07:35.160 mL, they get a message that says, you need to verify this. 95 00:07:35.519 --> 00:07:42.680 Right. Yeah, I just don't understand why somebody would send army to Army 96 00:07:42.759 --> 00:07:46.519 dot m IL and then get a bounce notice and then keep sending it. 97 00:07:46.639 --> 00:07:47.920 Well, who knows what they did? Well, who knows they did. 98 00:07:47.959 --> 00:07:50.360 There's a lot of people working in the military. Yeah, you're right, 99 00:07:50.639 --> 00:07:54.560 right, and and I me I mentioned some of those emails are, hey, 100 00:07:54.839 --> 00:07:58.360 want to meet for lunch? Right? Could be yeah, I'm just 101 00:07:58.439 --> 00:08:01.160 guessing, yeah, but there was some sensitive stuff. Anyway, It's very 102 00:08:01.199 --> 00:08:07.759 important to pay attention to details, sanitize your inputs. That's the moral of 103 00:08:07.800 --> 00:08:11.319 the story. Pretty funny, all right, So who's talking to us today? 104 00:08:11.399 --> 00:08:15.160 Richard Grabby comment to show seventeen seventy, which is back in December twenty 105 00:08:15.199 --> 00:08:18.199 one, when we talk to our friend Paul you can do it's about building 106 00:08:18.240 --> 00:08:24.120 microservices with Dapper Ye and Sean Kieran wrote this great comment and literally DAPR dapper, 107 00:08:24.360 --> 00:08:28.160 dapr. Yes, because too many product names. Life's hard. Yeah. 108 00:08:28.240 --> 00:08:31.399 Yeah, so it's about eighteen months ago. Sean wrote this great comedy 109 00:08:31.399 --> 00:08:33.399 says thanks for another great show. I don't know how you managed to keep 110 00:08:33.399 --> 00:08:37.759 coming up with them awesome work. I enjoyed listening to Paul talk about Dapper. 111 00:08:37.799 --> 00:08:41.679 It's a really interesting technology and it seems to have great hosting support too. 112 00:08:41.879 --> 00:08:45.440 And Paul mentioned a Dapper makes service discovery easier, which is great to 113 00:08:45.480 --> 00:08:48.799 hear. But the words service discovery in quotes also makes me shy away a 114 00:08:48.799 --> 00:08:54.240 little, as it seems to be a bag full of unnecessary complexity that comes 115 00:08:54.240 --> 00:08:58.240 along with the modern approach to microservices. And I'm with him, Like Jeffry 116 00:08:58.240 --> 00:09:01.600 speaking, I think discovery seems vaguely silly. It's like I kind of know 117 00:09:01.679 --> 00:09:05.440 where I want to call, Why do I need to discover it? Until 118 00:09:05.559 --> 00:09:11.519 you're dealing with uncoupled failover solutions, right. The whole idea that rather than 119 00:09:11.600 --> 00:09:16.000 saying, hey, when you need this service, call here, it's like, 120 00:09:16.159 --> 00:09:18.960 when you need the service, ask for this most of the time would 121 00:09:18.960 --> 00:09:22.200 be the thing we always thought it would be. But I could also have 122 00:09:22.240 --> 00:09:24.879 a backup one there and I can upgrade, I could you know, change 123 00:09:24.919 --> 00:09:30.440 things around without having to recompile other code. Right. This is all that 124 00:09:30.559 --> 00:09:35.639 sort of uncoupling approach, which but I agree that service discovery could be easily 125 00:09:35.639 --> 00:09:39.360 abused. They're used to. It reminds me of the old XML web services 126 00:09:39.440 --> 00:09:43.720 days. Didn't wasn't there a discovery Yeah, but protocol I mean even going 127 00:09:43.759 --> 00:09:48.399 back to ASMX right for crying out loud, like we've always had this idea 128 00:09:48.559 --> 00:09:52.720 of we want to ask by name for something, not by location. I 129 00:09:52.799 --> 00:09:56.440 just remember they did a demo where you could search like zip code services and 130 00:09:56.480 --> 00:10:01.159 all the web code, all the web services that provide zip codes would come 131 00:10:01.240 --> 00:10:03.639 up with endpoints, right. And that was the silly one. That the 132 00:10:03.679 --> 00:10:07.720 one where it's like I just want to call out into the Internet for a 133 00:10:07.759 --> 00:10:11.840 service to do something, and it's like, I'm pretty sure you should never 134 00:10:11.879 --> 00:10:15.399 do that. Never ever do that. It's just not a good idea. 135 00:10:15.879 --> 00:10:18.600 The Internet is not filled with your friends. That's that's what's out there. 136 00:10:20.039 --> 00:10:22.600 That was just you know, to prove prove it could be done, I 137 00:10:22.639 --> 00:10:26.600 suppose, yeah, and again didn't make it a good idea, But within 138 00:10:26.759 --> 00:10:33.600 a service architecture, to be able to be to request a particular class of 139 00:10:33.679 --> 00:10:37.519 service and not care that it's any given instance in any given location. It's 140 00:10:37.679 --> 00:10:43.360 kind of like the Swagger idea, right, that's all insane uncoupling. Yeah, 141 00:10:43.440 --> 00:10:48.240 yeah, now A Shan does gone to say he got involved with service 142 00:10:48.240 --> 00:10:50.720 buses back in two thousand and eight, so he's obviously an old schooler when 143 00:10:50.759 --> 00:10:54.399 he started with end Service Bush, which we know and love well. But 144 00:10:54.440 --> 00:10:58.679 he also switched over to Rebus, which I don't think we've ever talked about, 145 00:10:58.799 --> 00:11:01.360 developed by mog Heller Chrys No, we have none, I don't think 146 00:11:01.440 --> 00:11:07.240 no. And but then also mentions things like mass Transit, easynet QE Brighter, 147 00:11:07.480 --> 00:11:09.440 like there is a bunch of solutions there. There's no two ways about 148 00:11:09.480 --> 00:11:15.159 it. It makes this key point he says, when you build with these 149 00:11:15.200 --> 00:11:18.840 systems, you're making true He calls them true Microsoft services, which I think 150 00:11:18.919 --> 00:11:22.960 is a bit optimistic. But it is the idea that here is a platform 151 00:11:24.039 --> 00:11:28.919 that encourages you go down the path of separate services that could be worked together 152 00:11:28.960 --> 00:11:35.600 by it worked on different developers, deployed independently, can support multiple versions running 153 00:11:35.600 --> 00:11:39.200 on the same service. At the same time in production without having to worry 154 00:11:39.200 --> 00:11:41.720 about it, and that the way they do communication is schema base like it's 155 00:11:41.720 --> 00:11:46.759 all those sort of core ideas and today's Then then you have the abstraction of 156 00:11:46.799 --> 00:11:52.320 transport, so it might be Rabbit MQ or SMS or a service bus today 157 00:11:52.679 --> 00:11:56.799 or even Amazons SQS like, there's lots of different ways to do stuff, 158 00:11:56.840 --> 00:12:01.440 and that's the key to the power of all these service bus architectures that you 159 00:12:01.480 --> 00:12:05.399 don't have to commit to any given stack in changing those things is not that 160 00:12:05.480 --> 00:12:11.679 big of a deal anyway. I thought it was a nice love letter about 161 00:12:11.720 --> 00:12:16.320 service buses, but it's also I think a luxury for a lot of folks, 162 00:12:16.360 --> 00:12:20.000 Like it takes a very significant set of decision making to decide we're going 163 00:12:20.039 --> 00:12:24.480 to implement a set of applications. Is really what we're talking about, an 164 00:12:24.480 --> 00:12:28.480 overall solution suite in a service boss model, And I don't think we're going 165 00:12:28.519 --> 00:12:31.000 to talk about that today because I think most people don't start there. I 166 00:12:31.000 --> 00:12:35.440 think most folks build an application and get to a place where they now are 167 00:12:35.519 --> 00:12:39.320 told, you know, if only we'd build this as microservice as everything will 168 00:12:39.360 --> 00:12:43.559 be good. Tear it all down start over, which I've come to appreciate 169 00:12:43.600 --> 00:12:46.320 the main advantage of that approach is that it means you'll be left alone for 170 00:12:46.360 --> 00:12:52.320 six months while you admired your reartic. All I really want to do is 171 00:12:52.360 --> 00:12:56.440 stop coming to this meeting. If I say this, can I stop coming 172 00:12:56.440 --> 00:12:58.759 to this meeting? See in six months? That's what it works. Hey, 173 00:13:00.039 --> 00:13:01.480 John, thank you so much for your comment I thought was super relevant 174 00:13:01.480 --> 00:13:05.440 to our show today. And a copy of music cobuy is on its way 175 00:13:05.440 --> 00:13:07.480 to you. And if you'd like a copy of music Code Buy, write 176 00:13:07.480 --> 00:13:09.879 a comment on the website at dot at rocks dot com or on the facebooks. 177 00:13:09.879 --> 00:13:13.080 We publish every show there and if you comment there and I ready on 178 00:13:13.120 --> 00:13:15.559 the show, we'll send you a copy of music Go Buy. And you 179 00:13:15.600 --> 00:13:18.559 know you can follow us on Twitter. That's fine. But the real fun 180 00:13:18.720 --> 00:13:22.320 is happening over on Mastodon right now. I'm Carl Franklin at Techup dot social 181 00:13:22.399 --> 00:13:26.960 and I'm Rich Campbell at Mastodon dot social. And it's the real fun happening 182 00:13:26.960 --> 00:13:30.600 at Mastadon. I think it's or is it now happening at threads? No, 183 00:13:30.879 --> 00:13:33.480 it's happening at Macedon right now. For me, anyway. Yeah, 184 00:13:33.519 --> 00:13:37.480 I don't know. Are you on threads yet? I had to sign up 185 00:13:37.519 --> 00:13:39.240 with it. I'm one of the hundred million in five days. Yeah, 186 00:13:39.320 --> 00:13:41.879 me too. It's because we all had Instagram accounts, right, so it's 187 00:13:41.919 --> 00:13:46.279 not a big deal to flip across. I never had all that many Instagram 188 00:13:46.320 --> 00:13:50.360 followers anyway. Yeah, so we'll see. If your Instagram grids, then 189 00:13:50.360 --> 00:13:52.679 your thread's gonna be good. And you're Instagram not good, Your threads are 190 00:13:52.679 --> 00:13:54.840 not going to be so good. And yeah, are we really trying to 191 00:13:54.840 --> 00:13:56.919 Are we really looking to Zuckerberg to be the safe here of anything? No? 192 00:13:58.360 --> 00:14:01.559 Actually, no, thanks, No, not at all. Yeah, 193 00:14:01.679 --> 00:14:05.559 I've already given her on all. I got a blue Sky account to me, 194 00:14:05.639 --> 00:14:09.840 and I'm gonna try that with my friends. Yeah. Yeah, all 195 00:14:09.960 --> 00:14:13.559 right, Well, anyway, let's bring on Layla Porter. Laila is a 196 00:14:13.600 --> 00:14:18.559 developer advocate of VMware serving the dot net community. She makes videos and live 197 00:14:18.600 --> 00:14:24.600 codes on YouTube. She's a Microsoft MVP, a GitHub Star Progress Ninja, 198 00:14:24.799 --> 00:14:31.080 and the founder of the hashtag Women of dot Net initiative. Layla loves sharing 199 00:14:31.120 --> 00:14:37.200 knowledge whilst having fun. No question is stupid and beginners are always welcome and 200 00:14:37.279 --> 00:14:39.440 you are always welcome here on dot net Rocks Laylah, welcome back. Hello, 201 00:14:39.759 --> 00:14:43.399 thank you for having me back. Yeah, you know it's English. 202 00:14:43.399 --> 00:14:46.919 When you hear the word whilst, you can pull that word off. Nobody 203 00:14:46.919 --> 00:14:52.159 else can put can drop a whilst and mean it. I can't say just 204 00:14:52.399 --> 00:14:58.000 while unless I'm whiling away the time. Otherwise it's that's a while without an 205 00:14:58.120 --> 00:15:03.519 h that's a whole other w that's it. So you know that's the only 206 00:15:03.559 --> 00:15:07.240 time you'll hear me say while. Ye fair, fair enough, appreciate it. 207 00:15:07.399 --> 00:15:11.039 The last time we talked was at NDC somewhere, wasn't it. I 208 00:15:11.039 --> 00:15:13.200 don't know. This is my third appearance like that. Oh we did the 209 00:15:13.320 --> 00:15:18.720 dot net Foundation show, all right, Yeah, that was just an interesting 210 00:15:18.840 --> 00:15:24.639 time, as I recall. Quite yes, interesting, I have not. 211 00:15:24.399 --> 00:15:28.240 I mean, I the Foundation is still out there. Things seem a little 212 00:15:28.279 --> 00:15:35.559 more peaceful, which not much of an achievement, but I I mean, 213 00:15:35.559 --> 00:15:37.879 if there's anything I can say about the Foundations, like, I appreciate the 214 00:15:37.919 --> 00:15:43.639 focus on the open source leaders project leaders these days. I think it's wise 215 00:15:43.159 --> 00:15:48.000 and uh and something really and something important going on in our industry right now. 216 00:15:48.360 --> 00:15:52.759 But we'll that was womanly man like over almost three years ago, so 217 00:15:52.080 --> 00:15:58.559 we'll probably due for dragon some foundation folks in it a loop and having a 218 00:15:58.600 --> 00:16:02.960 conversation. Well, I just got some new directors, three new directors now, 219 00:16:03.000 --> 00:16:10.279 so now as did I. So what's on your mind today, Leila? 220 00:16:11.799 --> 00:16:15.960 Wow, there's a lot of things on my mind. But I guess 221 00:16:15.960 --> 00:16:21.120 the past two years, because it's been two years now since I joined VMware, 222 00:16:21.720 --> 00:16:26.879 it's been thinking about micro services. So you're talking about all of that 223 00:16:26.960 --> 00:16:33.600 just now was very relevant and that was a really steep learning curve and I 224 00:16:33.639 --> 00:16:37.440 can only imagine how steep it is for folks who are actually doing the thing 225 00:16:37.840 --> 00:16:44.799 and moving across to microservices. So I thought we could have a little chat 226 00:16:44.799 --> 00:16:51.080 about that and how I don't like microservices and would urge people to shy away 227 00:16:51.200 --> 00:16:53.879 unless they absolutely, really really have to. You are not alone. In 228 00:16:55.000 --> 00:17:00.720 fact, the sentiment from our most recent guests is do you really need this? 229 00:17:00.399 --> 00:17:04.160 Yeah? Yeah, it is sort of the I'm not gonna say it's 230 00:17:04.200 --> 00:17:10.839 a lashback, but anything that it falls into that one right way category gets 231 00:17:10.839 --> 00:17:15.640 pushed back on and with good reason. Yeah, and usually by the people 232 00:17:15.680 --> 00:17:19.839 that try it, and it just seems to complicate things and slow things down 233 00:17:21.200 --> 00:17:23.400 and that it does. Yeah, the question is does it get you anything? 234 00:17:23.480 --> 00:17:30.000 Like I have certainly worked on service bus architectured applications because they were complex 235 00:17:30.119 --> 00:17:33.640 enough, with enough different stacks and enough different development teams that that conscious up 236 00:17:33.680 --> 00:17:40.480 coupling to work on the work through a bus became essential. Otherwise this gigantic 237 00:17:41.000 --> 00:17:44.720 multimodal app resonated with each other. We couldn't ship anything. But not that 238 00:17:44.759 --> 00:17:48.599 many applications are like that. Well, buses incus are a good idea even 239 00:17:48.640 --> 00:17:52.279 if you don't have a big or complex thing. I mean, that's just 240 00:17:52.359 --> 00:17:56.960 a it's an asynchronous tool. Yeah, if that if that's if that's something 241 00:17:57.000 --> 00:18:00.640 you need. Yeah, but where are you coming at this from? Laila? 242 00:18:00.720 --> 00:18:04.960 Who are the frustrated devs? I found that at work a lot of 243 00:18:04.960 --> 00:18:11.359 the people I was speaking to were advocating hard for microservices. So it's something 244 00:18:11.359 --> 00:18:15.720 that I really had to look into and learn more about architecting. And the 245 00:18:15.759 --> 00:18:19.400 more I looked into it and the more I spoke to people, the more 246 00:18:19.440 --> 00:18:25.039 I saw that people were getting really drowned in the complexity of it. All 247 00:18:25.480 --> 00:18:30.640 right, And I think, as you say, there were some loud voices 248 00:18:30.680 --> 00:18:34.759 saying there's a particular way of doing something and it's a one size fits all, 249 00:18:34.839 --> 00:18:38.480 But really, when you're getting up to that scale and that type of 250 00:18:40.480 --> 00:18:47.559 enterprise application, it's really bespoke and I think it has to be a pragmatic 251 00:18:47.599 --> 00:18:52.119 approach. And there was far too much dogma for my liking. Yeah, 252 00:18:52.200 --> 00:18:55.480 yeah, it isn't that a double whammy. It's not only that microservices the 253 00:18:55.480 --> 00:19:03.079 way, but this form of microservices is the way. And most of the 254 00:19:03.359 --> 00:19:07.799 customers that I speak to are if we're lucky, they're on dot Net framework 255 00:19:08.039 --> 00:19:15.920 with a spaghetti tangle of code. A lot of them are still on Classic 256 00:19:15.960 --> 00:19:25.440 ASP and yeah, they have hundreds of applications, internal applications running on Classic 257 00:19:26.160 --> 00:19:32.039 And how do you get them from going from that mindset to this big deal 258 00:19:32.119 --> 00:19:36.599 of microservices? And do they need it? That's the big question. Yeah, 259 00:19:36.720 --> 00:19:40.000 is there a litmus test? Is there a few questions you can ask 260 00:19:40.039 --> 00:19:42.480 yourself to determine whether this is a good idea or not. My general thing 261 00:19:42.599 --> 00:19:48.279 is if you can't answer yes straight away, then the answer is no. 262 00:19:48.599 --> 00:19:52.960 That's kind of my going on it. If I say do you think you 263 00:19:53.039 --> 00:19:56.119 need microservices and they go, well, we heard it's a good idea. 264 00:19:56.119 --> 00:20:03.079 Blah blah. I stop them there because we heard or my CTO thinks it's 265 00:20:03.079 --> 00:20:07.200 a good idea, we want it, or the worst thing is resume development, 266 00:20:07.880 --> 00:20:11.839 resume driven development. I hear that a lot. We want to try 267 00:20:11.880 --> 00:20:19.160 it, and then the complexity that it adds is just not worth it. 268 00:20:21.279 --> 00:20:25.599 Also, if the teams aren't big enough, that's a big issue. I 269 00:20:25.640 --> 00:20:30.039 think you need to have a big enough development team to be able to pull 270 00:20:30.079 --> 00:20:34.839 it off. Otherwise everyone's going to be run ragged trying to manage this service 271 00:20:34.920 --> 00:20:40.880 or that service. I've seen customers layla that feel that they need to do 272 00:20:40.960 --> 00:20:47.480 it to sort of be ready for the inevitability that their application is going to 273 00:20:47.480 --> 00:20:52.240 become the next Facebook or the next Twitter or some sort of like Uber popular, 274 00:20:52.960 --> 00:20:56.559 you know, when in fact it's it's just another company, you know. 275 00:20:56.359 --> 00:21:00.519 Yeah, and I hear that a lot as well. We want to 276 00:21:00.519 --> 00:21:03.240 be read a funny thing and being that the Twitters and the facebooks didn't do 277 00:21:03.279 --> 00:21:07.839 that and were successful and then retro fitted into it, which is far more 278 00:21:07.880 --> 00:21:14.319 realistic. Yeah, And I think there's really good design decisions that one can 279 00:21:14.440 --> 00:21:21.440 make at the beginning of application development or through application development that will enable that 280 00:21:21.559 --> 00:21:26.559 transition at a later date, and that's what I advocate for. I think 281 00:21:26.799 --> 00:21:33.119 architecting your applications in a way such as that when you need to if way 282 00:21:33.240 --> 00:21:40.599 down the road that you actually need to go distributed or part distributed, it 283 00:21:40.640 --> 00:21:47.559 will be easier. And that's what I've try to sort of teach. Nowadays, 284 00:21:47.799 --> 00:21:52.519 I think you've sort of dropped a yagny on me yet another he ain't 285 00:21:52.559 --> 00:21:56.279 gonna need it. Oh, you ain't gonna ye, It's right, you 286 00:21:56.319 --> 00:22:00.880 ain't gonna need it. I remember that one. Yeah, yeah, hey, 287 00:22:00.079 --> 00:22:06.160 you know I had to double check. But Classic ESP only when out 288 00:22:06.200 --> 00:22:11.119 of long term support in December of twenty one. Really yeah, wow. 289 00:22:11.599 --> 00:22:15.200 Now the original version was nineteen ninety six, so it's twenty That was twenty 290 00:22:15.200 --> 00:22:18.519 five years. But you know, to me, and I think to all 291 00:22:18.519 --> 00:22:22.400 of us, when you said that, it's like, it's crazy that anybody's 292 00:22:22.400 --> 00:22:25.920 still be using Classic ESP. But it's like it's only JET. I mean, 293 00:22:25.920 --> 00:22:27.960 it's only it's been it's fully out of support for the past almost two 294 00:22:29.039 --> 00:22:37.079 years. But still okay, talk about spaghetti code wow man, and nightmares 295 00:22:37.119 --> 00:22:41.119 about that stuff. I mean, the enterprise architect in me thinks about that 296 00:22:41.160 --> 00:22:45.000 for a moment and would point them at power apps because odds are that's the 297 00:22:45.119 --> 00:22:51.799 kind of software they're building internally, our forms over data apps, and and 298 00:22:51.839 --> 00:22:55.039 I would want to go to the domain experts and say, hey, you're 299 00:22:55.079 --> 00:22:57.119 tired of using this, let me set you up with this tool and sort 300 00:22:57.160 --> 00:23:02.720 of go from there. I certainly don't think microservices from there. The idea 301 00:23:02.720 --> 00:23:03.920 of looking at classic ASP app and going, you know, when it fix 302 00:23:04.039 --> 00:23:11.440 this microservices, Oh my god, that's like the new title of a horror 303 00:23:11.480 --> 00:23:15.559 movie. Honestly, that's awful, and that I do hear it. It's 304 00:23:15.599 --> 00:23:22.240 such a Titanic leaps. It's just stunning. You're literally talking about nothing but 305 00:23:22.359 --> 00:23:26.039 code behind Yeah, right, Like one of ISP's big limitations was the lack 306 00:23:26.079 --> 00:23:32.039 of architecture, Like it was so hard to separate concerns at all in there. 307 00:23:32.480 --> 00:23:36.839 And now you're going into something that you've already pointed this out. Microservices 308 00:23:36.839 --> 00:23:40.519 serves lay well when the teams are big and plentiful, and that we need 309 00:23:40.559 --> 00:23:45.319 a lot of architecture so these folks can work together. That makes a lot 310 00:23:45.359 --> 00:23:49.799 of sense. Odds are the folks operating maintaining these ASP apps are one or 311 00:23:49.839 --> 00:23:55.440 two people that have ever touched that app probably ever. Yeah, we heard 312 00:23:55.480 --> 00:24:00.599 horror stories, didn't we, Richard, about people who followed a particular like 313 00:24:00.000 --> 00:24:07.359 very granular architecture for services. Everything was a service. And this was a 314 00:24:07.480 --> 00:24:12.119 very well known author that had this book and was consulting and they ended up 315 00:24:12.119 --> 00:24:17.680 but it ended up costing them millions of dollars because it was not only a 316 00:24:17.720 --> 00:24:19.920 waste of time, but it slowed everything down and there was no way to 317 00:24:21.000 --> 00:24:26.519 make it go faster, just completely over architected. Yeah, and I've heard 318 00:24:26.559 --> 00:24:36.160 stories now of companies going backwards that they're taking out their microservices and reconsolidating applications 319 00:24:36.279 --> 00:24:42.240 just because it's it's just wildly out of control, right, And I think 320 00:24:42.279 --> 00:24:48.359 it's just the developer experience when you start going into these these big systems that 321 00:24:48.400 --> 00:24:53.519 are distributed is awful. You don't always know where the errors are coming from 322 00:24:53.640 --> 00:25:00.519 unless you've put in great documentation that your testing is up to scratch. And 323 00:25:00.640 --> 00:25:07.400 I mean we all know that when you've got a PM or a CTO breathing 324 00:25:07.440 --> 00:25:11.480 down your neck and saying we need this yesterday, right, that some of 325 00:25:11.519 --> 00:25:15.759 those things are I'll put on a back burner and oh, I'll get to 326 00:25:15.880 --> 00:25:21.680 that and I'll implement that at some stage when it all quietens down, and 327 00:25:21.720 --> 00:25:26.319 then it never advocates implemented. Yeah, and you need all that. The 328 00:25:26.640 --> 00:25:30.359 point here is that the ceremony around all of this is important to it. 329 00:25:30.359 --> 00:25:33.039 It is it can't be can't be optional. And I don't hear you saying 330 00:25:33.079 --> 00:25:37.400 that there should be no separation of concerns, because there clearly has to be. 331 00:25:37.079 --> 00:25:44.119 But you need just enough to make it work and and don't you know, 332 00:25:44.480 --> 00:25:48.599 don't go overboard. That's it. And then finding that balance is kind 333 00:25:48.599 --> 00:25:51.000 of hard. But it seems like, you know, I can think of 334 00:25:51.039 --> 00:25:56.079 maybe three or four silos that a big application would want to be in, 335 00:25:56.039 --> 00:26:02.200 right, you know, reporting services is maybe you know, communication, email, 336 00:26:02.279 --> 00:26:07.759 that kind of stuff that. Yeah, But then I also find that 337 00:26:07.160 --> 00:26:10.319 I don't know if I'm going to get hate mail over this, But some 338 00:26:10.400 --> 00:26:15.759 of the DDD people have sort of contributed to this, you know, but 339 00:26:15.319 --> 00:26:19.400 domain driven meaning you know, all right, let's you know, find our 340 00:26:19.480 --> 00:26:23.759 domains and circle them out and these are going to map to services. What 341 00:26:23.920 --> 00:26:27.039 do you what do you think of that? Am I crazy? Well? 342 00:26:27.039 --> 00:26:32.920 I'm really glad you brought that up, Carl, because one of the things 343 00:26:33.039 --> 00:26:37.400 I keep coming up against is everything to do with micro services seems to lead 344 00:26:37.440 --> 00:26:45.000 you to DDD, and I think that is a completely different way of thinking. 345 00:26:45.200 --> 00:26:52.640 And I like to say I steal just enough DDD to be dangerous, 346 00:26:52.880 --> 00:26:57.519 but I actually think I still just enough DDD to get on and code what 347 00:26:57.599 --> 00:27:03.200 I need to code. And the main thing I take away from DDD is 348 00:27:03.240 --> 00:27:07.519 just high cohesion lease coupling. That's the main thing I take away, which 349 00:27:07.519 --> 00:27:11.839 I think is any sort of principle, well, is the main principle that 350 00:27:11.880 --> 00:27:18.759 you want to think about when you are designing your application and thinking about that 351 00:27:18.839 --> 00:27:22.400 separation of concerns? And again you're you're talking about a certain threshold of complexity 352 00:27:22.480 --> 00:27:26.599 to even be concerned about that. The app is big enough that it needs 353 00:27:26.640 --> 00:27:30.759 a separation of concerns. Yes, I would say it has to have that 354 00:27:30.839 --> 00:27:37.960 critical mass for you to actually be worried about modularizing it and going down the 355 00:27:37.119 --> 00:27:42.720 modular monolith, which I'm a big fan of and it's a great term it 356 00:27:45.559 --> 00:27:52.880 and that really does feel like the wild West when I've been researching the right 357 00:27:52.920 --> 00:27:57.920 way, and I do that in finger quotes. To do a modular monolith. 358 00:27:59.440 --> 00:28:06.359 There are so many different opinions, there's no real guidelines. I found 359 00:28:06.359 --> 00:28:12.960 that was a really under talked about area. There was very little information on 360 00:28:14.000 --> 00:28:17.640 that, a few YouTube videos, a few people speaking loudly about it, 361 00:28:17.680 --> 00:28:23.240 but then it always had that DDD overtone or DDD undertone, I should say, 362 00:28:25.000 --> 00:28:30.279 And I didn't want to go that way. So the past I don't 363 00:28:30.319 --> 00:28:33.680 know, eight months, I've been researching on how to do that, trial 364 00:28:33.720 --> 00:28:41.200 and error and coming up with an interesting way to architect it. And it's 365 00:28:41.559 --> 00:28:45.920 all just big chunks, And I think that's trying to keep the complexity as 366 00:28:47.039 --> 00:28:51.240 low as possible, but make it in such a way that you can break 367 00:28:51.279 --> 00:28:56.119 off these little satellites of applications if you need to, if you need that 368 00:28:56.240 --> 00:28:59.880 scale. Well, I appreciate the term that you're breaking off. So you're 369 00:29:00.200 --> 00:29:03.519 already coming from the angle of you have built a monolith, because that's the 370 00:29:03.599 --> 00:29:08.279 default, right that we tend to just keep adding things to that our applications 371 00:29:08.359 --> 00:29:12.640 need over time, and eventually eventually you have a problem. But the always 372 00:29:12.680 --> 00:29:18.480 question is like, what's the problem. Is it resonance, Like it's a 373 00:29:18.519 --> 00:29:21.119 big deal to make a change to anything. Is it affects so many other 374 00:29:21.160 --> 00:29:25.640 things. Or I often being the scaling guy, ran into the scaling problem 375 00:29:25.680 --> 00:29:29.680 where it's like, it is very costly to scale this monolith just because one 376 00:29:29.720 --> 00:29:33.319 set of services and it needs to run many more instances. That makes sense. 377 00:29:33.279 --> 00:29:38.640 You know, your asynchronous things becomes services and they those things can scale 378 00:29:38.720 --> 00:29:44.440 up and down. That's needed. That makes sense to me. So chipping 379 00:29:44.519 --> 00:29:48.640 pieces out of the monolith is that the fair term I would say. So 380 00:29:49.519 --> 00:29:55.960 I really like to think of them as satellites. And the one I always 381 00:29:56.039 --> 00:30:00.480 use as an example is like a notification service. You can have that in 382 00:30:00.519 --> 00:30:04.759 your monolith. But let's just say you're you want to bulks and emails or 383 00:30:04.799 --> 00:30:11.240 something like that. You may have that sporadically and you don't need it all 384 00:30:11.279 --> 00:30:15.079 the time. So it's a perfect thing to shove onto and as your function 385 00:30:15.279 --> 00:30:18.480 or an aw as lambda and just have that scale as and when you need 386 00:30:18.519 --> 00:30:22.759 it. But if you have that as a module in your modular monolith, 387 00:30:23.079 --> 00:30:26.839 it's just so easy to as you say, Richard, chip that off, 388 00:30:27.240 --> 00:30:34.920 throw it into something else and connect to that with ease and have your system 389 00:30:36.000 --> 00:30:41.000 still a monolith. You haven't got that added complexity of everything's distributed, and 390 00:30:41.039 --> 00:30:45.599 I think that's the middle ground where I think most companies and most applications need 391 00:30:45.680 --> 00:30:49.920 to sit. But there seems to be these this polar divide, and these 392 00:30:49.960 --> 00:30:55.880 two camps know we're sitting in this big ball of mud monolith over here because 393 00:30:56.119 --> 00:31:00.559 we don't want to go that route, and we love it. That's it 394 00:31:00.599 --> 00:31:11.599 in a mud pick, so happy right here. And then we have the 395 00:31:11.079 --> 00:31:18.279 distribute distribute everything camp over there where every little tiny thing is a service and 396 00:31:18.319 --> 00:31:25.799 now we've got minimal APIs and there's like a million minimal API applications and are 397 00:31:26.119 --> 00:31:30.000 both of these lies? I mean, really, nobody has one monolith. 398 00:31:30.079 --> 00:31:34.680 There's always some services extraneous, and nobody has a perfect set of micro services. 399 00:31:34.759 --> 00:31:40.480 There's always at least some ball of mud somewhere. Oh it's hidden, 400 00:31:41.200 --> 00:31:45.200 calling a ball of go. Yes, more than mud, it's like and 401 00:31:45.200 --> 00:31:48.039 it's it's you shouldn't be embarrassed that you have one. The only question is 402 00:31:48.079 --> 00:31:53.319 do you know where yours is? Right? Do you know where your ball 403 00:31:53.359 --> 00:31:57.400 of go is? Because if you don't, that's a concern, that's a 404 00:31:57.400 --> 00:32:02.440 big problem, right right. All the reason this world is people who have 405 00:32:02.640 --> 00:32:08.200 who know where their balls of mud are and people who are lying. Hey, 406 00:32:08.240 --> 00:32:13.000 guys, let's take a break. We'll continue this great discussion with Lalah 407 00:32:13.039 --> 00:32:21.920 Porter after these very important messages, and we're back. It's doting at Rocks. 408 00:32:21.960 --> 00:32:24.440 I'm Carl Franklin. That's my friend Richard Campbell, and this is our 409 00:32:24.480 --> 00:32:32.079 friend Lala Porter and she's she's quoting blasphemy here, blasphemy. I'm shocked, 410 00:32:34.119 --> 00:32:45.559 get shocked and awed and horrified. No microservices or maybe only one. Yeah, 411 00:32:45.640 --> 00:32:49.640 just a couple of couples. Fine, you know, microservices the word 412 00:32:49.680 --> 00:32:57.240 itself implies that the whole thing just get split up into all these little pieces. 413 00:32:57.640 --> 00:33:00.160 And that's you know, when you say, oh, we have a 414 00:33:00.240 --> 00:33:02.599 couple of microservices, then people look at your crosside. What do you mean 415 00:33:02.640 --> 00:33:08.920 a couple of microservices? Call them Bob and Doug. Yeah, and they 416 00:33:08.920 --> 00:33:13.839 sit in the corner. Yeah, I like your satellites. We have these 417 00:33:13.880 --> 00:33:19.279 satellites. That's that is a good term specific things. And I know that 418 00:33:19.319 --> 00:33:24.759 there is an architecture term that they call it a citadel, but I don't. 419 00:33:24.799 --> 00:33:30.279 That doesn't resonate with me. And so I've really hung onto this for 420 00:33:30.559 --> 00:33:36.599 the past few years, this idea of the satellites orbiting my monolith. And 421 00:33:37.519 --> 00:33:42.400 I do want to say that when I say monolith, people think it's like 422 00:33:42.640 --> 00:33:45.279 a negative thing, right, right. They get really touchy about it, 423 00:33:45.359 --> 00:33:49.279 like we've got a monolith, but you know, we're looking to distribute it. 424 00:33:49.319 --> 00:33:52.559 We want to spread it out, like people are going to judge them 425 00:33:52.640 --> 00:33:58.799 because they've got a monolith, or that they're outdated. Yeah, yeah, 426 00:33:58.839 --> 00:34:01.960 And I don't. It's like the word legacy. There's nothing wrong with a 427 00:34:02.119 --> 00:34:07.960 well architected and well maintained legacy applications, especially if it's making money. Oh 428 00:34:08.039 --> 00:34:14.800 yeah, yeah, crying all the way to the bank. Yep, it's 429 00:34:14.840 --> 00:34:22.679 written in VB. Shut up. So I just I think there's all this 430 00:34:23.000 --> 00:34:30.079 negativity around this space and there doesn't need to be. And I think monoliths 431 00:34:30.159 --> 00:34:37.480 are definitely where every application should start, and I think there needs to be 432 00:34:37.199 --> 00:34:44.440 a well considered, good plan for how that application is going to grow. 433 00:34:45.199 --> 00:34:49.760 And I think it comes down to people, and it's not the code, 434 00:34:49.840 --> 00:34:53.039 it's always the people. And what I mean by that is you have the 435 00:34:53.159 --> 00:34:59.599 visionary, the architect, and they do it all or beautifully and the application 436 00:34:59.679 --> 00:35:04.800 is st with best intentions. Because I'm sure no one out there has gone 437 00:35:04.800 --> 00:35:08.599 out to architect a big ball of mud or a spaghetti tangle. I can't 438 00:35:08.599 --> 00:35:15.559 think of anyone who would intentionally architect something like that. So I believe people 439 00:35:15.599 --> 00:35:20.159 are going with good intentions. But how does one but keeping all the services 440 00:35:20.199 --> 00:35:24.039 together in a deployment is actually efficient. Yes, it's fast, it interrupts 441 00:35:24.039 --> 00:35:28.639 well, it deploys easily. Like there's a lot of reasons to do that. 442 00:35:29.400 --> 00:35:32.639 I didn't make a mistake. That was the sensible thing to do until 443 00:35:32.800 --> 00:35:42.239 something changes, absolutely, And I think it's where things go wrong is when 444 00:35:42.239 --> 00:35:47.000 that architect leaves or they retire, or you get the new hires in and 445 00:35:47.039 --> 00:35:52.880 they're not on boarded correctly, or there is no design document or style guide. 446 00:35:53.480 --> 00:35:57.679 And I think that's very when too much of that architecture was in that 447 00:35:57.760 --> 00:36:02.719 person's head. That's it, and it's that what is it the bus prevention 448 00:36:04.000 --> 00:36:07.480 theory, hit by a bus thing for some term, or can't take a 449 00:36:07.599 --> 00:36:12.280 vacation, or when you take two weeks off, a whole bunch of stuff 450 00:36:12.280 --> 00:36:16.960 just stops until you get back, or worse, it carries on without your 451 00:36:17.039 --> 00:36:22.840 vision and oversight. And now you've got whole new services that are duplicating things. 452 00:36:23.760 --> 00:36:28.559 You've got this, and I'm talking about service services within an application, 453 00:36:28.599 --> 00:36:34.880 not microservices. So you've maybe got some different new interfaces, or people are 454 00:36:35.360 --> 00:36:42.239 doing weird things with dependencies, and you just get this this. Well, 455 00:36:42.679 --> 00:36:46.039 concerns are getting tangled, there's no separation. We're getting this cross contamination of 456 00:36:46.519 --> 00:36:52.440 those clear boundaries that should be in place. And I think this comes down 457 00:36:52.480 --> 00:37:00.159 to something I only recently discovered, and that that's like architecture tests. I 458 00:37:00.159 --> 00:37:05.280 don't know that was a thing until I started researching this, and it seems 459 00:37:06.079 --> 00:37:09.280 like a silly thing not to realize that it was there. But you can 460 00:37:09.480 --> 00:37:16.639 put in a whole load of architecture tests that makes sure that the architecture you 461 00:37:17.039 --> 00:37:22.880 put into your application as being adhered to, and that can be like different 462 00:37:22.880 --> 00:37:29.199 projects aren't referencing projects they shouldn't be. And it just seems so logical to 463 00:37:29.239 --> 00:37:32.639 me. In all the years I've done TDD and testing, this has never 464 00:37:32.719 --> 00:37:37.840 come up. If you never once unit tests to validate your adhering to an 465 00:37:37.880 --> 00:37:42.159 architectural press, Yeah, well it's a good idea and I'd never heard of 466 00:37:42.159 --> 00:37:45.360 it. I'm trying to conceptualize how that even works. Well, there's a 467 00:37:45.400 --> 00:37:50.519 framework coworld architecture dot net. I believe, I think that's the name of 468 00:37:50.519 --> 00:37:53.760 it. I could be wrong, don't quote me on that, but it 469 00:37:53.840 --> 00:38:01.960 is a series of unit tests that check for architecture parents and I had never 470 00:38:02.000 --> 00:38:06.599 seen it, And when you start looking into it, it makes perfect sense. 471 00:38:07.039 --> 00:38:13.000 And how what assembly can reference what assembly? You can get quite in 472 00:38:13.119 --> 00:38:15.519 depth with it. Okay, I get it. So you're using reflection a 473 00:38:15.559 --> 00:38:20.599 lot to figure out how these things are coupled or decoupled or not coupled, 474 00:38:20.599 --> 00:38:24.599 and what calls what and making a code map and yeah, okay, yeah, 475 00:38:24.679 --> 00:38:29.079 that makes sense. And it doesn't seem like something that you would write 476 00:38:29.119 --> 00:38:31.960 tests for. Maybe you would just tell it what the guidelines are, what 477 00:38:32.519 --> 00:38:37.760 are and it would run a test and say, okay, here are your 478 00:38:37.760 --> 00:38:43.280 problems as I see them. Yeah. Cool. I thought it was pretty 479 00:38:43.320 --> 00:38:47.639 cool because something that I've come up against when I was in engineering was that 480 00:38:49.679 --> 00:38:52.039 there was so many different places to do the same thing. I worked on 481 00:38:52.079 --> 00:39:00.079 a dot net framework app that was fifteen years old, and you didn't know 482 00:39:00.239 --> 00:39:04.719 where to add something in because it could be in one of a number of 483 00:39:04.760 --> 00:39:12.000 places, and there were I don't know ten twelve different projects within this application, 484 00:39:13.320 --> 00:39:15.480 and you didn't know where anything was going to go. And that is 485 00:39:15.920 --> 00:39:22.920 where so many applications are because they all sort of grow over time. And 486 00:39:22.960 --> 00:39:28.679 that's the whole point. It's a development process. It doesn't just magic up 487 00:39:28.760 --> 00:39:32.440 overnight. So you know, people don't hang around jobs that long. So 488 00:39:32.519 --> 00:39:37.119 how do you do this and how do you keep that? And it's I 489 00:39:37.119 --> 00:39:42.639 think there's three places that you can. You can start looking at adherence to 490 00:39:42.760 --> 00:39:47.760 your architecture, and that's visual looks, so getting someone to do a code 491 00:39:47.800 --> 00:39:54.719 review and going to check it. You can have sort of tests in place, 492 00:39:57.480 --> 00:40:00.239 and you can also have you know, compar wild time testing on that. 493 00:40:00.320 --> 00:40:06.159 So there's all these different levels that you can have to make sure that 494 00:40:06.199 --> 00:40:12.039 adherence is being met. And it just made sense to me, but I've 495 00:40:12.079 --> 00:40:15.719 never seen it done in practice. I'd love to know who's doing this in 496 00:40:15.840 --> 00:40:20.360 practice. Yeah, something something to fall around on. I did find the 497 00:40:20.719 --> 00:40:25.039 GitHub repository for net arc test. That's the one, yeah, based on 498 00:40:25.079 --> 00:40:30.039 the Java art test. Yeah. Yeah, and just that exactly idea of 499 00:40:30.199 --> 00:40:35.920 essentially writing assertions that say here's our architectural rules. I mean, I don't 500 00:40:35.960 --> 00:40:38.800 want to say that you just want to pop warnings, but certainly when you're 501 00:40:38.880 --> 00:40:42.800 writing code, especially new to a project, to have it come back and 502 00:40:42.840 --> 00:40:46.000 say, hey, we have an architectural requirement around this, and this code 503 00:40:46.079 --> 00:40:51.679 violates it. So at least you know you're pressing against edges that nobody wants 504 00:40:51.719 --> 00:40:55.880 your press against. And it's also documentation because someone can come and read those 505 00:40:55.920 --> 00:41:02.079 tests, and you know that's the first step of a documentation for your application 506 00:41:02.159 --> 00:41:07.559 and your style guide. You're describing intent at that point. And even the 507 00:41:07.599 --> 00:41:09.960 best part is when your architect goes on vacation, they could be sitting on 508 00:41:10.000 --> 00:41:15.119 a beach and looking at the results of these tests and then send an email 509 00:41:15.159 --> 00:41:17.760 that says, hey, what are you guys doing? Stop it? Yeah. 510 00:41:22.840 --> 00:41:28.360 Yeah. So it was really interesting to start delving into this world and 511 00:41:28.440 --> 00:41:36.039 it really felt like the wild West. And my teammates they're all Spring advocates, 512 00:41:36.280 --> 00:41:43.079 so they're very into the distributed systems, very into all of this enterprise 513 00:41:43.199 --> 00:41:49.519 architecture. I think Spring has been far ahead of dot net in that respect 514 00:41:49.760 --> 00:41:53.559 of pushing that and offering the libraries that support that kind of architecture. So 515 00:41:54.039 --> 00:41:58.400 learning from them, and some of them are really big DDD advocates, so 516 00:41:58.800 --> 00:42:04.880 trying to to dissect what I want from from what they say and the stuff 517 00:42:04.920 --> 00:42:09.599 that I don't which is too far in the DDD realm um. It has 518 00:42:09.679 --> 00:42:15.079 been really interesting, but it's something I don't hear spoken about. It is 519 00:42:15.119 --> 00:42:21.679 the tea camps stay away from monoliths or stay away from distributed systems, and 520 00:42:21.719 --> 00:42:24.559 there's never this in between, which I think is why people should be. 521 00:42:24.760 --> 00:42:30.800 I really really strongly feel that it's I mean, ultimately just to try and 522 00:42:30.840 --> 00:42:34.719 make more maintainable projects. Yeah, you have to have a new acronym here 523 00:42:34.840 --> 00:42:40.199 jed jeed just enough distribution, that's it. That's a great acronym. I 524 00:42:40.280 --> 00:42:47.079 like that. Oh okay, I don't like it so much now, No, 525 00:42:47.159 --> 00:42:53.880 not my favorite. To join my foundation, it's fifty acronym right there. 526 00:42:54.159 --> 00:43:00.599 But it was interesting going through the modular monoliths and how you can start 527 00:43:00.639 --> 00:43:07.199 implementing so many of these good patterns such as the asynchronous communication. You can 528 00:43:07.280 --> 00:43:14.599 have all of this message brokers implemented into your modular monoliths, so you can 529 00:43:14.639 --> 00:43:20.519 have all these modules and how are they speaking to each other by a service 530 00:43:20.559 --> 00:43:23.360 bus. So it's interesting that you were bringing up that because that was something 531 00:43:23.400 --> 00:43:30.719 that I worked really hard when I was building out a workshop on that used 532 00:43:30.719 --> 00:43:37.519 a modular monolith to get them messaging in that sublayer really really clearly defined so 533 00:43:37.559 --> 00:43:45.760 that people coming into those modules knew that each module could only communicate a cross 534 00:43:45.760 --> 00:43:53.199 a module via the asynchronous messaging, which was really a fun challenge to architect 535 00:43:53.239 --> 00:44:00.000 and think about how things were going to go and getting away from that synchronous 536 00:44:00.079 --> 00:44:02.639 I am waiting for a response mindset, yeah, yeah, and just trying 537 00:44:02.679 --> 00:44:07.440 to think, well, what does need immediate response? Well, anything user 538 00:44:07.519 --> 00:44:14.440 related and that's all going to be external, and basically anything internal doesn't need 539 00:44:14.559 --> 00:44:19.079 an immediate response, so you can offload all of that. Even though that 540 00:44:19.480 --> 00:44:23.400 even though the difference between immediate and this is milliseconds, it's perception, it's 541 00:44:23.960 --> 00:44:29.519 it's yeah's yeah, And it's also an architectural uncompelling yeah, that the returns 542 00:44:29.599 --> 00:44:34.360 come from a separate stream than the outputs. Um. I am deeply disturbed 543 00:44:35.280 --> 00:44:39.480 that we've spoken in this launched and you have not said Kubernetes, like, 544 00:44:39.519 --> 00:44:45.559 what's up? I did, but I try to avoid that very serious, 545 00:44:45.760 --> 00:44:52.920 right, I mean, there's another angle to this microservices push, which is 546 00:44:52.920 --> 00:44:57.920 it is also soling product right, and that's annoying too, Like there's other 547 00:44:57.960 --> 00:45:00.440 set of motivations around this and I and I mean as much as I'm making 548 00:45:00.440 --> 00:45:06.079 fun on the whole Kubernetes angles, like I am talking to more folks who 549 00:45:06.199 --> 00:45:13.119 are rehabilitating brownfield monoliths with Kubernetes, that that's a form of encapsulation. It's 550 00:45:13.360 --> 00:45:16.760 creating new security parameters, it's making them clean up messy bits of the code. 551 00:45:17.000 --> 00:45:22.079 The process of getting it to run well in a container tends to make 552 00:45:22.159 --> 00:45:24.920 the product better. They act better in the long run because it does start 553 00:45:24.920 --> 00:45:29.559 to separate out how we do state management, how we do storage, like 554 00:45:30.079 --> 00:45:34.480 all of those things are good, but it doesn't You're doing it because you 555 00:45:34.559 --> 00:45:37.960 want the software to be more reliable, not because somebody told you containers would 556 00:45:37.960 --> 00:45:45.119 save your life. And I've recently been shown this cool architecture by one of 557 00:45:45.119 --> 00:45:52.119 the solution engineers at work because VMware Tanzu the bit but I wipe for is 558 00:45:52.159 --> 00:45:59.360 all about cubanetis and that kind of system. I don't really delve that deep 559 00:45:59.440 --> 00:46:05.960 into it. I'm very much still on the code site. But the type 560 00:46:06.000 --> 00:46:09.519 of thing that you can do with CUBANETI, especially with the edge, is 561 00:46:10.079 --> 00:46:17.840 fascinating. So I learned a whole new way of architecting systems that is still 562 00:46:17.880 --> 00:46:27.920 monolithic but relies on Cubanetis as a way for engineers to easily distribute their code 563 00:46:27.920 --> 00:46:34.880 to edge locations and manage it centrally. And I've recently learned about a customer 564 00:46:34.960 --> 00:46:39.960 that has thousands of edge locations all running on VMS and they have to manually 565 00:46:40.079 --> 00:46:47.159 go and update each release on that, And I'd never thought about that aspect 566 00:46:47.280 --> 00:46:53.360 of it and coming background to how you can centrally manage that and get things 567 00:46:53.440 --> 00:47:00.199 that are low to no code locally because a lot of these edge locations don't 568 00:47:00.280 --> 00:47:06.760 have people who are technical at them, and they may not have constant Internet, 569 00:47:07.440 --> 00:47:12.320 so having something that can self heal and manage itself is really really important. 570 00:47:12.519 --> 00:47:15.639 And I've never appreciated that aspect of kubernetties. I always thought it was 571 00:47:16.159 --> 00:47:21.679 the oh, let's go to microservices, let's do this, it's the latest 572 00:47:21.679 --> 00:47:25.360 buzzword. But to see how it can work in that type of situation and 573 00:47:27.039 --> 00:47:34.320 make a DevOps engineer's life that much easier and automated had never occurred. To 574 00:47:34.360 --> 00:47:37.039 me. So that was a fascinating thing to learn. And I feel like 575 00:47:37.079 --> 00:47:42.800 I'm learning so much these past two years from a difference from being an API 576 00:47:42.880 --> 00:47:49.280 developer coming over to this whole new world of really big enterprise development. It's 577 00:47:49.320 --> 00:47:54.840 been a steep learning curven and I really appreciate people who are in those engineering 578 00:47:54.840 --> 00:47:59.679 teams trying to figure this out. Well. I think important part here is 579 00:47:59.719 --> 00:48:05.239 reckonizing EDGE doesn't mean the client machine. EDGE might be the CDN closest to 580 00:48:05.280 --> 00:48:07.480 the client machine, absolutely, Like that's just to getting into this idea that 581 00:48:07.480 --> 00:48:12.599 there's more places than the client and the server to deploy software too, and 582 00:48:12.760 --> 00:48:15.079 that you want to sort of unified strategy for saying, Okay, I'm going 583 00:48:15.159 --> 00:48:21.440 to push this compute closer to the customer, but not on the customer's machine. 584 00:48:21.599 --> 00:48:23.079 And I think it's a it's a hard idea to deal with. And 585 00:48:23.480 --> 00:48:28.400 you know, folks who've only ever thought about CDNs, think about static images 586 00:48:28.840 --> 00:48:32.519 and files that way, and now you're talking about units of compute that could 587 00:48:32.559 --> 00:48:35.760 be there where you don't know necessarily what you're going to do, but you 588 00:48:36.119 --> 00:48:39.280 they havent you have control over it. It's it's not exposed to as much 589 00:48:39.360 --> 00:48:45.679 security risk, but it is performant. Making changes is inconsequential, right, 590 00:48:45.760 --> 00:48:52.360 I mean simple, Well, the mockery of containers has been Hey, I 591 00:48:52.440 --> 00:48:55.320 took a fairly complicated set of services in the back end of my server and 592 00:48:55.440 --> 00:49:00.039 made them far more complicated, right, Like, just broke them into so 593 00:49:00.119 --> 00:49:04.119 many more pieces. So it's just so much more to manage not getting into 594 00:49:04.159 --> 00:49:06.880 this. Hey, it's not all sitting in the same server anymore. It's 595 00:49:06.880 --> 00:49:09.760 pushed to all these other places as well, and that was impossible when it 596 00:49:09.880 --> 00:49:16.880 was stuck in one location. These are very much opts problems that a lot 597 00:49:16.880 --> 00:49:20.880 of developers. I don't think you spend enough time just being aware of what 598 00:49:20.920 --> 00:49:25.880 we're trying to do to create good performance for customers those asynchronous bits, because 599 00:49:25.920 --> 00:49:30.119 the customers is not directly affected by them, mean it doesn't matter that we 600 00:49:30.159 --> 00:49:32.800 added latency by pushing that stuff to the edge, and the data is going 601 00:49:32.840 --> 00:49:37.199 to sink later because the customer's done, they feel they've entered their order, 602 00:49:37.239 --> 00:49:40.719 they've done their workload, whatever they wanted to do, and eventually, again 603 00:49:42.000 --> 00:49:45.679 measured in seconds, the data sink back to the primary repository, wherever that 604 00:49:45.800 --> 00:49:52.559 may be. These are complicated problems and you don't get to decide of an 605 00:49:52.559 --> 00:49:57.679 advance. Which you're doing here is building architecture to make those options possible. 606 00:49:58.440 --> 00:50:00.559 But don't do it if it's not going to happened, because it's not simple. 607 00:50:01.199 --> 00:50:08.360 No, it's that complexity versus the outcome. And it's something that I 608 00:50:08.559 --> 00:50:15.039 always try to stress is everything you add to your application is going to add 609 00:50:15.400 --> 00:50:21.480 complexity. You were talking about service discovery. I speak about service discovery. 610 00:50:21.639 --> 00:50:28.559 I've got it in workshops. It's good because you know your applications can self 611 00:50:28.599 --> 00:50:32.679 register. You don't have to worry about it. It's all dynamic and it's 612 00:50:32.760 --> 00:50:38.239 hands off. But hey, it's an added layer of complexity. And it's 613 00:50:38.400 --> 00:50:43.800 very easy just to go out Willie Nearly and add all these new services, 614 00:50:43.840 --> 00:50:49.199 these funky things, these features do all your resume driven development. And then 615 00:50:49.800 --> 00:50:58.639 now you have this horrifically complex application that even the architects don't know what's going 616 00:50:58.679 --> 00:51:01.440 on, and it just gets less and less and you get that distributed big 617 00:51:01.480 --> 00:51:05.920 bowl of mud. I mean, I wonder if you have to have a 618 00:51:05.960 --> 00:51:10.440 service failure right where the app's been deployed with this is the service we call 619 00:51:10.840 --> 00:51:14.599 and then for whatever reason, that service is down and the back of one 620 00:51:15.159 --> 00:51:17.000 is up. But because we didn't use the service discovery, we didn't even 621 00:51:17.039 --> 00:51:22.159 know it was there, so we're out. Before you finally justify adding that 622 00:51:22.280 --> 00:51:27.960 overall ongoing cost and complexity of service discovery, yes, yeah, it's like 623 00:51:28.000 --> 00:51:32.320 you need to feel the pain and have that experience before we value that complexity. 624 00:51:32.360 --> 00:51:37.639 Right, So if we now got pain driven developed, we've always had 625 00:51:37.679 --> 00:51:44.679 that, Yeah, well you know your resume driven models. They I've always 626 00:51:44.679 --> 00:51:47.199 wanted to build one of these, not that we need one of these. 627 00:51:47.960 --> 00:51:52.400 So part of that, you know, that pain piece is recognizing this can 628 00:51:52.440 --> 00:51:58.039 cause outages, and so we're going to incur this cost willingly you think about 629 00:51:58.039 --> 00:52:00.480 all the people that are affected by that. Right, It's not the developments 630 00:52:00.480 --> 00:52:05.119 more difficult. The deployment's more complicated. OPTS needs to know about it, 631 00:52:05.199 --> 00:52:07.719 to know when these services shift, make sure the security contexts are right, 632 00:52:07.800 --> 00:52:13.760 like, it's a lot of people involved going forward. Testings more complicated like 633 00:52:14.320 --> 00:52:20.119 that, nothing's free for adding that capability in exchange for avoiding a possible outage 634 00:52:20.119 --> 00:52:24.119 effectively. But also the other one, the other scenario that I've seen is 635 00:52:24.519 --> 00:52:30.400 we can't deploy because we need those other guys to update to this new version, 636 00:52:30.800 --> 00:52:35.079 to this new service too, before we can deploy where what we did 637 00:52:35.119 --> 00:52:38.199 bus is properly. We don't need to and that's why you have no Well, 638 00:52:38.320 --> 00:52:42.960 that's the worst case scenario which you see people do, which is that 639 00:52:43.119 --> 00:52:47.280 distributed big ball of mud. Yes, so they go from the monolith to 640 00:52:47.440 --> 00:52:53.800 that rather than the monolith to the modular monolith to the micro services, and 641 00:52:53.920 --> 00:52:58.679 it's the worst place to be. I have the distributed ball of mud. 642 00:52:58.760 --> 00:53:00.000 It's not just a ball of mud, it's all of mudd, and multiple 643 00:53:00.000 --> 00:53:07.280 times that. Leila, what is next for you? What's in your inbox? 644 00:53:08.239 --> 00:53:13.119 Ah? Well, I've got quite a lot of events coming up. 645 00:53:14.440 --> 00:53:20.599 I can't imagine. Yeah, just hanging out with people like you two in 646 00:53:20.800 --> 00:53:24.519 the meat space, which is always fun. There's quite a few events. 647 00:53:24.599 --> 00:53:30.039 Are we all doing INDC Porto, I think we are, Yes, Copenhagen, 648 00:53:30.280 --> 00:53:34.360 we're all doing Copenhagen, Yeah. And we're all doing dev Intersection yeah, 649 00:53:34.440 --> 00:53:42.599 yes, and that Richard and I are at dev Reach and Poland I'm 650 00:53:42.639 --> 00:53:45.760 basically doing a world tool with you. Richard. I think you're bombing around 651 00:53:45.760 --> 00:53:50.960 together pretty much. Are you going to run down to dev Reach after after 652 00:53:51.000 --> 00:53:53.559 Poland as well. Yeah, you'll probably get on the same flights. Oh 653 00:53:53.599 --> 00:53:57.679 yeah, because there's already three of us on that flight. Yeah, and 654 00:53:57.679 --> 00:54:00.800 we're yeah, we're splitting with like splitting shows like this. But you know, 655 00:54:01.039 --> 00:54:07.519 you get into situations you do. So yeah, I'm I'm working on 656 00:54:07.119 --> 00:54:12.320 the old YouTube content. I've just been on some cool courses learning how to 657 00:54:12.400 --> 00:54:17.559 do new awesome stuff with video streaming keeps getting cooler. That's great. Yes, 658 00:54:19.199 --> 00:54:22.199 that streaming is a weird place. I've sort of put a pause on 659 00:54:22.239 --> 00:54:27.440 that for a little while, but I do love it. I love just 660 00:54:27.840 --> 00:54:30.679 the live coding. So yeah, just doing a whole lot of load of 661 00:54:30.719 --> 00:54:37.719 stuff and always learning, was trying to cram more knowledge into this cranium. 662 00:54:37.719 --> 00:54:42.199 Awesome. Well that's great, Layla, thanks so much for spending this hour 663 00:54:42.239 --> 00:54:45.079 with us. It's been fantastic. Thank you for having me. All Right, 664 00:54:45.119 --> 00:55:09.079 We'll see you next time. I'm dot net Racks. Dot net Rocks 665 00:55:09.199 --> 00:55:14.760 is brought to you by Franklin's Net and produced by Pop Studios, a full 666 00:55:14.800 --> 00:55:20.360 service audio, video and post production facility located physically in New London, Connecticut, 667 00:55:20.400 --> 00:55:24.880 and of course in the cloud online at pwop dot com. Visit our 668 00:55:24.880 --> 00:55:30.840 website at dt n et r ocks dot com for RSS feeds, downloads, 669 00:55:31.000 --> 00:55:36.239 mobile apps, comments, and access to the full archives going back to show 670 00:55:36.320 --> 00:55:39.599 number one, recorded in September two thousand and two. And make sure you 671 00:55:39.679 --> 00:55:44.239 check out our sponsors. They keep us in business. Now, go write 672 00:55:44.239 --> 00:56:01.159 some code CNX time, got amcoring