Comment by agentgt | Hacker News Reader

Comment by agentgt | Hacker News Reader

More and more I see toolkits basically turning microservice into a message queue system. More and more intelligent behavior is needed at the endpoints that its starting to leak into the pipes.

Often times the behavior of the endpoints (e.g. discovery, reconnecting, timeout, etc) is so critical that you need that in all clients which totally defeats the "decoupling" of microservices [1] (ie any language or technology can participate). That is extremely complicated endpoint logic requires shared components (see referenced article).

You could get all of the behavior by having a semi smart broker like RabbitMQ with out having an extremly complicated endpoints... but thats not microservice.. its evil old enterprise single point of failure.

Perhaps I'm biased, old school or just so jaded of hearing "microservice" but I really think many companies particularly young startups could get more work done with an intelligent pipe ie message broker over fairly complicated to setup microservies and duplicated intelligent endpoint logic.

TL;DR semi-smart pipes are looking better and better these days.

[1]: http://www.microservices.com/ben-christensen-do-not-build-a-...

Your observation about clients requiring more and more logic (e.g. discovery, reconnecting, timeout, etc) is spot on. It is a pretty big overhead and teams that are building an architecture based on micro-services should be prepared to pay that cost.

I am not sure why people choose such an architecture, but for me the biggest reason to do this is to be able to run it on platforms like Mesos, Kubernetes, Nomad etc. Once you've aligned your system with such a platform you get plenty of benefits(improved workflow, reliability, fault tolerance, cloud mobility). But the price is pretty big.

The good part is that good tooling is becoming more widespread and open source projects like this make it easier for people to start up.

I want to second the fact that a microservice architecture is great because of the ease of deployments (but only after the initial overhead!). I can attest first-hand to the large overhead that comes with creating something from scratch with micro-services - we are still battling with Mesos/Marathon, and recently found Mantl (https://mantl.io/) which has been a huge help.

You may be interested in linkerd (https://linkerd.io) -- we built it specifically to address the complexity of proper connection management at scale (service discovery, timeouts, loadbalancing, retry policies). Extends to routing and instrumentation as well.

The goal is to offload that logic out of your application.

> Often times the behavior of the endpoints (e.g. discovery, reconnecting, timeout, etc) is so critical that you need that in all clients

But isn't it? Presuming you're writing RESTful things, and emitting the right error codes for the right reasons, any RFC-compliant HTTP client (as there should exist at least one of in every language) should automatically be capable of doing all those things.

IMHO, though, startups would do much better writing "component" libraries that force the same decoupling as microservices, without paying the cost of creating a distributed system from the beginning. Then, later, they can lift a "component" out and define another version of its 'client' library which is RPC rather than local. (In other words, follow the idiomatic approach to designing Erlang applications, and you'll scale nicely.)

Very good presentation, thanks for sharing.

One more reason to start reading that book I bought a few months ago!!

Reply on news.ycombinator.com