Starting with Microservices
As we mentioned earlier, there is no reason we cannot start with a monolith or more course-grained services. It could be that we have a very large team that is working on a new large-scale application, and the domain is well-understood. The counter-argument to starting with a monolith is that if we know our end goal is a microservices architecture, then there might be good reason to start there from the beginning.
It’s important that the domain is well understood before you begin partitioning it, as refactoring boundaries can be costly and complex.
By starting with a microservices architecture, we can avoid the cost of refactoring later on, and potentially reap the benefits of microservices earlier. We ensure our carefully designed components and boundaries don’t become tightly coupled, and based on history they generally will to some degree in a single codebase. The team becomes very familiar with building and managing a microservices-based application from the start. They are able to develop the necessary experience, and build out the necessary infrastructure and tooling to support a microservices architecture. There is no need to worry about whether or not we re-architect it someday, and we avoid some potential technical debt. As the tools and technologies mature, it can be easier to start with this approach.
Once we have made this decision, we will either have a monolith we need to refactor, or a new application we need to build using some combination of coarse- and fine-grained services. Either way, we need to think about approaches to breaking down an application into the parts suitable for a microservices architecture.