Software Architecture: There And Back Again - Interview With Steve Ardalis Smith

Hi, my name is Nick Cosantino and I'm a principal software engineering manager at Microsoft. In this video, I got to sit down with Steve Ardales, a fellow dome train author, and we were talking about software architecture. And I'll make this video short. The best architecture is just going to be microservices. That's it. End of video. Okay, that's not really the answer here. In fact, Steve has a course on dome train about working backwards from microservices back to a monolith and constructing a modular monolith. There's a lot to be learned about different architectures like monoliths and microservices and modular monoliths. And in this conversation, Steve goes over a whole bunch of this information to try and help guide you around different ways and different things that you should be thinking about in your software architecture. So, if you are building applications and services, this is going to be a great video for you to have some extra context and think through these types of things. So, I think it's a really awesome conversation. So, sit back, enjoy, and I'll see you next time. >> Steve, thanks for joining me. I think uh I'm really excited to to be able to chat with you and I I figured if you want to start us off by giving us a bit of your background for how you got to where you are, you can start as early as you'd like, but uh I think it's really cool when people can hear like when you decided software was the thing that you wanted to be in. >> Okay. Um sure. Yeah, we'll start I guess we'll start early. I I was born in the 70s and uh personal computers didn't exist at that time, but I was a baby so I didn't care. Uh, but by the 80s they were starting to become a thing. And my first uh home computer, I guess, you know, there was a Commodore Vic 20 in there somewhere at school, but then at home uh my dad bought an Apple 2 Plus computer and we would uh between us, you know, program games that we'd get from a magazine. Uh we could type in all the code and then play whatever, you know, silly game there was. Uh and that was kind of cool. first was my introduction to computers and having computer like in my house that I could play on was uh was definitely I think influential to my future career. Um I didn't think at that time like this is what I really want to do. I want to be a programmer um so much but I did really enjoy it and I and I you know was curious and and tried things and and all that. Uh, and you know, I was lucky that we had some computers when I went through public school and and got to high school that we had the ability to take a programming class, um, which I enjoyed. And then when I went to college, I I was really into physics. So my my major was going to be physics and I was going to, you know, do that. And I got a scholarship that wouldn't let me pick physics as the as the major. I had to pick like math or compsai or something else. Um, so I was like, fine, I'll do compsai because I like computers and physics. Um, and then by my sophomore year, I was, you know, f freshman year physics is pretty easy. Uh, I thought by sophomore year, the the physics stuff was like really hard. You'd get like homework problems. Here, do these three problems. And it would take you like an hour and a half to do three problems. And then the computer science stuff was like, "Hey, go write this program. You've got a week and go hang out with your friends in the computer lab and and work on it together." Uh, and that was a lot more fun and uh easier. And I was also thinking like, what am I going to do with a bachelor's degree in physics? um interesting as a job, right? uh you know this was you know mid 90s at this point where I'm in school and uh with computer science like obviously that was just booming uh all through the 90s uh things were doing great and and the whole.com thing was was springing to life uh and so I I decided I would just major in compsai and so I got a computer science engineering degree uh and and then later on after I went to work as a as a at a consulting company I also got a MBA a masterers in business and integration >> um and so that's kind of my my formal education and So I have, you know, sort of a a traditional background as far as how I became a a software developer was I went to school uh and learned that stuff in addition to doing my own thing. Um something else that I I started in the '9s uh was there was a website that someone else started called ASP Alliance and it was for active server pages which had just come out in like 1996 or 97. Um, and it basically provided folks that were willing to write articles or or share content a place where they could play around. They could upload stuff and you could do whatever with it. Um, basically had FTP access to your own folder. And so I I joined that and I just started putting all kinds of stuff out there on what I was learning about ASP and my first job was building stuff with ASP. Uh, and so as I would learn things, I would put them in ASP Alliance on my site and that became like really my first blog. Although blogs weren't a thing at that time. Nobody that word didn't exist. Um, but I would share what I knew for me so that when I went to another client and needed to know how to do this stuff, uh, instead of carrying around like a notebook or whatever, have, you know, I didn't have a laptop at the time. Um, I could just go to my website and be like, "Oh, here's all my notes. Here's how I do this stuff." And and I had all the source code and everything right with it. So, um, that that served me well and and writing and and doing that opened a lot of doors for me over the years. Before we move on, this is just a reminder that I do have courses available on dot train if you want to level up in your C programming. If you head over to dome train, you can see that I have a course bundle that has my getting started and deep dive courses on C. Between the two of these, that's 11 hours of programming in the C language, taking you from absolutely no programming experience to being able to build basic applications. You'll learn everything about variables, loops, a bit of async programming, and object-oriented programming as well. Make sure to check it out. That's super cool. There's a a handful of things that I wanted to make sure I could go back and touch on from, you know, from from that >> recap monologue. >> No, no, it's it's it's awesome. Uh the the one thing you had mentioned about having, you know, computer early access at home, right? like uh I had I had interviewed Scott Hansselman and he kind of talked about that being like a pivotal thing in his entire life trajectory where he was like his parents had sold a van and were able to get a a machine to have at home that he could use and because like his high or his uh I don't know if it I guess it was elementary school a teacher that he had was able to say like I think that he would do well at this so his parents were like sure and for him just having access to that because not everyone because >> he was saying like that's something that really changed his uh his trajectory. So, um I love and I've been hearing this more uh from a couple of people. I didn't grow up with the the magazine sort of era with the with the source code, but it sounds fascinating to be able to say, "Okay, there's a book that has code in it, and if you I'm not saying this was your only way to play video games necessarily, but having like a book that if you copied the code, you could have a video game uh to go play. Uh, I think that's super cool. Um, >> and this was all free internet, so that was like the only way you were going to get it. You know, the magazine didn't come with a disc or anything. And, uh, you know, later on that would happen. You'd get a CD or whatever with the magazine, but in the in the early 80s, it was like you got to type it out by hand and and if you make mistakes, you got to find them. >> Yeah. I think probably the earliest I saw with the magazines and and code or like sort of like demo software would have been Yeah. Like that kind of idea where you get a CD or a >> Yeah. And I can remember like at that time even for me I I think it was like I like computers but I I don't think that I was thinking like programming. I think my father probably saw it and was like hey he'll probably get into software development. So he was always pushing me cuz he saw me playing video games. He'd bring home a book that was like how to program like Doom in like C++ and I'm like no I'm playing Doom. I don't know what you mean. Go program your own Doom levels and stuff. So yeah, I think it's it's cool. I think a lot of people uh kind of get some early exposure through video games and things like that, which is uh you >> know, Minecraft, I think, helps uh a lot of kids these days, like in the last, you know, 20 years or whatever, um get into that, too. And there's a lot of programming aspects in Minecraft, uh that that a lot of kids are picking up. Um, but it occurs to me just as I was telling the story, like my kids, my my youngest kids, I have nine-year-old twins. Um, they don't actually have a PC that they can just go play around on. So, I'm like, maybe I need to do that. Um, but, you know, there's there's so many more concerns about having, you know, young children on the internet now than there were, you know, in in the early 80s, too. So, that's a it's a balance. >> Yeah. And I I absolutely get that. I I worked before Microsoft, I worked in digital forensics for eight years and like what we did was basically tried to create software to help you know uh kids that had gone through some uh some bad times especially like through you know internet activities and things like that. So it's uh it's scary just uh you know how how much access there is on the internet. It's such a such like a blessing and a curse at the same time. So um >> right >> definitely understandable. But yeah, the I had also talked to someone recently that said they went to to college for physics and ended up having a pivot into into software which I thought was uh awesome. I can't imagine going for physics because I know I had my entry level stuff in in computer engineering and I was already like high school was super easy and then anything at the college level was immediate immediately kind of pushing me over the edge of like no like get me get me to the code so I can I can pass. Very cool. >> Yeah, I had a really good uh high school physics teacher and I think that made a big difference uh and why I I I really loved it. But then the the amount of effort to get to to anything useful once you get past mechanics um just went through the roof. So, and the amount of math that you needed to have uh and with compsai like you know my degree required a decent amount of math but you know what what kind of math do we use dayto-day? It's like I I don't even use trig or calculus. Most most most most business applications don't need any of that. >> Right. And yeah, this is something I try to to bring awareness of. Uh I know like if people are going through school for computer science, like almost by definition, computer science is like heavy in math, but >> practical application. Uh when I talk about this, I try to remind people it's very much domain driven where your math comes in. If you're working in finance, if you're working in uh you know, graphics and games, like these are going to be things that have a ton of math >> because of the domain. But if you're just building like a a CRUD application or even I don't know like there's a lot of backend stuff where you're building it and the math doesn't come up unless you're trying to do like performance optimization and you want like statistics about like your your P95 or your multiple nines of uh up time and stuff. >> But even then it's like I don't I don't feel like you even really need to understand how it works. It's great if you do, but like if you can have tools that give you the numbers and you're like, I know I need to make that number go up or down, like it's not not so bad, >> right? >> Yeah. And and a lot of that stuff here in games, it's like the person that writes the game engine really needs to know the physics, right? But you can you can pick up a physics engine even for JavaScript, right? JavaScript has physics engine libraries. Uh or, you know, if you want to build a 3D game, you can use Unreal Engine or Unity or whatever. And uh you know, that's not that's outside my domain. I'm not a game developer, but I know those things exist. And if I wanted to build a game, I wouldn't necessarily have to figure out all the trig of how to, you know, this thing appears in front of that thing in this 3D world. Like I had to do a little bit of that in college, but it's not something I've ever had to do in my professional career. >> Yeah. And even for me, like I tried to pick up some Unity stuff on the side over the years just because it was fun and I wanted to like video games always kind of pull me back because it's a a passion. Like I love playing video games. So I'm like, "Hey, it'll be cool to dabble in this." And yeah, like I used Unity so that I could avoid a lot of that. >> And really like the most complicated stuff I would end up doing is having like >> I don't know like 2D, you know, uh tile maps and stuff and like okay, maybe a little bit of geometry because it's twodimensional, but like it's not >> it's really not that uh that crazy. So, um, yeah, the the other thing you mentioned that I thought was super cool was, uh, and I I hadn't heard of this, I guess, but yeah, you were talking about the active server pages and being able to have a spot to go create content, and I thought like a couple things that resonated for me with that were like it's almost like a learn in public type of opportunity, but also you mentioned that >> you're you're creating resources even for yourself to use. And when I even think about my own blog, when I get stuck on like, hey, what should I write about? I'm like, what are the problems that you just finished solving? Because like >> you're going to run into those again like in a month, in a year, whenever. >> Right. >> Yeah. Yeah. Next time you're like, "Yeah, I got to go, you know, search this on the internet." Like, it would be great if you could just go, "Let me go search on my blog because I have it documented for what I did." So, >> um, yeah. When you said that, I was like, "Yeah, that that stands out to me." >> Yeah. There there's a lot of stuff that I know I've got somewhere in my blog and I'll just Google and I'll just type our Dallas space and then a couple keywords. It's like there's my post. So, yeah. Yeah, it works really well. >> That's perfect. Yeah. And I guess yeah, you've been doing that for a while. So, it's like it's almost like a habit or routine or a way that you know works well for you and I think that's awesome that you have that. >> Super cool. Um, what did what did it look like for you after college? Like when you were like, "Okay, I'm I'm ready to enter the workforce." Like what what did that look like? >> All right. So, I I graduated in the late 90s and it was the middle of the dotcom boom uh before before everything kind of fell apart in in 2000 or so. And uh I I had a few options for where to go to work and uh I deliberately chose to go work at a consulting company because I wanted to go and work at a bunch of different companies and see how different teams built different kinds of software uh and figure out like what I liked, what I didn't like, what worked, what didn't work, etc. And just like give myself a breath of experience early on in my career. Uh, and so I worked for a company in Columbus, Ohio called Software Architects and had clients of, you know, varying sizes in in that area and, you know, learned learned a ton. Uh, one of my first clients was totally focused on the Y2K bug at the time, but they had this project that they needed built and all their staff were busy looking through all their code, fixing Y2K stuff. So, they basically handed me this new grad uh, this project and and let me pick the technology to build it in. So I you know I did some research. I ended up picking active server pages um and built this this whole app uh in in like a year or so uh for them and and so that was a really great you know initial experience but then all the other clients too like really helped give me a you know a breath of experience in like how different folks built software. >> That's really cool. I think when I when I had internship opportunities, I had a a similar approach where I said like and it was one of my first employers who went to the same uh university as me basically highly suggested he was like if you have internships he's like I highly recommend you go find a bunch of different places like when else cuz we had six internships and he said when else in your life are you going to have six opportunities that are four months long to go work wherever you can you know apply to. So uh I he took me back for a second internship and after that he said I'd love to have you back again but he's like almost like in good conscious I can't because I I want you to make sure that you have a good uh you know breadth of experiences and I kind of took that to heart and was like okay like let me go try different domains building different types of things and uh yeah I think I think it's important because and maybe it's a lot trickier now with I think it's a people are really feeling like it's harder to land like their first job and that kind of thing. So, I want to be have awareness of that that I can't just sit here and be like, "Oh, just go try a million things." Um, >> yeah. But I think if you if you do have that opportunity or once you uh can find sort of uh if you're finding that you are able to land jobs and move around and stuff like that, I I think that it's important that you have a bit of opportunity to explore and try to find like what you what you enjoy. Um, and that can be domain, it can be the different types of teams you're working in. Like there could be a lot of factors to consider to like try and find something that resonates with you. >> Yeah. And like you were saying, you having six fourmonthl long gigs like if you do that on on your resume, it's like people are going to wonder why you can't hold a job, right? Like you have to you have to say internship beside all those in order for that to not look bad. Um, but yeah, if you don't want the risk of jumping around like that, you know, find find a contracting position, find a consulting company or something like that where they're going to put you at different clients, but you're still going to have the same employer uh over that period. Um, just different options, right? And find a find a path that works for for you. >> Yeah, absolutely. Like in the in the consulting case, right? If you're sticking with a company that does consulting, you might find that you're like, "Hey, like I really like the people I'm working with. uh maybe the domain we're in right now not so great not really enthused by it but instead of being like okay I guess I have to go jump ship to find another company if you're like if you like working with the people and like that feels good like uh you could wait for the next contract that comes up and then say okay great like maybe this is more uh right >> you know I'm more passionate about this or it's more interesting so yeah lots of lots of cool opportunities there so no that's awesome thanks for thanks for sharing that because I think again people that are listening and watching if they're going through this kind of journey like uh like we said it's right now it's uh definitely pretty tricky for people to be be landing jobs but um given given time if they have the ability to explore I think that's going to be beneficial um but so these days you're doing a lot of course creation so uh I know uh we both kind of have some courses created for Nick Chapsis on dom train and you you you've been focusing a lot on on on software architecture it sounds like that's a really big sort of area for you um I don't know where to kick things off in the software architecture conversation, but I figured uh like what what courses do you have available on dom train and then maybe we can kind of chat through and see like where a good kickoff point is because that's obviously a huge area like it's it's it's very general in a sense but also I know we're talking about some net topics too so there's some things to drill into. >> Sure. So the the I've got three courses now on dome train and they're all around modular monoliths and so there's a beginning one, there's a deep dive and then there's one about uh going from microservices sort of back to modular monoliths that have already gone down the microservices path and have realized oh no we've made a big mistake. >> Uh and and so the the idea with modular monolith architecture is is pretty simple. It's you know why do most teams want to go to microservices? Well, if if it's not because they need the scalability, it's usually because they have a big ball of mud system and they're trying to make it more modular and make it so they can have more teams work on it or make it so they can be more agile and and make changes to this section without breaking these other sections over here. Well, they really just want the modularity. They don't want the distributed system and all the complexity that comes with that. So, if you could get the modularity and still have a monolithic application, you would get, you know, sort of this Goldilock solution. Uh, and then if if you do have individual modules that should be standalone, you can kind of tease those out as as microservices if it makes sense, but you don't have to go into it saying every single thing is going to be its own separate process that can only communicate over the network. Uh, because that leads to a lot of expense for a lot of teams. >> Absolutely. And I think yeah, like I've definitely been observing a shift completely backwards away from microservices, right? Like I I don't know for how long, but for a a long while now it's been like, "Hey everyone, microservices are the way." Because it's almost like on paper it looks really good. Like it's the ultimate for modularity. Everything's totally decoupled. You have all of this flexibility through it. But in practice, it's very much like >> there's a lot of overhead for trying to manage how all those things work. And >> right >> it's kind of funny cuz I think uh most probably the majority of programmers and software developers we have this bad habit of like okay I'm about to start something like what does perfect look like and okay well if I have ultimate like flexibility all this modularity it must be microservices so let me just start by focusing on building in that direction but >> the this the scale and all that kind of stuff that you would be like sort of requiring microservices for like you don't have that like you you might you you won't even might not even have customers for a year like and then you get a couple of customers and so why do you need something that horizontally scales like crazy it's like it's just overkill >> yeah I mean and you look at sites like Stack Overflow they are running on like one or two servers with a monolithic application I I don't think 99.9% of the business apps that most NET developers are building are ever going to have anywhere close to the traffic that Stack Overflow has. >> And so yeah, it's you don't have to have or ne necessarily need microservices to build a fast scalable uh application, >> right? They you end up you see like a solution like microservices are a solution for uh scalability and things like that, but that's not the only solution. So right >> and and there's some rum driven development going on there too. I mean a lot of developers are like hey microservices are cool and if I want to like build out my resume for my next position I better learn about that. So if I can apply them here you know that would be great for me and and and it's probably good for my company too but you know I I really want to learn about microservices so let's do that right and and you know Martin Fer wrote an article about it so it must be great you know. Yeah, I that's a that's a really interesting point, right? That like we're we almost like cause the problems for ourselves where uh we kind of say, "Okay, well, people are talking about this. How do I make sure I can jump on the bandwagon?" So, okay, like if there's an opportunity at work, we could we could try this thing out. People are talking about this. This this is the direction it seems like. And we kind of like it's like a vicious cycle of doing it. So, um yeah, that's >> there's a cycle train and you don't want to miss it. And so often it it ends badly for folks because you know there you've got to analyze the problem and come up with a solution that matches the problem's needs. Uh because in architecture the the first law of architecture is everything is a trade-off. And you know yes microservices is an architectural style. Uh but it has all kinds of trade-offs versus other architectural styles. >> Absolutely. And I so I didn't realize that you had uh this this third course you mentioned about going back. >> So um from from your perspect I just wanted to to kind of dive into this part cuz it's it's it's fascinating to me because it's it's funny seeing people talk about it online where you see the shift of everyone talking about microservices to a lot more people saying like that is probably overkill for like basically 99% of people it's going to be overkill. uh 99% of what you're building, you're not going to need that. Um so in situations where people have gone and they've started building out microservices in my head, it uh it feels like it would uh it would just feel very backwards to start like pulling code back into like a common spot. So, can you walk us through like without obviously without just revealing all of the course details, but can you walk us through like high level what does that look like and uh and could you think about like as I'm saying this like these mental barriers where you're almost like fighting against what what feels like uh you're starting to like couple things back together or something like that. >> Sure. Yeah. So, so one of the things the course includes are a number of case studies that uh are companies you've heard of that have done this and and the reasons why and the results uh and and a lot of times it's performance and cost uh because having a lot of out of process communication for you know things that need to communicate a lot uh is way more expensive over over the network uh versus putting everything in one place and just using inprocess communication. And in in some cases, you know, you might be building with, you know, the latest and greatest cloudnative technologies, right? So, so you've got everything is in a service bus and you got, you know, these serverless functions that are doing the work and you're paying, you know, for every single message that happens. Uh, and and so you build this architecture that needs to scale really large, like let's say you're processing video for YouTube or something. Um, and and you know, I'm sure YouTube doesn't do this, but you know, imagine that every time a video comes in, you've got to go and analyze it and look for copyright violations. And so for every like couple seconds of video, you're taking a piece of that, throwing it on a service bus, sending it to a serverless function, having it do its thing, put it back on the service bus, have something else pick it up, right? Whereas you could have had a worker sit there and and take a whole video in and just run through it, uh, and scale out as many workers as you want, right? But now it's not microervices because there's just one worker doing one job, right? Uh that's kind of the difference, right? And that's what some of these case studies have shown is, you know, we had this architecture that was highly distributed, Kubernetes, lots of little small pieces each doing one tiny little thing and the communication overhead over the network andor using cloud resources was causing the performance to be terrible and the cost to be outrageous. uh you know Amazon or yeah Amazon Prime uh had an example that was video processing related uh and they cut their cost you know to themselves because they were using AWS of course by 90%. Microserbased uh architecture and and consolidating it down into a more monolithic approach. Um so the first the first thing I do is I show why right what is the justification for why you might want to reconsider microservices. Um and and being able to say that you know other companies have reconsidered this you know they've it's not too late you can come back um and then after that it's you know do a bunch of testing make sure you understand what the system does now because like any refactoring even an architectural refactoring you want to be able to do it from a place of safety where you know that when you're done you you haven't broken anything still works um so I emphasize making sure you have proper testing in place uh and then after that it's it's a matter of identifying you know what what needs to come together and and in what order. Uh and and usually it's you know things like you you've got separate databases because microservices ideally should have their own data. Uh and so you look at consolidating that uh and then you know the functionality is is usually the next piece. Uh and you can identify hotspots where you do have these two microservices that aren't performing well enough or are extremely chatty with one another. And probably that was a poor design choice in the beginning to split them. Right? Right? And that's that's one of the problems with microservices. If you make a bad decision, it will get really expensive. Whereas if you make a bad decision with a monolith, it's like, you know, you can always refactor it. You know, just change the methods or have move the functionality from this function to that function. It's cheap, right? Microservices, you make the wrong call and it's way chatty than it should be. It's going to be very slow. It's going to be very costly. Um, and so bringing those types of things together uh as as sort of the lowhanging fruit, the first things you should tackle, uh, is is one of the things that I recommend. And I would imagine too when you have we're talking about live distributed systems if you have a bunch of microservices you were talking about the the cost of the chattiness right but even I could I could imagine the cost of the development effort to go refactor something like that that's live where you're like you have two three services however many services you're dealing with and you're like we need to make changes to to start optimizing these things but now you have to go change them in multiple live services that are running whereas if you have the monolith the development overhead. I'm not trying to say like obviously there's differences in how complex someone's code might be. So that aside, >> when it's in one spot and you're not like how do we like version the APIs between these things so that we don't have to like basically have downtime to go deploy them like >> I can imagine that's way cheaper >> and and what you just described is everyday life for microservices architecture. every deployment you have to think about how can I do this so there's not downtime and I don't break that other call right like oh this other thing needs a service that I need to expose or I need to change the message that I'm sending on the service bus to include another field or whatever and every time you change anything like that all your other things might depend on that and might break so you know the the complexity around that uh is much higher with microservices and it's not insurmountable but it it does require a lot more uh rigor in terms of your software engineer ing practices to do it in a way that doesn't introduce downtime. >> Absolutely. And like for for context like uh so at Microsoft now I I I've switched teams but I used to work on one of the deployment teams inside of Substrate. So all of the sort of backend infrastructure for the Microsoft 365 products and like the the part the nicer part about deployment was uh was working with the microservices as the deployment team because we would have these things where it was like go deploy them. It's nice to work with for us. Uh the stuff that was more challenging was monolithic deployments for us because if one team had an issue with a monolithic deployment, we'd have to go sorry every other team part of this deployment, no dice for you. Um and that's a really crappy spot to be in. But yeah, >> big difference here is like if we're talking about scale of Microsoft, there's hundreds of services >> and hundreds of these teams that are separated out doing these services and they've truly carved out like more isolated pieces and they can decouple themselves from from that work. So it's almost like a and I I'm curious about your perspective on this, but in in this case it's almost like >> the micros service is like a a team function where the team itself can be like isolated and work through things and that way the the overhead that we're talking about about like versioning APIs and stuff like >> you're not feeling that within your team like the things that we just want to talk with our own pieces are a pain in the butt. It's like you have these uh this separation through teams. Is that kind of your perspective or do you see it like a different way? Yeah, I mean I ideally each microser should have a team dedicated to it and that team should be able to independently release that software uh and and not worry about you know or have dependencies on other microservices. They need to coordinate and make sure that they're you know working with you know their their clients their their you know collaborators but um they're not bound by being bundled up with a monolith like you were describing where some other team can block them from being able to deploy. uh for instance uh one of the reasons why a lot of companies go to microservices in addition to a host of other reasons uh is to get that team scalability where it's like you know we've got an app and we're not moving fast enough to compete and we've got 10 developers on it we've got 20 developers on it and they're all stepping on each other's toes inside this repository and there's merge conflicts all the time and blah blah blah if we had microservices we could have you know three teams each working on different parts of this and we could go faster overall is the dream right now in many cases is that dream is a nightmare because now you've got three teams that all need to talk and it's constant meetings and every time they need to make a change it's you know weeks instead of minutes because they have to coordinate you know at various meetings when they make those changes. Um but the thing about the modular monolith approach is that you can do that right you can say you know this team is working on that module which will be integrated into the monolith and they can still deploy behind feature flags as often as they want. Uh and and then the monolith just ships on a regular cadence as long as no one has, you know, a showstopper bug, which if you're using feature flags and if you're writing tests properly, you know, is is all achievable, right? And so that, you know, 99% of the time you're deploying on a regular consistent cadence and anyone any team building any module can have their changes going out on that cadence, >> right? No, that's a really interesting point, right? So the and you kind of said it like in the beginning of our conversation, but it's like this goldilock scenario, but uh when you have a modular monolith, the the point is that you are decoupling code like you have modules that are their own their own areas. They don't have to be conflicting with each other, but the the deployment part is interesting, right? So, but you you kind of highlighted how you work around that because someone might argue like, okay, well, if we have a modular monolith, if we're all shipping the code together, it only takes, you know, the more teams you have, the statistically the more likelihood of one bug coming up blocking everyone, >> right? >> But there's a pattern for working around that, right? You don't have to say, "Oh, I guess we're screwed. We have to go separate all the code, have separate deployments." You say, "No, deploy it all, but like you can turn this part off, >> right?" Um, are there from your experiences, are there situations where something like a a feature flag is is not enough? Like, um, sort of like the the true limitations when we do start to go down the modular monolith path because it sounds like it's getting the best of both worlds, but like are there situations where like feature flags not enough and uh, you know, teams are going to be held up or any sort of other like pitfalls that are worth calling out? A modular monolith is more complex than just a ball of mud monolith because you still need to deal with things like versioning and stuff between the modules. The only way the modules can be independent is if they expose some contracts that are used with messages to communicate back and forth, right? And so they're not tightly coupled. you know, module A doesn't just, you know, new up a class for module B and start calling methods on it because if it did, then, you know, the team that's, you know, responsible for module B can't make changes to that class because if they do, they'll break module A, right? But what module B can do is expose a contract or a message and and you have some infrastructure where you can pass those messages around and now as long as they don't break the message contract, they can refactor how they implement everything inside their module all day long. Um and then when it's when they do need to add additional functionality, they need to add new messages with new versions or or what have you. Uh same type of thing you do in microservices, right? You have all those same problems. But with microservices, you also have all the fallacies of distributed computing tacked on top of that and all the issues with, you know, how you're going to deal with, you know, uh observability and traceability and debugging a distributed application, right? So with the modular monolith, yes, you still have to coordinate between teams. Yes, you still need to make it so each module is independent, has its own database, communicates through contracts, uh but at the end of the day, it gets packaged into an inprocess solution that that gets deployed as a single unit, >> right? Yeah, it's a good point, right? It's not it's not that modular monoliths are just there are zero problems or that we've avoided all of them. It's just like uh you kind of the framing was more like it they they move the problems and by moving the problems to a different spot so to speak it's like it makes it more manageable like it's it's easier to deal with the problems when they're like centralized like that. And the other thing that you said that I feel like most people like uh don't seem to notice is like distributed systems are ridiculously complicated. Um, and if you haven't built them before and you're like, "Well, no, it's not that bad. I have a database over here and I have my server over here. They talk to each other." Like, okay, like that. I get it. That's not so complicated. But start scaling these things out now, right? Like, you're going to quickly realize that as you start to do that, you have these funky distributed system problems that they're not easy to deal with. So, when you can remove a lot of those or minimize them, I think there's a there's a huge opportunity there. Right? And you just have to remember that every hour that you spend trying to figure something out with this cool event driven distributed architecture is an hour that you didn't spend building a feature or fixing a bug for the business like that that all that stuff is just you know overhead uh for you to ship working software >> right okay now so another another question I have for you then is like it seems like a lot of there's a lot of goodness with kind of coming back to modular monoliths in in this process uh or even if you started from from a modular monolith. What does it look like to be able to to truly carve like I'm going to use air quotes here like the right pieces back out into microservices? So I can imagine there is this hybrid approach where you're like hey look modular monolith is is a lot of goodness for us but we have X or Y or Z and we want to make sure that like that part scales horizontally like what what does that kind of look like and how do people approach that? >> Sure. Uh so I use command query responsibility segregation pretty regularly in in my architectures. Uh I think it's valuable in monoliths as well as in microservices. And so in your modular monolith you're typically going to have communication between modules happening as either commands or as events that are being raised between them. Um, and so you just need to take that same structure uh and instead of having it be an in-memory communication, it becomes something that is occurring either over an API or gRPC or or some kind of a service bus. Uh, and now it's out of process, right? And so inside your modular monolith, you could start out on day one building these as a modular monolith with you know exposed contracts for commands and events and and such uh and communicating in process with let's say mediator or or some in-memory channel uh you know channel of t uh that's that's doing all the work for uh that process. Uh maybe you upgrade at some point you say you know we're going to use mass transit we're going to use rabbit MQ but still just locally on this one machine um to do all that communication. Now later on you realize okay this thing really needs to scale out like you're describing. Well I can take that whole module and just drop it into its own separate solution and all the interfaces that it currently is using for you know picking up messages or picking up commands using an in-memory uh library like mediator or mass transit or whatever. Um, now you just replace that implementation, right? You take that interface and you create a new implementation that now uses Azure service bus or now uses a web API endpoint uh in order to get that that message. Uh, and you have to change it on both ends obviously, right? The sender now needs to send the message uh over a different uh infrastructure uh and then the microser now being in a separate process needs to listen for that message through a different mechanism as well. Um, but as long as you've abstracted those away, uh, which which you should do in the beginning, it makes it fairly straightforward to to do that. And and if you change your mind later, you want to bring it back in, just flip back to those other implementations and and you're able to do so, >> right? It seems like a really good opportunity where you've built like you said this contract. So you have an API like so it's an interface in your C code that's like I am I'm communicating through this API and the implementation of that uh to start off with would like you said just be in process because what what's the benefit of trying to go outside of that right it's back to you're going to have these other complexities it's just it's extra overhead so keep it in process uh and then because you are dealing with like an interface and not coupled to the implementation But when you want to change that, I know you mentioned changing both like the sending and the receiving side, but you're not changing the API to it. So it's not like, oh crap, we have to go rewrite all of the code that calls these spots. Like that should hopefully stay the same. I can imagine that like your first time through this or first couple of times and it it might not be perfect where you go, oh, like we didn't realize that this thing doesn't serialize well or something like oops. But like it should be minimized, right? By trying to go through this process of uh of of thinking about this as a communication >> like barrier, right? Like anything going over this, we should be thinking about these types of things. >> Yeah. And and it may be that you want both, right? Like there's a lot of folks that I run into that are anti-abstraction and they think, oh, you know, abstractions are terrible and and over abstraction is, you know, this huge problem u because you'll never need it, right? You're never going to change your database. You're never going to change, you know, how you communicate between A and B. But you know a lot of times you don't just change it like in production. You may want to change it in different environments. So yeah maybe I do have in production a microser way that I do this but you know maybe for some tests that I want to run locally I would like to just take module B and and run it in process in my monolith. Uh and if I just switch out which uh libraries I'm using which implementations of these messaging interfaces I'm using suddenly I can let the module live inside the monolith uh for some dev environment that I that I want to run like that. Uh it might even be that it's a feature that you you know if you're shipping software that customers uh can opt into you know for for the free tier you have everything in your monolith but at the enterprise level you can have it broken up into microservices right then you can have each of those different implementations available uh to turn on for different customers based on what level of product they're purchasing. Yeah, absolutely. I like the the idea that you you mentioned there about even like in a like say a test environment or you could pick a different environment and say like we need these pieces, we're going to configure them differently. And to me that checks out. I I know like personally like my bias is probably I lean towards like over abstracting things like you know self- admittedly I'm like I just I do it. Um, but I I think I would be more cautious about that in teams. Like if I were working and building software with other people, I would probably not like go to extremes of how I over abstract things. But the I think from doing it enough and in my own projects at least there are patterns I pick up on where uh one of the ones I talked about recently uh was uh building out uh how I was structuring some ASP.NET core applications with uh with plugins. >> Mhm. And I'm like, I just like building plug-in systems because it forces like a I'm going to say the word physical boundary. Although like it's software, there's no physical boundary. So that forces a physical boundary for me to say, look, these things need to be decoupled. They can't reference each other. For me, that just helps. >> And someone might say, well, okay, that's kind of dumb because now you're dynamically loading these DLs because you have a plug-in system. And I'm like, I get it. That part's overkill, but like the the extra like couple >> doesn't matter after the first one second of the application's life. >> Yeah. And I'm like and for me at least I understand how these things work. I'm comfortable with that in a team might change. But what I have found is like uh again when people say isn't that overkill? Isn't that extreme? I go I've actually had situations where >> instead of packaging my plugins in an ASP.NET core app I go I want a command line tool. like I want to be able to talk to my real server using my APIs and exercise them and I just have a command line tool sitting on top of my entire stack uh that like sort of bypasses the the web routes. So all of my business logic, my data layer, >> it's all right there and it's because I was able to kind of make these things modular. So slicing it a slightly different way, but the modularity and decoupling things and like you said maybe that's over abstracting, but like I don't know like I think when you're around when you're around a bunch of things a lot over time, you start to pick up on patterns and you might lean into some of these more and more frequently and other things you go maybe in your experience you're like, "Yeah, I've never actually swapped a database implementation after 25 years of of programming and like I just don't lean into that anymore. >> Sure. >> Yeah. Um, no, that's that's that's awesome. The the modular monolith topic I think is a huge focus for folks. Um, are there like I clean architecture is another one that comes up a lot. Um, I've never for some reason the word clean when it comes up in software in general I I kind of have to like I cringe a little bit because I'm like I don't know who got to decide what clean is. I know clean architecture is its own thing, but when people talk about like this is clean code, I'm like that's the most subjective thing like you could ever say, but um when >> like agile, right? >> Yeah. >> If you if you take a a style and you brand it in such a way that the opposite is just bad, right? Then then it makes it it's a really good marketing play, right? Like of course we're agile, but we want to be clumsy. Of course our code is clean. Should it be dirty? like you know you know that it it it's brilliant from a marketing perspective but yeah clean architecture is something I I also talk quite a bit about uh and and I do use that frequently uh one point I make in my modular monolith course though is that each module can have its own architectural structure internally so uh clean architecture which is basically the same or very similar to onion architecture hexagonal architecture ports and adapters all those things uh are just different names for very similar style um you could have some modules that use that style and have you know multiple projects for infrastructure and and domain or core you know entities or things like that. Um, but if if you're really into vertical slice architecture where you know you don't care about all that, you just want one project. You've got your endpoint and all the things it uses and and you just have a folder for each feature, let's say, right? You can totally do that in an individual module also. Um, and that's another thing that folks use as a as a benefit of microservices is that each microser can make its own decisions that are best for it. Um, in a modular monolith, you can also do that. The one thing you can't do typically is make a decision to do this module in Java and that module in C, right? You're you're pretty much going to all be in .NET if you're building your modular monolith as a as a .NET monolith. >> That's a that's a really good point and thanks for bringing up the the fact that like architecture is not something that has to be universally applied to an application at all different points, right? You might have the overall application follow some architecture. Makes sense. And then as you said kind of breaking it down into the module modules themselves can have their own architecture. I think that's a that's a really key part. Um and I think probably goes unnoticed a lot because it's like well what's the overall architecture for this application? We just have to follow that. I know like for me like in the beginning and probably the same for many people that started out like layered architectures like it's the thing like you just build things in layers like that's the you know the traditional way of like doing these levels of abstraction and stuff. >> So okay like that's how I started. It took a long while to sort of unlearn that and learn other patterns, right? So unlearn just doing layers and following other things because they might make more sense. But I actually find that when I go down a modular monolith path uh or like plug-in architecture vertical slices within my slice within my plugin within my module I kind of my brain defaults back to okay let me build the layers within here >> and it's its own layered architecture but in in its own little narrow vertical. So >> that's how my brain ends up going. the the principle that that I generally try to follow and I think it it is very valuable in most uh software situations is separation of concerns and it's it's a little vague like what is a concern right um but you know things like data access being coupled to user interface decisions right those should usually be things that are are separated somehow right they should be in different uh classes if nothing else or different functions uh and they should communicate through you know some you know abstraction or data type or construct that doesn't leak the details of either side. So that I could have, you know, how I get the data is totally independent from whether, you know, I'm displaying this in a console app or or it's a react app, right? Uh and and that's pretty fundamental to software design, I think. Uh although, you know, many developers would would say, "No, just put it all together and and you know, it'll be faster, it'll be easier, it's simpler, I can see it all at once." It's like I I think that's a something that over time you learn that there's benefits to having it separated and and when you're uh newer in your career maybe it's easier and faster for you to see everything together at once. Um but but there's downsides to that that you start to run into uh as software evolves and changes and and it becomes useful to have seams in your software where you can say no we're going to just deal with this section by itself uh and not be concerned with the other the other thing the other concern right >> yeah no I love that and I think your your example uh definitely holds true from like feedback I've seen online people talking about these things like why would you have like why would you go through the overhead of taking some some uh call it like a data transfer object, some class, and you have it here and you have almost the exact same thing on the other side. Like why would you go translate between these things? That's literally just >> extra overhead. You're never going to need this type of stuff. And I've at least from how I've built software, I have run into situations all of the time where the way that I'm storing data and accessing it, whatever like record comes out of that, >> whatever that looks like is just not the same thing that I need on my API. And they might start very very similar. And if on day one I said, you know what, >> uh, all the way from my data access layer, I'm going to pass the same type, like literally the same type all the way up, >> it it would work. It would work and it would be fine. And then maybe in a week, in a month, at some point, at least from my experience, it's almost guaranteed that it's going to change. And that will mean if I want to rename something, uh, and and we have to remember like if we're talking about web services, these things are live and running, >> right? So if I'm like, hey, I just want to rename something uh in the database, it doesn't make sense anymore. Okay. And if I was using an OM and it was mapping, if I needed to rename it in the code as well, so it made more sense. All of a sudden, just changing the name of a property that I have in code is now going to propagate through and my API response is going to break like >> for everybody. >> And it's it's like it's a ridiculous problem to have. But I don't know like for some people that might be something where they're like I can manage that. That's fine. But I've just had enough situations where I'm like I'm going to put in some translation layers and like >> right you could make the argument you could say well when that happens then I'll introduce a DTO right but now your architecture is is totally inconsistent. It's like well sometimes we just use the data entity and sometimes we have our bespoke API DTO that we use and well how do you decide which? Well it's complicated. it depends if we change something at some point in the past two years like you know that that's not great you know some new developer joining the team is not going to ever understand those arbitrary rules uh whereas if you just say look these are the contracts that we use for our clients of our public API this is the wire format right that's going to go over the wire and over here this is how we store our data and those are barely related you know they're coincidentally related uh and yeah there's there's definitely problems where I've seen folks that use their data uh table, their table schema essentially as their their wire format protocol uh and and you end up with things where you know they add metadata like you know last updated by or last update date uh or create date or whatever and then that that just magically appears on the DTO and so someone can you know make a post to the API and and decide to fill in like oh this was created on you know 2050 right and then inside the application where it's like hey here's the most recent things like, oh look, there's this one created in 2050. It will always be the most recent one because, you know, somebody overrode your system and was able to write to that field that never should have been writable in the first place. Never should have been exposed on the on the post endpoint um as something that someone could even send to you. >> Yep. Yeah. And I had the, you know, same type of example going the other way where just more data was added into the records on the back end. And now we're just like sending back to the front end more more information than it should probably be able to see. And it's like >> right, >> but we needed it in the in the in the back end as it was doing some processing. So it's yeah, that's >> they're separate things. >> Over overposting and and data leaking out. Both of those problems happen because you you were too lazy to have two classes like like it's not that hard to write a class in in C# or >> all of the performance overhead all of the performance overhead of >> of mapping. >> That's what's slowing your app down is copying one DTO to another. I'm sure >> that's right. Awesome. Well, no, Steve, I want to be conscious of time because we're we're coming to the top of the hour here. So, uh I wanted to say first of all, thank you so much for making the time to chat with me. Um, I know we kind of talked through some dome train courses. I'll make sure I have links uh to that, but where can people get in touch with you if they want to see more more Steve and and chat with you? >> Yeah. So, I go by Ard Dallas online. Uh, Aard D-dis. And so, you'll find me on youtube.comdales or rard dallas.com is is my website with my blog. Uh, anywhere online, GitHub, uh, same thing. Uh my company is Nimble Pros and we we build uh software and and help teams ship better software uh faster. So if you're looking for training or mentoring or help with moving from microservices back to monolith or from a .NET framework app to the cloud and .NET core um that's a lot of what we're doing for for teams these days along with uh you know a lot of domain driven design to kind of help them get there. >> Awesome. Well no thank you so much and like I said I'll make sure I get some links and stuff in the description in the comments so people can check that out. So >> cool. Appreciate it. >> Thanks again, Steve. Okay. Take care. >> Take care.