hybride Cloud realisiert: F5, Azure und Azure Stack
Heutzutage werden viele IT-Abteilungen von Führungsgruppen unter Druck gesetzt, sich von der statischen Natur traditioneller interner Rechenzentren zu lösen und auf dynamischere, Cloud-zentrierte Architekturen umzusteigen, die mehr Agilität, Flexibilität und Skalierbarkeit bieten und gleichzeitig die Betriebskosten senken. Und da öffentliche und private Clouds jeweils ihre Vor- und Nachteile haben,1 der Unternehmen implementieren Hybridmodelle, um mehr Vorteile zu nutzen und gleichzeitig viele der Nachteile zu umgehen. Allerdings nutzen dabei fast alle dieser Organisationen nicht homogene Cloud-Infrastrukturen und Application , was die Komplexität für die funktionsübergreifenden Teams, die mit der Architektur und Wartung dieser Bereitstellungen beauftragt sind, drastisch erhöht.
Die Verknüpfung zweier (oder mehr) unterschiedlicher Cloud-Umgebungen zur Erstellung einer Hybrid-Cloud ist nicht nur im Hinblick auf Agilität, Flexibilität und Skalierung vorteilhaft, sondern ermöglicht auch eine ganze Reihe spezialisierter Anwendungsfälle, deren Umsetzung viel schwieriger oder gar nicht möglich wäre. Die häufigsten davon sind wohl:
Das Einrichten und Verwalten eines hochverfügbaren, geografisch redundanten Backups einer privaten Cloud zur Vermeidung von Ausfallzeiten wichtiger Applications ist sehr teuer und würde wahrscheinlich die für den Betrieb einer einzelnen privaten Cloud erforderliche Investition verdoppeln. Sie würden nicht nur doppelt so viel physische Hardware benötigen, sondern auch ein separates Rechenzentrum mit eigener Stromversorgung, Kühlung und Personal an einem geografisch getrennten Standort.
Alternativ können HA- und DR-Umgebungen zu einem Bruchteil der Kosten in der öffentlichen Cloud untergebracht werden. Die Application werden bei jeder Sicherung aus der privaten Cloud gespeichert, während die eigentlichen Application und Netzwerkressourcen ungenutzt bleiben, bis sie benötigt werden, beispielsweise im Falle einer Katastrophe oder eines Ausfalls der privaten Cloud. Bei Bedarf werden diese Applications und Ressourcen mithilfe der gespeicherten Daten hochgefahren und betriebsbereit gemacht, um die Application und Geschäftskontinuität sicherzustellen.
Die Entwicklung einer neuen Application in einer privaten Cloud kann wesentlich teurer sein als in der öffentlichen Cloud. Zur Ausführung der Arbeitslast sind Vorabinvestitionen erforderlich, ohne dass eine Garantie besteht, dass die Lösung funktioniert oder auf dem aktuellen Markt angenommen wird. Aus diesen Gründen folgen Unternehmen dem Mantra „Fail Fast, Fail Cheap“, indem sie die On-Demand-Kapazität der öffentlichen Cloud nutzen, um neue Apps im Produktionsmodus zu entwickeln, zu testen und auszuführen. Sobald die Apps als betriebssicher eingestuft werden oder eine breite Akzeptanz bei den Benutzern zu verzeichnen ist, können sie in die private Cloud migriert werden, die auf lange Sicht sicherer und betriebswirtschaftlich günstiger sein kann. Alternativ könnten sie in der öffentlichen Cloud bleiben und in einer längerfristigen, kostengünstigeren Umgebung bereitgestellt werden, indem günstigere reservierte Instanzen und dergleichen verwendet werden.
Cloud Bursting gilt oft als die wünschenswerteste Hybrid-Cloud-Funktion, ist jedoch wahrscheinlich die am schwierigsten zu implementierende Funktion und wird häufig zum weißen Wal vieler Hybrid-Cloud-Strategien. Beim Cloud Bursting läuft eine Application überwiegend in der privaten Cloud. Wenn die Nachfrage die Kapazität übersteigt, werden zusätzliche Anfragen an eine exakte Replik umgeleitet, die in der öffentlichen Cloud auf gemieteter Infrastruktur ausgeführt wird. Dabei handelt es sich jedoch um einen temporären Zustand, der für den Umgang mit unerwarteten, kurzzeitig auftretenden Verkehrsspitzen gedacht ist. Bei anhaltend hohem Datenverkehr können Unternehmen die Kapazität ihrer privaten Cloud hochskalieren.
Die Konfiguration einer Hybrid-Cloud-Umgebung für Cloud Bursting ist naturgemäß schwierig und komplex. Es bedarf einer synergetischen Beziehung zwischen den beiden Umgebungen sowie einer ausfallsicheren Orchestrierung, um sicherzustellen, dass die Umleitung autonom und nahtlos erfolgt und die Erfahrung des Endbenutzers kaum oder gar nicht beeinträchtigt wird. Für die mit der Konfiguration und Verwaltung beauftragten Teams wird die Schwierigkeit noch größer, wenn die Infrastruktur, Dienste und Tools, die zum Ausführen und Unterstützen der Applications verwendet werden, in jeder Umgebung unterschiedlich sind.
Es dürfte Sie nicht überraschen, dass nicht alle Wolken gleich sind. Jeder verfügt über eine eigene Infrastruktur, Netzwerk- und Application , Entwicklertools, Benutzeroberfläche und Differenzierung gegenüber anderen Cloud-Konkurrenten. Beispielsweise ist es für Benutzer von Sharepoint, Exchange, SQL Server oder anderen Microsoft-Technologien viel einfacher, zu Microsoft Azure zu migrieren, als zu AWS oder Google Cloud. Diese Unterschiede zwischen Plattformen und Diensten führen zu Inkompatibilitäten zwischen den Clouds und erschweren die Entwicklung von Hybrid-Cloud-Umgebungen.
Microsoft hat jedoch erhebliche Fortschritte bei der Unterstützung der Erstellung von Hybrid-Clouds erzielt, indem das Unternehmen über Azure und Azure Stack synonyme Ressourcen und Dienste sowohl in öffentlichen als auch in privaten Cloud-Umgebungen anbietet. Azure Stack, das erst kürzlich vorgestellt wurde, bietet Benutzern viele Funktionen und Vorteile der öffentlichen Cloud mit der Kontrolle und Sicherheit eines internen Rechenzentrums.
Wir vergleichen drei gängige Hybrid-Cloud-Modelle auf hoher Ebene, um zu zeigen, wie dieser neue Ansatz in Kombination mit den erweiterten Application von F5 die Entwicklung und den Betrieb einer Hybrid-Cloud drastisch vereinfacht.
Modell 1 – Inhomogene Cloud-Plattformen und Application
Unser erstes Beispiel ist eine Hybrid-Cloud-Umgebung, die Azure mit Azure-nativen Application für den öffentlichen Cloud-Aspekt verwendet und gleichzeitig VMware mit F5- Application für die private Cloud-Komponente nutzt, wie in Abbildung 1 dargestellt.
Aufgrund der deutlichen Inkonsistenz zwischen den Umgebungen ist dieses Modell am schwierigsten zu implementieren und zu betreiben. Beim zuvor besprochenen HA/DR-Anwendungsfall müsste eine Application individuell konfiguriert werden, damit sie in jeder Cloud identisch ausgeführt wird. Angesichts der Unterschiede bei virtuellen Maschinen, APIs und zugrunde liegenden Netzwerkressourcen dürfte dies keine einfache Aufgabe sein. Diese Unterschiede tragen dazu bei, dass die Gesamtportabilität der Application aufgrund der komplexen Infrastruktur, die für die Operationalisierung der App in jeder Cloud erforderlich ist, reduziert wird. Dadurch verdoppelt sich effektiv der Arbeitsaufwand für das Erreichen ähnlicher Ergebnisse. Darüber hinaus verfügt jede Plattform auch über ihre eigene Portalschnittstelle und Entwickler-/Administratortools, wodurch dieses Modell schnell unerschwinglich kompliziert wird.
Und dabei handelt es sich lediglich um die Berücksichtigung der Plattformunterschiede. Wenn noch die Auswirkungen unterschiedlicher Application mit unterschiedlichen Schnittstellen, Verwaltungstools und Konfigurationsanforderungen hinzukommen, steigt die Komplexität exponentiell. Und mangelnde Verwaltungsfunktionen sind nicht das einzige Problem. Auch Funktionsinkonsistenzen verhindern, dass Applications in allen Clouds mit denselben Diensten konfiguriert werden können, was zusätzliche Risiken für Sie mit sich bringt. Beispielsweise führen unterschiedliche Sicherheitsdienste zu unterschiedlichen Firewall-Regelsätzen und -Richtlinien. Diese können Sicherheitslücken verursachen, die infolge der darauf folgenden Cyberangriffe zu Application oder zum Verlust von Kundendaten führen können.
Modell 2 – Inhomogene Cloud-Plattformen mit homogenen Application
Dieses Setup ähnelt dem in Modell 1, allerdings wird jede Cloud-Umgebung durch F5- Application unterstützt, wie in Abbildung 2 dargestellt.
Dank konsistenter Application können alle Dienste, Konfigurationen und Richtlinien von F5 über eine einzige Verwaltungsoberfläche hinweg in allen Umgebungen repliziert werden, was den Aufwand für die Systemadministratoren reduziert. Anstatt zwei separate Sätze an Funktionen, Schnittstellen und Terminologien zu erlernen und abzuwägen, kann ein standardisierter, funktionsreicher Satz an Diensten in der gesamten Hybrid-Cloud-Umgebung bereitgestellt werden. Und diese Dienste sind Cloud-agnostisch (d. h. sie laufen in allen Clouds identisch), wodurch die Angst vor einer Anbieterabhängigkeit, die mit der Verwendung Cloud-nativer Dienste verbunden sein kann, ausgeräumt wird. Allerdings geht dieses Modell nicht auf die Probleme ein, die mit der unterschiedlichen Plattforminfrastruktur verbunden sind und die berücksichtigt werden müssen.
Modell 3 – Homogene Cloud-Plattformen und Application
Dieses endgültige Modell weist weitere schrittweise Verbesserungen auf: Es übernimmt die in Modell 2 beschriebene Konfiguration und ersetzt die private VMware-Cloud durch Microsoft Azure Stack, wie in Abbildung 3 dargestellt.
Für diejenigen, die mit Azure Stack nicht vertraut sind: Diese Cloud-Plattform ist als Erweiterung (oder einfach eine weitere Region) von Azure in der privaten Cloud mit identischen Diensten, Tools und virtueller Infrastruktur konzipiert. Der Wert liegt in der Fähigkeit, Workloads problemlos zwischen Hybrid-Cloud-Umgebungen zu übertragen, ohne dass eine Application erforderlich ist. Gleichzeitig verringert die Konsistenz der Azure-Tools und der Portalschnittstelle die Verwaltungskomplexität. Als App-Besitzer können Sie eine App in Azure entwickeln und testen und sie dann schnell und nahtlos für die Produktionsbereitstellung auf Azure Stack übertragen (oder umgekehrt), während Sie beide Instanzen mit identischen F5- Application auf Unternehmensniveau unterstützen.
Im Vergleich zu Modell 1 kombiniert dieses Hybrid-Cloud-Modell die Vorteile konsistenter Application und Cloud-Infrastruktur und halbiert gleichzeitig die Anzahl der Systemvariablen von vier auf zwei. Dies verbessert die Application erheblich und reduziert den Aufwand für das IT-Management. Durch die Vereinheitlichung der Plattformen und Application können Netzwerkbetreiber und IT-Management ihre Hybrid-Cloud-Architektur als eine einzige homogene Einheit betrachten und nicht als zwei einzelne Monolithen.
Die BIG-IP Virtual Edition (VE) von F5 läuft auf beiden Plattformen identisch und verbessert die Parität der Azure/Azure Stack-Architekturen durch Replikation der unterstützenden Application . Entwickler können eine App nicht nur in einer Umgebung entwickeln und in eine andere verschieben, sondern auch ganze produktionsreife Stacks spiegeln, einschließlich aller gleichen BIG-IP-Konfigurationen, Richtlinien und Application . Dadurch entfallen zahllose Stunden der Application und des Testens und die Entwickler können sich auf das konzentrieren, was sie am besten können: Code schreiben.
Für Entwickler, die Apps in die öffentliche Cloud verschieben, ist die Sicherung von Applications und deren Daten oft ein Anliegen – das muss aber nicht so sein. Ein Entwickler kann eine App in seiner Azure Stack-Umgebung erstellen, während ein Sicherheitsarchitekt die erforderlichen Einstellungen in der Web Application Firewall (WAF) von F5 konfiguriert. Der gesamte Stapel kann in Azure repliziert werden, wobei Sie sicher sein können, dass die Application durch dieselbe branchenführende WAF geschützt wird. Durch identische Richtlinien und Regelsätze entstehen keine Sicherheitslücken oder Schwachstellen, die sonst durch den Einsatz unterschiedlicher WAFs entstehen könnten.
Und da Azure Stack Azure Resource Manager (ARM) unterstützt, kann die umfassende Auswahl an ARM-Vorlagen von F5 verwendet werden, um die Bereitstellung und Konfiguration von BIG-IP VE-Instanzen in beiden Umgebungen zu automatisieren, was die Hochlaufzeiten deutlich verkürzt und die Effizienz der Hybrid-Cloud verbessert. Letztendlich kommt die gesamte Arbeit, die F5 geleistet hat, um eine so enge Integration mit Azure zu erreichen, nun sowohl Azure- als auch Azure Stack-Kunden zugute.
Es gibt viele Gründe, warum sich ein Unternehmen für die Investition in eine Hybrid-Cloud-Strategie entscheiden kann. Und ebenso viele Möglichkeiten gibt es für die Umsetzung dieser Strategie. Durch die Diversifizierung und Nutzung mehrerer unterschiedlicher Cloud-Plattformen und Application wird die Aufgabe der Implementierung und des Betriebs einer Hybrid-Cloud-Architektur für Unternehmen exponentiell anspruchsvoller.
Durch die Standardisierung auf erweiterte Application von F5 in allen Cloud-Umgebungen und die gleichzeitige Nutzung der homogenen Natur der Cloud-Plattformen Azure und Azure Stack von Microsoft können IT-Organisationen eine echte Hybridarchitektur mit vollständiger Portabilität von Applications zwischen Ökosystemen erstellen. Durch die Unterstützung von Applications mit denselben BIG-IP-Verkehrsverwaltungs- und Sicherheitsdiensten können Netzwerk- und Sicherheitsbetreiber die Application für Endbenutzer optimieren und gleichzeitig Applications und ihre Daten mit konsistenten Sicherheitsfunktionen und -richtlinien schützen.
Und in diesem relativ frühen Kapitel der Geschichte des Cloud Computing stehen viele IT-Organisationen unter dem Druck, schwierige Entscheidungen hinsichtlich ihrer langfristigen Cloud-Strategie zu treffen – ob die gesamte Cloud, die gesamte private Cloud oder eine Mischung aus beidem genutzt werden soll. Die Application von F5 für Azure und Azure Stack mildern die Auswirkungen dieser Entscheidung, indem sie eine ganzheitliche Lösung schaffen, bei der ein gesamtes Application jederzeit zwischen Cloud-Umgebungen migriert werden kann, um sich an veränderte Geschäftsanforderungen anzupassen.
Verbinden mit F5
