In one of the projects the CTO has chosen to use a message broker in order to connect microservices. Is the use of such software aligned with the microservices theory?
Attempt to answer the question
In Sam Newman's Building Microservices chapter 12: Bringing it All Together, the author mentions seven principles including Decentralize all the things. The last paragraph of that part is as follows:
This principle can apply to architecture too. Avoid approaches like enterprise service bus or orchestration systems, which can lead to centralization of business logic and dumb services. Instead, prefer choreography over orchestration and dumb middleware, with smart endpoints to ensure you that you keep associated logic and data within service boundaries, helping keep things cohesive.
Enterprise service bus
implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA)
the automated arrangement, coordination, and management of computer systems, middleware, and services
the art or practice of designing sequences of movements of physical bodies (or their depictions) in which motion, form, or both are specified
I’m pretty confident that there exist enterprise service busses which are handling similar scenarios and those are the opposite of simple “dumb” ZeroMQ-like message passing frameworks.
Q: And regarding smart endpoints.. if I get it right, Microservice=endpoint, sort of something that can send/receive messages. The reason the endpoint is smart, because it has a logic inside, not on the middleware(e.g. ESB). Right? A: Exactly, endpoints have the logic and I actually did a project in an open source team which used JMS as the underlying communication for an ESB, so it should be still rather dumb
- What is the definition of choreography in IT?
- What are examples of dumb middleware?
- Are microservices smart endpoints?
- Is the use of message brokers, e.g. kafka, rabbitmq, zeromq and qpid in Microservices a bad practice?