Why do you need Microservices to create boundaries in your code?
You trade the ability for teams to deploy independently for the ability to be able to make breaking changes. This is a good trade off in my experience and is better for team velocity.
The approach we have taken is to keep a single codebase and deploy. We have applied the ideas from DDD to segment the code into contexts and assign ownership of each of those contexts to a team. This allows us to get some of the benefits of Microservices without losing all the benefits of a monolith. Having these boundaries in place also gives us the flexibility to move to Microservices if and when we decide we need to.
Ultimately the point of separating code into microservices is to develop the interfaces between teams. They certainly do not make sense compared to a monolithic app until a certain scale.
When you have 10 teams working in 1 mono-service, who is responsible for which parts of the DB schema? Can I query a table in one part of the app that another part owns? What if another team changes a table that I relied on and introduces a bug? Who is responsible for fixing it?
Microservices solve the people problems more than they solve the tech problems, assigning organizational responsibility for functionality, infrastructure, strategic objectives, etc. It also provides clear interface points between these things that can make organizing work easier. You get to split your 1 org into 10 little vertical orgs. This has benefits beyond just code boundaries. Now you can have 10 different goals all being achieved at once
You can go the other way, of course, and split the stack horizontally (One team is responsible for infrastructure, one for DBA, one for Frontend, etc) but then no team is working towards any one goal. Who is responsible for making forward progress?
The realization I’ve had after scaling a dev org from a single team to 10+ is that you don’t need microservices to achieve any of that.
> When you have 10 teams working on 1 mono-service, who is responsible for which parts of the DB schema?
You can still develop interfaces between teams without microservices. There are a number of ways to do this but the simplest is just a folder structure that reflects the boundaries and enforce them by convention. If the model/repository/[your favourite DB abstraction] lives in `context1/user` you can’t access it from `context2/account` without going through `context1/publicInterface`.
It’s surprisingly easy, depending on your language, to write tools to automatically verify boundary violations if you need to.
This still allows you to solve all of the problems you listed .
> Ultimately the point of separating code into microservices is to develop the interfaces between teams. They certainly do not make sense compared to a monolithic app until a certain scale.
Exactly. This is the idea that I haven't been able to articulate. And it is rarely addressed in the literature.
You trade the ability for teams to deploy independently for the ability to be able to make breaking changes. This is a good trade off in my experience and is better for team velocity.
The approach we have taken is to keep a single codebase and deploy. We have applied the ideas from DDD to segment the code into contexts and assign ownership of each of those contexts to a team. This allows us to get some of the benefits of Microservices without losing all the benefits of a monolith. Having these boundaries in place also gives us the flexibility to move to Microservices if and when we decide we need to.