A recurring pattern in software organizations is extracting services not because the system demands it, but because teams want cleaner ownership or a fresh start. This redistributes complexity to upstream callers without eliminating it, making revenue-generating applications harder to change while the extracted team enjoys serene isolation. The author argues services should only exist when the monolith genuinely cannot handle the requirement — a constraint expressible in a single sentence like performance isolation or a diverging scaling axis. Escaping gnarly SQL or avoiding cross-team coordination are not valid reasons; they solve org problems with system tools, and the system pushes back for years.
Sort: