One issue I have with this and similar architectures is that it often sticks an HTTP stack where it is not needed. The HTTP request/response paradigm does add a useful process management architecture, but it seems like you could implement that without the HTTP component, although then you would also need to figure out the inter-operability side of things if you wanted that flexibility to plugin into stuff. Which may lead you to wanting a protocol for making things easier.
Okay, I guess I do understand why the HTTP stack is wanted, but with HTTP/2 around the corner, it might be time to think about whether it makes sense to create a more primitive version of HTTP focused on non-networked or locally-networked applications
HTTP is great because it lets you use the same API in the browser. Given the right services, you can build your front end UI entirely based on your service APIs, no other back end needed.
If services used ZeroMQ or Thrift or similar, a browser front end would require an adapter layer. If you have 10+ services, that's a lot of redundant code.
Plus: You're leveraging a lot of great infrastructure. With HTTP APIs you can just curl into your APIs. Or load balance and proxy them with HAProxy, Nginx, Varnish etc.
Request/Reply pattern makes a poor choice for communication between services - it increases coupling. It doesn't matter much if it comes with HTTP or any other flavour.
I feel somewhat petty for this complaint as the content is good, but I found that link almost unreadable. It felt like someone awkwardly shouting random words in sentence, having every other word wrapped in <strong></strong>.
If anyone else finds this, here's a quick thing to paste into the developer console to make it more readable (the content is worth it):
The post talks about synchronous communication increasing temporal coupling.
There's nothing in sending a request and getting a response that's increasing coupling in a traditional sense, and often there's no much of an alternative anyway, if you want donuts, you'll have to request donuts, and then receive donuts.
While I dislike shoving HTTP everywhere for many reasons (reminds me of XML abuse), HTTP is not synchronous, nor asynchronous. It's a protocol sent over a socket. Synchronicity is not the domain of HTTP at all. It's up to the application how it does it.
Additionally, the response can always be a blank acknowledgement of the received request. There are very few cases where you just want to go forward blindly without even receiving an ACK about your request at some level (or alternatively, an error), because sometimes things fail.
There seems to be quite a lot of work around this, eg the various protobuf-like solutions as astandard message, and various things like zerovm as transports. They havent quite been put together into an equivalent, but they are lightweight enough that its not clear this is needed.
Okay, I guess I do understand why the HTTP stack is wanted, but with HTTP/2 around the corner, it might be time to think about whether it makes sense to create a more primitive version of HTTP focused on non-networked or locally-networked applications