Hacker News Reader

Comment by rshriram | Hacker News Reader

It depends on how you view it. Baking everything into the application logic works if you have a homogeneous stack. When you start going down the polyglot route, with 5-6 language runtimes, multiple databases, it becomes really really hard to maintain all the communication logic (discovery, load balancing, resilience) in the app code.

Take a look at AirBnB's smartstack, Yelp, Lyft's Envoy mesh. These are all polyglot applications, where the communication aspects are abstracted out into sidecars.

View on HN

Maybe it depends on the size / complexity of the services. In the 'serverless' trend, such a middleware makes more sense. But essentially, moving too much logic into a middleware may support bad, lazy design decisions that make the middleware a single point of failure - like ESBs.

The middleware in this case doesn't work like an ESB in the sense that all connections are point-to-point, intermediated by a service discovery mechanism. So you're not putting all your L7 traffic onto a big bus.

I'm a big fan of buses or perhaps more accurately I guess semi intelligent pipes with semi intelligent endpoints.

I have used RabbitMQ (and Kafka at times) for large portion of my career and anytime I tell people this the bring up the single point of failure.

The single point of failure arguments is getting really old and is fairly baseless particularly if your storage (e.g. RDBMS) or network (single zone or even multi zone load balancer) is also not a single point of failure.

So to avoid this red herring of a problem for many who really don't need to solve that problem they create massively complicated endpoints.

This endpoint code is proprietary and often has to be deployed at the same time and creates fairly tight coupling. The Netflix Hystrix creator (Ben Christensen) discussed this issue at length here: https://www.microservices.com/talks/dont-build-a-distributed... (its also ironic that he built Hystrix and various dependencies which are sort of the antithesis of this... I guess 20/20 hindsight).

There are pros and cons and its not always "lazy design decision".

> The single point of failure arguments is getting really old and is fairly baseless particularly if your storage (e.g. RDBMS) or network (single zone or even multi zone load balancer) is also not a single point of failure.

That sounds like multiple single points of failures, which just means you have more work to do, not that you can throw your hands in the air and say "welp".

I agree. Essentially it boils down to whether communication protocols and formats are open enough and replaceable with reasonable effort.

But with single point of failure, I don't mean outages. I mean, is it open and transparent enough towards your endpoints, that you can easily replace and / or fix things. Vendors go out of business or even a larger issue: your business changes.

Just pointing it out, but Envoy is a key piece of Istio (as I understand it).

Reply on news.ycombinator.com