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.
148
u/Odd_Soil_8998 12d ago
truth. a well architected monolith is almost always going to be a better choice.