Hacker News Reader

Comment by vilunov | Hacker News Reader

After years of working with various microservice-based systems, I got the impression that the whole idea of "microservices" means ignoring various nuances of particular products and organizations and just splitting your system in a pinky-sized codebases and services.

You are completely right, every project is different, and that's why the general idea of microservices is bad. Split your services where there are technical or heavy political and organizational reasons to do so, but don't go for splitting as your default solution.

View on HN

Your code structure should match your org chart is the best advice I've seen for splitting code. Each team in the org maintains their own micro service. They do whatever they want within it, but when going to a different one they go to an interface. It isn't perfect, but it seems to work the best.

There are interfaces besides RPCs

Until the org chart is reorganized, then what?

Then you reorg the system. Note that this can go either direction - you can also change your system to how you want the org chart to look. Generally it goes one way because engineers rarely have the power to change the org chart, but sometimes we are consulted and can suggest 'improvements'.

You can't fight Conways Law[1]. Or you can fight it I guess, but you will lose.

[1] https://en.wikipedia.org/wiki/Conway%27s_law

Org charts tend to change faster than services can possibly be re-architected in a large scale system that is growing quickly. Honestly you need a critical mass of engineers who can think end-to-end with a product and business-first mentality, they should decide what tradeoffs make the most sense taking into account a broad range of hypothetical future requirements and what makes sense given current domain knowledge. They must do this with real expertise and ownership, not basing it purely on a 3-year roadmap from non-technical PM. Then teams should be organized around the design of these systems (not the other way around). This overall process should be repeated iteratively as the product and business scales.

> Your code structure should match your org chart is the best advice I've seen for splitting code.

I've seen that so often it now feels like a sarcastic meme to me.

The org structure changes much faster than your code structure does. Good luck getting those two to stay in sync longer than the CTO stays in their role.

Reply on news.ycombinator.com