Hacker News Reader

Comment by itamarst | Hacker News Reader

Microservices are an organizational pattern: "we have 500 programmers working on one application, how the hell do we do it."

Solution: break up application into independent projects, each team of developers works on one of them, have extra team that builds tooling to make everyone happy.

Using microservices with a small teams is a terrible idea, usually, because you're switching to a distributed system when you don't need to. And distributed systems are hard to get right. And you're not even following the organizational pattern, because you have one team with N microservices.

View on HN

That organizational pattern used to be addressed by proper design, engineering and project management. IMO, allowing the hell that is Agile dictate architecture design is the tail wagging the dog.

Essentially, microservices are Conway's Law in practice.

You need a (good) programmer/architect for this to work in my experience. If you don't have someone who can accurately keep the entire 500-piece workflow in his/her head, success is much harder to achieve. If you have that person though, the 500 developers will feel very focused, and you end up getting where you intend to go. That architectural role is clutch from my experience.

And even then, those 500 programmers can be distributed across application modules, delivering libraries, no need for microservices.

Agreed. If you don’t have the discipline to maintain libraries and their interfaces then you won’t have the discipline to maintain micro services either. I am sure there are good use cases for micro services but using them to compensate for bad coordination won’t help.

Kind of. If you need to scale compute across multiple nodes, starting out as some kind of service abstraction over a method call will help. But most people don't need that scale.

We already learned back in the days of SUN RPC how scaling across method calls works in practice across the network.

By over, I meant over and above, fwiw.

I think RPC is a dreadful network programming abstraction. Anything that makes you think it has the same QoS as local calls is just a trap, stuff that works in development and fails horribly in production. Errors, latency, timeouts, retries etc are first class concerns once you bring in the network, far more so than local.

Yes, but I also think it isn't a bad idea to separate your applications. Just because each application is a monolith doesn't mean that all of your code has to be in one repository.

Can your admin system be a separate system? Can they be three separate systems because three separate groups will use them? Even if you don't immediately split them into separate repositories, it may make sense to segment them as if they were, because if successful, you will start running into problems at around 40 programmers.

That is why libraries exist.

Actual solution: Don't have 500 programmers.

Reply on news.ycombinator.com