Aus Linux-Magazin 07/2011

Cloud-Strategieplaner

© Paul Prescott, 123RF.com

Wer die Roadmap seines Unternehmens aufs Cloud Computing ausrichten will, steht vor komplexen Abwägungen. Dieser Artikel zeigt, wie Unternehmensgröße, Cloud-Angebote und -Formen zueinander passen und wie eine Firma sicher und gradlinig in die Wolken vordringt.

Private Anwender nutzen Clouddienste bereits seit Langem. Diverse Mailer wie Hotmail bieten seit knapp 15 Jahren Web-basierte E-Mail-Infrastrukturen an, treten also seit IT-Ewigkeiten als Anbieter des Service-basierten Clouddienstes auf. Privat ebenfalls sehr populär sind Storage-Services wie Dropbox (siehe Artikel zur Desktop-Cloud in diesem Schwerpunkt), die sich nahtlos in alle gängigen Betriebssysteme integrieren und auch auf mobilen Geräten einfachen Zugriff auf dort abgelegte Daten bieten. Dropbox nimmt dabei sowohl die Rolle eines Cloudanbieters als auch die eines Cloudnutzers ein, da es seinen Speicherplatzbedarf aus der Wolke speist.

Private Gepflogenheiten, die in der Regel weniger scharfe Sicherheitsanforderungen stellen, bringen im Unternehmenseinsatz aber neue Anforderungen. Klassische Dienste zum Datei-Austausch gelten zunehmend als antiquiert und unkomfortabel, immer mehr Mitarbeiter nutzen Dienste wie Dropbox auch zum Austausch von Unternehmensdaten. Meist erfolgt das trotz anders lautender Vereinbarungen und lässt IT-Leitern und Datenschutzbeauftragten angesichts beunruhigender Meldungen über Privatsphäre und Sicherheit bei Dropbox die Haare zu Berge stehen.

Ein für alle Unternehmenstypen gültiges Cloudkonzept ist jedoch unmöglich. So unterscheiden sich die Unternehmen sowohl in den IT-Fertigkeiten und der Ausprägung der zugrunde liegenden Service-Orientierung als auch generell darin, welche Dienste sie überhaupt einsetzen.

Kleine Unternehmen

Bei kleinen Unternehmen, typischerweise aus dem Handwerksbereich, spielt die IT eine stark unterrepräsentierte Rolle, gerade personell. Administrative Tätigkeiten erledigt nur selten ein Mitarbeiter in Vollzeit, in der Regel macht das ein kundiger Power-User zusätzlich zu seiner Haupttätigkeit nebenbei.

Sicherheits-Updates oder gar Servicelevel-Zusagen sind für das Management wenig relevant und werden häufig eher als lästige Pflicht, bisweilen gar als potenzielle Fehlerquelle angesehen. Kommt es zu einem temporären Stillstand der IT, hat dies meist auch nur geringe Auswirkungen auf das Kerngeschäft. In einem solchen Umfeld führt das Umstellen auf Cloud-basierte Dienste in der Regel zu einer Verbesserung des Status quo. Daten fallen meist nur in geringem Umfang an, oft verwalten die Unternehmen nur Kunden-Datensätze oder Daten zu Abrechnungszwecken.

Die Verfügbarkeit von Serverdiensten, sofern sie in signifikantem Umfang vorhanden sind, lässt sich durch Clouddienste deutlich verbessern, da lokale, durch Hardware verursachte Serverausfälle bei Services aus dem Web einfacher zu verkraften sind. Vor allem Start-ups setzen hier verstärkt auf Dienste aus der Wolke, nicht selten sogar bis hin zu virtuellen Desktops in der Cloud als ersten Ansätzen von IaaS (Infrastructure as a Service, Abbildung 1).

Abbildung 1: Die Cloudkonzepte IaaS, PaaS und SaaS eignen sich in unterschiedlichem Maße für Unternehmen und Dienste. IaaS schließt in der Regel PaaS und SaaS ein, die letzteren sind aber auch allein möglich.

Abbildung 1: Die Cloudkonzepte IaaS, PaaS und SaaS eignen sich in unterschiedlichem Maße für Unternehmen und Dienste. IaaS schließt in der Regel PaaS und SaaS ein, die letzteren sind aber auch allein möglich.

Das Thema Datenschutz spielt in solchen kleinen Unternehmen eine Nebenrolle, oft erledigen sie geschäftliche Mails über kostenfreie Webmailer mit Outlook, auch genügen hier häufig die Webfrontends der Provider. Auf regelmäßige Datensicherungen verzichten sie aus Gründen der Komplexität ebenfalls oft – trotz aller Vorschriften.

Den schnellsten Nutzen verspricht in kleinen Unternehmen der zusätzliche Einsatz von Software beziehungsweise Platform as a Service (SaaS, PaaS, Abbildung 1), weniger der Bezug von virtueller Infrastruktur. Durch den Einsatz einer Komplettlösung lässt sich auch das lästige Patchmanagement auf den Dienstanbieter abwälzen, der lokale Admin muss sich nicht um die Konfiguration einzelner Systeme sorgen – gerade für kleine Unternehmen ohne viel IT-Know-how stellt dies ein attraktives Angebot dar.

Beim Umstellen auf Webdienste wird der Browser, unabhängig vom zugrunde liegenden Betriebssystem, zur eigentlichen Plattform – ganz ähnlich, wie es Google mit Chrome OS vormacht [1]. Dies ebnet den Weg für freie Alternativen, wartungsarme Thin Clients und einfacheres Einbinden mobiler Endgeräte.

Bei konsequentem Minimieren der eigenen IT und dem Einsatz externer Ressourcen bleiben im Unternehmen praktisch nur noch die essenziellen Netzwerk-Basisdienste WAN-Anbindung, DHCP, Routing, Firewall, dazu vielleicht noch die Pflege eines Browsers und der Clientsoftware des Terminalservers. Doch der Aufwand für dieses Szenario ist beträchtlich, oft sind externe Dienstleister mit branchenspezifischem Know-how nötig. Als Lohn für den Aufwand reicht dann meist billige Hardware von der Stange.

Mittelstand

Mittelständische Unternehmen dagegen weisen eine andere IT-Struktur auf. IT ist dort nicht nur ein notwendiges Übel, sondern für die Geschäftsprozesse zwingend notwendig. Dediziertes Fachpersonal betreibt die fürs mittelständische Unternehmen meist existenziell wichtigen IT-Strukturen. Das Ziel darf hier nicht lauten, blindlings alle Dienste in die Wolke auszulagern, sondern bedarfsorientiert und weitsichtig zu handeln.

Cloudangebote lohnen auch dann eine Prüfung, wenn zum Beispiel eine Investition in Hardware ansteht. Zwar fallen einerseits Hardwarekosten weg, dem stehen jedoch Integrationsaufwände und Schulungskosten gegenüber – wie bei jeder Migration. Damit eine sinnvolle Abschätzung der Kosten überhaupt möglich ist, muss die interne IT idealerweise bereits Service-orientiert arbeiten und Bewertungsgrundlagen liefern.

Erster Schritt: Private Cloud

Im KMU ist der erste Schritt meist die Etablierung einer Private Cloud (Abbildung 2), also die Umstellung des internen Rechenzentrums gemäß den Cloudprinzipien. Konsequente Virtualisierung sowohl der Server als auch des Storage dient zum Entkoppeln der angebotenen Services von der Hardware. Nicht selten stellen hier bereits Terminalserver Arbeitsplätze remote zur Verfügung. Viele Anwendungen finden sich auch in Unternehmen mittlerer Größe schon als Webdienst, zum Beispiel die Groupware oder das CRM. Derlei Dienste können zuerst in der privaten Wolken landen – meist so transparent, dass der Anwender kaum etwas davon merkt.

Abbildung 2: Private, Hybrid und Public Cloud in der Übersicht.

Abbildung 2: Private, Hybrid und Public Cloud in der Übersicht.

Als Nächstes erarbeitet sich das Unternehmen im Idealfall ein Abrechnungsmodell für die pauschale oder zeitabhängige Leistungsverrechnung bei intern erbrachten Dienste, ganz ähnlich wie bei einem Cloudanbieter. Das hilft nicht nur dabei, Kosten zu erkennen und zu sparen, sondern macht auch eine etwaige Auslagerung in Hybrid oder Public Clouds planbar.

Hierbei gilt es – vor allem auch hinsichtlich rechtlicher Rahmenbedingungen – zu untersuchen, welche Dienste und Daten besser in der internen Wolke verbleiben. Gesetze, Kosteneffizienz und Aspekte des Datenschutzes verbieten häufig die Auslagerung ganz pauschal. Trotz aller Sicherheitsvorkehrungen ist manches besser im eigenen Rechenzentrum aufgehoben, da die Firmen-IT nur dort die absolute Hoheit über die Daten und die Durchsetzung eigener Sicherheitskonzepte erzwingen kann.

Heutige Cloudanbieter erkennen dieses Thema verstärkt als wesentliches Hemmnis beim Verkauf ihrer Dienste. Im stark von Vorschriften und Gesetzen geprägten Markt Europas und vor allem in Deutschland schrecken überdurchschnittlich viele Unternehmer vor dem Gang in die Wolke zurück, während in den eher dynamisch geprägten USA schon heute externe Cloudservices häufiger in Firmen zum Einsatz kommen.

Hat der Mittelständler ermittelt, welche Services er auslagern kann, fängt er mit dem Aufbau seiner Hybrid Cloud an, also einer Kombination der internen privaten Wolke mit externen, bedarfsabhängigen Services. Die lassen sich entweder dauerhaft oder zum Abfangen von Lastspitzen einsetzen, wie das Beispiel des Chat-Hosters Spinchat.de zeigt [2]. Auch Notfallszenarien, zum Beispiel beim Ausfall eines Rechenzentrums, lassen sich so zumindest teilweise abdecken. Hybrid-Lösungen setzen zwar einiges an Planung voraus, schaffen aber vielerorts erst die Grundlage für die in Marketingunterlagen oft versprochene “Dynamisierung” des IT-Betriebs.

Das Auslagern ganzer Infrastrukturen (IaaS) stellt wegen des hohen planerischen Aufwands auch eher einen mittelfristigen Weg dar. Generell sollten mittelständische Unternehmen, die einen schnellen Nutzen aus der Wolke ziehen wollen, eher nur sporadisch genutzte oder branchenspezifische Dienste auslagern. Ein typisches Beispiel dafür sind nicht dauerhaft benötigte High-Performance-Computing-Systeme (siehe Kasten “Sonderfall HPC”).

Sonderfall HPC

Die Auslagerung selten benötigter Systeme für sporadische, aber umfangreiche Berechnungen scheint ideal: Signifikante Investitionskosten in eigene Cluster entfallen, nur der Rechenaufwand schlägt zu Buche, die Konfiguration ist sowieso meist Sache eines externen Partners mit entsprechendem Applikationsverständnis.

Eine Umsetzung mit gewöhnlichen Serverinstanzen von der Stange ist dabei aber meist nicht möglich, da Erfordernisse wie leistungsfähige Interconnects mit geringen Latenzen oder notwendig hohe I/O-Durchsätze zum Tragen kommen. Auch unterstützen viele Applikationen in diesem Umfeld Berechnungen auf Grafikprozessoren, die in virtuellen Maschinen nicht zur Verfügung stehen.

Auf diese besonderen Anforderungen hat sich eine Reihe von Anbietern spezialisiert, sie bieten HPCaaS an. Das Steinbuch Forschungsinstitut des KIT (SCC, [4]) gilt dabei als wissenschaftlicher Vorreiter.

Großunternehmen

Großunternehmen dagegen haben ihre IT-Abteilungen in der Regel bereits Service-orientiert organisiert und so für die Vergleichbarkeit interner und externer Services gesorgt. Die meisten von ihnen nutzen bereits umfangreiche Virtualisierungs-Setups mit Hunderten oder gar Tausenden von Servern in einer privaten Wolke.

Dank kontinuierlicher Prozessoptimierung, insbesondere mit Blick auf die laufenden Kosten, herrscht in großen Unternehmen traditionell weniger Berührungsangst mit externen Dienstleistern. Häufig ist der komplette IT-Betrieb an einen solchen ausgelagert, der anfallende Aufgaben günstiger als die internen Kräfte erbringt. Die verbleibenden internen IT-Ansprechpartner agieren als Vermittler zwischen den internen Fachabteilungen und den Dienstleistern.

Große Unternehmen lockt am Cloud Computing (vor allem bei Public und Hybrid Clouds) vor allem das Einsparpotenzial, das durch die Umstellung von Investitionskosten hin zu Betriebskosten entsteht. Nur die tatsächlich benötigten Kosten sind zu bezahlen – das klingt verführerisch.

Marktmacht

Gerade Großunternehmen mit Compliance-Richtlinien können sich der rechtlichen Verantwortung nicht entziehen, wenn sie Services in die Wolke verlagern. Sie bleiben als Auftraggeber beispielsweise für die Einhaltung des Bundesdatenschutzgesetzes (BDSG, [3]) verantwortlich und sehen sich daher auch entsprechenden Bußgeldern oder kostenpflichtigen Abmahnungen durch Mitbewerber ausgesetzt.

Allerdings verfügen sie bereits über vielfältige Erfahrungen, wenn es um das Einbinden von Drittanbietern geht, und können beim Aushandeln von Verträgen und entsprechenden Service Level Agreements (SLA) mit einem anderen Gewicht auftreten, als dies für einen kleinen Auftraggeber möglich ist.

Zu den besonderen Herausforderungen zählen Integrationsfragen in bestehende Managementkonzepte und Werkzeuge. Den meisten Nutzen verspricht es, Infrastruktur auszulagern, die nur selten, dann aber in großer Stückzahl nötig ist und sich durch geringen Individualisierungsgrad auszeichnet.

Ein Beispiel dafür ist eine Erweiterung der Webserverkapazitäten im Zuge der Markteinführung eines neuen Produkts, für das sich der Hersteller einen großen Erfolg seiner Marketingkampagne erhofft. Für branchenspezifische Dienste existieren in den meisten Fällen langfristige Partnerschaften mit externen Partnern und Vendor-Lock-in. Deren Umstellung würde meist hohe Migrationskosten nach sich ziehen.

Als Beispiel für solche Dienste aus der Wolke kann das umfangreiche SaaS-Angebot der Datev ASP [5] gelten, die über Terminalservices SaaS rund um Steuer- und Wirtschaftssoftware anbietet.

Rechtliche Aspekte

Die derzeit größten Hemmnisse für den umfassenden Einsatz von Cloudservices speziell bei mittelständischen Unternehmen bereiten Datenschutzbedenken, das generelle Misstrauen gegen den schwammigen Cloud-Begriff, vor allem aber die regulierenden Vorschriften seitens des Gesetzgebers. So muss ein Unternehmen hohe Hürden nehmen, wenn es personenbezogene Daten, zum Beispiel aus einem CRM-System, durch Dritte verarbeiten lässt.

Der Gesetzgeber in Deutschland ist hier recht explizit: Im Allgemeinen kommt der Begriff der “Auftragsdatenverarbeitung” (§11 BDSG) zum Tragen – so bedarf es einer Einverständniserklärung von jeder betroffenen Person zur Verarbeitung der Daten durch Dritte. Selbst bei einer entsprechenden Freigabe bleibt aber nach wie vor der Auftraggeber der Verarbeitung uneingeschränkt für den Datenschutz verantwortlich.

Der Gesetzgeber formuliert dies im §11 BDSG eindeutig: “Werden personenbezogene Daten im Auftrag durch andere Stellen erhoben, verarbeitet oder genutzt, ist der Auftraggeber für die Einhaltung der Vorschriften dieses Gesetzes und des Datenschutzes verantwortlich.” [3]

Für Dienste innerhalb der EU gehen die meisten Juristen davon aus, dass dort an die Verarbeiter ähnlich hohe Maßstäbe anzusetzen sind wie in Deutschland. Die gefürchtete Transparenz der Datenhaltung, also dass zu keinem Zeitpunkt konkret angegeben werden kann, wo sich die Daten physisch befinden, tritt in diesem Fall in den Hintergrund. Wandern die Daten aber in Drittstaaten, auch die USA, besteht die latente Gefahr von Zugriffen durch staatliche Behörden.

Vor diesem Hintergrund muss sich der IT-Leiter klarmachen, ob er mit einem US-Unternehmen Verträge eingeht. Er muss genau prüfen, mit wem er den Vertrag schließt und welches Recht gilt.

Die Standortfrage

Aus diesem Grund gehört es bei US-Anbietern inzwischen zum guten Ton, auch Services ausschließlich aus europäischen Rechenzentren im Angebot zu haben. Es obliegt aber der Prüfungspflicht des Kunden, ob dem wirklich so ist und ob zu Stoßzeiten nicht doch eine transparente Migration in ein anderes, weniger ausgelastetes Rechenzentrum erfolgt.

Des Weiteren sollte er sich bewusst sein, dass er sich nicht nur auf die US-amerikanische Rechtsauffassung, sondern auch auf dortige Moralvorstellungen einlässt. So machte das Beispiel eines Fotografen die Runde, dessen – nach seiner Auffassung – “künstlerische Akte” ein Clouddienst kurzerhand entfernt hatte [6]. Das Beispiel zeigt, dass zum einen nicht nur die Inhalte ohne explizites Einverständnis gelöscht wurden, sondern andererseits auch, dass vorab eine Prüfung durch den Anbieter stattgefunden hatte. Als privat angesehenen Daten hatten Dritte eingesehen – ohne Rückfrage.

Vertragswerk

Deshalb muss das Vertragswerk auch zwingend definieren, welche Rechte und Fristen zum Sperren oder gar Löschen von Daten der Anbieter hat, beispielsweise bei Urheberrechtsverstößen, im Falle von offenen Rechnungen und besonders nach Vertragsende. Keinem Kunden dürfte an einer lukrativen Zweitverwertung der Daten durch den ehemaligen Anbieter gelegen sein.

Eine zum Beispiel in Deutschland rechtskonforme Nutzung von Clouddiensten erfordert umfangreiche vertragliche Regelungen, die sich bei weltweit agierenden Anbietern meist nur von Großunternehmen, bedingt durch ihre Marktmacht, durchsetzen lassen. Anfragen von kleinen Nutzern zu individuellen Absprachen ignorieren große Anbietern meist, es gibt nur Standardverträge nach dem Motto “Friss oder stirb”.

Vor solchen Hürden bleibt dem Unternehmen prinzipiell nur der Rat, sich an einen kleineren, nach hiesigem Recht agierenden Partner zu wenden – dessen individualisierte Lösungen aber oft nicht den Charme und die Konditionen der großen Anbieter aufweisen. Der Kunde kann dort aber eher seinen (regelmäßigen) Prüfungspflichten der getroffenen “technisch organisatorischen Maßnahmen” zum Schutz der Daten nachkommen, wie sie der Gesetzgeber in § 9 BDSG vorschreibt. Ein Besuch in einem Rechenzentrum von Amazon oder Google mag zwar reizvoll erscheinen, wird aber meist auf Seite des Anbieters dankend abgelehnt.

Fein raus beim Wolkenbruch

Doch ganz abgesehen vom Datenschutz fällt ein Ausfall der Wolke immer auf den Dienstnutzer zurück, der Anbieter selbst hat nur selten größeren Schaden zu befürchten. So kann es für ein Unternehmen große Einbußen bedeuten – mit Blick auf Einnahmeausfälle als auch auf verlorene Reputation –, wenn es zu einem Ausfall der genutzten Cloudservices kommt und das Unternehmen keinen Notfallplan hat.

Abbildung 3: Da helfen auch SLAs nicht mehr weiter. Bricht die Wolke auseinander, bleibt der schwarze Peter fast immer beim Kunden der Cloud.

Abbildung 3: Da helfen auch SLAs nicht mehr weiter. Bricht die Wolke auseinander, bleibt der schwarze Peter fast immer beim Kunden der Cloud.

PR-Profis wissen: Einen einmal zerstörten Ruf wiederherzustellen, ist teurer als jede Investition in Ausfallsysteme. Wer bei einem zweiten Cloudprovider oder in seiner Private Cloud Backupsysteme vorhalten will, muss das allerdings schon beim Konzipieren der eigenen Architektur berücksichtigen (vergleiche den Artikel über Cloudprodukte und High Availability in dieser Ausgabe). Die aus den SLA-Verletzungen bei Leistungsstörung resultierenden finanziellen Kompensationen helfen bei einer langen Dienstunterbrechung nur wenig weiter, da die Anbieter meist das Vertragswerk zu ihren Gunsten gestalten.

Eine Art IT-Gewitter in der Cloud sorgte Ende April bei einer Reihe von Web-2.0-Diensten zu stark eingeschränkter Verfügbarkeit. Der gemeinsame Infrastruktur-Anbieter Amazon hatte in einem Rechenzentrum einen größeren Ausfall zu verzeichnen. Einen Überblick über die damaligen Ereignisse und die Schlussfolgerungen gibt [7].

Ein besonders drastisches Beispiel dokumentiert [8]. Dabei bleibt zu hoffen, dass es sich um einen schlechten Scherz handelt: Ein Unternehmen, das die Heimüberwachung von Herzpatienten über Cloudsysteme abwickelt, schildert, wie es 48 Stunden lang nicht auf diese Systeme zugreifen konnte, sein Dienst stillstand und der Support “toter Mann” spielte.

Österliche Überraschung

Amazons Infrastrukturausfälle und die damit verbundenen Beeinträchtigungen der Dienstqualität hielten vom Donnerstag vor Ostern bis zum Dienstag danach an und brachten vor allem zahlreiche Start-ups in den USA in Verlegenheit. Die hatten bei der Bereitstellung ihrer Dienste vor allem wegen der Skalierbarkeit auf bei Amazon Web Services bezogene Infrastrukturen gesetzt. Primär kleine und junge Unternehmen scheinen vom Ausfall betroffen gewesen zu sein. Alteingesessene Firmen wie der Pharmariese Pfizer oder auch der Online-Videoverleih Netflix hatten weniger Probleme.

Fehlertolerantes Design

Dabei ist – nüchtern betrachtet – eigentlich nichts Besonderes passiert. Für Dienste gleich welcher Art braucht es in letzter Konsequenz Hardware, sowohl Server als auch Infrastruktur wie Switches, Router und nicht zuletzt eine gute Stromversorgung und entsprechende Klimatisierung. All diese Komponenten können ausfallen, weshalb sie möglichst ausfallsicher ausgelegt sein müssen, auch und gerade in einer Wolke, egal ob Private, Hybrid oder Public.

Cloudanbieter leisten sich aufgrund ihrer Größe aber deutlich aufwändigere Ausfallsicherheitskonzepte als ein kleines Unternehmen. Welches Kleinunternehmen kann für die von seiner IT angebotenen Dienste eine Verfügbarkeit von 99,95 Prozent zusichern, so wie dies Amazon verspricht? [9]

George Reese beschreibt in [10], dass der Ausfall nicht einen grundsätzlichen Designfehler im Cloudkonzept entlarvt, sondern einen Architekturfehler auf der Nutzerseite, also beim Einsatz von Clouddiensten. So sollte wie bei allen verteilten Systemen Verständnis dafür vorhanden sein, dass Ausfälle einfach dazugehören. Ein fehlertolerantes Design (Design for Failure) ist Pflicht.

Das ist teilweise auch schon bei einem einzelnen Anbieter wie Amazon möglich, wenn der Kunde Systeme an mehreren Standorten bucht. Amazon bietet beispielsweise fünf Standorte in über den Globus verteilten Zonen an. Aber hier beginnt schon die Verantwortung der Cloudnutzer: Sie müssen die Redundanz in der Wolke schaffen, indem sie in ihrer IT-Architektur Clouddienste als unsicher klassifizieren und entsprechende Ausweichmöglichkeiten im Fehlerfalle einplanen.

Ebenfalls eine verbreitete Ursache für derart fehleranfällige Architekturen ist der so genannte Vendor-Lock-in. Nicht nur aus Kostendruck, sondern auch durch vom Hersteller gewollt inkompatible Technologien sehen sich viele Unternehmen gezwungen, nur einen Cloudanbieter zu nutzen. Das liegt beispielsweise an Management-Tools, die nur für einen Dienst ausgelegt sind, und reicht bis zu Dateiformaten. Vor allem bei einem Anbieterwechsel, aber auch beim Zurück auf eigene Systeme, stellen sich hier große Hindernisse in den Weg.

Schritt für Schritt in die eigene Cloud

Die Auswahl eines Cloudpartners – beziehungsweise sinnvollerweise mehrerer – muss deshalb mit der Ermittlung der unternehmenskritischen Daten und Dienste und einer entsprechenden Risikoabschätzung beginnen. Meist verdienen hier die rechtlichen Rahmenbedingungen ein besonderes Augenmerk.

Die Klassifikation in Tabelle 1 hilft bei der Auswahl der Dienste, die für die Wolke – ob Private oder Public – in Frage kommen. Im nächsten Schritt ist zu prüfen, welche Anbieter sich eignen. Dabei spielt vor allem dessen Standort und der seiner genutzten Systeme eine Rolle, wobei Reputation und Zertifizierungen die Vorauswahl erleichtern. Danach sind entsprechende Verträge auszuarbeiten, die SLAs auszuwählen, Zuständigkeiten und Rechte des Anbieters widerspruchsfrei zu definieren.

Tabelle 1: Strategieplaner Cloud Computing

Tabelle 1: Strategieplaner Cloud Computing

Eine längere Testphase, sinnvollerweise mit Dummydaten, untersucht die Qualität der erbrachten Leistungen, die getroffenen Zusagen, die generelle Akzeptanz der Lösung und die Umsetzbarkeit von Notfallkonzepten. Erst nach eingehender Prüfung sollten Produktivdaten in der externen Wolke landen.

Gesetze, Markt und Dienste

Der Gesetzgeber fordert übrigens auch eine regelmäßige, fortlaufende Überprüfung des Dienstleisters. Sinnvoll ist es, den Marktüberblick zu behalten und das Vendor-Lock-in nachhaltig zu vermeiden, denn auch Cloudanbieter können in Insolvenz gehen. Schwieriger als die Vorgehensweise erweist sich jedoch die Abwägung, welche Dienste sich aus welcher Cloudform beziehen lassen, ohne Einschränkungen bei Verfügbarkeit, Sicherheit und Dienstqualität befürchten zu müssen.

Die Sorge um die Vertraulichkeit der Daten beeinflusst die Entscheidung, ob der Dienst in einer internen oder externen Wolke landen soll, stärker als die simple technische Machbarkeit. Eine Datenbank, ein Webserver oder auch ein CMS lassen sich intern und extern hosten, Downtime, Bandbreite und Standardisierungsgrad spielen dabei eine geringere Rolle als der Rechtsrahmen.

Hinzu kommt die Tatsache, dass sich IaaS, PaaS und SaaS sowohl in Private und Hybrid als auch Public Clouds einsetzen lassen. Hilfreiche Denkanstöße finden sich in Tabelle 1 “Strategieplaner Cloud Computing”.

World Wide Computer

In seinem Bestseller “The Big Switch” [11] zeichnet Nicholas Carr ein Bild der Zukunft, in der IT-Ressourcen aus dem “World Wide Computer” kommen, analog zum Bezug von Strom heutzutage, sodass Anwender nur noch eine Art Notstromversorgung im Haus behalten und der Rest einfach aus der Dose vom günstigsten Anbieter stammt.

Das ist noch Zukunftsmusik, klar hingegen ist bereits heute, dass es sich beim Einsatz von Services aus der Cloud um eine weiterentwickelte Spielart des seit Langem praktizierten Outsourcing-Konzepts handelt, das unkritische Ressourcen an externe Kräfte auslagert – mit allen damit verbundenen Vor- und Nachteilen sowie Risiken.

Die gestiegene Rechenleistung und schnelle Internetanbindungen erlauben solche IT-Strukturen und bieten unabhängig von der Unternehmensgröße vielfältige Möglichkeiten – sofern man Mittel und Wege findet, die rechtlichen Vorgaben einzuhalten und seine Architektur fehlertolerant zu gestalten.

Infos

  1. Kay Uwe Königsmann, “Reduzierter Glanz”: Linux-Magazin 03/11, S. 46
  2. Markus Feilner “Lack ab?”: Linux-Magazin 01/10, S. 28
  3. Bundesdatenschutzgesetz: http://www.gesetze-im-internet.de/bdsg_1990/index.html
  4. Steinbuch Centre for Computing SCC am KIT: http://www.scc.kit.ed
  5. Datev: http://www.datev.de/datevasp/
  6. Marc Heckert, “Wie ein Handy-Fan von Wolke Sieben fiel”: http://www.az-web.de/news/topnews-detail-az/1533902
  7. Rich Miller, “The Aftermath of Amazon’s Cloud Outage”: http://www.datacenterknowledge.com/archives/2011/04/25/the-aftermath-of-amazons-cloud-outage/
  8. “Life of our patients is at stake”: https://forums.aws.amazon.com/thread.jspa?threadID=65649&tstart=0
  9. Amazons SLA: http://aws.amazon.com/ec2-sla/
  10. George Reese, “The AWS Outage: The Cloud’s Shining Moment”: http://broadcast.oreilly.com/2011/04/the-aws-outage-the-clouds-shining-moment.html
  11. Nicholas Carr, “The Big Switch”: http://www.nicholasgcarr.com/bigswitch/

Der Autor

Holger Gantikow hat an der Hochschule Furtwangen Informatik studiert und ist seit 2009 bei der Science + Computing AG in Tübingen als System Engineer tätig. Dort beschäftigt er sich mit der Komplexität heterogener Systeme im CAE-Berechnungsumfeld.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 6 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben