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