© grafner / 123RF.com

Für viele Unternehmen mutiert die Public Cloud zum Albtraum: Vendor-Lock-in, immer neue Dienste und nicht zuletzt gesalzene Rechnungen zum Monatsende schlagen aufs Gemüt. Appscale verspricht eine private Cloud mit umfassender AWS-Kompatibilität als Ausweg.

An den Admin-Stammtischen und in den Kaffeeküchen der Republik hört man beim lockeren Plausch mit Administratorinnen und Administratoren momentan häufig eine bestimmte Geschichte: Anfangs sei das mit der Public Cloud und besonders mit AWS ja schön, gut und toll gewesen. Man war in der Lage, große Teile des eigenen IT-Geräteparks in die Cloud zu verlagern und schien viel Geld zu sparen, weil man keine eigene IT-Infrastruktur mehr betreiben musste. Inzwischen habe sich das Blatt allerdings gewendet: Weil der in der Cloud laufende Workload immer größer wurde, fielen die Rechnungen von AWS, die monatlich ins Haus flattern, mittlerweile geradezu horrend aus. Und weil nun das gesamte eigene Setup komplett auf AWS und seine diversen Dienste ausgerichtet sei, könne man auch keine Rolle rückwärts mehr vollführen.

Gleichzeitig hätten sich viele Versprechungen der Hyperscaler im Alltag als wenig bis gar nicht relevant herausgestellt: Dass man ein Webserver-Setup in kürzester Zeit von 10 auf 1000 Knoten skalieren könne, sei zwar cool, komme in der Realität aber praktisch nicht vor. Das gelte umso mehr, als viele Firmen ihre Anwendungen gar nicht so umgebaut hätten, um dieses Level an Skalierbarkeit nutzen zu können. Man bezahle also praktisch für eine Flexibilität, bei der von vorneherein feststeht, dass man sie kaum sinnvoll nutzen kann.

An diesem Punkt ist guter Rat teuer. Oder doch nicht? Appscale tritt als Suite für den Bau einer Private Cloud mit dem Versprechen an, zum AWS API-kompatibel zu sein, zumindest, was die wichtigsten Funktionen angeht. Gleichzeitig sei ein solches Setup leicht zu bauen, womit der Anbieter anderen Lösungen wie OpenStack voraus zu sein glaubt. Unter der Haube werkelt indes waschechte Open-Source-Software. Für den Storage-Stack kommt beispielsweise der Objektspeicher Ceph zum Einsatz. Grund genug, sich die Lösung genauer anzusehen: Was kann Appscale, wie einfach lässt es sich aufsetzen, und mit welchen Kosten müssen Admins tatsächlich rechnen?

Geldfrage

Bevor es um die technischen Details geht, lohnt es aber, sich mit den finanziellen Aspekten von AWS und einem Umstieg zurück auf eigenes Blech im Detail zu befassen. Lösungen wie Appscale haben einen offensichtlichen Schwachpunkt: Sie setzen den Betrieb eigener Infrastruktur voraus, und der kommt heute zweifelsohne noch teurer als in der ersten Hochphase der Migration in die Public Cloud vor ein paar Jahren. Mancher Administrator ist deshalb möglicherweise geneigt, die Idee einer eigenen, lokalen Cloud mit AWS-APIs sofort wieder zu verwerfen. Genaues Nachrechnen lohnt sich an dieser Stelle aber möglicherweise.

Was sind also bei den Hyperscalern und insbesondere bei AWS die Preistreiber? Im Kern verrechnet AWS ja eigentlich zwei verschiedene Arten von Diensten. Wer klassisches IaaS in AWS per EC2 realisiert – und das ist noch immer ein erquicklicher Anteil der AWS-Nutzer insgesamt –, zahlt im Wesentlichen Gebühren für die Bereitstellung von virtuellen Instanzen. Die sind zum Teil schon gar nicht so billig, wie mancher Administrator im ersten Augenblick glaubt. Wer viel RAM und flotte CPUs braucht, blecht für eine Instanz gut und gern 700 Euro oder mehr pro Monat.

Schon hier kommen erste Zweifel an den vermeintlich so günstigen AWS-Preisen auf. Für die fast 20 000 Euro, die ein solcher virtueller Hobel in zwei Jahren kostet, bekommt man durchaus ordentliches Blech etwa von Supermicro. Das amortisiert sich dann aber üblicherweise in fünf Jahren, ist also deutlich länger im Einsatz. Ein großer Teil der Kosten fällt also auch beim lokalen Betrieb an, und wenn nicht auf Seiten der Hardware, dann durch die Bereitstellung der Location mit Strom, Lüftung und allem, was dazu gehört. An dieser Preisschraube lässt sich auch mit Appscale nur wenig drehen.

Beim zweiten finanziellen Faktor der Public-Cloud-Nutzung ist das anders. AWS und Konsorten ködern Kunden gern mit As-a-Service-Angeboten, also gemanagten Datenbanken, gemanagten DNS-Diensten und vielem mehr. Dabei erfolgt die Verrechnung oft genug aber auf Basis von fließendem Traffic oder einzelnen Zugriffen. Aus Sicht von Admins birgt das das Problem, dass sich zuverlässige Prognosen im Vorfeld kaum treffen lassen.

Zudem spielt hier der schon erwähnte Skalierungsfaktor eine relevante Rolle. Klar: Dienste wie Amazons relationale Datenbank lassen sich per Mausklick beinahe beliebig groß gestalten. Viele Firmen haben in der Nutzung ihrer digitalen Dienste allerdings gar keine so großen Schwankungen, dass sich das ständige und dynamische Skalieren rentieren würde. Sie bezahlen also eine technische Möglichkeit mit, die sie gar nicht nutzen.

So oder so, beim Betrieb von Infrastruktur im eigenen Rechenzentrum skalieren die Kosten für Traffic und Aufrufe nicht linear mit den Anfragen. Der Faktor des verrechneten Verbrauchs ist absolut relevant, wenn man Public Cloud sowie lokales Setup gegenüberstellt. Unter Umständen lassen sich durch den direkten Vergleich zwischen privater und öffentlicher Cloud erhebliche Einsparungen realisieren.

Appscale unterstützt den Administrator also vor allem dabei, die Kosten des Betriebs eigener Infrastruktur besser zu planen. Hier fällt der gesamte Aufwand für den IT-Betrieb an, wie auch schon in der Vergangenheit. Automatisch billiger ist das mithin nicht, man sollte im Vorfeld mit dem spitzen Stift rechnen. Stellen sich die Kosten für Aufrufe von Diensten aber als Hauptkostentreiber heraus, kann Appscale durchaus eine valide Alternative sein und in der IT zu Kosteneinsparungen führen.

Bewegte Geschichte

Appscale existiert in seiner heutigen Form noch gar nicht so lange. Ursprünglich geplant war das Projekt als Nachbau der Google Cloud Platform (GCP). Das war allerdings zu einer Zeit, da der große Kuchen des öffentlichen Cloud Computings noch nicht verteilt war, und Appscale setzte quasi auf das falsche Pferd: Nicht GCP gewann in der Pionierphase des Cloud Computings die großen Aufträge, sondern Amazon. Die Idee, Software zu produzieren, die API-kompatibel zu GCP war, entpuppte sich insofern als Flop. Das hielt das Team rund um die Appscale-Entwickler vor über 15 Jahren aber nicht auf, und so begann man bald mit der Arbeit an einem EC2-Klon. EC2 steht für Elastic Cloud 2 und meint im Wesentlichen die IaaS-Funktion von AWS.

Der eine oder andere Leser hat Appscale im damaligen Zustand möglicherweise sogar noch in Erinnerung, denn die Software war unter ihrem damaligen Namen Eucalyptus (Abbildung 1) auch im Linux-Magazin einige Male Thema. Dann verschwand die Lösung für eine Weile von der Bildfläche: Zunächst verkauften die Entwickler ihre Software an HP, wohl in der Hoffnung, mit der dortigen Kohle ließe sich der Markt umfassend aufmischen. Dann jedoch stolperte HP in seine Restrukturierung und verlor bald das Interesse an der privaten Cloud insgesamt. Das Unternehmen stampfte kurzerhand nicht nur sein OpenStack-Engagement ein, sondern ließ auch die Eucalyptus-Entwicklung komplett einschlafen. Eine kleine Gruppe rund um die ursprünglichen Erfinder der Software begann schließlich mit der Arbeit an einem Fork der letzten von HP unter freier Lizenz veröffentlichten Eucalyptus-Version. Die firmiert seither unter dem Namen Appscale.

Abbildung 1: Alte Bekannte: Appscale ist der logische Nachfolger von Eucalyptus, das HP einst kaufte und als HP Helion Eucalyptus vermarktete. Quelle: The New Stack

Allerdings hat die Sache einen Haken. Während Eucalyptus unter den Fittichen von HP dahindarbte, erarbeiteten die Appscale-Entwickler unter demselben Namen ein Werkzeug für das Deployment und die Compliance-Überprüfung von Ressourcen auf Google Cloud. Und weil das Internet nicht vergisst, findet sich jenes Appscale bis heute in den Suchresultaten, wenn man lediglich nach diesem Begriff sucht. Möchten Sie sich im Nachgang der Lektüre dieses Artikels über die Lösung weiterführend informieren, sollten Sie stets einen zusätzlichen Begriff wie “AWS” mit angeben. Die Deployment-Lösung für GCP ist inzwischen in der Versenkung verschwunden.

Bekannte Architektur

Um Missverständnisse zu vermeiden: Welche Arten von Diensten eine private Cloud bieten muss und wie diese durch Komponenten zu implementieren sind, das haben Projekte wie OpenStack längst in epischer Breite vorgemacht. Die Architektur hinter Appscale (Abbildung 2) überrascht dann auch nur bedingt, denn viele Dienste und Prinzipien der Software kommen passionierten Admins privater Clouds bekannt vor.

Abbildung 2: Die Appscale-Architektur birgt wenige Überraschungen für Kenner privater Clouds. APIs steuern VMs und Speicher, eine Aufteilung in mehrere Availability Zones ist möglich. Quelle: Appscale

Im Grunde funktioniert Appscale so: Als zentraler Dreh- und Angelpunkt der Lösung fungiert ein Cloud Controller, der für das Verwalten von Ressourcen in allen Bereichen der Cloud zuständig ist. Er besteht als Cluster aus mehreren Diensten, die zur Außenwelt jedoch als Einheit erscheinen. Ihm untergeordnet sind die Cluster Controller, die für die Verwaltung der Appscale-Dienste in einer Region zuständig sind, etwa in einer Verfügbarkeitszone.

Den Cluster Controllern steht jeweils ein Storage Controller zur Seite. Dessen Aufgabe besteht darin, den lokalen Speicher zu provisionieren und so anzubinden, dass die virtuellen Instanzen auf den sogenannten Node Controllern ihn nutzen können. Die Anzahl der Node Controller pro Zone ist praktisch unbegrenzt. Entsprechend sieht Appscale die Nutzung eines skalierbaren Speichers vor: wie erwähnt Ceph. Dabei gilt, dass jede Availability Zone über einen eigenen Ceph-Cluster für Blockgerätespeicher verfügt. Auf der Ebene der Cloud-Steuerung (Cloud Control Plane) kommt ein weiterer Ceph-Cluster hinzu, der Object Storage über eine S3-kompatible API zur Verfügung stellt.

Zur Control Plane gehört auch das eigentliche Herzstück der Software: die Dienste, die verschiedene AWS-APIs emulieren. Neben den AWS-APIs für S3 und EC2 zählen dazu derzeit auch IAM, CloudFormation, CloudWatch, die Load-Balancer-Funktion ELB und der Security-Token-Dienst STS. Obendrein enthält Appscale eine Web Console, also eine Art GUI. Naturgemäß liegt der Fokus bei der Nutzung von Cloud-Plattformen allerdings eher auf den APIs.

Skalierbarkeit

Die Appscale-Architektur offenbart schnell, dass die Entwickler der Lösung das Prinzip der Skalierbarkeit verstanden und verinnerlicht haben. Auf den einzelnen Ebenen des Designs, insbesondere aber auf Seite der Compute Nodes, lassen sich Instanzen quasi beliebig hinzufügen und entfernen. Das ist per se aber kein Merkmal, mit dem Appscale sich von anderen Lösungen unterscheidet – nahtlose Skalierbarkeit kann OpenStack beispielsweise auch. Appscale verspricht, sich anders von den etablierten Werkzeugen abzuheben.

Das Key Asset ist dabei die Amazon-Kompatibilität, auf die wir später noch im Detail eingehen. Für mindestens ebenso wichtig halten die Entwickler indes ihren Deployment-Mechanismus, denn die Lösung kommt mit einem eigenen Installationswerkzeug daher. Gerade das initiale Setup der Umgebung ist ein neuralgischer Punkt, und OpenStack hat es bis heute nur begrenzt geschafft, einheitliche Werkzeuge, Tools und Abläufe zu etablieren. Potenzial, sich von der Konkurrenz abzuheben, gibt es also durchaus, und im Versuch strengt Appscale sich gehörig an, das auszunutzen.

Die Entwickler liefern ihre Umgebung kurzerhand mit einem eigenen Tool aus, das auf Basis von Ansible und anderen Automationswerkzeugen das gesamte Deployment in verhältnismäßig kurzer Zeit über die Bühne bringt. Dem Administrator fällt dabei nur die Aufgabe zu, einzelne physische Knoten mit ihrer Rolle im Appscale-Kontext zu verknüpfen. Nur so weiß die Installationsroutine schließlich, welche Dienste auf welchen Hosts laufen sollen. Das Deployment selbst funktioniert danach reibungslos. Will man das Setup später erweitern, nutzt man dieselben Werkzeuge, die grundsätzlich dafür ausgelegt sind, idempotent zu funktionieren. Im Zweifelsfall gibt man dann aber einfach mehr Compute-Systeme an, um die Umgebung zu vergrößern.

AWS-Kompatibilität

Quasi das Hauptversprechen von Appscale ist die Kompatibilität zu AWS. Das verwundert nicht, warb doch schon der Vorgänger Eucalyptus insbesondere damit, kompatibel zu etlichen AWS-APIs zu sein. Laut Appscale eröffnen sich der Kundschaft damit gleich mehrere Möglichkeiten. Eine davon ist der komplette Umstieg aus der öffentlichen in die private Cloud. Hier, so das Versprechen, lassen sich bestehende Workflow-Implementierungen ebenso weiterverwenden wie ein möglicherweise schon vorhandenes Tooling. Das betrifft einerseits das Deployment neuer Ressourcen in die Umgebung, andererseits zielt Appscale hier auch auf Prozesse wie Monitoring, Alerting und Trending ab.

Fast noch wichtiger ist aus Sicht der Anbieter aber die Option hybrider Workloads. Wenn die AWS-Cloud und die eigene, private Cloud dieselben APIs nutzen, lassen sich sämtliche Deployment- und Workflow-Werkzeuge auf beide anwenden. Nutzer können dann dynamisch und ad hoc entscheiden, ob sie aus ihrer bestehenden Deployment Chain heraus neue Workloads in AWS, in der privaten Appscale-Cloud oder hybrid und in Teilen in beiden Zielen ausrollen. Dass das gut und zuverlässig funktioniert, setzt aber einen hohen Grad an AWS-Kompatibilität voraus. Was das im Detail bedeutet, hängt vom Einzelfall ab.

Das liegt nicht zuletzt daran, dass es sich bei AWS nicht um einen offenen Standard handelt: Die genutzten APIs sind samt und sonders proprietär. Sämtliche Funktionalität in Appscale fußt insofern auf klassischem Reverse Engineering. Die Entwickler räumen selbst ein, dass sie nicht sämtliche Calls aller APIs der AWS-Dienste unterstützen. Das, so die Behauptung, sei aber für das Gros der Nutzer auch gar nicht nötig. Denn die bräuchten in den meisten Fällen ohnehin nur die wichtigsten API-Befehle. Die unterstützt Appscale laut eigener Aussage vollständig und gut. Unweigerlich fühlt man sich an das Pareto-Prinzip erinnert, nach dem 20 Prozent der Funktionalität genügen, um 80 Prozent der Anwender zufriedenzustellen.

Was aber bedeutet das in der Praxis, und wie kompatibel ist Appscale wirklich? Die schon zitierte Liste der unterstützten Dienste bringt Licht ins Dunkel. Klar: EC2 für virtuelle Instanzen, EBS für dynamische Blockspeichergeräte sowie S3 als Objektspeicher dürfen im Portfolio nicht fehlen. Auch virtuelle Netze, also das Gegenstück zu Virtual Private Clouds, bietet Appscale an. Den Cloud-Orchestrierer CloudFormation samt kompatibler Templates können Nutzer ebenfalls verwenden. Etwas komplizierter wird es bei fortgeschrittenen AWS-Diensten. CloudWatch (Abbildung 3), also das AWS-Monitoring, unterstützt Appscale ebenso wie das bei AWS-Kunden besonders beliebte Autoscaling-Feature. Das greift auf Daten von CloudWatch zu und fährt je nach Auslastung VMs hoch oder runter.

Abbildung 3: Alte Bekannte: Das Appscale-Dashboard weist unverkennbare Ähnlichkeiten mit Eucalyptus auf, bietet aber auch Dienste wie CloudWatch oder Autoscaling an. Quelle: Appscale

Im Bundle dazu gehört der elastische Load Balancer ELB, der in Appscale ebenfalls zur Verfügung steht. Den globalen DNS-Dienst Route 53, bei AWS-Kunden ebenfalls sehr beliebt, stellt Appscale mittlerweile ebenfalls bereit, im Augenblick jedoch noch als Tech Preview. Damit Kunden ein einheitliches Regime in Sachen Autorisierung und Authentifizierung haben, haben die Entwickler auch den Amazon-Dienst IAM nachgebaut, also das Identity and Access Management. Ebenfalls als Technical Preview gibt es den Simple Queue Service (SQS). Database as a Service baut Appscale als relationale Datenbank in Form von RDS ebenfalls nach. Der Dienst ist auch kein Technical Preview mehr, bietet in Sachen Funktionalität aber deutlich weniger Auswahl als das Original.

An ein paar Diensten werkelt Appscale zudem augenblicklich noch. Dazu gehören ElastiCache, also Managed Redis mit Memcached sowie Elastic MapReduce, also eine Art Hadoop as a Service. Einen Message-Bus sowie einen Workflow-Manager will Appscale als Gegenstück zu AWS SNS und SWF ebenfalls bald liefern.

Fehlende Dienste

Andere Dienste will Appscale zwar nachbauen, aber nicht so, dass sie kompatibel zu AWS sein werden. Kubernetes etwa, fast unverzichtbar im modernen IT-Betrieb der Gegenwart, wird man in Form von Rancher mit K3s über CloudFormation-Templates umsetzen. Das ist ein signifikanter Unterschied zu AKS, dem AWS-eigenen Kubernetes, und deutet auf ein größeres Problem hinter den Kulissen hin.

Gerade die As-a-Service-Optionen von AWS sind für viele Anwender der Plattform erst das Salz in der Suppe. Datenbanken wie Aurora oder RedShift etwa erleichtern Anwendern die Nutzung von AWS erheblich. Das ist kein Zufall: Seit jeher setzen die Hyperscaler verstärkt auf derartige Dienste, weil eben diese den Lock-in-Effekt zementieren wie keine andere Gruppe von Anwendungen. Wer in AWS nur IaaS betreibt, hat mit etwas Migrationsarbeit und unter Investition von viel Zeit eine reale Chance, seine Workloads zu einem anderen Anbieter zu migrieren. Wer aber seine eigene Anwendung vollständig auf Dienste wie RedShift oder DynamoDB (Abbildung 4) ausrichtet, müsste diese bei einem Ausstieg aus AWS komplett umbauen. Das wäre eine Mammutaufgabe, für die vielen Firmen schon ganz banal die monetären Mittel fehlen.

Abbildung 4: Dienste wie DynamoDB sind für Anwendungsentwickler ausgesprochen nützlich, binden aber auch an einen Anbieter. Appscale kann sie nicht liefern. Quelle: Capterra

Die Krux an der Sache: Bei AWS arbeiten praktisch unbegrenzt viele Menschen, sodass entsprechend viel Manpower für die Umsetzung etwaiger Dienste zur Verfügung steht. Das ist bei Appscale naturgemäß anders. Die Implementierung eines zu DynamoDB kompatiblen Diensts würde ein kleines Entwicklerteam vermutlich Monate Arbeit kosten, wenn nicht Jahre, die bei Appscale zweifelsohne anderswo besser genutzt ist. Denn klar ist auch: Zwar bietet AWS mittlerweile unfassbar viele Spezialdienste dieser Art an, doch nutzt diese nur ein relativ kleiner Prozentsatz der Anwender. Pareto lässt einmal mehr grüßen, was auf die wirtschaftlichen Notwendigkeiten bei Appscale hindeutet.

Nichts zu meckern

Die Dienste, die Appscale implementiert, setzt der Anbieter immerhin gut um. In einem kurzen Test war es mit klassischen GUI- und CLI-Werkzeugen möglich (Abbildung 5), in Appscale die grundlegenden AWS-Dienste ebenso in Anspruch zu nehmen wie in AWS selbst. Das Anlegen neuer Instanzen klappte reibungslos. Sie erhielten auch ohne Murren ein privates, virtuelles Netzwerk und bei Bedarf elastische Blockspeichergeräte.

Ausdrücklich nicht zu testen war im Vorfeld allerdings die Performance der Lösung. Der Mini-Test im Rahmen dieses Artikels stellte das Konstrukt naturgemäß nicht vor Probleme. Unternehmen, die große Appscale-Setups planen, sollten sich sicherheitshalber im Vorfeld jedoch mit dem Anbieter in Verbindung setzen und sich etwaige Benchmarks zeigen lassen, die mit dem geplanten eigenen Setup vergleichbare Umgebungen produzieren.

Abbildung 5: Die Kompatibilität der AWS-APIs von Appscale ist gut genug, um auch offizielle AWS-Werkzeuge wie »aws« zufriedenzustellen. Quelle: Appscale

Preispolitik

Technisch lässt sich mit Appscale also durchaus ein gut funktionierender lokaler AWS-Klon bauen. Wie aber gestalten sich die Geschäfts- und die Preispolitik des Unternehmens? Die schönste Plattform ist ja nichts wert, wenn auch sie wieder Unsummen für Lizenzen und Subskriptionen verschlingt. An dieser Stelle ist allerdings Entwarnung angesagt, denn Appscale arbeitet nicht nur mit fixen Tarifen, sondern geht dabei sogar sehr transparent vor.

Potenzielle Appscale-Kunden haben die Wahl zwischen dem kompletten Selbstbetrieb der Software auf eigener Infrastruktur und dem Betrieb durch einen Appscale-Partner. Dabei handelt es sich im Grunde um eine Sonderform der hybriden Cloud. Die so entstehende Plattform ist zwar privat, aber das Unternehmen braucht sich über den Betrieb der Plattform trotzdem keine Gedanken zu machen: Das übernimmt ein vom Hersteller beauftragter Dienstleister. Fixe Tarife lassen sich dafür allerdings kaum nennen, weil diese stark von der Dimension des Setups abhängen.

Anders sieht die Sache aus, will man Appscale komplett im eigenen Rechenzentrum und sozusagen auf eigene Faust betreiben. Dann stehen Verträge mit einer Dauer von drei, fünf oder sieben Jahren zur Verfügung, wobei längere Laufzeiten zu höheren Rabatten führen. Wichtig aus Sicht des Herstellers: Für die Verträge fallen fixe Preise an, die sich nicht nach Benutzung oder Durchsatz richten.

Konkrete Preise nennt Appscale auf seiner Website unter https://www.appscale.com zwar nicht, doch finden sich im Netz immerhin Hinweise. Demnach rangiert der Preis pro Knoten bei der selbst gehosteten Variante im Bereich von 40 Euro pro Monat. Wer also eine bereits recht große private Cloud mit 200 Compute-Knoten betreibt, muss mit Kosten von rund 8000 Euro pro Monat für die Software rechnen. Das ist je nach Setting deutlich günstiger als der komplette Gang in die Public Cloud.

Fazit

Eucalyptus steigt wie Phoenix aus der HP-Asche auf und feiert als Appscale ein Comeback. Dass der Hersteller seine Produktstrategie im Griff hat, zeigt insbesondere die Option, Appscale als private Cloud zu betreiben, aber von einem Anbieter speziell für die eigenen Bedürfnisse hosten zu lassen. Unternehmen erhalten auf diese Weise das Beste aus beiden Welten: Sie müssen keine eigene IT-Infrastruktur betreiben, bekommen aber trotzdem eine private Cloud mit AWS-Kompatibilität.

Weniger überzeugend erscheint der Ansatz, Appscale komplett selbst zu betreiben. Diese Option dürfte sich nur für solche Firmen wirklich lohnen, die bereits massiv in die AWS-APIs investiert haben, nun aber die Rolle rückwärts in Richtung privater Cloud machen wollen. Preislich lohnt sich der Umstieg vor allem dann, wenn die Kosten für API-Aufrufe und Transitverkehr das Gros der eigenen Rechnung von AWS ausmachen.

Technisch präsentiert Appscale sich auf der Höhe der Zeit, und die gebotene AWS-Kompatibilität dürfte für die meisten Fälle genügen. Es schmerzt aber, dass viele AWS-Dienste in einer Appscale-Cloud nicht zur Verfügung stehen. Das indes kann auch niemand wirklich erwarten, denn das Appscale-Team hat schließlich nicht annähernd die Ressourcen zur Verfügung, mit denen AWS wuchern kann. (jcb)