2 ms·
I think one of the essential reasons to start with a monolith is cultural. When you have an existing project/product and you are making incremental improvement
by ianbicking 11y ago
I think one of the essential reasons to start with a monolith is cultural. When you have an existing project/product and you are making incremental improvements to that project, there's a lot of shared understanding (everyone knows what the product already does), and so a small group can go off and work in isolation and get some efficiency from that.
When the product doesn't even exist, there is not shared understanding. It takes constant communication to prioritize correctly, and to understand the purpose of all the pieces, and to detect cases where an implementation is diverging from the purpose. In a kind of inverted Conway's Law, the architecture of the application will affect the communication structures of the team. You don't want the team to communication like microservices communicate. You want the team to communicate like a monolith, where everyone is always in everyone else's business, where conflict is frequent, but conflict resolution cannot be avoided.
I'm in the middle of a greenfield project where there's lots of little pieces communicating to each other over message channels. It's not an architectural preference, it's just how the environment works. Every single-page-app-style website has at least two services with a message channel. It's interesting to look at how this can be technically reminiscent of microservices, but culturally completely different. Those message channels don't make my project any less of a monolith (just a kind of annoying to debug monolith). But that's because they are deployed together, developed together, no individual has a responsibility that ends at one of those boundaries, there's no contract across those boundaries, there's few principles applied to the design of those communication channels (experiential and intuitive principles I suppose). That team structure, and that shared relation to the code, feels absolutely right for a new project.