Hacker News Reader

Comment by corpMaverick | Hacker News Reader

Microservices are a good way to scale up development teams. So if you have 16 developers you can partition the work in two teams with one microservice each. If you have 80 devs you can have 10 teams with one microservice each team. Use Conwayś law to your advantage. Use DDD to decide where the boundaries are.

The advantage of having each team own a microservice is that each team can deploy their software independently from the rest of the teams. And it works as long as the APIs are honored. So Microservices are way to decouple the work of different teams allowing them to work independently from each other.

View on HN

This only works for the simplest cases. If the two microservices must share data and direct calls (API calls) are not allowed (because they make your services highly coupled to each other to the point where if one of them ia down, then the other cannot work properly, or simply because your use case cannot tolerate the latency overhead) then each service must 1) replicate the data needed locally by listening to interesting events of the other service and b) emit interesting events so that the other service can update its local db. In other words, async communication.

While this let's you scale up teams, it's a huge overhead. So, unless you have over, let's say, 500 devs, it's not worth it.

> This only works for the simplest cases. If the two microservices must share data and direct calls (API calls) are not allowed

Actually, one assumption is that the microservices don't share data. Only API (Rest, SOAP, GraphQL, etc) calls are allowed. And the boundaries are created minimizing the coupling between microservices.

> While this let's you scale up teams, it's a huge overhead. So, unless you have over, let's say, 500 devs, it's not worth it.

As opposed to Monolith ? I think you will have problems collaborating in a Monolith at around 30 devs.

What I am opposing is the idea that you can have 30 devs and 50 microservices. Which I have seen in real life.

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?

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

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 .

bingo. having each team own he boundary of a service lets everyone work as fast as possible, making choices that are right for their service, while preserving the right level of abstraction between components.

that’s very different from a team of 8 people managing two dozen microservices, which is just insanity.

Reply on news.ycombinator.com