Below are some of the notes I wrote to myself on the (now old) Monolith First article by Martin Fowler:
- Using a monolith design in the beginning a project allows you to gain better understandings of the systems requirements, models and future services/components boundaries that a microservices design will demand. If you try to implement a microservices design without this, you mid find yourself having to refactor later on anyway.
- Using a monolith allow much faster cycles in the beginning, allowing to reach go-to-market faster, which is crucial – It’s better to have some refactoring work on your hands in a successful project, than have an amazing microservices design for a product that no one uses.
- Refactoring monolith might prove difficult if its codebase is too complex, or the dependencies within the monolith are a mess. If possible, create the monolith with clear boundaries between the components.
- Obviously, if this is not a greenfield project, and you already have understanding of the product/systems, a microservices design might work (since it’s not really a “first” implementation, even if you’re starting from scratch).
Related reads: