Am 20.01.2015 um 11:14 schrieb Lukas Krejci
<lkrejci(a)redhat.com>:
In that scenario, you will rarely encounter usecases where no
communication
between the components is needed. Fabric1 have zookeeper for similar purpose,
kubernetes have etcd similarly, too.
Aren't zookeeper and etcd. distributed configuration databases and not meant to
replace a communication bus? My understanding is that you do not want to
push incoming metrics in to ZK to later pull them off by other components like alerts.
ZK and etcd are afaiu registries, where a component can register itself and its
services and other components can look them up.
the bus. Any change in the component API (or behavior!) would have to
be
reflected in the glue, too. The glue would become the bottleneck or would be
massively harder to deploy in a distributed manner.
Yes about the former, not sure I understand the latter. With Java method
calls you also need to refactor all clients when a method signature changes.
With (REST) APIs you can offer multiple api versions in parallel on the receiver
side (through content negotiation) and still support old client versions while
in parallel offering new and enhanced services for newer client versions.