4 ms·

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

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?

corpMaverick 6y ago
> 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.
rched 6y ago
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 .

corpMaverick 6y ago

> 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.

rched 6y ago

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 .