By Stephan Schulze
I had a fascinating discussion with a young startup about the best time to migrate into microservices. The company has a small team of engineers who maintain a monolith-based codebase, and they were wondering if they should already break it into microservices.
I advised them to wait as long as possible and ensure that their application components were properly decoupled.
What do I mean by that? Well, imagine that one module of your app is responsible for transactions and another handles user management; a good practice would be linking them internally via an API instead of interacting directly with each module’s database.
This approach results in better testing and saves time when you’re ready to split the app into microservices.
Another aspect is the staff. Implementing a distributed system when you only have a few people adds complexity: They would need to maintain all these interdependent services, orchestrate multiple deployments in parallel, etc.
When should you adopt microservices?
- When you have a module that handles high traffic, you can extract it from the application and run it independently. This way, you serve your users’ needs without scaling your entire monolith.
- When your team grows and multiple sub-teams work on the same codebase, it’s time to shuffle: Assign one team per product or domain, each fully responsible for a specified set of services.
The theoretical foundation for this decision is Conway’s law–the system architecture represents how teams communicate with each other. Leaning into this model, it makes sense that monolith is the right choice for startups and small teams.
When you’re ready to scale, you can either build autonomous teams to support a distributed service architecture or start with the system: Design it to fit autonomous, distributed teams.
Does your team setup correspond to your software architecture?