[Spivak]

I don't disagree at all. In fact I'm saying the desire for microservices is a sign your monolith could use a refactor. I would call it a canary but it's long dead by this stage.

If it's faster to spin up a new production service from scratch to implement some functionality than leverage your existing code then something has gone very wrong. Shouldn't all that code make implementing complex features faster and easier? Shouldn't your codebase be full of powerful tools that can be leveraged to build completely new things?

Every time I see this happen is because frameworks -- not 3rd party frameworks, but the whisper from Satan that suggests that wrap code in more layers to make it "easier", "simpler" for the user.

[amy-petrik-214]

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.

[FLT8]

> Monoliths are problematic because they are too large and unweildy;

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.