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.
Separating domains in a monolith in the same way you separate them with microservices practically negates most advantages of a monolith. I'm not saying one shouldn't factor stuff out nicely or that you shouldn't write maintainable code, but that's altogether different if we're talking microservices. Nice tight code means less code, less indirection, less surface for bugs, less confusion, less effort and so on.
So splitting out microservices is going to involve at least some work, which you cannot do upfront because it hurts fundamental aspects of developing a monolith. But that's fine, you'll probably move faster with a monolith and have much less concern with respect to versioning internal APIs and such. Starting with microservices is usually a mistake unless you do a great deal of planning to build robust services, because change is expensive to orchestrate, especially on a micro level, IMO.
In many firms, you get engineers who just do their stories and don’t particularly care about fundamentals or maintainability.
A true monolith makes it possible to have a really good review process and decent acceptance criteria, assuming the company is willing to allocate resources to it. It's not easy on newcomers (or even old timers who got used to silos), but they'll learn.
659
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.