|
|
|
|
|
|
by amy-petrik-214
633 days ago
|
|
|
exactly - refactor the monolith. What we do is refactor the monolith into microservices that we like to call "micro-monoliths". What you get is the agility of a microservice with the simplicity and lack of sync issues of a monolith. Monoliths are problematic because they are too large and unweildy; microservices are problematic because now you have 200 microservices to track and if one service node goes down it can trigger a cascading failure - we're talking complex distributed systems here. The solution is the micromonolith, a hybrid approach striking a balance between the two, best of both worlds. |
|
|
The idea that something could become less unwieldy or overall "smaller" by splitting it into separate codebases and introducing RPC and dealing with all the other complexities I mentioned above seems fanciful to me.
As far as I can tell the only semi-reasonable reason to want to move to micro-services is social -- effectively Conways law driven by Dunbar's number -- ie. you've scaled your organisation to a point where you have too many people to work effectively together and you need to split off into smaller teams, each with a subset of your total pool of developers, and want to be able to grant each team autonomy over their 'microservice'/domain to prevent death-by-committee.
I'd still argue most would be better off modularising/maintaining the monolith so multiple teams can work on it, but I do at least understand that rationale.