The Doppler Quarterly (DEUTSCHE) Frühjahr 2017 - Page 10

Hybrid oder Multi Cloud Es ist an sich kein Fehler, eine Hybrid- oder Multi-Cloud-Strategie zu verfol- gen. Doch den Vorschlag, Ausfälle wie die erlebte S3-Störung am besten durch mehrere Cloud-Provider zu verhindern, halte ich für kurzsichtig. Bevor Sie Zeit, Geld und Ressourcen in eine Multi-Cloud-Strategie investieren, nur um Redundanz und Hochverfügbarkeit zu erreichen, überlegen Sie Folgendes: 1. Stellen Sie sicher, dass Ihre aktuelle Architektur durch das Design auf Ausfälle vorbereitet ist. AWS empfiehlt beispielsweise zum Zwecke von Hochverfügbarkeit und DR die regionenübergreifende Replikation für S3. 2. Testen Sie Ihre Systeme im Hinblick auf Ausfälle. Wenn Sie einfach davon ausgehen, dass jede AWS-API immer funktioniert, und Sie keine Anwen- dungsfälle für Fehler entwerfen und testen, werden Sie es büßen, wenn der Service ausfällt. Simulieren Sie Ausfälle, testen Sie Hochverfügbar- keits- und Wiederherstellungslösungen, nutzen Sie die Simian Army etc. 3. Machen Sie sich ein Bild der wahren Gesamtbetriebskosten (TCO), die mit dem Hinzufügen eines weiteren Cloud-Anbieters zu dem Mix ver- bunden sind, und unterschätzen Sie den Aufwand nicht. Ist die Multi Cloud nur als Sicherheitsnetz dies wert? Angesichts des ganzen Trubels rund um Container und Tools wie Terraform wird meiner Meinung nach vorschnell davon ausgegangen, dass alles, was Sie in einer Cloud erstellen, ganz einfach in eine andere portiert werden kann. Lassen Sie mich diese Annahme korrigieren. Ich stimme zu, dass das Betriebssystem und virtuelle Maschinen sehr portier- bar sein können. Wenn Sie sie in einen Container platzieren, sollten sie sich mühelos von jedem Cloud- oder Nicht-Cloud-Provider ausführen lassen (vor- ausgesetzt, Ihr Setup ist Cloud-unabhängig). Doch das Betriebssystem und virtuelle Maschinen sind nur ein kleiner Teil des Ganzen. Wie sieht es mit IAM (Identity Access Management), VPC-Design (Virtual Private Cloud), Sicherheit- stools, Netzbetrieb etc. aus? Ich habe noch keine machbare Lösung gefunden, um die Cloud-Anbieter-spezifischen APIs rund um Sicherheit und Vernetzung so zu abstrahieren, dass ein einmal erstelltes Design vielfach portiert werden kann. Man könnte argumentieren, dass eine PaaS-Lösung das für Sie über- nimmt, doch auch dann muss für jede Cloud eine Integration vorgenommen werden. Es gibt viele gute Argumente für und gegen reine PaaS-Lösungen, die jedoch Stoff für einen anderen Artikel zu einem späteren Zeitpunkt bieten. Es sind erhebliche Vorarbeiten nötig, um die von AWS so genannte „Landing Zone“ oder die nötige Infrastruktur für die Ausführung Ihrer Apps entspre- chend zu präparieren. Bei der Umstellung auf Ihren nächsten Cloud-Provider ist ein Großteil der erstellten Landing Zone nicht portierbar. Jeder Cloud-An- bieter hat seine eigenen APIs für Sicherheits- und Netzwerkfunktionen. Es sind auch einmalige Integrationen mit den verschiedenen Sicherheits-, Überwa- chungs- und Protokollierungstools von Drittanbietern nötig. Viele SaaS-Imple- mentierungen dieser Dritt-Tools sind entweder zu teuer oder ihnen fehlt die erforderliche Funktionalität ihrer Nicht-SaaS-Version. Diese Tools müssen daher in der Infrastruktur des Cloud-Providers installiert und verwaltet wer- den. Natürlich unterscheidet sich die Implementierung dieser einzelnen Tools zwischen den jeweiligen Cloud-Providern, weil sie über unterschiedliche APIs für Sicherheit und Netzbetrieb verfügen. Hinzu kommen die Kosten. Wenn Sie Hunderte Terabyte an Daten auf S3 gespeichert haben, möchten Sie diese wirklich für einen anderen Cloud-Provi- der d \^Y\[8$\[X\Z]ۙ][Z[[Z][[HZBHTR M