Eines der Versprechen der Cloudjünger lautet seit dem ersten Aufkommen des Konzepts, dass IT für Unternehmen billiger wird. Das klingt zunächst logisch, denn der Betrieb von IT-Infrastruktur, also Rechenzentren und den Anwendungen in diesen, ist aufwendig, teuer und bedingt spezifisch ausgebildetes Personal. Laut AWS & Co. alles kein Problem mehr mit der Cloud, könne der Cloudanbieter doch zentralisiert seine Kräfte bündeln und die jeweilige Dienstleistung günstiger anbieten. Dass es mit Ersparnissen beim Umzug in die Cloud aber oft nicht weit her ist, erfahren viele Administratoren am eigenen Leib schmerzhaft immer dann, wenn die Monatsrechnung ins Haus flattert.

Das US-Unternehmen AppScale will dem ein Ende bereiten und verspricht der Welt nicht weniger als die "Demokratisierung des Cloudansatzes". Mit viel verbalem Getöse bewirbt der Anbieter sein gleichnamiges Produkt, dessen Hauptziel darin besteht, Firmen den Cloudbetrieb zu ermöglichen, ohne dabei schwankende Kosten bei AWS in Kauf nehmen zu müssen. Wer sich schon einmal mit der Implementierung von Cloudansätzen befasst hat, merkt: Das ist ein dickes Brett, das App-Scale da mit Leichtigkeit zu bohren vorgibt. Grund genug, sich das Ganze genauer anzuschauen – ist AppScale eine realistische Alternative zu AWS und Konsorten?

Dieser Frage gehen wir auf Basis von fünf Kriterien auf den Grund. Zunächst muss sich AppScale bei der Grundfunktionalität beweisen. Was bekommt der Admin überhaupt und wie hoch ist der Aufwand, den er noch selbst betreiben muss? Das zweite Kriterium beschäftigt sich mit der Skalierbarkeit des Produkts. Ein On-Premises-Aufbau muss wie jede andere Cloudumgebung in der Lage sein, sinnvoll zu wachsen. Außerdem schauen wir uns an, welche Verwaltungswerkzeuge für die Administration zur Verfügung stehen. Das vierte Kriterium befasst sich mit der tatsächlichen Kompatibilität zu AWS. Laut Anbieter erreicht sein Produkt "bis zu 80 Prozent Kompatibilität". Stimmt das? Im fünften und letzten Teil des Tests geht es schließlich um die Themen Sicherheit und Compliance, ohne die eine Cloudplattform kaum sinnvoll zu betreiben ist.

Unternehmen, die sich eine private Cloud ins Rechenzentrum zimmern, sind in den meisten Fällen gar nicht darauf aus, sämtliche Workloads auf der eigenen Infrastruktur zu betreiben. Vielmehr geht es meist darum, eine private Cloud für genau jene Daten zu betreiben, die die Infrastruktur des Unternehmens nicht verlassen dürfen – hybride Aufbauten sind die Folge. AppScale kann grundsätzlich beide Einsatzszenarien abbilden.

Allerdings dürfen Systemverwalter hier nicht einen Katalog von 400 Anwendungen erwarten, die AppScale nachgebaut hat, um dem Original AWS das Wasser abzugraben. Das komplette Universum der AWS-Anwendungen dürfte für die allermeisten Unternehmen aber ohnehin höchstens von theoretischem Interesse sein. Denn kaum eine Organisation braucht etwa die Wahl zwischen fünf SQL-Datenbanken, die sich nur in Nuancen unterscheiden. Und eine global skalierbare Datenbank wie AuroraDB, die AWS selbst für die Kunden betreibt, benötigen die meisten Firmen ebenso wenig. Folglich versucht AppScale erst gar nicht, in dieses Rennen einzusteigen.

Stattdessen gilt das Pareto-Prinzip: App­Scale hat sich der Maxime verschrieben, mit 20 Prozent der implementierten Funktionalität 80 Prozent der Ansprüche der Anwender befriedigen zu können. Und so wundern die Dienste nicht, die der Anbieter von AWS übernimmt und entsprechend nachahmt: Neben dem unvermeidlichen EC2 für IaaS-Instanzen gehört dazu S3 für Objektspeicher, EBS für blockbasierten virtuellen Speicher, die Authentifizierungs- und Autorisierungskomponente IAM sowie der Dienst für elastische Loadbalancer. Ferner gesellen sich zum Gespann noch ein Nachbau des Auto-Scaling-Dienstes, CloudFormation für Orchestrierung auf Basis echter AWS-Templates sowie ein Nachbau von STS, dem "Security Token Service", der temporäre Sicherheitstokens für den Zugriff auf einen Account ausstellt.

Zack, fertig: Andere beliebte AWS-Dienste wie etwa die verschiedenen DBaaS-Features gehören erst gar nicht zum AppScale-Angebot. Hier ist eher der Einfallsreichtum des Administrators gefragt, denn DBaaS ist ja längst nicht mehr nur über eine Plattform abzuwickeln. Sämtliche Distributionen für Kubernetes etwa bieten mittlerweile vorgefertigte Container, die eine Datenbank schnell und komfortabel starten. Mancher Kritiker behauptet gar, dass Dienste wie DBaaS eher auf diese Schicht gehören, weil sie dann von den Vorteilen der Container-Orchestrierung noch zusätzlich profitieren. Vor diesem Hintergrund ist also zu verzeihen, dass AppScale die entsprechende AWS-Komponente nicht nachgebaut hat.

Insgesamt gilt, dass AppScale durch Art und Umfang der eigenen Software als Firma viel größer erscheint, als es tatsächlich der Fall ist. Damit geht der Anbieter aber offen und transparent um und weist schon auf der eigenen Website darauf hin, dass das Produkt auf verschiedenen freien Fundamenten fußt.

Wer sich im Open-Source-Umfeld des Cloud Computings etwas auskennt, trifft hier also auf einige alte Bekannte. Die gesamte Cloudsoftware beispielsweise beruht auf Eucalyptus. Dies war einst ein Hauptkonkurrent von OpenStack; zwischenzeitlich hat AppScale – dem etliche der Eucalyptus-Gründungsmitglieder angehören – den Quelltext der Software vom Original abgespalten und auf die Entwicklung des eigenen Produktes hin getrimmt. Zuvor hatte Eucalyptus nach dem Kauf durch HP mehrmals den Eigentümer gewechselt und war letztlich eingeschlafen.

Auch in Sachen Storage begegnet dem passionierten Admin darüber hinaus kein Unbekannter, denn integraler Bestandteil von AppScale ist Ceph. Dieses implementiert sowohl den skalierbaren Blockspeicher für VMs als auch die S3-kompatible Schnittstelle für den Objektspeicher.

Der Zugriff erfolgt bei AppScale wahlweise über eine grafische Oberfläche oder direkt über die APIs der Plattform. Der API-basierte Ansatz erfreut sich größerer Beliebtheit, weil er die Nutzung von Werkzeugen wie Terraform ermöglicht oder zumindest die Orchestrierung mit CloudFormation erlaubt. Vorhandene Werkzeuge für den Einsatz mit AWS lassen sich im Regelfall auch mit AppScale verwenden, falls sie denn überhaupt die Möglichkeit bieten, eine andere Ziel-URL als jene offiziellen AWS-URLs anzugeben. Die grafische Oberfläche präsentiert sich übersichtlich und im Grunde typisch; einzelne Punkte im Menü erlauben direkten Zugriff auf Funktionen wie das Erstellen virtueller Netze, virtueller Blockspeichergeräte oder neuer Instanzen (Bild 2).

Summa summarum gibt es also bei der Grundfunktionalität von AppScale nichts zu meckern. Alle basalen Funktionen einer Cloudumgebung implementiert der Dienst, hinzu kommen ein paar wenige essenzielle AWS-Dienste. Kopfzerbrechen dürfte dem Administrator allenfalls der Aufwand bereiten, der mit der Inbetriebnahme einer AppScale-Cloud verbunden ist. Das ist aber nicht Anbieter-typisch, sondern impliziter Faktor beim Betrieb privater Clouds, den manche Unternehmen allerdings unterschätzen: Wer eine eigene Cloud bereitstellen möchte, muss diese installieren und betreiben. Und damit gehen alle lästigen Aufgaben einher, die mit dem Betrieb physischer Infrastruktur verbunden sind.

Verglichen mit dem Ansatz, einfach in AWS ein paar Dienste auszurollen, ist die benötigte Vorlaufzeit und der zu investierende Aufwand bei AppScale also gigantisch und vergleichbar etwa mit jenem bei OpenStack. Daran ändert nichts, dass AppScale dem Systemverwalter die Arbeit durch verschiedene Werkzeuge, Skripte und fertige Designvorlagen erleichtern will. Wer Infrastruktur betreibt, bindet sich erheblich mehr Aufwand ans Bein, als es bei der Nutzung virtueller Ressourcen in der Cloud der Fall wäre – da beißt die Maus leider keinen Faden ab.

Jede Cloudumgebung, egal ob privat oder öffentlich, ist ab Werk darauf ausgelegt, zu wachsen. Wer keine mitwachsende Plattform braucht, ist beim Cloud Computing schlicht falsch und sollte sich eher mit klassischen Virtualisierungstools wie VMware oder Proxmox beschäftigen – denn ansonsten stehen Aufwand und Ertrag in keinem sinnvollen Verhältnis mehr zueinander.

Damit eine Cloud wachsen kann, muss die unterliegende Software dazu aber freilich in der Lage sein. Eucalyptus patzt hier nicht, was nicht weiter verwundert. Denn bereits in seiner Produktdokumentation weist der Hersteller auf die Möglichkeit eines "One-Node-Deployments" hin. Das ist eine Installation, bei der sämtliche Dienste auf einem einzelnen System laufen. Für den produktiven Einsatz eignet sich so eine Architektur zwar nicht, sehr wohl aber für erste Tests und Evaluierungen.

Die zwei Einsatzszenarien für den produktiven Einsatz sieht AppScale einerseits in einem typischen "Hyperconverged Setup", bei dem Ceph sowie die Clouddienste und die VMs auf denselben Hosts laufen, sowie in einem "Massive Scale Out"-System, bei dem die einzelnen Dienstarten der Cloud auf separate Server verteilt sind. Zwischen den Konzepten ist ein fliegender Wechsel möglich; der Beginn mit einem Hyperconverged-Ansatz funktioniert also auch, wenn der Plan ist, diesen später in eine Scale-Out-Umgebung zu erweitern.

Hinsichtlich der faktischen Grenzen der Skalierbarkeit erteilt der Anbieter keine genaue Auskunft, und das wäre wohl auch kompliziert. Denn die Frage, wie viele Knoten eine Cloud verträgt, ist komplex. Eucalyptus beherrscht die Unterteilung in separate Zonen und Regionen. Je nach Implementierungsvariante können Zonen wie Regionen eigene Dienste der Cloud selbst betreiben, sodass es etwa mehrere Storages gibt, die voneinander weitgehend unabhängig sind. Dieser Ansatz, auch "Federation" genannt, kommt besonders dort zum Einsatz, wo geographisch stark verteilte Infrastrukturen notwendig sind.

Doch ist es eher unwahrscheinlich, dass viele Unternehmen in diese Skalierbarkeitsregionen vordringen. Für die durchschnittlichen Anforderungen kleinerer privater Cloudumgebungen ist AppScale aber jedenfalls bestens gerüstet. Hier besteht also in keinem denkbaren Szenario ein Problem: mehrere hundert Compute-Knoten gehen immer.

Wie erwähnt geht der Betrieb einer eigenen Cloud stets mit viel Aufwand einher. AppScale bildet von dieser Regel keine Ausnahme. Doch liefert der Anbieter mit seinem Produkt eine ganze Kiste voller Werkzeuge, die Setup, Betrieb und Wartung der Plattform leichter von der Hand gehen lassen. Dazu gehört zum Beispiel eine Sammlung von Rollen für Ansible, mit denen sich die zu AppScale gehörenden Dienste in beliebigen Zielumgebungen schnell auf die Systeme bringen lassen.

Was dabei auffällt: die AppScale-Entwickler erfinden das Rad zumindest in mancherlei Hinsicht neu. So gehören zu den Ansible-Rollen für AppScale beispielsweise komplette Rollen für das Deployment aller zu Ceph gehörenden Dienste. Die gibt es indes aber auch schon von Red Hat – mal ganz davon abgesehen, dass Red Hat mittlerweile zum Deployment in Container-Form übergegangen ist und dafür das Ceph-eigene Werkzeug cephadm nutzt.

Nicht ganz klar wird an dieser Stelle, ob die eigenen AppScale-Rollen ein Relikt aus der Vergangenheit sind oder technisch wirklich notwendig. Sicher sind sie aber aus Sicht des Anbieters selbst ein erheblicher Mehraufwand, wenn es um die Themen Wartung und Entwicklung geht. Im Gegenzug sind die zu AppScale gehörenden Ansible-Rollen alle bestens aufeinander abgestimmt. Der Admin darf also annehmen, dass er bei Benutzung eben dieser Rollen letztlich eine funktionale AppScale-Plattform bekommt.

Zusätzlich zu den Ansible-Rollen findet sich im Git-Verzeichnis des Anbieters eine CLI-Werkzeugsammlung namens "app-scale-tools". Die soll das Starten und das Verwalten der AppScale-Dienste leichter machen. Der Blick ins GitHub-Verzeichnis verheißt allerdings wenig Gutes, denn die letzte Änderung am Quelltext fand im Januar 2020 statt, also schon vor über drei Jahren.

Andererseits muss das nicht zwingend ein KO-Kriterium sein. Denn wer sich für AppScale entscheidet, dürfte den Aufbau kaum vollständig auf eigene Faust durchziehen, sondern sich Hilfe beim Anbieter der Software holen. Solange die AppScale-Tools also in ihrem aktuellen Zustand zum Rest der Umgebung passen, sollten sie funktionieren. Zumindest in unserem Test war das der Fall.

Zu unterscheiden ist an dieser Stelle noch zwischen der Administration der Clouddienste durch Systemverwalter und die Nutzung der Dienste durch Endkunden. Letztere greifen wie bereits beschrieben eher über das UI des Diensts oder CLI-Werkzeuge auf AppScale zu, und letztlich immer so, dass die Anfragen bei den API-Diensten der Umgebung landen.

Unser viertes Kriterium im Test, die Kompatibilität zu AWS, ist ausgesprochen schwierig zu bewerten. Denn mit Nachbauten ist es immer so eine Sache: Offiziell sind die APIs von AWS nicht frei und damit auch nicht öffentlich dokumentiert. Das Problem ist bekannt von den diversen Nachbauten für AWS S3, die am Markt seit Jahren existieren. Sie alle eint, dass sie fast ausnahmslos auf Reverse Engineering fußen. Entwickler traktieren also die offiziellen APIs des Anbieters auf Grundlagen dessen veröffentlichter Entwickler-Dokus mit Befehlen, beobachten das AWS-Verhalten und versuchen, dieses dann in ihrer eigenen Software nachzubauen.

Dabei entsteht naturgemäß eine Art Grauzone von Befehlen, die in AWS zwar funktionieren, in den Nachbauten aber nicht. Hiervon bildet auch AWS EC2 oder EBS keine Ausnahme, wie sie in AppScale implementiert sind. Immer gilt: Der Klon folgt dem Best-Effort-Prinzip und hat nie den offiziellen Segen von AWS. Was damit meistens hinten herunterfällt sind einerseits besonders neue Features und andererseits Funktionen, die nur wenige Anwender nachfragen und deren Nachbau aus Sicht des Softwareanbieters dadurch kommerziell nur bedingt Sinn ergibt.

Trotzdem brüstet AppScale sich damit, für das eigene Produkt über die implementierten Dienste hinweg eine API-Kompatibilität von über 80 Prozent zu erreichen. Weil hier wieder das Pareto-Prinzip greift, heißt das im Klartext: Die allermeisten Standardfunktionen wie das Anlegen virtueller Netze, das Starten von virtuellen Instanzen oder das Zuweisen virtueller Blockspeichergeräte funktionieren einwandfrei. Exotischere Funktionen, die besonders in speziell für das "echte" AWS entwickelten Programmen vorkommen, schlagen im ungünstigsten Fall aber mit einer entsprechenden Meldung fehl.

Im Rahmen unseres Tests war ein solches Szenario künstlich aber nicht herbeizuführen. Selbst komplexere Templates nach dem AWS-CloudFormation-Standard hat der AppScale-Nachbau zuverlässig und letztlich erfolgreich interpretiert. Ähnlich verhielt es sich mit API-Anfragen über diverse Tools für die Kommandozeile, die ebenfalls zum gewünschten Ergebnis geführt haben. Die 80-Prozent-Kompatibilität – streng genommen geht AppScale hier ja sogar weit über das Pareto-Prinzip hinaus – ist also keinesfalls an den Haaren herbeigezogen. Stattdessen liefert App-Scale hier solide Ingenieursarbeit.

Fast schon ein Evergreen in unseren Softwaretests sind die Themen Security und Compliance. Denn kein Unternehmen kann es sich heute leisten, eine Plattform zu betreiben, die offen wie ein Scheunentor ist und beispielsweise nicht an zentrale Benutzerverzeichnisse wie LDAP anschließbar. Auch hier enttäuschte App­Scale im Test nicht. Einerseits enthalten die Ansible-Playbooks für das Deployment der Software nämlich etliche Vorkehrungen, die den Betrieb veralteter Software verhindern sollen. Wenn der Anbieter selbst also Sicherheitsupdates veröffentlicht, lassen sich diese dank der Grundeigenschaft von Ansible mit relativ wenig Aufwand ausrollen. Das gilt natürlich nur, wenn der Admin seine Ansible-Umgebung grundsätzlich im Griff hat und funktional hält.

Darüber hinaus erbt AppScale sämtliche Compliance-Eigenschaften von Eucalyptus. Und die können sich sehen lassen: Die Integration mit einem bestehenden LDAP-Verzeichnis sowie das Mapping bestehender Rollen auf die cloudeigene RBAC-Struktur gehören für Eucalyptus und somit für AppScale etwa zu den leichteren Übungen. Insgesamt erfüllt App-Scale die Anforderungen in Sachen Security und Compliance der Gegenwart ohne Schwierigkeiten. Weil für Sicherheitsupdates obendrein gesorgt ist, lässt sich dieses Testkriterium schnell abhandeln.

AppScale präsentiert sich als potenzielle Alternative zum mitunter teuren Betrieb sämtlicher IaaS-Dienste auf AWS. Zwar ist auch das Vorhalten eigener Infrastruktur vor Ort mit erheblichem Aufwand verbunden, doch greift hier das Prinzip der Economy of Scale: Ist die anstehende Arbeit einmal ordentlich erledigt und die Automation am Werk, profitiert ein Unternehmen fortwährend davon. Qualitativ gibt sich der Kern des Produkts, Eucalyptus, keine Blöße. Und in Sachen AWS-Kompatibilität liefert der Anbieter, was er verspricht. Schlaue Werkzeuge, die beim Deployment und beim Betrieb der Umgebung helfen, runden das Angebot ab. Insgesamt gilt, dass Administratoren AppScale auf der Uhr haben sollten, wenn sie den Betrieb einer eigenen Umgebung in Erwägung ziehen und Open-Stack nicht als einzigen Probanden evaluieren wollen.