Hacker News Reader

Comment by leetharris | Hacker News Reader

These blanket statements on Hackernews are so frustrating to read. Every one of these articles is bait for these type of comments. The comments fill up with people saying microservices suck, then it fills up with comments saying those comments suck.

Please understand that every environment, company, and project is different.

View on HN

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.

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.

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.

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

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

There are interfaces besides RPCs

> Please understand that every environment, company, and project is different.

No doubt, but my point is there is a unifying metric that we can use to evaluate the effectiveness of these environments, Percentage of time spent on the environment itself versus on user needs. I think that number is too high for any system that is overly-decomposed.

Reply on news.ycombinator.com