Still very new to studying application architecture and having trouble stomaching some ideas in a book about microservices. In my readings, I have come across the older idea of the ESBs(Enterprise Service Bus) and its role in coordinating messages between new services and legacy applications. ESBs are touted as a solution to problems poised by point-to-point integration. Microservices seem to be the approach taken by newer companies as the de facto standard to creating an agile, scalable, and resilient app. But aren't microservices using point-to-point integration? Each node in an application built from microservices is communicating directly with other nodes, right? I feel I am connecting some dots that shouldn't be connected. Any help much appreciated, thanks in advance.
4 Answers
ESBs are solutions that have been implemented in many companies to ensure application interoperability and traceability. However, they are heavy solutions that do not allow to scale horizontally, usually the ESBs adopt a configuration of two nodes, active-active or active-passive.
On the other hand, services in ESB are not usually deployed individually but in deployment packages alongside other services, making delivery management and testing more complicated.
Microservices are designed to be developed and deployed individually, and so that within a cloud infrastructure can easily scale horizontally increasing the number of instances dynamically.
Interoperability between applications has moved into the background at present, as today's communication by web services is virtually commonplace, although some middleware that solves connectivity may still be needed in some very old infrastructures.
Microservices do not necessarily rely strictly on point-to-point integration.
The problems associated with direct communication are often managed in a microservice architecture using a message broker. If communication can be done asyncrounously -- "fire and forget" -- the application sending a message does not become inoperable if the receiver goes down. And the messages will still be there when the receiving service comes back up.
If microservices are integrating over REST, the caller does need to know how to react if the other service doesn't respond. Since this gets hairy when you're saving data across systems (i.e. a distributed transaction), I like to use REST only for data retrieval APIs. And do all saves as a result of messages.
It's important to note that there's a lot more to ESBs than just messaging. See more on that in the answer here.
Both approach are not necessary exclusive. Microservices may communicate using a messaging middleware (kafka, AMQP, Akka actors, JMS...) instead of direct http channels. It depends on your constraint (mainly consistency) and deployment policies.
Each choice has his strengths and weakness, I personally advise not to limit yourself to one approach but to use both and choose according to each situation
See Microservices: REST vs Messaging and https://capgemini.github.io/architecture/is-rest-best-microservices/
Microservices are not a replacement for ESB.
Microservices is a concept for development of backend systems, including it's API. The opposite of microservices approach is a monolith. If the API is consumed directly by the consuming systems, we come to point-to-point (spaghetti) integration. If the consumer uses a middleware, often called API gateway we can have centralized visibility, security and tracing (as with ESB). API gateways are simpler than ESBs and thus are better suited for horizontal scaling. API gateways should not include additional business/integration logic.
ESB does the same as API gateway (acts as a proxy), but in addition allows to include business logic, compose multiple services into one and other advanced functions. ESBs often grew into burdensome solutions with a big overhead and only little added value, and that's why they became hated.
Conclusion
ESB can be used together with microservices architecture, there are many companies which keep ESB simple and it is almost equal to so called API gateways.
My opinion
API gateways are introducing new functionalities and are getting more complex, coming closer to ESB.
Related