So, why did we actually have an ESB (Enterprise Service Bus) in the first place? So that it could do mediation, routing, data transformation and provide connectivity. But over time, most of the applications have become smart
enough to expose or consume web services – SOAP or REST. For applications that are still not web-services enabled, there is an option to use a messaging mechanism such as JMS or AMQP. Microservices, which are becoming
popular now, bring forth ideas that mandate that the services be decentralized, independently deployable and be built for a specific functionality (e.g. order history processing, contact management etc).
Martin Fowler, who is a major proponent of Microservices, is well-known to have a negative opinion of ESBs. So, it comes as no surprise when he says that the microservices architecture should have “Smart endpoints and dumb
pipes”. He advocates for the middleware to use a plain messaging mechanism such as RabbitMQ/ZeroMQ instead of BPEL for orchestration. Cloud Foundry founder Chris Richardson states at Microservices.io that an API Gateway
should be used for exposing/managing microservices. He also seems to shift the responsibilities of the ESB such as routing to the API Gateway. An API Gateway now appears to be a leaner version of an ESB with minimal mediation, data or
protocol transformation and basic routing capabilities.
With a growing trend of API adoption, it appears that the ESB would remanifest itself as an API Gateway with features for metering APIs, throttling and native JSON support. Already, we see products from vendors such as WSO2
provide features of a service registry and an API gateway. As for the legacy and other applications that cannot be service-enabled, they would soon be a minority and should be able to be integrated using adapters. It only
appears to be a matter of time that this would happen. The most interesting point though is on the the size and complexity of microservices. Too large and they will become monoliths; too small and they would not be
independent. The right size and complexity will ensure that microservices are not just SOA with HTTP/REST APIs. It will not be surprising to see guidelines, standards and specifications appear to aid/complicate in defining these.