Cloud Exit-Strategien
Es wird immer wieder über Cloud Vendor lock-in diskutiert. Ist es aber wirklich eine Frage des Cloud Anbieters? Es gibt Beispiele, welche Probleme aufzeigen, die mit einem spezifischen Cloud Anbieter zu tun haben. So ist zum Beispiel der Aufruf von SQL Datenbankabfragen in Azure anders implementiert, als es bei einer lokalen Anwendung der Fall wäre. Dies würde gegen eine Nutzung sprechen. Jedoch muss man bedenken, dass man sich nicht diesen Restriktionen hingeben muss. Es ist doch vielmehr die Frage wichtig, in wieweit die eigene Applikation so gestaltet werden kann, dass sie möglichst lose gekoppelt ist und somit eine einfache Austiegsstrategie ermöglicht.
Andererseits sollte man sich bei Nutzung eines externen Anbieters von IT Dienstleistungen immer überlegen, wie man im Fall der Fälle seine Applikationen oder Daten von diesem weg bekommt. Und dabei spielt es keine Rolle, ob es sich um einen Cloud Anbieter oder einen traditionellen klassischen Hoster handelt. Es ist somit eine Anforderung an das Applikationsdesign. Dieses führt mich dann auch zu einer Checkliste, anhand derer ich dann auch unterschiedliche Anbieter miteinander vergleichen kann. Mit einem guten und soliden Design ist es möglich von einem Anbieter zu einem anderen zu wechseln.
Problematisch bleibt jedoch der bereits geschilderte Fall, wenn eine Anwendung einen Datenbankdienst erfordert, dieser aber lokal anders angesprochen wird, wie beim externen Anbieter. Dann bleibt nur einen eigenen Datenbankserver aufzusetzen oder den Anbieter nicht zu nutzen.
Es gibt viele relativ junge Unternehmen, die sich aufgrund ihres Budgets von vornherein überlegen müssen, was passiert, wenn sie den Anbieter wechseln müssen, weil z.B. die Performance nicht stimmt. Gerade für StartUps mit einem guten Produkt aber wenig Budget könnte dies erfolgsentscheidend sein.
Was ist mit bereits bestehenden Anwendungen? Wenn die Anwendung bereits in die Jahre gekommen ist und es sowieso einen Grund gibt diese zu modifizieren, dann sollte man auch eine Ausstiegsstrategie mit implementieren. Jedoch ist eine bestehende, performante und skalierende Anwendung zu verändern ist sicherlich ein sehr gewagtes Unterfangen. Jedoch gibt es auch hier Möglichkeiten eine Ausstiegsstrategie zu entwickeln. Z.B. kann man die unterschiedlichen Komponenten der Applikation automatisieren. Chef- oder Puppet-Skripte sind dabei nur eine Möglichkeit das Anwendugsdeployment zu automatisieren. Auch helfen Anbieter wie Rightscale gerne dabei entsprechende Automatisierungsmöglichkeiten zu schaffen. Denn nur eine solide generische Basis für eine Anwendung und deren Deployment ist auf Dauer Erfolg versprechend.
Dies ist also ein Appell an alle, die mit dem Gedanken spielen eine Anwendung im Produktivbetrieb in die Cloud zu migrieren, sich über eine Ausstiegsstrategie frühzeitig genug Gedanken zu machen.
Ein sehr gutes Beispiel für einen reibungsfreien Anbieterwechsel ohne Downtime gibt zum Nachlesen hier: http://bit.ly/ht2hIO
Einmal laufend hat man die Möglichkeit die über den neuen Debug Button detaillierte Ausgaben der Fehlerlogs und vom Controller zu bekommen. 
Im Falle eines Fehlers kann nun schneller festgestellt werden, wo das Problem liegt. Dies dürfte dann auch die lokale Installation einsparen, da das Debugging nun auch auf die Seite von Amazon verschoben werden kann. Eine Ausgabe wie diese: org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory s3n://…/output already exists and is not empty hilft schnell das Problem zu beseitigen und wieder durchzustarten.