> Can you elaborate why? Presumably, with microservices, you're always running the latest version, whereas you're mentioning a need for "different branches and

> Can you elaborate why? Presumably, with microservices, you're always running the latest version, whereas you're mentioning a need for "different branches and versions" in your comment. Not necessarily. Depends on the needs of the customer and what we deploy to them. In general, we try to deploy the most recent version of everything when we make a release for a particular customer. The issue we have with our builds is dependency management. As a note below, that in itself is something that could be addressed by refactoring our projects[1]. Because of the way we need to deploy our software (shaded uberjars) even a well-structured dependency hierarchy would result in large data updates every time we had to update the monolithic application. > Microservices don't force you to modularize, you can still make a mess by not cleanly separating things or by cutting across the wrong boundary. You modularized well because you created a clean, separated, thought-out architecture, not because of any intrinsic property of microservices. They don't force you to modularize well. but they force you to think about how to break your application up. You still need the systems engineering to break it up well. You're right that services aren't the only way or necessarily the best way to accomplish this. We could get the modularization just by refactoring the organization of out projects. In the absence of the requirements for third-party integration and an actual need for horizontal scalability, that is what I would have done. All-totaled, though, I think the service paradigm was the right way to go for us. I need to note for context that the software we write and deliver needs to be delivered on physical disks (yes, we still literally ship software) and that deployment size is an issue. We also can't guarantee that we will have access to anything besides a Windows or Linux JVM, so our deployment needs to drag all of its supporting data along with it. being able to simply deploy a new version of a particular service makes updates much less painful. [1] And actually using versions for our Maven artifacts, but that is a battle I lost a long time ago...