4 ms·
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
by lifty 11y ago
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.
- spudfkc 11y agoI 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/ https://mantl.io/) which has been a huge help.
- williamallthing 11y agoYou may be interested in linkerd (https://linkerd.io 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.