Hacker News Reader

I guess overall there is a fine equilibrium to find between having a totally uniform stack used by everyone, and having each team using drastically different tools. ESBs can make you fall into an extreme without realising it, because at first, it may look like a grandiose unification plan.

This totally nails it on the head. The problem with Entreprise service buses is the same problems that every major unification plan runs into. It usually executives looking for one ring to rule them all. This misses all the complexity that is going on in the business and deprives the teams that are actually solving those problems the independence to solve them the best way.

> The key here is that technological diversity inside a company is not a bad thing

Agreed! I love working in companies where there is margin for teams to choose their own tech (within reason). It's just that it's hard to know where to draw the line. At one company I worked in, the infrastructure team had a terribly difficult time developing company-wide solutions within acceptable deadlines because the tech and standards where all over the place, the result of a policy of "everything goes, as long as it keeps the company running". This works until you reach a point where some rule must be enforced company-wide... and then chaos ensues. Rules can be anything company-wide: tests, privacy, backups, automated checks, disaster recovery, any kind of compliance, monitoring, etc.

Agreed about your overall point though, and that the ESB is an extreme.

Why not both though? What makes an ESB more onerous than, say, providing a microservice for other departments to use?

Implicit vs. explicit interactions/contracts. Both between consumers & producers but also...

The features, constraints, goals, etc. expected out of the ESB substrate by the different use cases becomes a nightmare of responsibility/blame shifting. Durability and replay? That's the ESB's problem. Load balancing? Yep, ESB. But it's screwing up the ordering guarantees! Well, make the ESB 'smarter' and we can just keep punting all of our problems to someone else. Etc.

Agreed, but that's one side of the coin. The other is that these guarantees and constraints are clearly located in one place (and one team), instead of spread across many teams and implemented with varying maturity and seriousness. I've seen this often happens when separate teams are responsible for separate microservices, implemented in random technologies.

For this to work, the ESB must be acknowledged as the critical piece of the architecture, and the team responsible must be empowered enough.