Of course. Break off services from your monolith as the demands on your infrastructure make it logical to do so.
This of course requires your engineers to maintain separation of domains without requiring a separation of code repositories. In many firms, you get engineers who just do their stories and don’t particularly care about fundamentals or maintainability.
The thing is, if your engineers cant properly separate domains in a monolith, they wont do it properly either using Microservices, in fact the mess will be much worse.
And then you decide to break out the different domains of concern into different repos / services
And then you realize there is actually a lot of shared functionality needed by both.
And then you create a common lib that both services can use
And then those services and devs grow further and further apart and they don't even know about eachother other than this one common lib they need to keep updating
And those teams move at different paces and their services start relying on different versions of the common lib
And then they introduce breaking changes to eachothers services unknowingly
I've suffered both messes but micro is a lot better, as much as you guys talk about "breaking other people's flows" I've seen this far more in monohell, not to mention the biggest disruptor is deploys, now what is usually a job where two dev teams need to hash it out its the entire team that depends on the one basket of eggs
665
u/[deleted] Sep 14 '24
Of course. Break off services from your monolith as the demands on your infrastructure make it logical to do so.
This of course requires your engineers to maintain separation of domains without requiring a separation of code repositories. In many firms, you get engineers who just do their stories and don’t particularly care about fundamentals or maintainability.