Heiter bis holprig

Sogenannte Cloud Services revolutionieren die IT. Sagt jedenfalls das Marketing. Auch wenn es unbestrittene Vorteile gibt: Wer die Sache nüchtern betrachtet, stellt schnell fest, dass zahlreiche Hürden den Weg in die Wolke verstellen. Vor besonderen Schwierigkeiten stehen Kunden und Dienstleister, wenn es darum geht, Integrationsprobleme zu lösen.

6

27.04.2011, 00:00 Uhr

Lesezeit: 8 Min.

iX Magazin

Von

Markus Kopp

Viele von den Cloud-Anbietern in die Welt gesetzte Erfolgsgeschichten vermitteln den Eindruck, als ließe sich eine Anwendung einfach in „die Cloud“ übertragen und dort je nach Bedarf hoch- oder herunterskalieren. In der Praxis eignet sich jedoch längst nicht jede Software für diese Variante des Outsourcings. Es sind etliche technische Klippen zu umschiffen, besonders die Abhängigkeit des fraglichen Programms von anderen Systemen wirft Fragen auf.

Vorab eine Klarstellung: Es gibt nicht „die“ Cloud, denn die meisten Anbieter haben eigene Spielarten entwickelt. Folgende Definition hat sich jedoch als praktikabel erwiesen: Cloud Services bezeichnen den bedarfsgerechten Einsatz eines Dienstes (zum Beispiel Infrastruktur, Plattform oder Anwendung), der sich schnell an neue Bedingungen anpassen lässt und der basierend auf dem tatsächlichen Gebrauch der bereitgestellten Ressourcen abgerechnet wird.

Zwei wichtige Argumente sprechen also für solche Services: Ihre Flexibilität, denn die Anwender können schnell reagieren, wenn sich ihr Geschäftsumfeld ändert, und durch das individuelle Abrechnen lässt sich potenziell Geld sparen. Letzteres ergibt sich in erster Linie durch die Umlage von Investitions- auf Betriebskosten [1]. Insgesamt sind dadurch schnellere Produkteinführungszeiten für alle Geschäftsbereiche möglich. Das gilt auch für die Dienstleister selbst.

Verschiedene Wolkenformationen

Bisher sind drei Arten von Cloud Services verbreitet, nämlich IaaS, PaaS und SaaS. IaaS steht für Infrastructure as a Service. Darunter fallen Komponenten wie CPUs, Speicher und Netzwerke. Plattform as a Service (PaaS) enthält neben Infrastrukturelementen ein Betriebssystem sowie eine technische Ablaufplattform, etwa einen Applikationsserver oder eine Datenbank. Software as a Service bezeichnet ein vollständiges Anwendungssystem. Wer eine Applikation in eine Cloud übertragen will, muss also zunächst die Frage beantworten, welche Servicekategorie sich am besten dafür eignet. Zu bedenken ist, dass die Abhängigkeit vom Anbieter steigt, je mehr Komponenten man extern von ihm betreiben lässt.

Infrastrukturdienste wie Amazon Web Services bieten die größte Flexibilität, da sich dort beinahe jede Software ausführen lässt. Eine Webanwendung, die in die Cloud verlagert werden soll, ist jedoch selten völlig autark. Häufig nutzt sie eine SQL-Datenbank und ein Identity Management System (IMS), das alle Zugriffe prüft. Vor der Migration müssen die Verantwortlichen daher klären, wie sich die Rolle von Datenbank und IMS künftig darstellt. Da sich der direkter Zugang auf solche Backend-Komponenten aus Sicherheitsgründen verbietet, lässt sich eine damit gekoppelte Anwendung nicht ohne Weiteres in eine öffentliche Cloud auslagern.

Geeignete Applikationen dürfen daher nur direkt mit Systemen zusammenarbeiten, die aus der Cloud heraus ebenfalls zugänglich sind. Im genannten Beispiel muss der Entwickler die Datenbank und das IMS (sowie alle anderen benötigten Teile) ebenfalls migrieren. Für IaaS-Umgebungen ist dies technisch machbar. Ob es sinnvoll ist, entscheidet der Einzelfall.

Wer eine Applikation in die Cloud verschieben will, verspricht sich vor allem Flexibilitätsvorteile. Dazu muss die Anwendung skalierbar und idealerweise zustandslos sein. Ist das Halten eines Zustands unbedingt notwendig, bieten sich zwei Optionen an: das Verwenden von Sticky Sessions im Load Balancer oder das Festschreiben der Sessions in einer Datenbank.

Einen Zustand sicher festhalten

Über Sticky Sessions verteilt ein Load Balancer Anfragen immer an den gleichen Server, der intern eine Sitzung für jeden Anwender vorhält. Es gibt jedoch einen Engpass: den IaaS-Anbieter selbst. So unterstützt Amazon derzeit Sticky Sessions nur für HTTP-Anfragen und nicht für HTTPS. Ein Load Balancer vor Ort schafft eine weitere Möglichkeit, Sticky Sessions einzusetzen. Er nimmt die Anfragen entgegen und leitet sie an die verschiedenen Cloud-Instanzen weiter. Allerdings muss diese technische Konstruktion in der eigenen Systemumgebung angemessene Verfügbarkeit und notwendigen Durchsatz garantieren. Beide Optionen eignen sich deshalb nur bedingt zum Halten eines Zustandes. Wer Sessions unbedingt einsetzen muss, sollte sie in einer Datenbank ablegen, sodass alle Anwendungen darauf zugreifen können. Viele IaaS-Provider bieten für diesen Zweck NoSQL-Datenbanken mit hohem Durchsatz an. Vertreter dieser Gattung sind etwa Google BigTable, Amazon SimpleDB sowie die freien Apache-Implementierungen CouchDB und Cassandra. Da SQL-Datenbanken nicht zustandslos sind, stellen sich die Vorteile der Flexibilität hier nicht ein. Zum Skalieren von Datenbanken in der Cloud stellen viele Dienstleister spezielle Services zur Verfügung.

Bei der PaaS-Ausprägung betreibt der Anbieter einen vollständigen Application Server und richtet die Webanwendung hier ein. Die Ressourcen für die Webanwendung teilt er je nach Preismodell zu. Microsofts Azure arbeitet beispielsweise nach dem PaaS-Modell. Weitere Vertreter dieser Gattung sind Googles App Engine, Force.com von Salesforce sowie VMforce, eine Cloud für Java-Programmierer.

Wer eine Anwendung in eine PaaS migriert, kann beispielsweise Datenbank und Identity-Management-System nicht mitnehmen, er muss die Services der Anbieters nutzen (Abb. 1).

Zunächst muss der Entwickler klären, ob es überhaupt einen Anbieter gibt, der in der Lage ist, die zu migrierende Anwendung zu betreiben. Die Einschränkung, dass sie nur mit Systemen kooperieren dürfen, die von dieser Plattform ebenfalls erreichbar sind, gilt hier ebenfalls – sogar in verschärfter Form, da einige PaaS-Protagonisten das Anbinden externer Systeme nicht zulassen. Somit müssen alle benötigten Komponenten in der PaaS-Cloud laufen. Fast alle Dienstleister stellen neben dem Application Server auch Datenbanken und andere Services bereit. Dennoch wird man in der Regel kein Cloud-Unternehmen finden, das in der Lage ist, alle involvierten Programme zu hosten. So kann es beispielsweise notwendig sein, die Schnittstelle der Datenbank anzupassen. Für das Identity Management System haben die meisten Provider entsprechende Services im Angebot. Ohne Migrationsaufwand geht es hier also nicht. Zudem muss sich der Kunde meist auf proprietäre Dienste des Anbieters einlassen, was das Abhängigkeitsverhältnis vertieft. Dafür kümmert sich der PaaS-Anbieter um die Skalierungsfragen sowie das Session Handling (Abbildung 1).

SaaS: Alles aus einer Hand

Bei einer SaaS-Anwendung ist dem Kunden meist nicht bekannt, welche Komponenten im Hintergrund ihren Dienst verrichten (Abb. 2).

Bei SaaS geht es nicht um das Verlagern einer Anwendung in eine Cloud, sondern um ihre Ablösung durch einen Online-Service. Wenn der entsprechende Anbieter gefunden ist, muss man die relevanten Daten zu ihm übertragen. Es bleibt zu klären, wie der Dienst mit externen Softwarekomponenten klarkommt. In einer Umfrage des IDC (siehe iX-Link) nannte die Mehrzahl der Befragten Sicherheitaspekte als größte Herausforderung in diesem Umfeld. Diejenigen, die bereits einen solchen Service nutzen, stellten hingehen die Integration mit anderen Systemen in den Vordergrund. Interessierte sind daher gut beraten, sich schon vor der Inbetriebnahme eines Dienstes Gedanken über potenzielle Integrationshürden zu machen (Abbildung 2).

Über eine Virtual Private Cloud (VPC) lassen sich alle internen Systeme erreichen. Angebunden sind sie über ein virtuelles privates Netz (Abb. 3).

Als weitere Variante kann das Migrieren von Anwendungen in eine Virtual Private Cloud gelten. Dabei handelt es sich nicht um eine hausinterne private Wolke, sondern ebenfalls um eine von einem Dienstleister bereitgestellte. Der Zugang erfolgt über ein gesichertes Virtual Private Network (VPN). Die verlagerte Anwendung ist netzwerktechnisch komplett von der Außenwelt abgeschirmt und lässt sich ausschließlich über das interne Netz erreichen. Durch diesen Kniff ist es möglich, ausschließlich die Webanwendung und nicht die abhängigen Systeme in die Cloud zu verlagern (Abbildung 3). Virtual Private Clouds existieren derzeit für IaaS und PaaS. Amazon bietet beispielsweise in Nordamerika einen solchen Service an. Andere Mitspieler, etwa Microsoft, haben ähnliche Offerten angekündigt.

Welche Cloud die richtige ist, hängt von zahlreichen Faktoren ab, pauschale Antworten gibt es nicht. Zu Sicherheitsaspekten und Integrationsfragen lassen sich derzeit noch wenige allgemeingültige Aussagen treffen. Im ersten Schritt sollte man seine Anforderungen formulieren und die Vor- und Nachteile der verschiedenen Services abwägen. Die richtige Auswahl hängt leider wie so häufig vom Einzelfall ab.

Markus Kopp

ist Management Consultant und Cloud Service Manager bei Logica in Deutschland.

Literatur

[1] Constantin Christmann, Jürgen Falkner, Dietmar Kopperger, Anette Weisbäcker; Wirtschaft; Schein oder Sein; Kosten und Nutzen von Cloud Computing; iX Special 2/2010 Cloud, Grid, Virtualisierung, S. 6

Alle Links: www.ix.de/ix1105044

Cloud Computing – Pro und Contra

Cloud ist zwar schon jetzt das IT-Modewort des Jahres – aber muss wirklich jeder mitmachen? Analysen der Voraussetzungen für die Migration in die Cloud geben Entscheidungshilfen, ein Exkurs zum Open-Source-Werkzeug OpenNebula ergänzt das Bild.