4 ms·
Why not both though? What makes an ESB more onerous than, say, providing a microservice for other departments to use?
by bcrosby95 6y ago
Why not both though? What makes an ESB more onerous than, say, providing a microservice for other departments to use?
- johnm 6y agoImplicit 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.
- the_af 6y agoAgreed, 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.