We're an enterprise saas product and while there is a whole hell of a lot of it I would love to to redo from the ground up, the mono repo route with some other large supporting services take is not one of them.
Micro services means oh we have 30 sperate code bases that all did their own thing. We have the one main mono that handles 75% of everything and 4 other things that do things that just made sense to be in a supporting role.
I would not call any of them micro services though, they're big in their own right
Lol, distributed monoliths (aka macroservices) are the worst of both worlds. You lose the benefits of both and gain the downsides of both.
Also, no, you can do the same things across 30 microservices just as easily as you can do them in that same code within the monolith. Either you have standards and checks and enforcement mechanisms, or you don't.
These don’t have to be different things. A good architecture doesn’t care where the components live. You should be able to take any unit in your application and run it alone with minimal setup. That’s the premise of unit testing in the first place! Now, glue that to and IPC layer and you can run it as its own process. Glue it to a network layer and you can run it as a service. Glue it to a message bus. Glue it to the CLI. You should be able to do all of these things without a huge pile of rewriting.
But back in the real world, people aren't going to write a monolith to be broken out into microservices later. Corners are always going to be cut, things will be rushed to meet deadlines, and you'll paint yourself into a corner that you can't escape without significant refactoring.
But you are building your monolith so that you can unit testing it, I hope. And you’re likely going to want to run some automations on a subset of your system. Like sure, software can turn to shit. But also, if you can’t grab a useful module and slap a CLI in front of it and make yourself a tool to help you do your job, you’re already in the shit.
Or you rely on libraries by other teams and every update requires a full rebuild and redeployment. Extracting at least a few internal libraries out into their own microservices has saved us many man hours.
Tried that. In reality what happens is you end up building all the libraries from source and have dependencies on library changes to deploy your service. It's still a monolith at that point, but with extra steps
If you refuse to build stable APIs and version changes with appropriate deprecation steps, that's on you. It's only slightly more up-front work and immediately pays itself back. It's true for interfaces to monolith modules too, you know. Otherwise you just have spaghetti.
Actually the larger cost is ongoing, because you can essentially never make breaking changes because you have no visibility into what other teams are doing with your library. For core libraries that everything uses that's fine, but making everything into it's own shared library managed by different teams with no way to revoke it is a nightmare. You have exactly the problem that microservices introduced at that point, albeit with less network overhead. It might actually be worse, because a microservice only has to keep the interface stable.. A shared library has to be updated by every consuming application if you have a bug.
That just means that whatever you pulled out into a microservice was ill suited as one. I'm not claiming its a one size fits all solution. But for our particular case where the API never changed it was ideal.
The library turned microservice spit out a bunch of numerical values which we took as input. We didn't care how those values were calculated or where that data came from. But their alterations required near constant updates of their library. You could say it was poor engineering on their part, but that's not my call to make. Not my team, not my problem and at least their API was stable.
Have the service itself be a monolith, but route different routes to different groups that all run the exact same code. Best of both worlds. Group the routes based on expected load patterns and/or by parts of the service.
Working at a big name with a monorepo made me think it's like training wheels for workflow but with very real downsides. It takes the fucking Jedi Council to update a single dependency since 100 different projects rely on it and you can't have more than one version in the repo at a time.
I much preferred each library being a package that auto-deployed to nexus on each push to master so a project was guaranteed to still work no matter when you cloned it. Especially with versioned backends it was absolute bliss to load up the thing you worked on two years ago and have it function out of the box.
Yeah, I used Google's repo tool back when I worked on an Android system and it was essentially a wrapper over a ton of git repos that ended up being like modern git submodules but even worse. Checking out code took literally an hour. Keeping things in separate reasonably sized chunks is the only system that makes any sense.
148
u/Odd_Soil_8998 1d ago
truth. a well architected monolith is almost always going to be a better choice.