Das beschriebene Failover-Modell kommt mit ein paar unangenehmen Nachteilen daher, die dem Image solcher Installationen schaden. Einerseits stehen sie im Verdacht, ökologisch problematisch zu sein, weil einer der Knoten immer läuft, Energie verbraucht und Wärme produziert, ohne etwas Sinnvolles zu tun. Andererseits genießt die Usability der vielen Cluster-Manager, allen voran Pacemaker, keinen guten Ruf, obwohl sich das in der Vergangenheit oft genug als altes Vorurteil gegenüber Heartbeat 2 erwiesen hat, dem direkten Vorgänger von Pacemaker. Bleibt das Argument, dass Failover-Setups für manche Dienstarten nicht die beste Möglichkeit darstellen, um Hochverfügbarkeit zu erreichen. RESTful-Dienste, die auf HTTP oder HTTPS basieren, sind ein klassiches Beispiel.
REST-basierte Dienste waren im Admin-Magazin in letzter Zeit einige Male Gegenstand der Betrachtung. Im Kontext von Cloud-Computing-Lösungen erleben sie einen wahren Aufschwung. Denn immer mehr Hersteller von Anwendungen gehen dazu über, für die Kommunikation zwischen ihren Diensten und den Clients nicht ein eigenes On-Wire-Protokoll zu entwerfen, sondern stattdessen lieber das seit gefühlter Ewigkeit vorhandene HTTP-Protokoll zu nutzen. Dann braucht es "nur" noch eine definierte API, damit ein Client standardisiert auf einem Server URLs aufrufen kann, gegebenenfalls spezifische Header mitschickt und der Server weiß, was er tun soll – fertig ist das RESTful-Interface.
Gerade weil HTTP eines der erprobtesten Protokolle des Internets ist, haben sich über die Frage der Hochverfügbarkeit bereits vor längerer Zeit clevere Entwickler Gedanken gemacht. Die gängige Lösung, um Hochverfügbarkeit und zugleich auch Scale-Out bei HTTP-Diensten in den Griff zu kriegen, sind Loadbalancer.