Jimmy Bogard - AUDIO EDIT
===

Paul: [00:00:00] Hi there and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket provides AI first session, replay, and analytics, which helps surface UX and technical issues impacting user experiences. Start understanding where your users are struggling and tried for free@logrocket.com today.

My name is Paul and join with me today is Jamie Bogard. He's the creator of Auto Mapper and Mediator, and today we're gonna be talking about modularizing, the monolith. It's a hot, fun topic that. We can go back and forth on ~for, ~for days and days on end. ~Uh, ~but Jimmy recently gave a talk and we're gonna be diving in deep.

So Jimmy, excited to have you,~ um,~ and pick your brain about bringing teams to the next level.

Jimmy: Yeah, glad to be on. ~And.~

Paul: ~So when you say mod, oh yeah, please go ahead.~

Jimmy: ~I was gonna say, ~we're both gonna mispronounce modularizing like at least seven times during this podcast. It's just a thing.

Paul: Good. I'm glad we can clear the air with that. ~Uh, I was going, ~I was going over the little notes on the outline. I was like, oh gosh. Yeah. This is a word. ~Uh, ~so when you say modularizing the monolith, what does that mean to you? Does it mean like destroying monoliths? It doesn't mean,~ uh,~ yeah, talking about that.

Jimmy: my [00:01:00] day job as a consultant, I, I do most of my work like modernizing existing systems, not necessarily greenfield, you know, file new entire system application. It's like I got an existing system and we want to make it better. ~Um, ~ and so what this talk was about was about taking existing systems. And moving them towards a modular architecture, ~um, ~ as opposed to trying to throw the whole thing away and going to, ~uh, ~ like a microservices architecture or trying to take an existing monolith and trying to transition in place into microservices.

It's to say, well, let's try to put boundaries in place in this monolith first. And then see if we can then, if it's important to us or it's worthwhile, then try to break that out into perhaps services, microservices, whatever.

Paul: And so this is distinctly different from like building out a microservice first architecture.

Jimmy: gotta be honest, I've never really seen that work too well. ~Um, ~I've seen teams like really try to, to build those, [00:02:00] you know, build these really small services that just do one thing and one thing well. And of course, everyone argues, well, what is small? What is one thing? And of course, what does it mean to do it?

Well, no one agrees on any of that stuff. ~Um, ~ and so typically people try to go really far down one of those kind of measures of saying, well, then everything's a Lambda, you know, everything's a Lambda talks to some, you know, single database and that's all it does. It's like, well, that's great. But then that.

can often result in what's known as a distributed monolith, where you just have lots and lots of tiny little services that have to call each other. But because they're all distributed, you introduce all the problems of distributed systems where you've got, okay, whoa, wait, we have, now we need distributed transactions where we can't do that.

Oh, we've got insane latency between all these different calls. Cause now it's, you know, one request takes a thousand API calls. So, you know, the performance is terrible. So the idea here is like, well, you've got this thing that already exists, this monolith. And it's doing well for, I mean, it's, well, it's making money for the business.

It's doing something [00:03:00] well for the business. Maybe it's hard to change. So perhaps instead of trying to go to, you know, full new stack full, all these new things, perhaps we can try to work on what we have right now and make that better and try to build those boundaries first, as opposed to, ~uh, ~ learning a lot of ton of like turning a ton of hard lessons of one, trying to build.

Microservices to Bing with, and two, like, trying to get the boundaries out of what those microservices could be. ~Um, ~that's the really, really difficult problems of finding good boundaries and distributed systems and trying to do both at the same time when teams usually don't have experience doing either of those things is just a, a huge hill to climb.

Yeah.

Paul: And you mentioned, so you mentioned boundaries,~ um,~ that at the end of the day is those things we're drawing. It's ~those, ~those delineations that we're disagreeing on. team ~when we're, ~when we're hopping into architecture calls,~ um,~ what is a boundary to you? Like I, ~is it, ~is it something that is purely contrived ~out ~out of more of a team based ~and, ~and semantic based situation?

Or is it very data-driven? How do you view a boundary?

Jimmy: ~Um, ~ so [00:04:00] I guess it depends on the context we're talking about. I'm sorry, I'm a consultant, so I might say it depends quite a lot.

Paul: no, 

Jimmy: I know, right? But yeah, it depends on sort of the context we're talking about. I mean, there's the, ~uh, Uh, ~ the boundaries that sort of the, the C4 model talks about, ~um, ~ it don't make me say what the C's are, because I don't remember, Simon Brown can tell you, I forget, ~um, ~ but it's, it's the idea that, ~uh, ~ we, we define ownership areas, we define areas of concern, and we, we have rules that are enforced only ~ within a specific set of, uh, ~a ~specific, uh, ~boundary, and you'll see that, ~uh, ~ Happening in organizations in the real world, right?

~You don't, ~you don't have just, ~uh, ~ large companies that are just like a, I don't know, a football field full of just humans, just trying to get something done and it's just a chaotic mess. You know, like where every single person's a microservice, so they can need to do one thing well and whatever, but like, how do you organize that together to get something real done as a, as a group?

And so companies do that, right? They, they do that. They, you know, I've been part of startups, small companies as, as [00:05:00] those companies grow, you start to say, Oh, wait, now we're doing these set of responsibilities and they kind of all go together. So we should form more structure around that for more formal policies.

So it's not like every single person just decide on their own what the rules are today. You want to have a consistent experience, both within the company and towards the customers. So you're like, well, then we have to formalize these structures, formalize these rules. ~Um, ~ and the service or, ~uh, ~ like our, our developer land that also talks about formalizing the security rules, formalizing the data ownership, formalizing the, ~uh, ~ the, you know, the user interface of this, those different services, ~um, ~ formalizing the interactions between those different boundaries as well.

So that's the ideas. Formalization of interactions, formalization of security, formalization of information, formalization of business logic, ~and then, ~ and then the interactions between ~those different,~ those different boundaries is to have that made explicit as opposed to like, Just anyone can do anything with any other service at any given time.

It's to create an enforced boundary [00:06:00] that says you, if you want to interact with me, you gotta, you gotta talk this language, you gotta go through these specific channels, you gotta use this specific, specific interface.

Paul: I,~ I,~ I know it. It's gonna depend Jimmy. On team and, and a lot of other things. But where does that conversation start? Does it usually end where it starts right there? Is it like a representative from every team? ~Is it, ~is it usually somebody who has a bird's eye view over everything that,~ uh, will, ~will help start defining those boundaries and formalization?

Jimmy: when I've done this as part of just sort of, ~uh, ~ a consulting engagements, we're doing like discovery processes and things like that. ~Um, ~ a lot of times I'm not just interviewing the developers on teams because they'll have a very specific perspective of the technical, ~uh, ~ areas. They'll have domain knowledge as well and business knowledge.

~Um, ~ but I'm also talking to, ~uh, ~ the actual business folks as well. ~Um, ~ everywhere from sort of sea level on down to get a fuller picture of what's going on. What the system as a whole is trying to accomplish. And when I say system, it's like the, the, the company business system, not just [00:07:00] the technical systems.

Because what I often find is like there's the, there's a system that, that exists on, on disk. But there's also the system around the users that's that they use to get the whatever there is, their job is done. So 11 example was we were working with an insurance company and, ~uh, ~ the developer said the system work like this and then went to the manager and they said, well, the system works works like that.

And I talked to the user and they had a different opinion about how the system works. And then I went to their actual place of work, like I went to their cube, and then I saw that they've got all these kind of printouts and post -it notes and like little placard cards of reminders and stuff like this.

I'm like, well, There's actually an entire process around the software as well that is not captured in the code itself. So all those kinds of, like, angles are important to understand what the one, what the system as a whole is doing and to try to further dive into where the boundaries exist in the business and how the boundaries may exist in the code as well.

Paul: Is there [00:08:00] like ~a, ~a wise word ~of, ~of,~ uh, you know, if, if, ~if you're trying to do this in your own small team,

Jimmy: Mm -hmm. Mm

Paul: you don't have it, Jimmy? What's the first thing you would do? What's the first question you would ask or the first person you would go to? Because like sometimes, yeah, it totally depends ~and, and ~where you go next might depend on that first person.

But ~where, ~where should folks start?

Jimmy: mean, I, I usually do start sort of in my, ~uh, ~ let's say change of command, I, I'd start to look at, okay, who's my sort of direct contact. So that may be your direct sort of product owner, scrum master, whoever that has more of the business domain knowledge. ~Um, ~ sometimes it is like architects as well. They've got the experience of talking to the business as well.

To perhaps understand the entire flow of the business, the entire, the flow of the system, because they've been asked over the years to build features to solve a specific business problem. And so they've already had to sort of dig into, okay, this is the business process process in the real world. How do we take what is probably ambiguous and probably, you know, has a lot of different edge cases.

And how do we formalize that [00:09:00] to something that isn't too rigid, isn't too flexible? We can actually do in the system. So I usually start on the technical side. ~Um, ~ And then start to work my way outwards towards the business, if that's part of my charge. So if I'm like being asked to do so, that's when I start going and asking those questions.

I wouldn't necessarily say like, someone should go about modularizing a system without sort of a, ~Uh, uh, ~ buy -in from, from upper levels to do so because the, what the business loves to hear, right, is, Hey, ~uh, ~ we're going to go refactor the system for 18 months, no new features. And when we come out the other end, we promise it'll be so much easier to add new things to the system.

Like they, they never want to hear that. They want to just hear like, yes, we'll have it next week. So I, I don't try to do these kinds of efforts without some buy -in from, you know, upper levels that are also bought into. Understand the problems we're trying to solve and are also bought into a potential solution of this kind of modularization effort.

I wouldn't just start mucking about, you know, and asking these [00:10:00] sort of questions. Like, let's get that buy -in first. Like, one, do we have a problem? And, ~uh, ~ two, like, is this the right approach to solve this issue?

Paul: ~Do you, ~do you find that the problems are typically. driven user, bug driven, their growth scale, preparedness driven.

Jimmy: so usually when this sort of thing comes up, ~uh, ~ whether it's like I want to rewrite the system, I want to convert it to microservices. They're all talking about sort of architectural modernization, modernization, and hopefully there's a business driver behind that. That is like, ~um, ~ either we're not able to take advantage of new, ~um, ~ new avenues of revenue or like new business ventures, or we're not able to.

Go capitalize on soon new market because our existing system doesn't do it and it's really hard to modify the system to make it do so, or it's just even trying to be business as usual. We've seen that our team has gotten slower and slower and slower over time to where now the team spends most of the time.

Just [00:11:00] analyzing the system to make sure they don't break it versus actually adding new features and all my, some of the stuff, like it comes out from, ~uh, ~ the six Sigma lean folks with the, like, what are the value add activities versus the wasteful activities. And I tend to find it's wasteful to spend time analyzing a system.

Like bugs are bad. Yes. But like the value add is like adding the new feature, the value subtractor is. Just sitting and looking at code and be like, what could this possibly break? Because we remember we did this thing last week and it broke a whole bunch of stuff we didn't know was even going to be affected.

But so we're trying to just, you know, do risk mitigation to make sure we just don't break anything. So the team is spending most time doing that. That means they're going slower over time. And so that business is getting mad. Like how sure was easy to add features two years ago. Like, yeah, there was way less code then.

~Um, ~ the modularization is a way for us to. Get back to that, ~uh, ~ level of being able to add features more quickly without having so many side effects.

Paul: And so ~my, ~my next question [00:12:00] about ~like, who you're, ~who you're talking to, who benefits from this? ~I, ~I think lands on team size or like project maturity. ~Um. ~Because if you ask founders who create products that stick with their MVP, ~I mean, ~that's not none of it's great code. You like,~ you're,~ you're doing what you talked about?

You're shipping features as fast as possible to understand your audience and get it out there,~ which,~ which yields monoliths. It can packages that maybe aren't properly encapsulated. But then there's problem. This problem also exists in large companies, large teams. I remember my time at VMware working on something that I was like, wow, this is still ~a, ~a monolith.

That's big monolith. So ~where, ~where on the scale do you find that this conversation happens? Is it everywhere? Is it really after one person, MVP projects ~and, and, ~and planning it out? Should people be thinking about this doing that?

Jimmy: so one of the things that I try to do, at least even for sort of new applications, is to ensure that ~ the,~ architecture I choose, Well, scale with complexity, especially if I know [00:13:00] like this isn't just a one off application that does like, you know, it's a, it's an API with 10 end points. Okay. Whoop -dee -doo.

You can just make the, the code doesn't have to be that well factored at all. Just, you know, it's 10, 10 API events. We care who cares, but if I know I'm projecting out like, well, this is going to serve a lot of folks, then I will at least try to organize. The application code, so there's less coupling, ~uh, ~ further down the road.

~Um, ~ and so this is the idea that we had of, ~uh, ~ this, this idea of organizing the application logic instead of these, like, most of the time you see, like, clean architecture, things like that, or organizing things in terms of, I don't know, like, I put all my forks in this drawer. I put all my knives in that drawer.

Plates go over here. And it's like, no, we want to organize things based on use case and feature so that each individual feature's logic, use case logic, is separate from the other. So if I have to change things or move things around, at least I'm not affecting things adjacent to me. So that's kind of the first sort of level set I do.

But after that, it usually takes, like, I'd say, a certain amount [00:14:00] of growth. And this... It won't necessarily be based on time, because, you know, I've been part of startups, too, that just have this explosive growth. ~Um, ~Wish I exited well from those situations, but whatever, different story. ~Uh, ~ but like we have some explosive growth, so it could be just the size of the codebase or the amount of problems that are trying to be solved with one specific codebase.

Like the insurance company I was working for, they had a 50 year old mainframe that got started in like 1972. Just like, it had been around forever, but it did definitely get to the point where not just like. It was hard to find Cobol developers, but really the system was trying to solve too many problems for too many people in the business, so that if you kind of poke a system over here, then something would pop out over there and break.

Something so completely unrelated that you didn't even know was connected to this. So these systems that grow without boundaries between anything will inevitably get to the point where they become too coupled between individual, between data, between features, [00:15:00] between behaviors, that, that becomes like, oh, the big ball of mud, basically, oh, I'm, I'm whatever.

But even if you say I have, like, the most cleanest, you know, most pristine, ~um, ~ Now, like, ~uh, ~luminaries of software -approved architecture, we still get to the issue that if, if the data models are trying to solve everyone's problem, we often get to the point there as well that the data models also are trying to solve too many problems for too many people, that if I try to change the data model to fit a new kind of business structure, or new, new kind of way of doing business, it's fundamentally incompatible with what's already there, and you can't just sort of jam it in.

And so that becomes the issue of like, well, We're just, we're trying to solve too many people's problems at the same time with one application and one data model and trying to do everything for everyone. Like you don't make everyone happy. So the solution is like, you need boundaries in order to, in order to limit the surface area of the effects of your changes.

Paul: ~Let, ~let's talk about the data model real quick, [00:16:00] because the data model is arguably ~a, ~a slightly different layer than app layers, service boundaries. they are a coupled, but that's a whole new ~like, ~can of worms. ~Um, ~do you find that boundaries around where your business logic lies, where it's deployed?

Comes with a one to one conversation of depth ~and ~and rearrangement with the data model, or do you start with boundaries moving to the data model or vice versa?

Jimmy: No, I tend to just sort of assume a monolithic data model at first, mostly because I mean, I'm saying like I'm starting from sort of a starter mentality, build it fast, just get something working because it's just too hard to predict where we're going to land 6, 12, 18 months from now. So you kind of have to let the business mature, ~uh, ~ to understand where the boundaries should be.

If you try to build those boundaries too early, they're going to be wrong, but it's way easier to change the boundaries and in a single monolithic application than it is with microservices. And I know like, Oh, you can throw away microservices. It's supposed to be disposable. [00:17:00] I've never ever seen that to be actually the case where you can like, just like destroy these things.

Inevitably things are pointing to it and depend on it. And like they'll break if you just get rid of it and changing boundaries and a service oriented microservice architecture is pretty challenging to do. Whereas if you're inside a code base like there's. There's tools to do so, right? Like you can use refactoring tools, JetBrains tools, you know, ~you can use, I,~ you can use tools to assist in those refactorings with service oriented architectures.

That's much more challenging to do,

Paul: And with the. A model. I assume that's also one of the most costly things to embark you were Yeah.

Jimmy: Yeah, absolutely. It is. So, ~uh, ~ when you're looking at boundaries, module boundaries, and we talk about a modular monolith, the, the modules ~ do need to extend. ~They're intended to extend to the database as well. ~So you don't just, uh, ~it's not just a rearranging and sort of enforcement of contracts or something at the business logic application level.

~Um, ~ it's also the data [00:18:00] level as well. So that each module can. Modify its own data model without worrying about the effects on other models as well. I wouldn't necessarily say that everyone should do that for every single module that they build, or necessarily like on this refactoring journey. I often say let's like, let's wait for the data model last because that's the hardest thing to change.

Let's make sure we've at least got the application logic can work by itself. And then when we talk about the data layer, then there are additional sort of incremental Refactoring techniques at the data level to be able to get from one picture to another, ~uh, ~uh, and I'll leave a link for folks, but there's a great blog post from the stripe engineering guys, ~um, ~ that's talk about refactoring or, ~ or, uh, ~database migrations at scale.

They just talk about, I have this data model. I want to go to that other one. ~How do I. ~ With a live system in production, how do I do that incrementally without incurring any downtime? And it's definitely possible, but you want to make sure you got those boundaries right first before [00:19:00] you start, like, getting the scalpel out at the database level.

Paul: ~I, I, ~I wanna make sure we also leave this pod jimmy with concrete things that people can go Google, like you just mentioned. Like that's awesome. We can have show notes. ~Um, of a, ~of a similar train of thought though, ~like. ~Are there any patterns that you would point people to? Like one example is the past couple years I personally learned about the repository pattern that have you data repository leading into your service and that was a nice way to do things.

~Are, ~are you familiar, is that one you're a fan of? What other patterns do you usually find effective?

Jimmy: so sort of the biggest one, ~um, ~ well, there's, there's, there's lots of great books around this boundary, topic. ~Um, ~ so I would still even look at, ~uh, ~ books that talk about microservices. Also talk about how to define your boundaries and those same boundaries that were that. Should have been drawn around the services, microservices are the same boundaries.

I look for in my modules as well. So that does mean that a modular Mike model does [00:20:00] not have like 1000 modules in it. That's like way too granular. Instead of I'm looking at is, well, how does the business organize themselves first? So businesses don't have 1000 departments reporting to a CEO. They got like six.

So that's probably the first good place to start. Then I go one level below and say, okay, well for the CTO or chief product officer or whatever things people got, like, well, what are those top level departments that they have reporting to them? So you kind of get like a much more core screen set of module boundaries.

And that's, that's what a lot of the microservices books actually talk about is, okay, we should look at the sort of Conway's law of, of organization and say, that's probably a good place to start. At least for that. So, yes, ~um, ~ if you kind of stop at the technical parts of those books and just focus on like how do you define boundaries, that's a very good first start.

~Um, ~ but then from there you, now I'm looking at like a business process, ~uh, ~ books of like, well, a lot of times businesses ~organize their, their, their, uh, ~their [00:21:00] company around macro business processes or value streams or value chains of like, well, it starts off with marketing and then it goes to sales and then there's a sales rep that goes out and then they, then it goes to this and this and this.

And so there's usually some very big top level business process of how a business makes money and they've organized that. So I, I look as well to those kinds of like business process books to say if the business has already defined the boundaries within the organization, then that's a good first step, or at least a good first take about what our boundaries should be in our system, not making a technical focus to make it ~more, um, ~ more aligned with business instead.

Paul: ~I, ~I love that we're moving the combo a little bit away from just like looking at the code,~ uh,~ that's an Alice Wonderlands rabbit hole to fall down. In terms of the best way,

Jimmy: Yeah,

Paul: who

Jimmy: that's, we, we love bike shedding in the technical world. We love, I guess. We love to argue about the right pattern for repositories or whatever. But in of like actual patterns, though, [00:22:00] some of the really good ones I've used are this, the kind of the basic ones of dependency inversion, not in terms of like dependency injection or like the specific technical ways of doing it.

But if it got, you know, you know, you know, like, you know, Component A directly talking to Component B, ~um, ~ instead of Component A Directly calling component B, they could say, I need to be provided by this information and component B then says, I can provide it, but it's, it's not a directly talking to B.

It's saying I need this information and B is supplying it for it. So you're, you're swapping the contract on that. So it kind of, if I have a arrow going this way, you're swapping the arrow to make it a bit easier to change the implementation without having to change. The the the originator of that, and it's just like little things like that of swapping those arrows help break those sort of like dependency directions.

Paul: I also think it's neat that you mentioned Conway's,~ uh, uh, ~rules here. As ~a way to start.~ A way to start. Maybe that's where you land. 'cause it does at the end of the day, come back to us, the human condition, the human nature, [00:23:00] how we organize ourselves. And that leads me to like a question that's been stewing in my head during our whole conversation, which is ~how, ~how is this changing now?

Because it all bases upon the business as your source of truth. With the advent of AI tooling. Now granted to say it's not earth shattering for how businesses are changing. If you read like some of these economists reports, 90% of businesses aren't even seeing any ROI on their of AI or implementation ~of ~of ai.

~But, ~but there's still a change, like business processes are changing the way teams might organize themselves are changing. Does this affect the stuff that we've talked about today, the fundamental truth of. Where you might wanna start.

Jimmy: think it can help us, ~uh, ~ do the experimentation more quickly of like, if I say that, you know, I want a group, you know, sometimes you can even go to the screens, right? Like, there's a menu item here that explodes down of saying like, well, if the business has told us organize the menu structure in this way, what if we take that menu structure and organize the things that are behind that into a group?

[00:24:00] Now I could ask Claude or whatever to like, could you do that for me? Like, what does that look like? So at least help us like determine the, the impact or side effects of being able to do this. ~Um, ~ as well as being able to ask questions of our code to say, Hey, I've got this component. How coupled is this component to other parts of the system to understand if I make a change.

Then what's the potential impact of that? Cause like we're still trying to get to, you know, the same like low coupling, high cohesion, that's like not changed really that much. We're just talking about, okay, instead of breaking things up into different independently running services and systems, then we just want that high Cohesion, low coupling, but just it's all in process as well.

So can we ~uh, ~ ask the AI tools to assist in determining, ~uh, ~ the impact of that? So like, for these sets of things, like how connected is this? And that kind of tells us how hard it's going to be to be able to rip this thing out. But it also can tell us later on. ~Um, ~ if we make a change and make about like make this module boundary, we can ask and say, [00:25:00] well, now, how has that changed?

Are we are we more or less coupled to where we were before?

Paul: Fast iteration ~and, and, ~and fast trialing ~of, ~of new ways code diving,

Jimmy: Yeah, make it more experimental. ~Make it, you know, uh, you know,~ one of the things that's really challenging about microservices is it's really hard to undo. What you've already put on production, but it's much simpler in a monolithic system. So it'd be great to use tools that can allow us to experiment and try something as opposed to spending hours or days or weeks on a whiteboard and be like, well, now we think we've got it.

And then we try it out and like, nope, we're wrong. Okay. Let's try it again. Cause my, after doing microservices for many years, I realized like, The boundaries are going to be wrong. Just like they're going to be wrong from whatever we draw on the right board to where we implement, something's going to be wrong, but in a microservice land, like, okay.

But even as simple as I remember one situation, we got the name of something wrong, it was supposed to be something like, this is a quote, but actually it was like, I dunno, a [00:26:00] purchase order, something stupid like that, but the name was already. Named in the github repository. It was the name of the modules we were deploying and publishing.

It was in the code files everywhere is the name of the database. Like changing the name would have been a nightmare, but if it's a name change inside an existing code base, like that's not that big of a deal, right? You can use like grep tools to just be like, blah, blah, blah, blah. Change change. And I mean, maybe the database is a little bit more difficult, but like, it's still possible.

And a microservice when you get a name wrong, like that's your trouble. Like, it's

Paul: Yeah,

that's a, yeah, that, that's a huge lift to change. ~Um, what, what about. ~Just tapping real quick on, you mentioned like course service boundaries, right? ~Like, and, ~and that realization might derive from looking at your organizational structure,

Jimmy: hmm.

Paul: in the conversation of how businesses might be changing their own internal processes,~ um,~ on the people side ~with, ~with ai.

~In, ~in those tools, do you find course more course less course boundaries emerging at all, or is that still TBD ~as ~as the. Sectors

Jimmy: see

the [00:27:00] course boundaries are generally the same. Cause you look at like. Any large company, Walmart, Google, whoever, you're like, how do they make money? That hasn't changed that much over these. The details have changed inside. I see inside those, those little boundaries. ~Um, ~ like I've. I've had, ~uh, ~ manufacturing clients where I go to a physical manufacturing facility, and they're, they're modular, they can move things around, like, yes, here's the loading dock, and we can't change where those doors are, so that's where that is.

But inside there, then like, yes, we can pull the tape off the ground, we can move these plugs over here, and we can reconfigure. ~Um, ~ so inside the facility, it's more malleable, but from the outside perspective, no, it is pretty set in stone that this is where the, you know, this is where things get built, whatever.

So I kind of look at the same way as like make those core screen boundaries to things that are kind of less changed over time. And then internally, it's now that I've got a boundary, it makes it a bit easier to be more flexible inside that boundary and do different things.

Paul: ~What?~ Okay, Jimmy,~ we're,~ we're running up on time a little [00:28:00] bit. We have a few more minutes ~to to, ~to discuss what's going on with,~ uh,~ modularizing and future proofing ~your, ~your stack here. But

Jimmy: hmm.

Paul: where do you see the space headed right now? ~Like what's, ~what's the fad from your thousand foot view in the space and topic, what you think of it?

Jimmy: mean, the one fat is that this is really easy to do, but that's not true. Like, ~um, ~ it's still really hard to define the boundaries. It takes a deep, not a deep level of understanding of the business. So what I am seeing is like more tooling in this space to make, ~uh, more, like~ more pattern definitions, that's something that I, when we started this out, we're kind of rediscovering the patterns that modular architectures had years ago, things like.

I mean, WordPress is modular, right? But we didn't really, we just like PHP, ugh. Um, but like the architecture of those, you know, content management systems, those are modular architectures. So you're like, okay, well, what, what are those patterns that they're actually using? So that's where I'm kind of seeing things now is more of a formalization of the language around these patterns.

Like you're saying, enforce a boundary. Well, okay, [00:29:00] but, but how? Like what, how, how do I do that? What is that boundary? What does that actually look like? And so we need a bit more formal definition of what it means to define these boundaries between modules in an existing single process system. So that's kind of where I'm seeing things going right now is, ~um, ~ a more formalization of defining what it means to be modular here, as well as like the, of the process as well to get there.

Paul: ~And, ~and that's interesting here because I feel like there's a lot of books, there's a lot of literature out there that will talk about the proper micro sass architecture and this and that. ~But, but, ~but now you're saying there's more cohesion in the space there ~and, ~and agreement formalization, that means a centering of science, I guess if I were to interpret that

Jimmy: Yeah, although nothing we do is scientific. I mean, ~um, ~but yeah, I, I just see that because this is a popular topic that, I mean, similar to the microservice when that's really got going that you had a lot more formalization of discussions of, ~uh, ~ API contracts, you know, messaging [00:30:00] contracts, you've got Kafka and, and, ~uh, ~ contracts, ~um, ~ definitions and things like that.

So I, I would, I'm seeing that starting out in this space as well. ~Um, it's just a little. Uh, ~it could be a little siloed because monoliths are by definition single applications that get deployed. So it's still very specific to what the platform that application is built upon. ~Um, ~ but you do start to see kind of some larger patterns.

It's just the conversations can be a bit siloed now, like the Java folks say this, the Rails folks say that, Node folks say this. Like it, it'll take some time, I think, for those ideas to sort of percolate between the different communities out there. Thank you.

Paul: All right, Jimmy,~ well, uh, ~wrapping up our conversation here. If people want to ~like ~read more on this,~ um, they can,~ we can certainly point them to ~the, ~the talk that you gave. ~Um, ~but ~do you, ~do you do public writings anywhere? ~Um, ~blog posts,~ um,~ or other appearances?

Jimmy: I do, yes, but it's mainly talks these days. There are some other great resources out there for doing this. At least in my space, I'm in like Microsoft .net land. Sorry, folks. So I do have resources for [00:31:00] that. Otherwise, what I lean, I can just share what I lean on, which are really like refactoring books and refactoring techniques, because that's really what we're doing.

We're refactoring existing code, ~um, ~ as well as, ~um, ~The boundary definition literature out there. Those two things together are kind of the blueprints of how we get to this modular monolith. I don't know. Ideal world here. Yeah. 

Paul: ~Um, ~awesome. ~And, ~and do you have any socials that you post on ~if, ~if you wanted to throw out ~for, ~for folks to follow?

Jimmy: yeah, you can find me on BlueSky. ~Um, ~ there's still Twitter out there that says I'm on BlueSky now. So that's there. ~Um, ~ as well as, ~uh, ~ like LinkedIn as well. That's like where we post the nerd stuff these days, I think. Is, you know, getting that clout on LinkedIn, I guess. ~Um, ~you can find me there.

I'm on BlueSky at JimmyBogard .com and LinkedIn, Jimmy Bogard. That's where you'll find me.

Paul: Awesome. Well, well thank you so much for your time, Jimmy. ~It's, ~it's been a pleasure. Discussing the monolithic microservice architecture.

Jimmy: All right. Thanks, Paul. .