I've witnessed two ESB rollouts at different companies, in both cases with the same noble goals of just helping with some monitoring and authentication, providing "better" access to legacy systems. In both cases in just 1-2 years the ESB became a single point of failure, a bottleneck for change, and generally a roadblock for all projects.
ESBs are just too convenient not to use them. First, you'll just add some special routing for a message you want to send to some system, then you just quickly solve translating some xml message to another format, because you can. Then you add some more XSLTs or whatever to cover for a version update that would be too expensive to fix in the client system. And so on...
Before long, you will have business logic on there. All teams will have to coordinate with the ESB team for all rollouts, new messages or even changes in message formats. It will kill the independence (the low coupling) of your teams.
The point of the Microservices architecture, as you pointed out, is to enable autonomous operation not just for the service, but for its team as well. This enables quick change. Ideally this would mean:
- Avoid any synchronization points with other teams, be it for testing, rollout, configuration or operation (i.e. you have to go cross-functional and do DevOps, etc.)
- Avoid synchronization points runtime with other services. This means avoiding synchronous calls regardless of technology. You should only do fire-and-forget, never request-response even if the response comes at later point in time.
- Avoid dependencies to other teams. This means avoid code-sharing (of code that has business-logic or business-related objects)
Basically, you should be able to keep operating your microservice (and roll out new versions) even if the rest of the company shut theirs down and went on vacation.
Of course that is an "idealized" scenario, but an ESB most definitely goes against all goals above. It is a synchronization point, a centralized dependency both runtime and organizationally.
