How'd you like to listen to dot net Rocks with no ads? Easy? Become a patron For just five dollars a month you get access to a private RSS feed where all the shows have no ads. Twenty dollars a month will get you that and a special dot net Rocks patron mug. Sign up now at Patreon dot dot net rocks dot com. Hey Carlin Richard here. As you may have heard, NDC is back offering their incredible in person conferences around the world, and we'd like to tell you about them. NDC Copenhagen is
happening August twenty seventh through the thirty first. Go to NDC Copenhagen dot com for more information. NDC Porto is happening October sixteenth through the twentieth. Go to Dcporto dot com to register and check out the full lineup of conferences at NDC Conferences dot com. Hey there, this is Jeff Fritz, the purple blazer guy from Microsoft, letting you in on a little secret about my friend Carl Franklin. You know, the guy who started dot net Rocks, the
first podcast about dot net in two thousand and two. The guy who's been teaching Blazer on YouTube since twenty twenty. Yeah that Carl Franklin. Well, Carl's joined up with the folks from Code in a Castle to teach a week long hands on Blazer class at Are you ready to get this? At a castle slash villa in Tuscany. It's sort of a luxury vacation with Blazer learning
built in. Carl's calling it the Blazer master Class. You'll learn Blazer from the ground up, finishing the week with the ability to build and deploy Blazer applications. Since the training happens for only four hours in the morning over six days, you can bring your significant other, your partner with you and you should right This part of Italy is absolutely beautiful. There's so much to see and do and in Larry and Marco from Code into Castle are organizing daily activities
both at the castle and in the area. The castle is in the Marema, a less touristed region of Tuscany, offering both classic Tuscan hill country as well as easy access to the Etruscan Riviera, with sublime local food, wine and olive oil around every corner. Breakfast is included every day. There will be two communal dinners at the Castle book ending the experience and most other meals and all activities are included. And did I mention you'll learn Blazer in person
from Carl Franklin. Listen, space is limited and for very good reason. This is quality training in a beautiful setting. Go to code in Acastle dot com slash Blazer twenty twenty three. That's bla z o R two zero two three to take advantage of this amazing opportunity to join Carl in Tuscany for an unforgettable week of led dulce vita while advancing your programming skills in this important new technology. Hey guess what it's doing at Rocks. I'm Carl Franklin and I'mmateur
Campbell, And you're here again. Isn't that cool? They're here again? They show up. This keeps happening. I don't know, I don't know why. I'm beginning to get an idea why. Yeah, maybe how you been, mister Campbell? How's how's moving going? I'm packing mostly right, And the problem, of course, is that we're not moving into a new place. We're moving into a place that we've already furnished. So we have entirely too much of everything. Not the least of which is a downsize.
So twenty something years have been in this house. It's a lot of purging. Yard sale. Um no, not a yard sale kind of guy. You know. That's the thing. I admit. I will Facebook Marketplace like good bits of electronics and things that we but it's only good for free. Yeah, if you as soon as there's a price forget it, you're wasting your time. Yeah. But if you want to get rid of something on a weekend quickly, you can stick it in the driveway and throw it on
Facebook Marketplace. It will be gone in an hour. And if you say you want ten bucks for it, somebody's going to offer you too. Well, they won't even do that. All they'll do is waste time after that. If you give it away, it's gone and that's fine unless there's something nice, in which case they go, oh it's a scam. So is there any if there are any dot net rocks listeners in your area, can they contact you and see what you got? Do you have a list somewhere?
I don't really have a list. Which kind of stuff comes along and it goes out the door pretty quickly, but yeah, okay, yeah, it's not that organized. Too much stuff, man, too much stop and but a lot of what's happening right now is and you know, my wife will enough to know that she purchased a particular size of plastic bin with locking lids and stacking mounts. Oh yeah. And so we are our packaging up
the things that need to stay into these bins. We have measured off the space in the garage up on the coast, and so we know how many bins were allowed to have and we're sort of making it fit to the space. And so I keep doing runs in the truck up there and continuing to pile up a monolith, you know, something out of pink floids the wall, and eventually will be done. Wait a minute, that's part of what we're talking about monoliths today, right with Leila? You like that? All
right? Well, before we get Leila on, let's uh do better, no framework, because I got something really kind of interesting to share, all right. So this is a story reported by the verge right. Millions in quotes of sensitive US military emails were reportedly sent to the country of Mali to a typo right for over ten years, millions of I won't read the whole
thing but here's the gist. For over ten years, millions of emails associated with the US military having getting sent to Molly, a West African country allied with Russia, due to a typo. According to a report from The Financial Times, instead of appending the military's dot mil domain to their recipient's email address, people frequently type dot mL, the country identifier for Mali. I mean,
presumably all these emails bounce. Well, here's the story. So this guy, a Dutch entrepreneur, Johannes Zubier probably something like that, contracted to manage Molly's domain, tells the Financial Times. This has been happening for over a decade, despite his repeated attempts to warn the US government, and when he began noticing requests for non existent domains like Army dot mL and Navy dot mL, he set up a system to catch the misdirected emails, which was
quote rapidly overwhelmed and stopped collecting messages. He reportedly intercepted a hundred and seventeen thousand misdirected emails, some of which contained sensitive information. Oh my goodness, yep, that's a good one. Attention to detail, kids, it's really important. Well, and any I mean again, I guess they mostly bounced.
Yeah, but the real the real point, I think he's at the end of this story where it's like that now the Defense Department has set it up so that when any dot mL domain email address tries to said to dot mL, they get a message that says, you need to verify this. Right. Yeah, I just don't understand why somebody would send army to Army dot m IL and then get a bounce notice and then keep sending it. Well, who knows what they did? Well, who knows they did.
There's a lot of people working in the military. Yeah, you're right, right, and and I me I mentioned some of those emails are, hey, want to meet for lunch? Right? Could be yeah, I'm just guessing, yeah, but there was some sensitive stuff. Anyway, It's very important to pay attention to details, sanitize your inputs. That's the moral of the story. Pretty funny, all right, So who's talking to us today?
Richard Grabby comment to show seventeen seventy, which is back in December twenty one, when we talk to our friend Paul you can do it's about building microservices with Dapper Ye and Sean Kieran wrote this great comment and literally DAPR dapper, dapr. Yes, because too many product names. Life's hard. Yeah. Yeah, so it's about eighteen months ago. Sean wrote this great comedy says thanks for another great show. I don't know how you managed to keep
coming up with them awesome work. I enjoyed listening to Paul talk about Dapper. It's a really interesting technology and it seems to have great hosting support too. And Paul mentioned a Dapper makes service discovery easier, which is great to hear. But the words service discovery in quotes also makes me shy away a little, as it seems to be a bag full of unnecessary complexity that comes along with the modern approach to microservices. And I'm with him, Like Jeffry
speaking, I think discovery seems vaguely silly. It's like I kind of know where I want to call, Why do I need to discover it? Until you're dealing with uncoupled failover solutions, right. The whole idea that rather than saying, hey, when you need this service, call here, it's like, when you need the service, ask for this most of the time would be the thing we always thought it would be. But I could also have a backup one there and I can upgrade, I could you know, change
things around without having to recompile other code. Right. This is all that sort of uncoupling approach, which but I agree that service discovery could be easily abused. They're used to. It reminds me of the old XML web services days. Didn't wasn't there a discovery Yeah, but protocol I mean even going back to ASMX right for crying out loud, like we've always had this idea
of we want to ask by name for something, not by location. I just remember they did a demo where you could search like zip code services and all the web code, all the web services that provide zip codes would come up with endpoints, right. And that was the silly one. That the one where it's like I just want to call out into the Internet for a service to do something, and it's like, I'm pretty sure you should never do that. Never ever do that. It's just not a good idea.
The Internet is not filled with your friends. That's that's what's out there. That was just you know, to prove prove it could be done, I suppose, yeah, and again didn't make it a good idea, But within a service architecture, to be able to be to request a particular class of service and not care that it's any given instance in any given location. It's
kind of like the Swagger idea, right, that's all insane uncoupling. Yeah, yeah, now A Shan does gone to say he got involved with service buses back in two thousand and eight, so he's obviously an old schooler when he started with end Service Bush, which we know and love well. But he also switched over to Rebus, which I don't think we've ever talked about, developed by mog Heller Chrys No, we have none, I don't think no. And but then also mentions things like mass Transit, easynet QE Brighter,
like there is a bunch of solutions there. There's no two ways about it. It makes this key point he says, when you build with these systems, you're making true He calls them true Microsoft services, which I think is a bit optimistic. But it is the idea that here is a platform that encourages you go down the path of separate services that could be worked together by it worked on different developers, deployed independently, can support multiple versions running
on the same service. At the same time in production without having to worry about it, and that the way they do communication is schema base like it's all those sort of core ideas and today's Then then you have the abstraction of transport, so it might be Rabbit MQ or SMS or a service bus today or even Amazons SQS like, there's lots of different ways to do stuff, and that's the key to the power of all these service bus architectures that you
don't have to commit to any given stack in changing those things is not that big of a deal anyway. I thought it was a nice love letter about service buses, but it's also I think a luxury for a lot of folks, Like it takes a very significant set of decision making to decide we're going to implement a set of applications. Is really what we're talking about, an overall solution suite in a service boss model, And I don't think we're going
to talk about that today because I think most people don't start there. I think most folks build an application and get to a place where they now are told, you know, if only we'd build this as microservice as everything will be good. Tear it all down start over, which I've come to appreciate the main advantage of that approach is that it means you'll be left alone for six months while you admired your reartic. All I really want to do is
stop coming to this meeting. If I say this, can I stop coming to this meeting? See in six months? That's what it works. Hey, John, thank you so much for your comment I thought was super relevant to our show today. And a copy of music cobuy is on its way to you. And if you'd like a copy of music Code Buy, write a comment on the website at dot at rocks dot com or on the facebooks. We publish every show there and if you comment there and I ready on
the show, we'll send you a copy of music Go Buy. And you know you can follow us on Twitter. That's fine. But the real fun is happening over on Mastodon right now. I'm Carl Franklin at Techup dot social and I'm Rich Campbell at Mastodon dot social. And it's the real fun happening at Mastadon. I think it's or is it now happening at threads? No, it's happening at Macedon right now. For me, anyway. Yeah, I don't know. Are you on threads yet? I had to sign up
with it. I'm one of the hundred million in five days. Yeah, me too. It's because we all had Instagram accounts, right, so it's not a big deal to flip across. I never had all that many Instagram followers anyway. Yeah, so we'll see. If your Instagram grids, then your thread's gonna be good. And you're Instagram not good, Your threads are not going to be so good. And yeah, are we really trying to Are we really looking to Zuckerberg to be the safe here of anything? No?
Actually, no, thanks, No, not at all. Yeah, I've already given her on all. I got a blue Sky account to me, and I'm gonna try that with my friends. Yeah. Yeah, all right, Well, anyway, let's bring on Layla Porter. Laila is a developer advocate of VMware serving the dot net community. She makes videos and live codes on YouTube. She's a Microsoft MVP, a GitHub Star Progress Ninja, and the founder of the hashtag Women of dot Net initiative. Layla loves sharing
knowledge whilst having fun. No question is stupid and beginners are always welcome and you are always welcome here on dot net Rocks Laylah, welcome back. Hello, thank you for having me back. Yeah, you know it's English. When you hear the word whilst, you can pull that word off. Nobody else can put can drop a whilst and mean it. I can't say just while unless I'm whiling away the time. Otherwise it's that's a while without an h that's a whole other w that's it. So you know that's the only
time you'll hear me say while. Ye fair, fair enough, appreciate it. The last time we talked was at NDC somewhere, wasn't it. I don't know. This is my third appearance like that. Oh we did the dot net Foundation show, all right, Yeah, that was just an interesting time, as I recall. Quite yes, interesting, I have not.
I mean, I the Foundation is still out there. Things seem a little more peaceful, which not much of an achievement, but I I mean, if there's anything I can say about the Foundations, like, I appreciate the focus on the open source leaders project leaders these days. I think it's wise and uh and something really and something important going on in our industry right now.
But we'll that was womanly man like over almost three years ago, so we'll probably due for dragon some foundation folks in it a loop and having a conversation. Well, I just got some new directors, three new directors now, so now as did I. So what's on your mind today, Leila? Wow, there's a lot of things on my mind. But I guess the past two years, because it's been two years now since I joined VMware,
it's been thinking about micro services. So you're talking about all of that just now was very relevant and that was a really steep learning curve and I can only imagine how steep it is for folks who are actually doing the thing and moving across to microservices. So I thought we could have a little chat about that and how I don't like microservices and would urge people to shy away
unless they absolutely, really really have to. You are not alone. In fact, the sentiment from our most recent guests is do you really need this? Yeah? Yeah, it is sort of the I'm not gonna say it's a lashback, but anything that it falls into that one right way category gets pushed back on and with good reason. Yeah, and usually by the people that try it, and it just seems to complicate things and slow things down and that it does. Yeah, the question is does it get you anything?
Like I have certainly worked on service bus architectured applications because they were complex enough, with enough different stacks and enough different development teams that that conscious up coupling to work on the work through a bus became essential. Otherwise this gigantic multimodal app resonated with each other. We couldn't ship anything. But not that many applications are like that. Well, buses incus are a good idea even if you don't have a big or complex thing. I mean, that's just
a it's an asynchronous tool. Yeah, if that if that's if that's something you need. Yeah, but where are you coming at this from? Laila? Who are the frustrated devs? I found that at work a lot of the people I was speaking to were advocating hard for microservices. So it's something that I really had to look into and learn more about architecting. And the more I looked into it and the more I spoke to people, the more
I saw that people were getting really drowned in the complexity of it. All right, And I think, as you say, there were some loud voices saying there's a particular way of doing something and it's a one size fits all, But really, when you're getting up to that scale and that type of enterprise application, it's really bespoke and I think it has to be a pragmatic approach. And there was far too much dogma for my liking. Yeah, yeah, it isn't that a double whammy. It's not only that microservices the
way, but this form of microservices is the way. And most of the customers that I speak to are if we're lucky, they're on dot Net framework with a spaghetti tangle of code. A lot of them are still on Classic ASP and yeah, they have hundreds of applications, internal applications running on Classic And how do you get them from going from that mindset to this big deal of microservices? And do they need it? That's the big question. Yeah, is there a litmus test? Is there a few questions you can ask
yourself to determine whether this is a good idea or not. My general thing is if you can't answer yes straight away, then the answer is no. That's kind of my going on it. If I say do you think you need microservices and they go, well, we heard it's a good idea. Blah blah. I stop them there because we heard or my CTO thinks it's a good idea, we want it, or the worst thing is resume development,
resume driven development. I hear that a lot. We want to try it, and then the complexity that it adds is just not worth it. Also, if the teams aren't big enough, that's a big issue. I think you need to have a big enough development team to be able to pull it off. Otherwise everyone's going to be run ragged trying to manage this service
or that service. I've seen customers layla that feel that they need to do it to sort of be ready for the inevitability that their application is going to become the next Facebook or the next Twitter or some sort of like Uber popular, you know, when in fact it's it's just another company, you know. Yeah, and I hear that a lot as well. We want to be read a funny thing and being that the Twitters and the facebooks didn't do that and were successful and then retro fitted into it, which is far more
realistic. Yeah, And I think there's really good design decisions that one can make at the beginning of application development or through application development that will enable that transition at a later date, and that's what I advocate for. I think architecting your applications in a way such as that when you need to if way down the road that you actually need to go distributed or part distributed, it
will be easier. And that's what I've try to sort of teach. Nowadays, I think you've sort of dropped a yagny on me yet another he ain't gonna need it. Oh, you ain't gonna ye, It's right, you ain't gonna need it. I remember that one. Yeah, yeah, hey, you know I had to double check. But Classic ESP only when out of long term support in December of twenty one. Really yeah, wow. Now the original version was nineteen ninety six, so it's twenty That was twenty
five years. But you know, to me, and I think to all of us, when you said that, it's like, it's crazy that anybody's still be using Classic ESP. But it's like it's only JET. I mean, it's only it's been it's fully out of support for the past almost two years. But still okay, talk about spaghetti code wow man, and nightmares
about that stuff. I mean, the enterprise architect in me thinks about that for a moment and would point them at power apps because odds are that's the kind of software they're building internally, our forms over data apps, and and I would want to go to the domain experts and say, hey, you're tired of using this, let me set you up with this tool and sort
of go from there. I certainly don't think microservices from there. The idea of looking at classic ASP app and going, you know, when it fix this microservices, Oh my god, that's like the new title of a horror movie. Honestly, that's awful, and that I do hear it. It's such a Titanic leaps. It's just stunning. You're literally talking about nothing but code behind Yeah, right, Like one of ISP's big limitations was the lack of architecture, Like it was so hard to separate concerns at all in there.
And now you're going into something that you've already pointed this out. Microservices serves lay well when the teams are big and plentiful, and that we need a lot of architecture so these folks can work together. That makes a lot of sense. Odds are the folks operating maintaining these ASP apps are one or two people that have ever touched that app probably ever. Yeah, we heard horror stories, didn't we, Richard, about people who followed a particular like
very granular architecture for services. Everything was a service. And this was a very well known author that had this book and was consulting and they ended up but it ended up costing them millions of dollars because it was not only a waste of time, but it slowed everything down and there was no way to
make it go faster, just completely over architected. Yeah, and I've heard stories now of companies going backwards that they're taking out their microservices and reconsolidating applications just because it's it's just wildly out of control, right, And I think it's just the developer experience when you start going into these these big systems that are distributed is awful. You don't always know where the errors are coming from
unless you've put in great documentation that your testing is up to scratch. And I mean we all know that when you've got a PM or a CTO breathing down your neck and saying we need this yesterday, right, that some of those things are I'll put on a back burner and oh, I'll get to that and I'll implement that at some stage when it all quietens down, and then it never advocates implemented. Yeah, and you need all that. The point here is that the ceremony around all of this is important to it.
It is it can't be can't be optional. And I don't hear you saying that there should be no separation of concerns, because there clearly has to be. But you need just enough to make it work and and don't you know, don't go overboard. That's it. And then finding that balance is kind of hard. But it seems like, you know, I can think of maybe three or four silos that a big application would want to be in, right, you know, reporting services is maybe you know, communication, email,
that kind of stuff that. Yeah, But then I also find that I don't know if I'm going to get hate mail over this, But some of the DDD people have sort of contributed to this, you know, but domain driven meaning you know, all right, let's you know, find our domains and circle them out and these are going to map to services. What do you what do you think of that? Am I crazy? Well?
I'm really glad you brought that up, Carl, because one of the things I keep coming up against is everything to do with micro services seems to lead you to DDD, and I think that is a completely different way of thinking. And I like to say I steal just enough DDD to be dangerous, but I actually think I still just enough DDD to get on and code what I need to code. And the main thing I take away from DDD is
just high cohesion lease coupling. That's the main thing I take away, which I think is any sort of principle, well, is the main principle that you want to think about when you are designing your application and thinking about that separation of concerns? And again you're you're talking about a certain threshold of complexity to even be concerned about that. The app is big enough that it needs
a separation of concerns. Yes, I would say it has to have that critical mass for you to actually be worried about modularizing it and going down the modular monolith, which I'm a big fan of and it's a great term it and that really does feel like the wild West when I've been researching the right way, and I do that in finger quotes. To do a modular monolith. There are so many different opinions, there's no real guidelines. I found
that was a really under talked about area. There was very little information on that, a few YouTube videos, a few people speaking loudly about it, but then it always had that DDD overtone or DDD undertone, I should say, And I didn't want to go that way. So the past I don't know, eight months, I've been researching on how to do that, trial
and error and coming up with an interesting way to architect it. And it's all just big chunks, And I think that's trying to keep the complexity as low as possible, but make it in such a way that you can break off these little satellites of applications if you need to, if you need that
scale. Well, I appreciate the term that you're breaking off. So you're already coming from the angle of you have built a monolith, because that's the default, right that we tend to just keep adding things to that our applications need over time, and eventually eventually you have a problem. But the always question is like, what's the problem. Is it resonance, Like it's a big deal to make a change to anything. Is it affects so many other
things. Or I often being the scaling guy, ran into the scaling problem where it's like, it is very costly to scale this monolith just because one set of services and it needs to run many more instances. That makes sense. You know, your asynchronous things becomes services and they those things can scale up and down. That's needed. That makes sense to me. So chipping pieces out of the monolith is that the fair term I would say. So I really like to think of them as satellites. And the one I always
use as an example is like a notification service. You can have that in your monolith. But let's just say you're you want to bulks and emails or something like that. You may have that sporadically and you don't need it all the time. So it's a perfect thing to shove onto and as your function or an aw as lambda and just have that scale as and when you need
it. But if you have that as a module in your modular monolith, it's just so easy to as you say, Richard, chip that off, throw it into something else and connect to that with ease and have your system still a monolith. You haven't got that added complexity of everything's distributed, and I think that's the middle ground where I think most companies and most applications need
to sit. But there seems to be these this polar divide, and these two camps know we're sitting in this big ball of mud monolith over here because we don't want to go that route, and we love it. That's it in a mud pick, so happy right here. And then we have the distribute distribute everything camp over there where every little tiny thing is a service and now we've got minimal APIs and there's like a million minimal API applications and are
both of these lies? I mean, really, nobody has one monolith. There's always some services extraneous, and nobody has a perfect set of micro services. There's always at least some ball of mud somewhere. Oh it's hidden, calling a ball of go. Yes, more than mud, it's like and it's it's you shouldn't be embarrassed that you have one. The only question is do you know where yours is? Right? Do you know where your ball of go is? Because if you don't, that's a concern, that's a
big problem, right right. All the reason this world is people who have who know where their balls of mud are and people who are lying. Hey, guys, let's take a break. We'll continue this great discussion with Lalah Porter after these very important messages, and we're back. It's doting at Rocks. I'm Carl Franklin. That's my friend Richard Campbell, and this is our friend Lala Porter and she's she's quoting blasphemy here, blasphemy. I'm shocked,
get shocked and awed and horrified. No microservices or maybe only one. Yeah, just a couple of couples. Fine, you know, microservices the word itself implies that the whole thing just get split up into all these little pieces. And that's you know, when you say, oh, we have a couple of microservices, then people look at your crosside. What do you mean a couple of microservices? Call them Bob and Doug. Yeah, and they sit in the corner. Yeah, I like your satellites. We have these
satellites. That's that is a good term specific things. And I know that there is an architecture term that they call it a citadel, but I don't. That doesn't resonate with me. And so I've really hung onto this for the past few years, this idea of the satellites orbiting my monolith. And I do want to say that when I say monolith, people think it's like a negative thing, right, right. They get really touchy about it, like we've got a monolith, but you know, we're looking to distribute it.
We want to spread it out, like people are going to judge them because they've got a monolith, or that they're outdated. Yeah, yeah, And I don't. It's like the word legacy. There's nothing wrong with a well architected and well maintained legacy applications, especially if it's making money. Oh yeah, yeah, crying all the way to the bank. Yep, it's written in VB. Shut up. So I just I think there's all this
negativity around this space and there doesn't need to be. And I think monoliths are definitely where every application should start, and I think there needs to be a well considered, good plan for how that application is going to grow. And I think it comes down to people, and it's not the code, it's always the people. And what I mean by that is you have the visionary, the architect, and they do it all or beautifully and the application
is st with best intentions. Because I'm sure no one out there has gone out to architect a big ball of mud or a spaghetti tangle. I can't think of anyone who would intentionally architect something like that. So I believe people are going with good intentions. But how does one but keeping all the services together in a deployment is actually efficient. Yes, it's fast, it interrupts well, it deploys easily. Like there's a lot of reasons to do that.
I didn't make a mistake. That was the sensible thing to do until something changes, absolutely, And I think it's where things go wrong is when that architect leaves or they retire, or you get the new hires in and they're not on boarded correctly, or there is no design document or style guide. And I think that's very when too much of that architecture was in that
person's head. That's it, and it's that what is it the bus prevention theory, hit by a bus thing for some term, or can't take a vacation, or when you take two weeks off, a whole bunch of stuff just stops until you get back, or worse, it carries on without your vision and oversight. And now you've got whole new services that are duplicating things. You've got this, and I'm talking about service services within an application,
not microservices. So you've maybe got some different new interfaces, or people are doing weird things with dependencies, and you just get this this. Well, concerns are getting tangled, there's no separation. We're getting this cross contamination of those clear boundaries that should be in place. And I think this comes down to something I only recently discovered, and that that's like architecture tests. I don't know that was a thing until I started researching this, and it seems
like a silly thing not to realize that it was there. But you can put in a whole load of architecture tests that makes sure that the architecture you put into your application as being adhered to, and that can be like different projects aren't referencing projects they shouldn't be. And it just seems so logical to me. In all the years I've done TDD and testing, this has never
come up. If you never once unit tests to validate your adhering to an architectural press, Yeah, well it's a good idea and I'd never heard of it. I'm trying to conceptualize how that even works. Well, there's a framework coworld architecture dot net. I believe, I think that's the name of it. I could be wrong, don't quote me on that, but it is a series of unit tests that check for architecture parents and I had never seen it, And when you start looking into it, it makes perfect sense.
And how what assembly can reference what assembly? You can get quite in depth with it. Okay, I get it. So you're using reflection a lot to figure out how these things are coupled or decoupled or not coupled, and what calls what and making a code map and yeah, okay, yeah, that makes sense. And it doesn't seem like something that you would write tests for. Maybe you would just tell it what the guidelines are, what are and it would run a test and say, okay, here are your
problems as I see them. Yeah. Cool. I thought it was pretty cool because something that I've come up against when I was in engineering was that there was so many different places to do the same thing. I worked on a dot net framework app that was fifteen years old, and you didn't know where to add something in because it could be in one of a number of places, and there were I don't know ten twelve different projects within this application,
and you didn't know where anything was going to go. And that is where so many applications are because they all sort of grow over time. And that's the whole point. It's a development process. It doesn't just magic up overnight. So you know, people don't hang around jobs that long. So how do you do this and how do you keep that? And it's I
think there's three places that you can. You can start looking at adherence to your architecture, and that's visual looks, so getting someone to do a code review and going to check it. You can have sort of tests in place, and you can also have you know, compar wild time testing on that. So there's all these different levels that you can have to make sure that adherence is being met. And it just made sense to me, but I've never seen it done in practice. I'd love to know who's doing this in
practice. Yeah, something something to fall around on. I did find the GitHub repository for net arc test. That's the one, yeah, based on the Java art test. Yeah. Yeah, and just that exactly idea of
essentially writing assertions that say here's our architectural rules. I mean, I don't want to say that you just want to pop warnings, but certainly when you're writing code, especially new to a project, to have it come back and say, hey, we have an architectural requirement around this, and this code violates it. So at least you know you're pressing against edges that nobody wants
your press against. And it's also documentation because someone can come and read those tests, and you know that's the first step of a documentation for your application and your style guide. You're describing intent at that point. And even the best part is when your architect goes on vacation, they could be sitting on a beach and looking at the results of these tests and then send an email that says, hey, what are you guys doing? Stop it? Yeah.
Yeah. So it was really interesting to start delving into this world and it really felt like the wild West. And my teammates they're all Spring advocates, so they're very into the distributed systems, very into all of this enterprise architecture. I think Spring has been far ahead of dot net in that respect
of pushing that and offering the libraries that support that kind of architecture. So learning from them, and some of them are really big DDD advocates, so trying to to dissect what I want from from what they say and the stuff that I don't which is too far in the DDD realm um. It has
been really interesting, but it's something I don't hear spoken about. It is the tea camps stay away from monoliths or stay away from distributed systems, and there's never this in between, which I think is why people should be. I really really strongly feel that it's I mean, ultimately just to try and make more maintainable projects. Yeah, you have to have a new acronym here jed jeed just enough distribution, that's it. That's a great acronym. I
like that. Oh okay, I don't like it so much now, No, not my favorite. To join my foundation, it's fifty acronym right there. But it was interesting going through the modular monoliths and how you can start implementing so many of these good patterns such as the asynchronous communication. You can have all of this message brokers implemented into your modular monoliths, so you can have all these modules and how are they speaking to each other by a service
bus. So it's interesting that you were bringing up that because that was something that I worked really hard when I was building out a workshop on that used a modular monolith to get them messaging in that sublayer really really clearly defined so that people coming into those modules knew that each module could only communicate a cross a module via the asynchronous messaging, which was really a fun challenge to architect
and think about how things were going to go and getting away from that synchronous I am waiting for a response mindset, yeah, yeah, and just trying to think, well, what does need immediate response? Well, anything user related and that's all going to be external, and basically anything internal doesn't need
an immediate response, so you can offload all of that. Even though that even though the difference between immediate and this is milliseconds, it's perception, it's it's yeah's yeah, And it's also an architectural uncompelling yeah, that the returns come from a separate stream than the outputs. Um. I am deeply disturbed that we've spoken in this launched and you have not said Kubernetes, like,
what's up? I did, but I try to avoid that very serious, right, I mean, there's another angle to this microservices push, which is it is also soling product right, and that's annoying too, Like there's other set of motivations around this and I and I mean as much as I'm making fun on the whole Kubernetes angles, like I am talking to more folks who
are rehabilitating brownfield monoliths with Kubernetes, that that's a form of encapsulation. It's creating new security parameters, it's making them clean up messy bits of the code. The process of getting it to run well in a container tends to make
the product better. They act better in the long run because it does start to separate out how we do state management, how we do storage, like all of those things are good, but it doesn't You're doing it because you want the software to be more reliable, not because somebody told you containers would save your life. And I've recently been shown this cool architecture by one of the solution engineers at work because VMware Tanzu the bit but I wipe for is
all about cubanetis and that kind of system. I don't really delve that deep into it. I'm very much still on the code site. But the type of thing that you can do with CUBANETI, especially with the edge, is fascinating. So I learned a whole new way of architecting systems that is still monolithic but relies on Cubanetis as a way for engineers to easily distribute their code
to edge locations and manage it centrally. And I've recently learned about a customer that has thousands of edge locations all running on VMS and they have to manually go and update each release on that, And I'd never thought about that aspect of it and coming background to how you can centrally manage that and get things that are low to no code locally because a lot of these edge locations don't have people who are technical at them, and they may not have constant Internet,
so having something that can self heal and manage itself is really really important. And I've never appreciated that aspect of kubernetties. I always thought it was the oh, let's go to microservices, let's do this, it's the latest buzzword. But to see how it can work in that type of situation and make a DevOps engineer's life that much easier and automated had never occurred. To
me. So that was a fascinating thing to learn. And I feel like I'm learning so much these past two years from a difference from being an API developer coming over to this whole new world of really big enterprise development. It's been a steep learning curven and I really appreciate people who are in those engineering teams trying to figure this out. Well. I think important part here is
reckonizing EDGE doesn't mean the client machine. EDGE might be the CDN closest to the client machine, absolutely, Like that's just to getting into this idea that there's more places than the client and the server to deploy software too, and that you want to sort of unified strategy for saying, Okay, I'm going to push this compute closer to the customer, but not on the customer's machine.
And I think it's a it's a hard idea to deal with. And you know, folks who've only ever thought about CDNs, think about static images and files that way, and now you're talking about units of compute that could be there where you don't know necessarily what you're going to do, but you they havent you have control over it. It's it's not exposed to as much
security risk, but it is performant. Making changes is inconsequential, right, I mean simple, Well, the mockery of containers has been Hey, I took a fairly complicated set of services in the back end of my server and made them far more complicated, right, Like, just broke them into so many more pieces. So it's just so much more to manage not getting into this. Hey, it's not all sitting in the same server anymore. It's pushed to all these other places as well, and that was impossible when it
was stuck in one location. These are very much opts problems that a lot
of developers. I don't think you spend enough time just being aware of what we're trying to do to create good performance for customers those asynchronous bits, because the customers is not directly affected by them, mean it doesn't matter that we added latency by pushing that stuff to the edge, and the data is going to sink later because the customer's done, they feel they've entered their order, they've done their workload, whatever they wanted to do, and eventually, again
measured in seconds, the data sink back to the primary repository, wherever that may be. These are complicated problems and you don't get to decide of an advance. Which you're doing here is building architecture to make those options possible. But don't do it if it's not going to happened, because it's not simple. No, it's that complexity versus the outcome. And it's something that I always try to stress is everything you add to your application is going to add
complexity. You were talking about service discovery. I speak about service discovery. I've got it in workshops. It's good because you know your applications can self register. You don't have to worry about it. It's all dynamic and it's hands off. But hey, it's an added layer of complexity. And it's very easy just to go out Willie Nearly and add all these new services,
these funky things, these features do all your resume driven development. And then now you have this horrifically complex application that even the architects don't know what's going on, and it just gets less and less and you get that distributed big bowl of mud. I mean, I wonder if you have to have a service failure right where the app's been deployed with this is the service we call and then for whatever reason, that service is down and the back of one
is up. But because we didn't use the service discovery, we didn't even know it was there, so we're out. Before you finally justify adding that overall ongoing cost and complexity of service discovery, yes, yeah, it's like you need to feel the pain and have that experience before we value that complexity. Right, So if we now got pain driven developed, we've always had that, Yeah, well you know your resume driven models. They I've always wanted to build one of these, not that we need one of these.
So part of that, you know, that pain piece is recognizing this can cause outages, and so we're going to incur this cost willingly you think about all the people that are affected by that. Right, It's not the developments more difficult. The deployment's more complicated. OPTS needs to know about it, to know when these services shift, make sure the security contexts are right,
like, it's a lot of people involved going forward. Testings more complicated like that, nothing's free for adding that capability in exchange for avoiding a possible outage effectively. But also the other one, the other scenario that I've seen is we can't deploy because we need those other guys to update to this new version, to this new service too, before we can deploy where what we did
bus is properly. We don't need to and that's why you have no Well, that's the worst case scenario which you see people do, which is that distributed big ball of mud. Yes, so they go from the monolith to that rather than the monolith to the modular monolith to the micro services, and it's the worst place to be. I have the distributed ball of mud. It's not just a ball of mud, it's all of mudd, and multiple times that. Leila, what is next for you? What's in your inbox?
Ah? Well, I've got quite a lot of events coming up. I can't imagine. Yeah, just hanging out with people like you two in the meat space, which is always fun. There's quite a few events. Are we all doing INDC Porto, I think we are, Yes, Copenhagen, we're all doing Copenhagen, Yeah. And we're all doing dev Intersection yeah, yes, and that Richard and I are at dev Reach and Poland I'm basically doing a world tool with you. Richard. I think you're bombing around
together pretty much. Are you going to run down to dev Reach after after Poland as well. Yeah, you'll probably get on the same flights. Oh yeah, because there's already three of us on that flight. Yeah, and we're yeah, we're splitting with like splitting shows like this. But you know, you get into situations you do. So yeah, I'm I'm working on the old YouTube content. I've just been on some cool courses learning how to
do new awesome stuff with video streaming keeps getting cooler. That's great. Yes, that streaming is a weird place. I've sort of put a pause on that for a little while, but I do love it. I love just the live coding. So yeah, just doing a whole lot of load of stuff and always learning, was trying to cram more knowledge into this cranium. Awesome. Well that's great, Layla, thanks so much for spending this hour with us. It's been fantastic. Thank you for having me. All Right,
We'll see you next time. I'm dot net Racks. Dot net Rocks is brought to you by Franklin's Net and produced by Pop Studios, a full service audio, video and post production facility located physically in New London, Connecticut, and of course in the cloud online at pwop dot com. Visit our website at dt n et r ocks dot com for RSS feeds, downloads, mobile apps, comments, and access to the full archives going back to show number one, recorded in September two thousand and two. And make sure you
check out our sponsors. They keep us in business. Now, go write some code CNX time, got amcoring