The cracking monolith: the forces that call for microservices
- Overweight monoliths exhibit degrading system performance and stability, or slow development cycles, or both.
- Single points of failure are typical of large monolithic apps and when they come under pressure, your team spends too much time solving technical issues instead of on development. For example - outages in non-critical data processing that bring down the whole system. Or all time-intensive tasks grouped into the background and becoming so unstable as to need a dedicated team. Or changing one part of the system affects others that should logically be unrelated.
- If shipping a hotfix takes weeks or months, you will have a problem with slow development. To know when it is a good time to break the monolith, you should watch out for:
- CI builds that take longer than 10 minutes (though a good CI tool should help it by splitting or auto-sequencing tasks).
- Slow deployment, due to many dependencies and multiple app instances, especially when containerized.
- Slow onboarding of new staff as it may take them months to get comfortable enough to make a non-trivial change to the codebase. Veteran team members becoming a bottleneck as reviewers because too many developers are waiting for their inputs.
- New use cases and problems are not easily addressed with existing tools, and software updates are being put off, indicating you are dependent on outdated technology.
Full post here, 6 mins read