Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0

From: "Thomas Segismont" <tsegismo(a)redhat.com&gt; To: hawkular-dev(a)lists.jboss.org Sent: Tuesday, November 10, 2015 3:06:33 PM Subject: Re: [Hawkular-dev] Hawkular Metrics + Hawkular Alerts - Phase 0 Le 10/11/2015 18:09, John Sanda a écrit : >> After this long introduction, there are three main reasons the current >> solution needs improvements: >> > >> >1) Addressability -> the current solution does not work in the >> >distributed environment because there is no clear way how to access the >> >public API of the services deployed. Let's say the installation spread >> >across 5 containers. How can I make a public API call from a Metrics >> >instance to an Alerts instance. There is no directory to know where the >> >Alerts or Metrics instances are deployed. > Addressability is provided by the messaging system. There is no need for a > directory. You just to need to communicate with the messaging > server/broker. Beyond that there are a lot of features around > addressability and routing such as message selectors, message grouping, > hierarchical topics, and more. +1 > >> >2) Load distribution -> there is no clear way on how the load >> >distribution works or who is responsible for it. > Again, this is largely handled by the messaging system. Multiple consumers > take messages from a queue where each message corresponds to work to be > done. > Right, load distribution is a feature of the messaging system. As for HTTP load balancing, there is hardware and software dedicated to this, I would avoid building an HTTP load balancer into the project. >> >3) Availability of the existing public API -> There is no reason to >> >implement a new API just for the purposes of communicating between the >> >components. Given that we strive for this micro-service architecture, >> >the one and single public API should be the main method for >> >communicating between components for request-reply. > I do not think it is a given that we strive for a micro-service > architecture. It might make more sense in an OpenShift environment, but I > don’t think it necessarily does in general. > > >> >We might need to extend what we have but the public API should be front >> >and centre. So if we use JMS or HTTP (or both, or UDP, or any other >> >method), the public API interface should be available over all the >> >channels. Sure there might be difference on how to make a request in JMS >> >vs HTTP (one with temporary queues, and the other with direct http >> >connections) but the functionality should be identical. > I don’t know that I agree with this. Suppose we decide to offer an API for > inserting metric data over UDP to support really high throughput > situations. Are you suggesting for example that the operations we provide > via REST for reading metric data should also be available via the UDP API? > And since the motivation for a UDP API is performance/throughput, we might > event want to a more compact request format than JSON. > > Lastly and most importantly, if you want push for an alternative > communication mechanism between components in H-Metrics and H-Alerts, then > you push for the same across all of Hawkular because it does not make to > have to support two different mechanisms. The public API (JSON over HTTP) is how the users must interact with the Hawkular platform. It is the unique entry point for the users. It's has been agreed during the project inception to make Hawkular components talk to each other via the bus. It is not a trivial change to break this assumption: everything the bus provides (see above) will need to be re-implemented. That is why I am opposed to the change, unless it is proven that it is a limitation. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev