Hintergrund zu TeamDrive und ownCloud

TeamDrive und ownCloud verfolgen zwei unterschiedliche Geschäftsmodelle. Wo sich TeamDrive als vollständig kommerzielles Produkt für Unternehmen am Markt positioniert, setzt ownCloud auf die Open-Source Community, um damit Marktanteile zu gewinnen. Mit einer kommerziellen Version adressiert ownCloud allerdings auch den Markt für professionelle Unternehmenslösungen.

Über TeamDrive

TeamDrive ist eine Filesharing und Synchronisations-Lösung für Unternehmen, die ihre sensiblen Daten nicht bei externen Cloud-Services speichern wollen und es ihren Teams zudem ermöglichen möchten, Daten oder Dokumente zu synchronisieren. Dazu überwacht TeamDrive beliebige Ordner auf einem PC oder Notebook, die man mit eingeladenen Anwendern gemeinsam nutzen und bearbeiten kann. Damit stehen Daten jederzeit, auch offline zur Verfügung. Eine automatische Synchronisation, Backups und Versionierung von Dokumenten schützen die Anwender vor Datenverlust. Mit der Möglichkeit die TeamDrive Registration- und Hosting-Server im eigenen Rechenzentrum zu betreiben, lässt sich TeamDrive in vorhandene IT-Infrastrukturen integrieren. Dafür stehen alle notwendigen APIs zur Verfügung.

Über ownCloud

ownCloud ist eine Open-Source Filesync- und –sharing-Lösung für Unternehmen und Organisationen, die ihre Daten weiterhin selbst unter Kontrolle behalten möchten und nicht auf externe Cloud-Storages zurückgreifen wollen. Der Kern der Anwendung besteht aus dem ownCloud Server über welchen sich die Software zusammen mit den ownCloud-Clients nahtlos in die existierende IT-Infrastruktur integriert und die Weiternutzung bereits vorhandener IT-Management-Tools ermöglicht. ownCloud dient als lokales Verzeichnis, bei dem unterschiedliche lokale Speicher gemountet werden. Dadurch stehen die entsprechenden Dateien allen Mitarbeitern auf allen Geräten zur Verfügung. Neben einem lokalen Storage können ebenfalls Verzeichnisse über NFS und CIFS angebunden werden.

TeamDrive und ownCloud: Die Sicherheitsarchitektur

In diesem Vergleich soll es um die Sicherheitsarchitektur hinter TeamDrive und ownCloud gehen. Der sonstige Funktionsumfang der beiden Lösungen wird nicht betrachtet. Es geht also um die Betrachtung der Verschlüsselungsverfahren, Datenhaltung, Datenverarbeitung und der Benutzerautorisierung, soweit Informationen zur Verfügung stehen. Dabei wird davon ausgegangen, dass grundlegende Kenntnisse zum Thema Sicherheit bekannt sind.

TeamDrive: End-to-End Verschlüsselung

TeamDrive ist trotz seines kommerziellen Ansatzes recht auskunftsfreudig und stellt einige Sicherheitsinformationen öffentlich zur Verfügung. Darunter zu dem Thema Verschlüsselung. Zudem wird mit dem Datenschutzsiegel des „Unabhängigen Landeszentrum für Datenschutz Schleswig-Holstein (ULD)“ geworben. Nach einer Anfrage wurden bereitwillig umfangreiche Informationen zur Verfügung gestellt, wobei einige jedoch einem NDA (Non-Disclosure Agreement) unterliegen.

Verschlüsselungsverfahren

TeamDrive setzt auf die folgenden Verschlüsselungsmechanismen:

• Advanced Encryption Standard – AES 256
  Zur Verschlüsselung der Daten setzt TeamDrive auf das Advanced Encryption Standard (AES) Kryptosystem mit einem 256 Bit Schlüssel und verwendet die C Code Implementation der OpenSSL library.
• Diffie-Hellman und RSA 3072
  Für den Schlüsselaustausch setzt TeamDrive bei seinen älteren Clients auf den Diffie-Hellman Algorithmus. Neue Clients hingegen verwenden RSA 3072. Die Diffie-Hellman Implementierung basiert dabei auf der C Code Implementation wie sie von der OpenSSL library zur Verfügung gestellt wird.
• Message Digest 5/6 – MD5/MD6
  Der TeamDrive Hash-Funktionalität liegt der MD5 bzw. MD6 Algorithmus zu Grunde, wobei der Hashwert mit einer zufällig gewählten Zeichenfolge (Salt) gespeichert wird.
• PrimeBase Privacy Guard – PBPG
  Der PrimeBase Privacy Guard (PBPG) ist ein proprietäres Public/Privat Schlüsselsystem, das auf dem Diffie-Hellman Schlüsselaustausch und der AES Verschlüsselung aufsetzt. Das Verhalten von PBPG für den Anwender gleicht dem bekannten Public/Privat Schlüsselsystemen von PGP oder GnuPG. Die PBPG-Verschlüsselung generiert zufällige Änderungen und verifiziert die Dateien während des Austauschs, damit PBPG erkennen kann, ob eine Nachricht oder ein Schlüssel manipuliert oder anderweitig verändert worden sind. Zwei Nachrichten sind dabei niemals gleich. Dabei wird nicht nur für jeden Benutzer ein Schlüsselpaar erzeugt, sondern ebenfalls für jede Installation. Die PBPG Implementierung ist offen und kann bei Bedarf von Partnern und anderen Interessierten überprüft werden.

Systemarchitektur

Daten werden bei TeamDrive in einem sogenannten Space gespeichert, auf dem eine festgelegte Anzahl von Nutzern Zugriff erhalten kann. Der Austausch findet über ein Space Depot statt, welches auf einem TeamDrive Hosting Server oder WebDAV liegen kann.

Jeder Space verfügt über seinen eigenen 256 Bit AES Schlüssel, der für die Verschlüsselung der Daten in diesem Space genutzt wird, wenn die Daten das Endgerät des Nutzers verlassen. Dabei hat nur die TeamDrive Software, welche auf dem Endgerät der anderen Nutzer eines Spaces installiert ist, Kenntnisse über den Schlüssel.

Jeder Server auf dem ein Space Depot zur Verfügung steht, ist für das Speichern, Weiterleiten und Anpassen von Veränderungen innerhalb des Depots verantwortlich. Damit können die Clients auch dann Daten austauschen, wenn nicht alle zur selben Zeit online sind. Alle Daten, die auf dem Server gespeichert sind, werden mit einem 256 Bit AES Schlüssel des Spaces verschlüsselt.

Benutzerautorisierung

Die Anmeldung eines Nutzers erfolgt über die TeamDrive Client-Software, die ihn gegen den TeamDrive Registrierungsserver überprüft. Das erfolgt grundsätzlich über die Eingabe einer E-Mail Adresse oder eines Benutzernamens und eines Passworts.

Die Autorisierung zwischen dem TeamDrive Client und dem Registrierungsserver erfolgt auf Basis des Public Key des Registrierungsserver. Informationen wie die E-Mail-Adresse und das Registrierungspasswort plus weitere Daten des Benutzers werden unter der Verwendung des Public Key des Registrierungsservers verschlüsselt an den Registrierungsservers übertragen.

Einzig der Aktivierungscode wird unverschlüsselt über eine ebenfalls unverschlüsselte E-Mail an den Nutzer verschickt. Zudem wird eine verschlüsselte Antwort mit der Device ID an den TeamDrive Client gesendet. Nach der Aktivierung durch den Nutzer generiert die Client-Software einen PBPG Key und einen passenden Public Key. Im Anschluss schickt die Client-Software das Registrierungspasswort und den Public Key verschlüsselt, unter Verwendung des Public Keys des Servers, an den Registrierungsserver zurück. Der Aktivierungscode wird verifiziert und der Public Key des Nutzers gespeichert. Alle im Anschluss folgenden Nachrichten, die an den Registrierungsserver geschickt werden, sind mit dem PBPG Public Key des Nutzers verschlüsselt und benötigen die Geräte-ID und das Registrierungspasswort zur Autorisierung.

Datenhaltung und Verarbeitung

Zum Erzeugen eines Space, benötigt der Benutzer ein Space Depot und dessen Passwort. Damit weiß der TeamDrive-Client, mit welchem Server er Kontakt aufnehmen muss, um den Space zu erzeugen. Anschließend fordert die Client-Software den Public Key des TeamDrive Hosting Servers an. Die Client Software sendet die Geräte-ID, die Space Depot ID, Benutzername, Benutzer-ID, den Public Key des Benutzers und den Namen des Spaces als verschlüsselte Nachricht an den TeamDrive Server. Die Nachricht wird mit dem Public Key des Servers verschlüsselt übertragen. Die Space Depot ID und das Passwort werden überprüft. Für die verschlüsselte Übertragung der Antwort wird der Public Key des Benutzers verwendet. Der TeamDrive Server erstellt einen neuen Space auf dem vorgegebenen Space Depot. Ein 128 Bit “Genehmigungscode” wird zufällig für den neuen Space erzeugt und an den Client zurückgesendet.

Für den Zugriff auf einen Space wird die entsprechende URL, ein Autorisierungscode und ein Space Datenschlüssel benötigt. In der URL ist die Adresse des Servers, über die das Space Depot mit dem Inhalt des Spaces angesprochen wird, sowie die Space ID, enthalten. Veränderungen in dem Space werden auf das Space Depot und in den Space hochgeladen bzw. heruntergeladen. Dabei werden HTTP PUT und POST Methoden verwendet. Bevor eine Datei den Client verlässt, wird diese komprimiert und mit dem 256-Bit AES Schlüssel verschlüsselt.

Um auf einen Space zuzugreifen, öffnet der TeamDrive Client eine Session mit dem Server. Darin wird zunächst die ID des Space, auf den der Zugriff stattfinden soll, übertragen. Der Server erzeugt nach erfolgreicher Prüfung eine neue Session ID mit einer 128-Bit Zufallszahl (RND) und sendet diese an den Client zurück, der hier lokal abgelegt wird. Für das Hochladen und Löschen von Daten verwendet der Client die RND und den Autorisierungscode des Space und verknüpft diese xor inkl. einer MD5 Operation auf dem Ergebnis. Das Ergebnis wird zusammen mit der Session ID und den verschlüsselten Daten an den Server geschickt.

Die Sicherheit eines Space Depot wird dadurch sichergestellt, dass nach jeder Anfrage ein zufälliger RND Wert zurückgesendet wird, die der Client jedes Mal für einen lokalen Wert neu berechnen muss. Zudem garantiert ein MD5 Hash, dass der Autorisierungscode des Space nicht abgeleitet werden kann. Auch dann wenn der RND und der lokale Wert auf der Client-Seite bekannt sind. Damit wird ebenfalls verhindert, dass ein Angreifer in eine Session eindringen kann, um Daten auf den Server hochzuladen.

Zusammenfassung

Die Datensicherheit in einem TeamDrive Space wird durch die Verschlüsselung der Daten mit einem 256-Bit AES Schlüssel sichergestellt. Dabei ist der Schlüssel nur den TeamDrive Clients bekannt die Mitglied eines Space sind. Anbieter von Storage-Services auf Basis von TeamDrive oder Systemadministratoren haben keinen Zugriff auf die Daten. Der Austausch der Space Autorisierungsschlüssel unter TeamDrive Nutzern erfolgt mit einem sicheren Public/Privat-Key Verfahren, welches selbst eine 256-Bit AES Verschlüsselung verwendet. Der Zugriff auf ein Space Depot bzw. einem Space wird mit einem 128-Bit Autorisierungscode geschützt. Mit dem Autorisierungscode wird verhindert, dass der Speicherplatz eines Space Depot bzw. eines Space von unautorisierten Dritten verwendet werden kann.

Neben der verschlüsselten Speicherung der Daten auf den Servern und den Clients, werden die Daten ebenfalls während der Übertragung immer komplett verschlüsselt, wodurch TeamDrive eine vollständige End-to-End Verschlüsselung der Daten gewährleistet.

Weiterhin ist zu erwähnen, dass TeamDrive von dem “Unabhängigen Landeszentrum für Datenschutz in Schleswig Holstein (ULD)” das Datenschutzgütesiegel erhalten hat. Die Prüfnummer lautet 2-3/2005. Darüber hinaus wurde TeamDrive im Mai 2013 von Gartner zum “Cool Vendor in Privacy” 2013 benannt.

ownCloud: Serverseitige Verschlüsselung

Bei ownCloud sucht man vergeblich nach öffentlichen Sicherheitsinformationen, die von ownCloud selbst zur Verfügung gestellt werden. Das verwundert ein wenig, da selbst in der ownCloud Community scheinbar viele offene Fragen [1], [2] hinsichtlich der Serverseitigen Verschlüsselung und der Verschlüsselung im Allgemeinen bestehen. Einzig ein Blog-Beitrag ist zu finden, in dem das grundsätzliche Verständnis von ownCloud zum Thema Sicherheit öffentlich dargestellt wird. Auf direkte Nachfrage bei ownCloud wurden jedoch anstandslos Fragen beantwortet und weitere Informationen zur Verfügung gestellt.

Verschlüsselungsverfahren

Für die Verschlüsselung der Daten setzt ownCloud 5.0 auf den Advanced Encryption Standard (AES) mit einem 256 Bit Schlüssel.

Der Sicherheitsblogger Pascal Junod hatte sich Anfang 2012 mit der Verschlüsselung von ownCloud 4.0 auseinandergesetzt. Die notwendigen Informationen sind in der OC_Crypt class zu finden. Junod hat in diesem Zusammenhang diese PHP Datei analysiert und entsprechende Informationen veröffentlicht. Demnach wird der Schlüssel in der mt_rand() PHP Routine generiert. Die den Mersenne Twister, einen Pseudozufallszahlengenerator, implementiert. Junod kommentiert, das es sich dabei nicht um eine kryptographisch gute Qualität handelt. Der generierte Schlüssel wird mit dem Benutzerpasswort in Verbindung mit dem symmetrischen Blockverschlüsselungsalgorithmus Blowfish im ECB Mode verschlüsselt und anschließend in der encryption.key gespeichert. Junod kommt zu der Schlussfolgerung, dass ein Angreifer im Besitz dieser Datei über die Brute-Force-Methode an das Passwort gelangen könnte. Er macht zudem darauf aufmerksam, dass dieser Schlüssel für die Verschlüsselung sämtlicher Daten eines Nutzers verwendet wird und dass die Daten serverseitig verschlüsselt werden. Er beschreibt weitere Möglichkeiten, um die encryption.key zu stehlen. So wird das Passwort, welches für die Verschlüsselung der Datei zuständig ist, in Klartext (einfaches HTTP) vom Client an den Server übertragen. Wird die Verbindung nicht mit HTTPS gesichert, ist jeder in der Lage die Kommunikation abzuhören und das Passwort zu stehlen und könnte somit auf den ownCloud Account und sämtliche Daten zugreifen. Weiterhin wird die encryption.key im Klartext in den Sitzungsdaten auf der Serverseite gespeichert. Die meiste Zeit im /tmp Verzeichnis. Das bedeutet, dass ein böswilliger ownCloud Serveradministrator in der Lage wäre, die Daten zu entschlüsseln. Zudem weißt Junod darauf hin, dass die Verschlüsselung serverseitig vorgenommen wird, wodurch ein Systemadministrator mutwillig die ownCloud Installation manipulieren könnte. Er empfiehlt daher ownCloud 4.0 niemals einzusetzen, um vertrauliche Informationen zu speichern.

ownCloud bestätigt in der Anfrage, dass ownCloud 5.0 selbst keine vollständig integrierte End-to-End Verschlüsselung in der Software implementiert hat. Dies kann jedoch mit Tools von Drittanbietern realisiert werden. Weiterhin wird Verschlüsselung “at rest” betrieben. Das bedeutet, dass die Daten physikalisch in verschlüsselter Form gespeichert werden. Die Verbindung zwischen den Endgeräten und dem Server wird mit SSL gesichert. Der Schlüsselaustausch erfolgt autorisiert über die Provisioning API. Ein umfangreiches Schlüsselmanagement soll in Zukunft folgen.

Systemarchitektur

ownCloud verfügt über ein Plugin für die serverseitige Verschlüsselung, mit der Administratoren die Daten verschlüsselt auf dem Server ablegen können. Nutzer erhalten Zugriff auf die Daten und können diese teilen, als seien sie unverschlüsselt. Das neue Plugin in ownCloud 5.0 ersetzt dabei die Sicherheitslücke in ownCloud 4.0, bei der ein böswilliger Systemadministrator die Sicherheitsarchitektur umgehen konnte, indem er Anpassungen am ownCloud Quellcode vornehmen konnte, um eine Backdoor oder einen Passwort Sniffer zu integrieren. Für die Verschlüsselung der Daten während der Übertragung vom Server zum Endgerät wird SSL verwendet. Das Passwort kann von einem Nutzer jederzeit geändert werden. Sämtliche Dateien werden anschließend mit dem neuen Passwort verschlüsselt.

Für eine serverseitige Sicherheit muss der Administrator die Verschlüsselungs-App in ownCloud der ownCloud Managementkonsole aktivieren und den Hacken „Verschlüsselung“ in der Admin-Oberfläche setzen. Anschließend wird ein Schlüsselpaar (Public/ Private) für alle Nutzer erstellt. Hierzu wird das Nutzerpasswort verwendet, um den privaten Schlüssel zu schützen. Darüber hinaus wird, für jede auf den Server hochgeladene Datei, ein symmetrisches Schlüsselpaar erstellt. Die von dem Nutzer hochgeladenen Daten werden mit dem symmetrischen Schlüssel verschlüsselt und gespeichert. Als Algorithmus wird der Advanced Encryption Standard (AES 256) verwendet. Der symmetrische Schlüssel wird mit dem privaten Schlüssel des Nutzers verschlüsselt und auf dem Server abgelegt. Werden die Daten von dem Server abgerufen, werden sie zunächst entschlüsselt und anschließend über eine SSL-Verbindung an den Client gesendet. Die Verschlüsselungsroutine verhält sich mit anderen, an ownCloud angebundenen Applikationen, wie der Web-Oberfläche, der Versionierung und dem Algorithmus für die Synchronisierung, exakt gleich. Ändert ein Nutzer sein Passwort, wird sein privater Schlüssel mit dem alten Passwort entschlüsselt und mit dem neuen Passwort erneut verschlüsselt.

Für den Nutzer gleicht eine auf den ownCloud Server hochgeladene und anschließend verschlüsselte Datei wie eine nicht verschlüsselte Datei. Die Verschlüsselung ist für ihn vollständig transparent. Wird eine Datei mit einem anderen Nutzer geteilt, werden die öffentlichen Schlüssel von jedem dieser Nutzer in der verschlüsselten Datei hinterlegt. Diese Nutzer können damit auf die Datei zugreifen und Änderungen an ihr vornehmen, als handelt es sich um eine unverschlüsselte Datei. Genauso verhält es sich mit einem Ordner. Nutzer können keine Dateien öffnen, die nicht für sie bestimmt sind. Sollte ein böswilliger Nutzer versuchen, Zugriff auf das Speicher-Backend zu nehmen, werden die Dateien und Schlüssel darin unlesbar.

Ist das entsprechende Plug-In aktiviert, ist ein Systemadministrator in der Lage, über die Kommandozeile, alle Dateien zu sehen, die auf ownCloud gespeichert sind. Allerdings sind die Inhalte der Dateien verschlüsselt. Es können weiterhin normale Backups vorgenommen werden, jedoch bleiben alle Dateien verschlüsselt. Selbst dann, wenn die Daten nach außerhalb des Systems kopiert werden. Ein Administrator kann zudem weitere Einstellungen vornehmen, um bestimmte Dateigrößen und -formate von der Verschlüsselung auszuschließen.

Zusammenfassung

Mit der Version 5.0 bietet ownCloud nun auch serverseitige Verschlüsselung der Daten an. Jedoch muss von einem Administrator dazu explizit ein Plug-In aktiviert werden, um Dateien mit AES 256 zu verschlüsseln. Verlässt eine Datei den ownCloud Server wird sie zunächst entschlüsselt und über eine SSL-Verbindung an den ownCloud-Client übertragen. Das bedeutet, dass eine vollständige End-to-End Verschlüsselung derzeit mit einfachen Bordmittel nicht zur Verfügung steht, was ownCloud selbst bestätigt.

Das ownCloud Encryption-Module wurde für den Einsatz innerhalb eines Unternehmens-Rechenzentrum, auf unternehmenseigenen Servern und unter der Verwaltung von vertrauensvollen Administratoren, entwickelt.

Empfehlung für das Management: TeamDrive vs. ownCloud

Der Vergleich von TeamDrive mit ownCloud stellt gewissermaßen auch einen kommerziellen einem Open-Source Ansatz gegenüber. Was hier jedoch ein wenig irritiert ist die Offenheit des kommerziellen Anbieters TeamDrive gegenüber ownCloud. Kommerzielle Anbieter werden oftmals kritisiert, wenig über ihre Sicherheitsarchitektur zu sprechen. In diesem Fall sehen wir genau das Gegenteil. Das mag bei ownCloud möglicherweise daran liegen, dass bisher nicht viel Sicherheit respektive Verschlüsselung implementiert war, über die man sprechen konnte. Erst mit der ownCloud Version 5.0 wurde ein Modul für die serverseitige Verschlüsselung implementiert. Dass allerdings Informations- aber insbesondere Sicherheitsbedarf besteht, zeigen die Fragen aus der ownCloud Community. Hier ist die ownCloud Community auch weiterhin gefordert, mehr öffentliche Informationen und Sicherheit einzufordern.

In diesem Zusammenhang macht der Inhalt des oben angesprochenen Blog-Artikels von ownCloud Sinn, der die grundlegende Sicherheitsphilosophie von ownCloud widerspiegelt. ownCloud sieht das Thema Verschlüsselung zwar als einen wichtigen Punkt an. Der Fokus sollte aber eher auf der Kontrolle der Daten liegen.

Sicherheit vs. Flexibilität

TeamDrive setzt auf einen vollständig integrierten Ansatz und bietet zudem eine End-to-End Verschlüsselung aller Daten, die vom Server zum Client des jeweiligen Endgeräts übertragen werden. Damit ermöglicht es TeamDrive trotz eines sehr hohen Anspruchs an das unbequeme Thema Sicherheit, die bequeme Nutzung eines Cloud-Storage Service. ownCloud entschlüsselt die Daten erst wenn diese vom Server geladen werden und überträgt sie in einer SSL-Verbindung. Die fehlenden Bordmittel zur End-to-End Verschlüsselung lassen sich mit externen Lösungen von Drittanbietern erreichen. Hier sollte jedoch bedacht werden, dass die Integration damit aufwändiger wird und ob ein Open-Source Ansatz speziell in diesem Fall noch Kostenvorteile bietet.

Verschwiegen werden darf nicht, dass ownCloud auf Grund seines Open-Source Ansatzes mehr Flexibilität bietet als TeamDrive und damit vollständig den eigenen Bedürfnissen nach an die eigene IT-Infrastruktur angepasst werden kann, wenn das erforderlich ist. Hinsichtlich der Sicherheit besteht bei ownCloud allerdings noch Nachholbedarf. Das hat zur Folge, dass die Lösung per se nicht den aktuellen Sicherheitsansprüchen von Unternehmen entspricht und daher nur bedingt zu empfehlen ist.

Am Ende muss die Entscheidung getroffen werden, ob ein Unternehmen einen kommerziellen und integrierten Ansatz inklusive Sicherheitsmechanismen anhand von Bordmittel erwartet oder eine Open-Source Software, für die weitere externe Sicherheitslösungen benötigt werden, die selbst zu integrieren sind. Wer eine All-in-One Lösung inklusive vollständiger End-to-End Verschlüsselung und damit gleichzeitig mehr Sicherheit sucht, sollte sich für TeamDrive entscheiden.

Über TeamDrive

TeamDrive ist eine Filesync- und -share-Lösung für Unternehmen und Organisationen, die nicht riskieren wollen, dass sensible Daten bei externen Cloud-Services verstreut werden und ermöglicht es Daten oder Dokumente im Team zu synchronisieren. Dazu überwacht TeamDrive beliebige Ordner auf einem PC oder Notebook, die man mit eingeladenen Anwendern gemeinsam nutzen und bearbeiten kann. Damit stehen Daten jederzeit, auch offline zur Verfügung. Die automatische Synchronisation, Backups und Versionierung von Dokumenten schützen die Anwender zuverlässig vor Datenverlust. Mit der Möglichkeit die TeamDrive Registration und Hosting-Server im eigenem Datacenter zu betreiben, lässt sich TeamDrive sehr gut in vorhandene IT-Infrastruktur integrieren. TeamDrive stellt hierzu alle notwendigen APIs zur Verfügung.

Mehr über TeamDrive ist unter “TeamDrive: Dropbox für Unternehmen” zu finden.

Darüber hinaus arbeite ich gerade an einem Sicherheitsvergleich zwischen TeamDrive und der Open-Source Cloud Storage Lösung ownCloud. Diese wird in den nächsten Tagen hier auf CloudUser und als Paper (PDF) veröffentlicht.

Neuigkeiten zur Google Compute Engine

Mit der Google App Engine, BigQuery und dem Google Cloud Storage hat Google seit 2008 sein Cloud Portfolio stetig ausgebaut. Was noch fehlte war eine Infrastructure-as-a-Service Lösung, mit der virtuelle Maschinen bei Bedarf genutzt werden können. Die Google Compute Engine (GCE) brachte Google zu seiner I/O 2012 in einer geschlossenen Beta auf den Markt, um virtuelle Maschinen (VM) mit dem Linux Betriebssystem auf der Google Infrastruktur, die auch von Google Mail und anderen Services eingesetzt wird, zu nutzen.

Zusammen mit der Google I/O 2013 hat die GCE nun auch den Status der allgemeinen Verfügbarkeit erreicht. Weiterhin hat Google einen Cloud Datastore, eine von Google vollständig verwaltete NoSQL Datenbank für nicht relationale Daten, veröffentlicht. Der von der GCE unabhängige Service bietet eine automatische Skalierbarkeit, ACID Transaktionen sowie SQL-artige Anfragen und Indizes. Weiterhin gibt es eine eingeschränkte Vorschau der Programmiersprache PHP für die App Engine. Damit will Google Entwickler und Nutzer von Open-Source Applikationen wie z.B. WordPress ansprechen. Zudem wurde die Integration mit anderen Teilen der Cloud Plattform wie Google Cloud SQL und Cloud Storage verbessert. Darüber hinaus geht Google auf die Rückmeldung seiner Nutzer ein, dass es möglich sein sollte, Applikationen auf der App Engine einfacher modularisiert zu entwickeln. Als Reaktion darauf ist es nun möglich, Applikationen in einzelne Komponenten zu partitionieren. Jede mit ihrer eigenen skalierungs-, bereitstellungs-, versionierungs- und performance- Einstellung.

Weitere Neuigkeiten

Zu den weiteren größeren Ankündigungen gehören u.a. eine granularere Abrechnung, neue Instanz-Typen sowie eine ISO 27001 Zertifizierung:

• Genauere Abrechnung: Jeder Instanz-Typ wird nun pro Minute abgerechnet, wobei 10 Minuten mindestens berechnet werden.
• Neue Instanz-Typen: Es gibt nun neue Micro- und Small Instanz-Typen, die dafür gedacht sind, kostengünstig kleinere Workloads zu verarbeiten, die nur wenig Rechenleistung benötigen.
• Mehr Speicherplatz: Die Größe der “Persistent Disks”, die mit einer virtuellen Instanz verbunden werden können, wurden um bis zu 8.000 Prozent erweitert. Das bedeutet, dass nun eine Persistent Disk mit einer Größe von bis zu 10 Terabyte an eine virtuelle Maschine der Compute Engine angehängt werden kann.
• Erweitertes Routing: Die Compute Engine unterstützt nun basierend auf dem eigenen SDN (Software-Defined Networking) Möglichkeiten für das Software-Defined Routing. Damit lassen sich Instanzen als Gateways und VPN-Server einsetzen und Applikationen so entwickeln, dass diese im eigenen lokalen Netzwerk als auch in der Google Cloud laufen.
• ISO 27001 Zertifizierung: Die Compute Engine, App Engine und Cloud Storage wurden vollständig mit ISO 27001:2005 zertifiziert.

Entwickler: Google vs. Amazon vs. Microsoft

Zunächst, die größte Ankündigung für die Google Compute Engine (GCE) ist ihre allgemeine Verfügbarkeit. In den letzten Monaten wurde die GCE nach jeder Neuigkeit als DER Amazon Killer hochgehalten, obwohl sie sich noch in einer geschlossenen Beta befand und somit kein Vergleich auf Augenhöhe bestand. Die wirkliche Zeitrechnung beginnt jetzt.

Viele versprechen sich von der GCE, dass Google damit einen echten Konkurrenten zu den Amazon Web Services schafft. Fakt ist, das es sich bei der Google Compute Engine um ein IaaS Angebot handelt und Google auf Grund seines Kerngeschäfts über die Expertise, hochskalierbare Infrastrukturen aufzubauen und diese hochverfügbar zu betreiben, verfügt. Die Google App Engine zeigt darüber hinaus, dass Google es versteht, Entwickler anzusprechen, auch wenn sich der Markt hier mit zunehmend attraktiven Alternativen verengt.

Es fehlt die Diversifikation

Schauen wir uns die Compute Engine an, dann sehen wir Instanzen, Speicherplatz, sowie Services für das Speichern und Verarbeiten von strukturierten und unstrukturierten Daten (Big Query, Cloud SQL und Cloud Datastore). Wer Google unter diesen Gesichtspunkten daher als DEN Amazon Killer sieht, sollte seine Erwartungen erst einmal ein wenig herunterschrauben. Amazon hat ein sehr diversifiziertes Portfolio an Cloud Services, mit denen die Amazon Cloud Infrastruktur genutzt werden kann. Daran muss Google erst einmal anknüpfen, was sich allerdings nicht als all zu schwer erweisen dürfte, da viele Google Services bereits vorhanden sind. Ein Blick auf das Serviceangebot von Amazon AWS und der Google Cloud Platform ist aus diesem Grund lohnenswert.

Hybrid Betrieb für Applikationen

Google darf auf keinen Fall unterschätzt werden. Im Gegenteil, aus einem ersten Performance-Vergleich zwischen der Google Cloud Platform und Amazon AWS ging Google als Sieger hervor. Das liegt u.a. an den Technologien, die Google ständig verbessert sowie an seinem weltweiten hochperformanten Netzwerk. Was besonders auffällt, Google bietet nun die Möglichkeit, Applikationen für einen hybrid Betrieb, im eigenen Rechenzentrum und in der Google Cloud, zu entwickeln. Das ist ein unerwarteter Schritt, da bei Google bisher eher die Devise “Cloud only” lautete. Allerdings hat auch Google in letzter Zeit ähnlich wie Amazon mit technischen Ausfällen zu kämpfen gehabt, was nicht zur Stärkung des Vertrauens in Google beiträgt.

Ein Seitenhieb ist das neue Preismodell. Instanzen werden nun pro Minute (mindestens 10 Minuten Nutzung) abgerechnet. Amazon und auch Microsoft rechnen ihre Instanzen derzeit noch pro Stunde ab. Ob die Erweiterung der “Persistent Disks” auf bis zu 10 Terabyte zur Diversifikation beiträgt wird sich zeigen. Amazon gilt auch unter Entwicklern als der Vorreiter unter den IaaS Anbietern, was es für Google nicht einfacher machen wird in diesem Segment (Entwickler) ausreichend Marktanteile zu gewinnen. Außerdem darf Google davon ausgehen, dass neben den gewöhnlichen Nutzern, ebenfalls Entwickler keine Lust auf Googles “Service an/aus” Spielchen haben.

Amazon und Microsoft sind schon einen Schritt voraus

Wo Google mit seiner SaaS Lösung Google Apps seit geraumer Zeit massiv auch Unternehmenskunden angeht, richtet sich die Compute Engine in erster Linie an Entwickler. Amazon und Microsoft haben auch in diesem Kundensegment angefangen, aber längst damit begonnen, ihre Infrastrukturen respektive Plattformen für Unternehmenskunden attraktiver zu machen. Hier wird auf Google noch viel Arbeit zukommen, wenn dieses Kundensegment erschlossen werden soll, was zwangsläufig unumgänglich ist. Allerdings geht es in diesem Bereich um viel mehr als nur Technologien, sondern darum, Vertrauen zu schaffen und organisatorische Themen (Datenschutz, Verträge, SLA, usw.) für wertvoll zu erachten.

Googles Problem: Unbeständigkeit

Keine Frage, bei Google handelt es sich mit Abstand um das innovativste Unternehmen auf unserem Planeten. Aber gleichermaßen auch um das Unbeständigste und Datenhungrigste. Das werden auch Entwickler und speziell Unternehmen beobachtet haben und beide sollten sich die Frage stellen, wie Zukunftssicher das Google Cloud Portfolio überhaupt ist. Wird die Compute Engine ein Erfolg, braucht man sich keine Sorgen machen. Aber was ist, wenn sie für Google(!) zum Ladenhüter wird. Man erinnere sich an den Google Reader, dessen Nutzerzahlen für Google nicht mehr ausreichend genug waren. Hinzu kommt, dass die Compute Engine einen weiteren KPI hat, den Umsatz! Was macht Google, wenn dieser nicht mehr stimmen sollte?!

Geschwindigkeit: Der Caterham F1 unter den Cloud Storages

Das ist wirklich ein analog sehr gut gewähltes Beispiel. SkyDrive kommt einfach nicht aus dem Knick. Die initiale Synchronisation hat ernsthaft(!) fast zwei Wochen benötigt! Ich muss zu SkyDrives Verteidigung sagen, dass ich nur hinter einer 4 MBit (3,7 Mbit/s) Leitung mit 288 kbit/s Upload sitze. Dennoch war die immer so oft gewählte Marketing-Floskel “Customer Experience” mit Dropbox viel galaktischer. Sicherlich war ich mit Dropbox, welches ich vorher genutzt habe, verwöhnt. Das hängt u.a. mit der Deduplizierung zusammen, die SkyDrive nicht verwendet.

Dennoch bin ich nicht der Einzige, der sich über die Geschwindigkeit beklagt. In der Microsoft Community wird ebenfalls von einer “Terrible Skydrive speed performance” gesprochen.

Transparenz: Man weiß nicht was SkyDrive macht

Das ist wirklich das Schlimmste! Man weiß einfach nicht was SkyDrive im Hintergrund macht. Nach dem Start zeigt das Symbol in der Taskleiste “Änderungen werden gesucht” an. Das kann schon mal etwas länger dauern. Eine Statusanzeige wie “x Prozent von y”? Fehlanzeige!

Werden Dateien synchronisiert, verwendet SkyDrive die Statusanzeige: “Änderungen werden verarbeitet”. Ja, aber welche Dateien genau? Und wie lange dauert die Synchronisation noch? Was heißt denn Änderungen werden verarbeitet? Und warum dauert das z.B. mal 2 Stunden, ohne das etwas passiert? Ein Benutzer wird hier total im Stich gelassen. Das ist besonders ärgerlich, wenn man “mal eben” etwas in den SkyDrive Ordner kopiert, um es unterwegs auf einem anderen Gerät nutzen zu können.

Unzuverlässig: SkyDrive Client hängt sich immer wieder auf

In diesem Zusammenhang kommt es dann auch zu dem sehr unglücklichen Umstand, dass sich der SkyDrive Client im Hintergrund anscheinend aufhängt. Da man jedoch nicht weiß, was genau im Hintergrund passiert, ist man als Nutzer völlig aufgeschmissen. Man möge dann meinen, unter “Synchronisationsprobleme anzeigen”, mit einem Rechtsklick auf das SkyDrive Icon in der Taskleiste, gibt es mehr Informationen. Leider nicht, dieser ist ständig grau. Bedeutet also, dass alles in Ordnung ist. Ich frage mich dann aber, wie alles in Ordnung sein kann, wenn “Änderungen werden verarbeitet” über 9 Stunden für eine Dateigröße von nicht einmal 2MB angezeigt wird. Das ist KEIN SCHERZ!

Manchmal kann man dieses Problem lösen, wenn man den SkyDrive Client beendet und neu startet. Oftmals bringt das aber nichts. Das bedeutet dann, man muss die Dateien, die man eigentlich synchronisieren möchte, wieder aus dem SkyDrive Ordner nehmen, den Client neu starten und die Dateien einzeln hochladen lassen, bis “Alles Aktuell” ist. Jedoch hat auch das sehr oft nicht funktioniert. Dann heißt die Devise: Browser auf; SkyDrive.com öffnen; und alles von Hand in die entsprechenden Ordner hochladen!

Ich habe mal einen Blogbeitrag gefunden, in dem erklärt wurde, dass dieses Problem wohl an der lokalen SkyDrive Datenbank liegen soll. Die Lösung war, die Verknüpfung des PCs mit SkyDrive aufzuheben und neu zu erstellen. Dann wird die Datenbank neu abgeglichen, was quasi einer initialen Synchronisation entspricht. Unter Windows 7 hat es funktioniert. Allerdings ist das KEINE Lösung! Seit Windows 8 ist SkyDrive jedoch direkt mit dem Benutzer in das Betriebssystem integriert. Somit ist “Diese Option nicht verfügbar, da Sie mit einem Microsoft-Konto angemeldet sind.”

Just wo ich diesen Artikel schreibe, bin ich gerade dabei, eine 3,85 MB PDF-Datei hochzuladen. Status: “Änderungen werden verarbeitet” – “Letztes Update vor 58 Minuten”. Und ich habe den Client bereits zwei Mal neu gestartet.

Kosten: Unschlagbar

Hinsichtlich der Kosten gibt es keinen Kritikpunkt. Neue SkyDrive Nutzer erhalten 7GB kostenlosen Speicher. Die Speichererweiterungen werden in drei Kapazitätsstufen angeboten. Diese erweitern das kostenlose und bestehende SkyDrive Kontingent. 20GB Speicher kosten 8,00 € pro Jahr, 50GB 19,00 € pro Jahr und 100GB 37,00 € pro Jahr.

Mobile Clients: Gut bedienbar und schnell

Auch an den mobilen Clients gibt es meinem Befinden nach nichts zu kritisieren. Bis auf Linux, stehen für alle Betriebssysteme inkl. iOS und Android Clients zur Verfügung. Die mobilen Clients sind gut und flüssig zu bedienen. Auch der Zugriff auf die Daten im SkyDrive geht schnell.

Unter diesem Umständen nur bedingt empfehlenswert

Trotz der vergleichsweise geringen Kosten, der guten Integration in andere Microsoft Produkte sowie der guten mobilen Clients, kann ich SkyDrive unter den Gesichtspunkten der Geschwindigkeit aber insbesondere der Verlässlichkeit bisher nur bedingt weiterempfehlen. Vielleicht mache ich auch etwas falsch oder habe irgendwo ein Häkchen falsch gesetzt, was ich beides bezweifle, weil SykDrive hier wirklich auf Einfachheit setzt, was wiederum gut ist.

SkyDrive Pro habe ich mir bisher noch nicht angeschaut. Wenn das Produkt, wohl gemerkt für Unternehmen(!), allerdings genau so implementiert ist, dann gute Nacht!

Hilfe auf dem Weg in die Cloud

Bereits als einfacher Managed-Hosting Anbieter hat Rackspace seine Kunden beim Infrastrukturmanagement unterstützt. Für seine OpenStack basierte Cloud Plattform wurde der Standard Support nun erweitert. Kunden sollen ab sofort auch Unterstützung auf Applikationsebene inkl. Debugging der Anwendung erhalten, die auf der Rackspace Cloud betrieben wird. Das bedeutet, dass die Interaktion mit den Kunden deutlich verstärkt werden soll, indem nicht nur die Grundlagen, sondern spezifisches Entwickler Know How vermittelt wird. Das geht sogar soweit, dass Rackspace Ingenieure bei Wunsch den Quellcode der Applikation analysieren und Verbesserungsvorschläge für eine effektivere Nutzung auf der Rackspace Cloud und insbesondere mit den Rackspace APIs und SDKs machen oder sogar bei der vollständigen Entwicklung helfen. Entwicklern soll es damit einfacher gemacht werden, zu verstehen, wie ihre eigene native Applikation auf der Rackspace Cloud bzw. OpenStack funktioniert.

Support zur Differenzierung

Nun mag man denken: Support zur Differenzierung? In Zeiten des Self-Service und der Automatisierung in der Cloud? Ja genau, das ist gar nicht so abwegig und ein gar nicht so unkluger Schachzug. Die Not macht erfinderisch. Rackspace hat schon immer viel Wert auf seinen Support gelegt und genießt hier einen guten Ruf.

@renebuest in pre-cloud days I greatly appreciated exactly this kind of help from RS

— Jeff Sussna (@jeffsussna) 14. Mai 2013

Weiterhin sollte man bedenken, dass, trotz des Self-Service und dem damit einhergehenden einfachen Bezug von Ressourcen für den Aufbau einer virtuellen Infrastruktur respektive dem darauf entwickeln einer eigenen Cloud-fähigen Applikation, Cloud Computing nicht einfach ist! Ich habe das erst kürzlich in dem Artikel “Cloud Computing ist nicht einfach!” beschrieben und Netflix als sehr positives Beispiel genannt. Es gibt nur wenige Nutzer-Unternehmen, die Cloud Computing so durchdrungen haben wie Netflix, die sich mit ihrer Simian Army wie dem Chaos Monkey oder dem Chaos Gorilla Test-Software für einen skalierbaren und hochverfügbaren Betrieb in der Cloud geschrieben haben. Wenn man jedoch schaut, was für einen Aufwand Netflix dafür betreibt, mit dem auch Kosten verbunden sind, ist Cloud Computing nicht auf die leichte Schulter zu nehmen, wenn man es ernsthaft einsetzen möchte.

Aus diesem Grund ist es nur ein logischer und für mich richtiger Schritt von Rackspace, seinen Support weiter auszubauen und dort zu unterstützen, wo es bei der Cloud ankommt, der skalierbaren und verfügbaren Entwicklung von Applikationen, die auch die Eigenschaften der Cloud berücksichtigen. Ob das nun reicht, um gegenüber Amazon mit großen Schritten aufzuholen wage ich zu bezweifeln. Aber innerhalb der Anbieter, die ebenfalls auf OpenStack setzen, ist es eine gute Möglichkeit sich von diesem Wettbewerb zu differenzieren.

An der IT-Abteilung vorbei

T-Systems möchte mit seinem Cloud-Portal auch nicht-technischen Nutzern in Großunternehmen den Zugang zu speziellen Cloud-Lösungen ermöglichen. Der Cloud-Anbieter bezieht sich dabei auf eine Studie von Gartner, die besagt, dass bis zum Jahr 2015 in etwa 35 Prozent der IT-Ausgaben, außerhalb der IT-Abteilungen ausgewählt und verwaltet werden. Genannt seien hier zum Beispiel die Bereiche Marketing, Einkauf und das Rechnungswesen.

Mobile Device Management

Das Mobile Device Management aus der Cloud soll Unternehmen bei der Administration mobiler Endgeräte mit unterschiedlichen Betriebssystemen, z.B. iOS und Android, über eine standardisierte Web-Plattform helfen. Darüber lassen sich etwa Sicherheitseinstellungen vornehmen, Zugriffsrechte auf Funktionen sowie Applikationen regeln oder bei Verlust des Endgeräts die Daten per Fernzugriff löschen. Ein Test des Mobile Device Management ist in den ersten vier Wochen für bis zu drei mobile Endgeräte kostenlos.

Dynamic Services for Infrastructure

Für Infrastructure-as-a-Service (IaaS) stehen zwei Angebote bereit: Zum einen die “Dynamic Services for Infrastructure” (DSI) aus einer Hosted Private Cloud. Zum anderen die “DSI with vCloud Datacenter Services” als eine hybride Variante. Das Management der Ressourcen übernimmt der Kunde selbst über ein web-basiertes Portal beziehungsweise über seine eigene VMware Management Software. Übersichtliche Preismodelle sollen die Kosten für die Infrastruktur transparent machen. So kostet z.B. im Paket “Small” ein Server aus der Hosted Private Cloud ab 9 Cent pro Stunde. Bei der hybriden Lösung liegt der Paketpreis für ein Virtual Datacenter in der kleinsten Ausführung bei genau 999,84 Euro pro Monat.

Enterprise Marketplace

Der Enterprise Marketplace umfasst unter anderem weitere IaaS-Lösungen inkl. Betriebssysteme für Linux und Windows Server, Platform-as-a-Service (PaaS) Lösungen, u.a. Tomcat und Microsoft SQL Server sowie eine stetig steigende Zahl von Software-as-a-Service (SaaS) Angeboten wie Doculife, CA Nimsoft, TAXOR, TIS, WeSustain, Metasonic, ARAS, Tibco Tibbr, Sugar CRM, Microsoft Enterprise Search und Microsoft Lync. Darüber hinaus sollen Unternehmen damit die Möglichkeit erhalten, nicht nur eine Vielfalt an Anwendungen hochsicher in bedarfsgerechten Formaten zu beziehen, sondern auch eigene Anwendungen migrieren und hosten zu lassen. Die volle Verfügbarkeit des Enterprise Marketplace ist für diesen Sommer geplant. Derzeit steht auf dem Cloud Portal bereits eine Vorschau zur Verfügung.

Kommentar

Mit dem Enterprise Cloud Portal fasst T-Systems sein gesamtes Cloud-Portfolio unter einem einzigen Dach zusammen. Ich hatte in einem Artikel für die Computerwoche: “Das Cloud-Portfolio von T-Systems” im Jahr 2011 analysiert. Zu dem Zeitpunkt bestand das Angebot jedoch noch aus einzelnen unabhängigen Services. Allerdings bin ich bereits damals schon zu dem Ergebnis gekommen, dass T-Systems über ein sehr gut durchdachtes und abgerundetes Cloud-Portfolio verfügt.

Das zeigt sich nun auch im konsolidierten Enterprise Cloud Portal. Von SaaS über PaaS bis IaaS und weiteren Lösungen für mobile Endgeräte ist alles dabei. T-Systems verfügt damit als einer der wenigen Anbieter über einen vollständigen Cloud-Stack und das nun sogar noch gebündelt in einem einzigen Portal.

Insbesondere in dem Enterprise Marketplace steckt viel Potential. Auf der diesjährigen CeBIT konnte ich einen ersten Blick darauf werfen, der sich meiner Einschätzung nach zu diesem Zeitpunkt noch in einem Alpha-Status befand. Einige grundlegende und zwingend notwendige Funktionen für ein IaaS Angebot, genannt seien nur automatische Skalierbarkeit und Hochverfügbarkeit, fehlten noch. Aber das war im März und ich gehe davon aus, dass T-Systems hier schon weitere Fortschritte gemacht hat. Zudem habe ich bereits aus einer sicheren Quelle erfahren, dass T-Systems/ Telekom ihre Cloud-Infrastruktur sukzessive auf OpenStack umstellen wird, was auch dem Enterprise Marketplace einen weiteren Schub hinsichtlich Kompatibilität geben wird.

Was T-Systems als Vorteil für nicht-technische Nutzer in Unternehmen sieht, sollte bei IT-Verantwortlichen Sorgenfalten verursachen. Zwar bin ich auch auf dem Standpunkt, dass sich die IT-Abteilungen zu einem Service-Broker entwickeln werden und sogar müssen. Allerdings halte ich es für recht bedenklich, wenn jede Abteilung einfach loslaufen darf und sich nach belieben IT-Services extern einkauft. Die Schuld liegt natürlich bei den IT-Abteilungen selbst, da diese sich über die Jahre hinweg einen schlechten Ruf aufgebaut haben und als langsam und nicht innovativ gelten. Darüber habe ich hier bereits vor zwei Jahren ausführlich philosophiert (Cloud Computing und die Schatten-IT).

Eine gewisse Kontrollinstanz in der Form eines Service-Broker ist weiterhin notwendig, denn sonst kommt es zu einem unkontrollierten Wildwuchs von externen Services, über die man den Überblick verlieren wird. Das lässt sich selbstverständlich kontrollieren, wenn man die Services über einen einzigen Anbieter bezieht. Und das ist genau das Ziel von T-Systems und seinem umfangreichen Enterprise Cloud Portal. Ein Kunde soll explizit und abteilungsübergreifend die Services aus der T-Systems Cloud beziehen, um damit den Wildwuchs zu vermeiden und den Überblick behalten. Die Frage ist, ob sich das bei den Kunden intern auch so durchsetzen lässt. Denn auch andere Anbieter haben hübsche Services.

Am Ende möchte ich noch auf ein Thema eingehen, was im Endkunden-Umfeld derzeit für Aufregung sorgt, Unternehmenskunden aber einen großen Vorteil bietet. Das End-to-End Angebot von Services. T-Systems ist auf Grund seiner Situation, Tochter von der Deutschen Telekom zu sein, einer der wenigen Cloud-Anbieter, der ein Service-Level von den Services auf Applikations- oder sogar virtueller Maschinen Ebene im Rechenzentrum, inkl. der Datenleitung anbieten kann. Das ermöglicht es den Kunden einen ununterbrochenen Quality-of-Service (QoS) sowie ein umfangreiches Service Level Agreement (SLA) zu erhalten, was viele andere Cloud-Anbieter nicht leisten können.

Software-defined Scalability und Software-defined High-Availability

Derzeit kursieren wieder neue Begriffe durch die IT-Stratosphäre. Software-defined Networking (SDN) und auch Software-defined Datacenter (SDD). Ein SDN führt eine weitere Abstraktionsebene oberhalb der Netzwerkkomponenten ein. Typischerweise besitzt jeder Router und Switch seine eigene lokale Software, über die er per Programmierung mit Intelligenz versorgt wird. Der Netzwerkadministrator sagt dem Router somit bspw. welches Paket unter welchen Bedingungen wohin geleitet werden soll oder auch nicht. Innerhalb eines SDN entfällt die Aufgabe jeder einzelnen Komponente für sich eine lokale Intelligenz einzuverleiben. Die Intelligenz wandert eine Ebene höher in eine Managementschicht, in der das gesamte Netzwerk designed wird und die einzelnen Regeln für jede Komponente zentral festgelegt wird. Ist das Design fertiggestellt, wird es über die Netzwerkkomponenten ausgerollt und das Netzwerk ist konfiguriert. Mit SDN soll es daher möglich sein ein vollständiges Netzwerkdesign “per Knopfdruck” zu verändern, ohne jede einzelne Komponente direkt anfassen zu müssen.

Die Idee des SDN Konzepts muss bei der Nutzung einer Cloud-Infrastruktur ebenfalls zwingend in Betracht gezogen werden. Denn der Einsatz eines PaaS aber noch viel mehr eines IaaS bedeutet sehr viel Eigenverantwortung. Mehr als man auf dem ersten Blick denken mag. Eine oder zwei virtuelle Maschinen zu starten bedeutet nicht, dass man eine virtuelle Cloud Infrastruktur nutzt. Es sind und bleiben zwei virtuelle Server. Ein IaaS Anbieter stellt darüber hinaus nur die Komponenten, wie die genannten virtuellen Maschinen, Speicherplatz, weitere Services und zusätzlich APIs bereit, mit denen die Infrastruktur genutzt werden kann. Unterm Strich lässt sich vereinfacht sagen, dass ein IaaS Anbieter seinen Kunden nur die Ressourcen und entsprechenden Werkzeuge zur Verfügung stellt, um damit auf seiner Cloud Infrastruktur eine eigene virtuelle Infrastruktur respektive ein eigenes virtuelles Rechenzentrum aufzubauen.

Man muss daher per Software (die eigene Applikation) selbst dafür sorgen, dass die Cloud Infrastruktur bei Bedarf skaliert (Software-defined Scalability, SDS) und im Falle eines Ausfalls einer Cloud Infrastruktur-Komponente berücksichtigen, dass entsprechend eine Ersatzkomponente (z.B. virtuelle Maschine) gestartet wird und die Ausgefallene damit ersetzt wird (Software-defined High-Availability, SDHA). Die Software sorgt also für die Skalierbarkeit und Hochverfügbarkeit der genutzten virtuellen Cloud Infrastruktur, damit die Web-Applikation selbst skaliert und ausfallsicher ist und den Charakter der jeweiligen Cloud eines Anbieters nutzt und das Maximum aus ihr schöpft.

Wie eine Cloud Computing Infrastruktur quasi in Perfektion genutzt wird zeigt Netflix eindrucksvoll.

Netflix das Paradebeispiel

Netflix ist mit Abstand der größte Cloud Service weltweit. Der Video-Streaming Dienst ist während Spitzenzeiten mittlerweile für ein Drittel des gesamten Internetverkehrs verantwortlich. Diese Nutzeranfragen gilt es selbstverständlich performant und zu jedem Zeitpunkt zu beantworten. Dazu setzt Netflix schon seit seinem Start im Jahr 2009 auf Cloud Technologien und hat im November 2012 seinen vollständigen Technologie-Stack und die darauf basierende Infrastruktur in die Cloud zu den Amazon Web Services verlagert. Hier laufen rund 1.000 virtuelle auf Linux basierende Tomcat Java Server und NGINX Web-Server. Hinzu kommen weitere Services wie Amazon Simple Storage Service (S3) und die NoSQL Datenbank Cassandra in Verbindung mit Memcached sowie ein verteiltes Memory Object Caching.

Das ist jedoch nur die eine Seite der Medaille. Viel wichtiger ist die Nutzung mehrerer Availability Zones in der Amazon Cloud. Netflix nutzt insgesamt drei Availability Zones, um die Verfügbarkeit und Geschwindigkeit des eigenen Service zu erhöhen. Tritt in einer Availability Zone ein Problem auf, ist die Architektur der Netflix-Applikation so ausgelegt, dass der Service durch die anderen beiden weiterlaufen kann. Dabei hat Netflix sich nicht auf die reinen Marketing-Versprechen von Amazon verlassen, sondern mit dem Chaos Gorilla selbst eine eigene Software entwickelt, mit der die Stabilität der virtuellen Server Amazon Elastic Compute Cloud (EC2) getestet wird. Kurzum wird dabei der Ausfall einer kompletten EC2 Region bzw. Availability Zone simuliert, um sicherzustellen, dass der Netflix-Service im Ernstfall weiterhin funktioniert. Eine der größten Herausforderungen besteht dabei darin, dass im Falle eines Fehlers in einer Amazon Zone, das Domain Name System (DNS) automatisch neu konfiguriert wird, damit die Netflix Kunden von dem Ausfall nichts mitbekommen. Die unterschiedlichen APIs der DNS-Anbieter machen die Aufgabe hier allerdings nicht einfacher. Zudem sind die meisten so entwickelt worden, dass die Einstellungen noch manuell vorgenommen werden müssen, was es nicht einfacher macht, dies zu automatisieren.

Unterm Strich ist zu sagen, dass Netflix für den Fehlerfall vorausschauend plant und sich nicht auf die Cloud verlässt. Denn irgendwas läuft auch mal in der Cloud schief, wie in jedem gewöhnlichen Rechenzentrum auch. Mann muss nur darauf vorbereitet sein. Wer sich mehr dafür interessiert, was Netflix macht um diesen Zustand zu erreichen sollte “Netflix: Der Chaos Monkey und die Simian Army – Das Vorbild für eine gute Cloud Systemarchitektur” lesen.

Die Einfachheit zählt

Vielleicht verlange ich noch zu viel. Schließlich ist Cloud Computing in seiner Form ein relativ junges Konzept. Dennoch zeigt Netflix eindrucksvoll das es funktioniert. Wenn man jedoch bedenkt, was für einen Aufwand Netflix betreibt, um in der Cloud erfolgreich zu sein, muss man einfach sagen, dass Cloud Computing nicht einfach ist und eine Cloud Infrastruktur, egal bei welchem Anbieter, mit der entsprechenden Architektur aufgebaut werden muss. Das bedeutet im Umkehrschluss, dass die Nutzung der Cloud simpler werden muss, um auch die versprochenen Kostenvorteile zu erzielen. Denn wenn man Cloud Computing richtig nutzt, ist es zwangsläufig nicht günstiger. Neben den Einsparungen der Infrastrukturkosten die immer vorgerechnet werden, dürfen niemals die weiteren Kosten z.B. für das Personal mit den notwendigen Kenntnissen und die Kosten für die Entwicklung der skalierbaren und ausfallsicheren Applikation in der Cloud vernachlässigt werden.

Das erfreuliche ist, dass ich erste Startups am Horizont sehe, die sich der Problematik annehmen und den einfachen Bezug von fertigen Cloud Ressourcen, ohne als Nutzer selbst auf Skalierbarkeit und Hochverfügbarkeit achten zu müssen, zu ihrer Aufgabe gemacht haben.

Neue Funktionen in Eucalyptus 3.3

Eucalyptus 3.3 wurde neben den Netflix Tools um AWS-kompatible Funktionen wie Auto Scaling, Load Balancing und CloudWatch erweitert. Mit Auto Scaling lassen sich Regeln erstellen, um Workloads automatisch mit weiteren virtuellen Maschinen zu unterstützen, wenn eine bestimmte Lastgrenze erreicht ist. Dabei soll der Mechanismus exakt derselbe sein wie auf der Public Cloud Infrastruktur der Amazon Web Services. Weiterhin ist es nun möglich, Workloads automatisch zu AWS zu sklarieren

Chaos Monkey, Asgard und Edda

Der Chaos Monkey ist ein Service der auf den Amazon Web Services läuft, nach Auto Scaling Groups (ASGs) sucht Instanzen (virtuelle Maschinen) pro Guppe wahllos beendet. Dabei ist die Software flexibel genug entwickelt worden, dass sie ebenfalls auf den Plattformen anderer Cloud Anbieter funktioniert. Der Service ist voll konfigurierbar, läuft standardmäßig aber an gewöhnlichen Werktagen von 09.00 Uhr bis 15.00 Uhr. In den meisten Fällen hat Netflix seine Anwendungen so geschrieben, dass diese weiterhin funktionieren, wenn eine Instanz plötzlich Probleme hat. In speziellen Fällen passiert das bewusst nicht, damit die eigenen Leute das Problem beheben müssen, um daraus zu lernen. Der Chaos Monkey läuft also nur ein paar Stunden am Tag, damit sich die Entwickler nicht zu 100% auf ihn verlassen.

Bei Asgard handelt es sich um eine Web-Oberfläche, mit der das Deployment von Applikationen gesteuert und eine Cloud verwaltet werden kann. Netflix selbst nutzt Asgard, um seine virtuelle Infrastruktur auf den Amazon Web Services zu steuern.

Edda ist ein Service, den Netflix nutzt, um kontinuierlich seine benötigten AWS Ressourcen über die AWS APIs abzufragen. Mit Edda lässt sich über die aktiven Ressourcen suchen und der Status herausfinden. Der Hintergrund für Edda ist, dass virtuelle Instanzen in der Cloud ständig in Bewegung sind. Das bedeutet, dass sie ausfallen können und dafür neue gestartet werden müssen. Ebenso verhält es sich mit IP-Adressen, die von unterschiedlichen Anwendungen wiederwendet werden können. Hier gilt es den Überblick zu behalten, wobei Edda unterstützt.

Ursprünglich hat Netflix diese Tools für die AWS Cloud-Infrastruktur geschrieben. Durch das Open-Source Release und die Eucalyptus Adaption, können sie nun ebenfalls in einer Private Cloud genutzt werden.

Kooperation: Eucalyptus und Amazon Web Services

Im März 2012 hatten die Amazon Web Services und Eucalyptus eine Kooperation angekündigt, um die Migration von Daten zwischen der Amazon Cloud und Private Clouds besser zu unterstützen. Dabei ist die Kooperation unterschiedlich aufgebaut. Zunächst sollen sich Entwickler aus beiden Unternehmen darauf konzentrieren, Lösungen zu schaffen, die Unternehmenskunden dabei helfen sollen, Daten zwischen bestehenden Rechenzentren und der AWS Cloud zu migrieren. Weiterhin und noch bedeutender ist jedoch, dass die Kunden in der Lage sein sollen, dieselben Management Tools und die eigenen Kenntnisse für beide Plattformen zu nutzen. Darüber hinaus werden die Amazon Web Services Eucalyptus mit weiteren Informationen versorgen, um die Kompatibilität mit den AWS APIs zu verbessern.

Die ersten Früchte hat diese Kooperation mit dem Eucalyptus Release 3.3 nun getragen. Eucalyptus nähert sich stetig immer näher an die Funktionen der Amazon Web Services an. Meine Theorie, dass Amazon für den Bau der CIA Private Cloud möglicherweise Eucalyptus nutzt, ist daher nicht ganz unberechtigt.

Übernahme nicht unwahrscheinlich

CEO Marten Mickos scheint seinem Ziel ein Stück näher zu kommen. Während eines Gespräches im Juni 2012 erzählte er mir, dass seine erste Amtshandlung als neuer Eucalyptus CEO darin bestand, zum Telefonhörer zu greifen, Amazon anzurufen und das Interesse an einer Zusammenarbeit zu bekunden.

Wie ich es bereits in dem Artikel “Netflix veröffentlicht weitere Monkeys als Open-Source – Eucalyptus Cloud wird es freuen” geschrieben habe, hat Netflix mit der Veröffentlichung seiner Monkeys Eucalyptus damit kräftig in die Arme gespielt. Dies wird nicht zuletzt die Kooperation der Amazon Web Services und Eucalyptus weiter stärken, sondern Eucalyptus für Amazon als Übernahmeobjekt immer attraktiver machen.

Warum ich dieser Meinung bin, habe ich ausführlich unter “Amazon kauft Eucalyptus Cloud – Es ist nur eine Frage der Zeit” beschrieben.

Es passt in die Strategie

Microsofts aktuelle Strategie lautet “CLOUD First”, das ist kein Geheimnis und wurde mir von Microsofts Seite mehrfach bestätigt. Unter anderem aus dem Bereich Dynamics CRM, das durch die Cloud stetig wächst. Bei Microsoft gilt seit der Einführung von Dynamics CRM Online im Jahr 2011 “Cloud first!” und das scheint sich zu bewähren. Die Cloud Lösung hat bei den Kunden mittlerweile eine hohe Akzeptanz erreicht, wodurch Microsoft 30% mehr Kunden für Dynamics CRM gewinnen konnte. Dabei setzen 60% aller Neukunden auf die Cloud Lösung.

Ähnlich sieht es in vielen anderen Unternehmensbereichen aus. Genannt seien nur Windows Azure, das stetig ausgebaut wird, oder Office 365. Aus diesem Grund ist und wäre der Bau mindestens eines Rechenzentrums in Deutschland der nächste logische Schritt, um auch uns Deutschen hinsichtlich Vertrauen weiter entgegen zu kommen.

Rechenzentrum in Deutschland: Ein enormer Wettbewerbsvorteil

Microsoft versorgt den europäischen Markt derzeit über Rechenzentren in Irland (Dublin) und den Niederlanden (Amsterdam). Das stößt bei vielen Deutschen, vornehmlich Datenschützern und mittelständischen Unternehmen, auf Unbehagen. Das Speichern von Daten außerhalb von Deutschland und ein Vertrag nach maximal europäischen Recht wird nicht gerne gesehen. Jedoch sollte und darf der Wirtschaftsstandort Deutschland nicht vernachlässigt werden. Für die US-amerikanischen Unternehmen mag Deutschland zwar ein kleines Land sein, aber die Wirtschaftskraft zu unterschätzen wäre fatal.

Trifft die Information also tatsächlich zu, dass Microsoft ein Cloud Rechenzentrum in Deutschland baut, wäre das ein enormer Wettbewerbsvorteil gegenüber anderen Anbietern wie den Amazon Web Services oder Google. Insbesondere im stark umkämpften Markt für Unternehmenskunden, in denen Amazon AWS und Google sich schwer tun und wo Microsoft bereits die beste Ausgangslage, auf Grund einer bestehenden breiten Kundenbasis, hat, würde Microsoft damit einen großen Schritt nach Vorne machen.

Darüber hinaus – sollte das Rechenzentrum gebaut werden, wovon ich strategisch gesehen sehr stark ausgehe, werden Amazon und Google nicht mehr drum herum kommen, jeweils ein eigenes Rechenzentrum in Deutschland zu bauen. Wenn auch beide und insbesondere Amazon technologisch weiterhin die Vorreiter im Cloud Computing Markt sind, ist der Standortvorteil mit einem Rechenzentrum in Deutschland nicht zu vernachlässigen, um aktiv damit zu beginnen, die Bedenken den deutschen Unternehmen zu nehmen.

Denn, Cloud Computing ist die Zukunft! Es müssen nur die rechtlichen und datenschutztechnischen Themen dem jeweiligen Länderniveau angepasst und die Bedürfnisse der Kunden berücksichtigt werden. Technologien und Services dürfen und müssen sogar standardisiert werden! Aber Verträge und organisatorische Themen gehören auf Augenhöhe geführt.