Menu
I have read an article "Microservices" by Martin Fowler and find it difficult to understand smart endpoints and dumb pipes. Please explain these terms, examples are welcome.
968
Smart endpoints just meaning actual business rules and any other validations happens behind those endpoints which are not visible to anyone to the consumers of those endpoints think of it as a place where actual Magic happens.
A microservice is a small, single service offered by a company. It derives from the distributed computing architecture that connects many small services, rather than having one large service. The microservice can then be delivered through an application programming interface (API).
In some cases, there may be only one endpoint, whereas in some other cases, there could be more than one endpoint in a microservice. For instance, consider a sensor data service, which collects sensor information, and has two logical endpoints--create and read.
- Simplicable What is Smart Endpoints And Dumb Pipes? Smart endpoints and dumb pipes is a design principle that favors basic, time-tested, asynchronous communication mechanisms over complex integration platforms. The term is associated with microservices.
Microservices architectures favor these tools because they enable a decentralized approach in which the endpoints that produce and consume messages are smart, but the pipe between the endpoints is dumb.
Despite using “dumb pipes” microservices can still implement essential messaging primitives without the need for a centralized service bus. Instead, microservices should make use of the broad ecosystem of frameworks that exist as dumb pipes for both request-response and observer communications.
The pipe in between is just a dumb network protocol such as HTTP. Backing services – Dumb pipes allow a background microservice to be attached to another microservice in the same way that you attach a database. Concurrency – A properly designed communication pipeline between microservices allows multiple microservices to work concurrently.
I didn’t read the article, so I can only speculate what he can mean exactly, but as he gives ESB as an example against microservices and ZeroMQ as an example for micro services I hope my speculation will be pretty exact:
One of the ideas of Unix (and Linux) is to build small independent applications and connect them via pipes. The probably most common set of two command which I’m using is ps and greplike this: ps aux | grep PROCESS_NAME - here you can see a dumb pipe which only forwards the output of ps to stdin of grep.
Other messaging systems like ZeroMQ work similarly, although they can have a little bit more complexity like round-robin distribution and reliable delivery. Erlang as a language is built on top of small smart endpoints sending messages between each other. The advantages here are obvious and also mentioned in the article, small applications are easier to maintain, decoupling makes it easier to scale.
On the other hand of Microservices are most commonly big enterprise applications, like the mentioned Enterprise Service Bus. I didn’t really work with those enough to give you a specific example, but generally those busses contain a lot of functionality which is either included via scripts or configuration. Such functionality mostly includes a configureable Workflow with advanced routing and can even transform the messages, so different endpoints can handle them.
An example could be - if you want the perform some advance action in a system, for instance change the requirements in an already running project, this could start a workflow, where the ESB would send out automatically different notifications to different actors around those changed requirements and wait for 1 or more of those actors to confirm before this change would be applied. Which would be basically the opposite - dumb endpoints (which just send/receive the data to/from the bus) and a very smart pipe (the bus, which can be configured or scripted to handle all possible enterprise scenarios).
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.
Basically the logic has to be implemented somewhere - either in the big ESB, or in the endpoints. The idea of microservices is to put it into the endpoints rather than into the bus and have a similar philosophy as unix applications.
64
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
