Microservices: What are smart endpoints and dumb pipes?

Question

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.

Loreenlorelei

Watch this: youtube.com/watch?v=2yko4TbC8cI – Rwanda

Answer 1

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.

Monochasium

Nice one on dumb pipes, thanks! JMS broker turns out also is dumb? 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? – Loreenlorelei

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 – Monochasium

Erlang is a worthy addition, but because you didn't read the article much of this answer is paraphrases the article. The first two paragraphs article specifically describes the Unix philosophy ("Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense") for pipes and gives ESB as a counter-example ("... stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB)"). – Emotionalize

Answer 2

I think Martin Fowlers’ article falls woefully short by mischaracterising the ‘ESB’ concept. This mischaracterisation is widespread. How many time have you seen a diagram that represents the ‘bus’ as a pipe down which messages flow? I’ve certainly lost count and it makes me wince every time. A ‘bus’ is not a pipe. It is a mechanism for making ‘enabling services’ readily accessible across a distributed, service-orientated environment. The classic analogy is a bus bar in a factory. Although electricity flows through the bus bar, that’s not why it a ‘bus’. It is a ‘bus’ because it runs the full length of the manufacturing floor. Any machinery (service implementations) can tap easily into the bar to get power (from a generating service), wherever that machinery happens to be located. The bus is a ubiquitous enabler which supports flexibility and change over time.

The only things that live on a service bus are services, and as a general principle they are best implemented as microservices wherever possible or desirable. The mantra of ‘smart endpoints, dumb pipes’ goes back way before the advent of microservices. I first heard it from a member of the Microsoft BizTalk team many years ago in public debate with a leading advocate of ESB. The ESB guy was advocating the desirability of very fine-grained stand-alone transformation services (microservices) rather than the typical BizTalk approach where transformations are applied at endpoints (smart endpoints). The ESB guy was criticising BizTalk, claiming that it was ‘monolithic’ and therefore could not be used to implement such fine-grained, independently deployable services. The BizTalk guy pointed out that he was factually wrong (as demonstrated subsequently in the BizTalk ESB toolkit), but that the main point was the general desirability of doing transformation at the message endpoints (from an integration perspective) rather than downstream in some intermediate service invoked in the interchange (conceptually, further down the ‘pipe’).

This was a grown-up debate between serious practitioners. I agreed with the BizTalk guy on this point – smart endpoints, dumb pipes. Ironically, the ESB guy was effectively promoting a microservice approach in an ESB context. To me, it’s a great example of how the microservice mantra, like any other philosophy, can be taken a step too far.

Polygraph

If i'm following you on this, how does one ensure a pipeline in an ESB environment then if the ESB is itself not the pipeline? – Capsulize

This seems like a defence of ESB (when the article isn't attacking ESB) rather than answering the actual question of what are smart endpoints / dumb pipes – Emotionalize

The article is only saying that an ESB is not a dumb pipe, not criticising the ESB in any way. "we've seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.". Perhaps you can say that he doesn't characterise the ESB correctly, but I think it's fair that an ESB is clearly not a dumb pipe – Emotionalize

This post is a response to the Martin Fowler article. It does not really answer the question posed here, which is basically this: What are smart endpoints and dumb pipes?. Or if it does, it is so convoluted that it isn't clear and hence a pretty bad answer. – Imposition

Answer 3

Components in a system use "pipes" (HTTP/S, queues, etc...) to communicate with each other. Usually these pipes flow through an ESB (Enterprise Service Bus) which does a number of things to the messages being passed between components.

It might do:

• Security checks
• Routing
• Business flow / validation
• Transformation

Once it's completed these tasks the message will be forwarded onto the "endpoint" component. This is an example of "smart pipes" as lots of logic and processing reside inside the ESB (part of the system of "pipes"). The endpoints can then be "dumb" as the ESB has done all the work.

"Smart endpoints and dumb pipes" advocates the opposite scenario. That the lanes of communication should be stripped of business processing and logic and should literally only distribute messages between components. It's then the components themselves that do processing / logic / validation etc... on those messages.

Kendre

Answer 4

It is a very general questions. I will try to keep it that way

Smart endpoints

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.

Dumb pipelines

Dumb pipelines means any communication means where no further actions e.g validations are taken place, it simply carries the data across that particular channel and it may also be replaceable if need be.

Rampage

Answer 5

According to Martin Fowler: "The second approach in common use is messaging over a lightweight message bus. The infrastructure chosen is typically dumb (dumb as in acts as a message router only)".

The rationale for using smart end points is implied by: "The key property of a component is the notion of independent replacement and upgradeability - which implies we look for points where we can imagine rewriting a component without affecting its collaborators.".

To support the latter a micro service needs to be tolerant to its consumer. E.g. adding a mandatory input argument later on would break the interface, and therefore should be avoided. Instead one should use compensation strategies, like defaults, or support some sort of internal "routing" so that the microservice is still able to give a valid response. This is a kind-of smart "end-point".

Glossology

Answer 6

Dumb pipes simply means point to point connections. The end points do all the work and any complexity is taken out of the mechanism connecting them. I think people talk about ESBs in this conversation because dumb pipes (point to point connections) are a terrible idea in an enterprise setting (and in many others). ESBs are not 'dumb pipes'. ESBs are pretty much a good definition of very intelligent pipes. And they help get control of the incredibly hairy mess that point to point connections create whenever you have more than a few services that need to talk to each other.

WSO2 has just created a set of good webinars on microservices, and they talk about this concept. But even they shy away from using the concept of dumb pipes.

Now dumb pipes can make sense if the services are used purely in an ad hoc basis but not when trying to manage complex enterprise systems. Setting up multiple network connections for every service is the least of it.

Gutow

Dumb pipes doesn't mean P2P connections. Martin Fowler's microservices article says "The infrastructure chosen is typically dumb (dumb as in acts as a message router only)". It just means that routing is the only function the pipes should be doing: keep business logic, transformation, etc. out. Having said that, it doesn't always make sense to push all this functionality into the endpoints, particularly in enterprise integration scenarios, as not all endpoints have equal capabilities. – Allister