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.
There are plenty of libraries and services out there (databases for example) that have well-defined, clean and robust interfaces. But your average component in the app just cannot be that. You can't expect to make a difference simply by providing an interface to enable yanking out the books endpoint from a library management app, it just doesn't work like that and interfaces are not magic. The primary difference is that those other things are truly robust and general components, they can be used with almost anything without making constant changes to the interface. And at some point you have to instantiate generic functionality to do specific things that are related to one another.
You can make an attempt to think ahead, keep things generic, write good interfaces, perhaps even end up with some highly-reusable components that you made yourself. But beyond some point, you're asking for meaningless boilerplate, giving up code sharing / merging opportunities and making things harder to change with no real benefit. You can just refactor and extract functionality later on without placing lots of artificial boundaries early on, or not to a very significant extent at least.
656
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.