2 ms·
In my experience, most places rearchitect to microservices because they have a shitty monolith that they are dealing with. The monolith has been built over a s
by nerdix 4y ago
In my experience, most places rearchitect to microservices because they have a shitty monolith that they are dealing with.
The monolith has been built over a span of 10+ years. It is fragile, brittle, no one understands how the whole thing works, and large scale refactoring without widespread breakage is near impossible. No one wants to touch it because no one understands how the whole thing works. Because of this the codebase is also falling behind and isn't staying current with language updates (I know everyone here likes working with 10 year old tech but it does affect hiring when you have to say that you're using Java 8)
But it is true that distributed monoliths are very common. One problem is that it's hard to get everyone on board with going "all the way". The question "Do we really need multiple databases" is one of the main culprits that spawn distributed monoliths.
- 0x445442 4y ago> The question "Do we really need multiple databases" is one of the main culprits that spawn distributed monoliths. It's true the lack of bounded contexts is a big problem. But I also see a lot of orchestration services with multiple dependencies on other services, some of which are themselves orchestration services. This quickly cascades into dependency hell only you don't get the benefit of a compiler to alert you to the problems.