Hybrid oder Multi Cloud
Es ist an sich kein Fehler , eine Hybrid- oder Multi-Cloud-Strategie zu verfolgen . 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 Anwendungsfälle für Fehler entwerfen und testen , werden Sie es büßen , wenn der Service ausfällt . Simulieren Sie Ausfälle , testen Sie Hochverfügbarkeits- 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 verbunden 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 portierbar 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 ( vorausgesetzt , 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 ), Sicherheitstools , 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 übernimmt , 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 entsprechend zu präparieren . Bei der Umstellung auf Ihren nächsten Cloud-Provider ist ein Großteil der erstellten Landing Zone nicht portierbar . Jeder Cloud-Anbieter hat seine eigenen APIs für Sicherheits- und Netzwerkfunktionen . Es sind auch einmalige Integrationen mit den verschiedenen Sicherheits- , Überwachungs- und Protokollierungstools von Drittanbietern nötig . Viele SaaS-Implementierungen 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 werden . 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-Provider duplizieren – nur als Sicherheitsnetz für den einen Zeitpunkt im Jahr , zu
8 | THE DOPPLER | FRÜHJAHR 2017