Just for reference, here's Wikipedia's definition:
A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural pattern that arranges an application as a collection of loosely-coupled, fine-grained services, communicating through lightweight protocols.
While microservices can be a great choice to scale multiple teams - that may even specialize in different programming languages and/or problem domains - they can be a huge burden for a single small team.
Here are 15 things to keep in mind when evaluating the microservice architecture for your project and team:
- It can be more complex and difficult to understand and implement compared to a monolithic architecture.
- It may be difficult for a small team to effectively manage the complexity of a microservice architecture.
- The team may not have the resources to properly monitor and maintain the individual microservices.
- A small team may not have the expertise or experience to properly design and implement microservices.
- The overhead of communication and coordination between services can be significant, and may be difficult for a small team to handle.
- The overhead of managing and deploying multiple separate microservices can be significant.
- The need for strong communication and coordination within the team can be a significant challenge.
- It can be difficult to ensure that the different microservices are properly integrated and work together seamlessly.
- The development process can be more complex and time-consuming in a microservice architecture.
- There may be a lack of standard tools and best practices for developing and maintaining microservices within a small team.
- A microservice architecture can make it more difficult to track and manage dependencies between different services.
- The increased complexity can make it more difficult to onboard new team members and get them up to speed.
- The cost of implementing and maintaining a microservice architecture may be prohibitive for a small team.
- The need for strong communication and coordination can make it more difficult to distribute work among team members and maintain high levels of productivity.
- A microservice architecture may not be necessary or beneficial for a small team with a relatively simple or straightforward project.
Maybe one more thing to keep in mind. Your project might never reach a point where you are no longer able to scale - not just from an HR/human resources perspective, but also from an infrastructure/performance perspective. ... unless you (unknowingly?) slipped in some major bottlenecks yourself, but that's where solid monitoring comes into play.
And as you and your business (and team) grow, you can still reconsider and start extracting microservices from your monolith. But first, you want to deliver business value and grow.
To ensure you don't end up with a tangled mess, it's usually a good idea to set up your CI/CD tooling to detect code/architecture smells
and ensure you have a somewhat decently modularized monolith.
Personally I do like to use facades as the only permitted "entry" into a domain/module and treat it like an external package/dependency, where I have no control over its inner workings.
Is this a good approach? You tell me! :D
Since there's no reason for me to repeat what other's have already said very well - here's Martin Fowler's take on a "Monolith First" approach https://www.martinfowler.com/bliki/MonolithFirst.html