Thought Leadership
Multi-Cloud ist derzeit einer der heißesten Trends für Unternehmen. Die Verwendung mehrerer Clouds gleichzeitig, kann viele Vorteile bieten.
Richtig eingesetzt kann man mit der richtigen Kombination von Clouds unter anderem die Kosten für Infrastruktur senken, die Präsenz von Daten und Workloads in verschiedenen Regionen verbessern oder die Herstellerbindung an Cloud-Anbieter vermeiden. Unternehmen, die den Ansatz Multi-Cloud hingegen falsch verstanden haben, kann dieses Missverständnis viel Geld kosten. Denn eine fehlgeleitete Multi-Cloud-Strategie hat das Potenzial, Anwendungen, Teams und Budgets unnötig aufzusplitten. Eine fragmentierte Cloud-Strategie zwingt die zuständigen Infrastrukturteams zu erheblichem Mehraufwand beider Konfiguration, Bereitstellung und Skalierung von Anwendungen in der Cloud. All dies ist natürlich kostspielig, zeitaufwendig und steht im Widerspruch zum eigentlichen Versprechen der Multi-Cloud. Dabei ist dieser grundlegende Fehler eigentlich einfach zu vermeiden: IT-Verantwortliche müssen nur erkennen, dass die Multi-Cloud grundsätzlich eine Anwendungsstrategie und keine Infrastrukturstrategie ist.
Abstraktion der Anwendungen von der zugrunde liegenden Infrastruktur
Cloud-Ressourcen von mehreren Anbietern zu erwerben ist der einfache Teil: Backup auf Azure, produktive Workloads in AWS und die kritischen Systeme laufen in der Privaten Cloud im eigenen Rechenzentrum. Schwieriger ist es jedoch verschiedene Clouds nahtlos zu verbinden, damit man sich leicht über die einzelnen Cloud-Silos hinwegbewegen kann. Dieser Schritt ist jedoch zwingend notwendig um den Mehrwert der Multi-Cloud nutzen zu können. Erreicht wird dies erst, wenn Anwendungen von der zugrunde liegenden Infrastruktur und Anwendungsdiensten, wie z.B. Load Balancern, abstrahiert worden sind. So abstrahiert, wird eine heterogene Umgebung geschaffen, in der die Anwendung volle Flexibilität und Portabilität genießt und ihre benötigten Ressourcen erhält, ohne dass eine spezifische Konfiguration für die Cloudumgebung erforderlich ist. Ziel ist es, die Anwendung agnostisch für die Cloud-Infrastruktur zu machen und Dienste direkt bei der Application anzuwenden, damit sie die gleiche Portabilität haben.
Abstraktion ermöglicht es Unternehmen also, sich mit der Geschwindigkeit ihrer Anwendungen zu bewegen, nicht mit der Infrastruktur, die sie bereitstellt. Viele Plattformen, insbesondere containerbasierte Technologien, sind bereits agnostisch und überspannen problemlos mehrere Clouds. Die meisten Anwendungsdienste, wie Load Balancing und Web Application Firewalls, sind jedoch immer noch infrastrukturzentriert und passen nicht zu einer Anwendungsstrategie in der Multi-Cloud. Dies zeigt sich deutlich am Beispiel traditioneller Load Balancer, die sich aus mehreren Gründen nicht für Multi-Cloud-Konzepte eigenen.
Es ist an der Zeit, Load Balancing neu zu überdenken
Native Load Balancer der Cloud-Anbieter funktionieren fast selbstredend nur in ihrer jeweiligen Umgebung. So funktioniert AWS ELB beispielsweise nicht in Azure und Azures Application Gateway nicht in AWS. Und auch virtualisierte Load Balancer sind so konfiguriert, dass sie nur innerhalb eines Infrastruktursilos arbeiten. Diese an Hardware gebundenen Load Balancer funktionieren immer noch als Appliances, was bedeutet, dass sie fest mit ihrer Infrastruktur verbunden sind und nicht die gleiche Flexibilität und Portabilität bieten, wie die Anwendungen die sie unterstützen. Diese traditionellen Load Balancer sind auf die Infrastruktur ausgerichtet, nicht auf Anwendungen.
Ohne eine Multi-Cloud-Strategie sind multiple Clouds nur weitere Silos, die zusätzlich verwaltet werden müssen.
Für IT-Teams besteht die Herausforderung darin, Anwendungen so in einer Multi-Cloud-Umgebung mit hoher Verfügbarkeit bereitzustellen, dass sie mit der Anwendungsstrategie übereinstimmen. Um dies zu erreichen ist an der Zeit, Load Balancing neu zu überdenken.
Rack and Stack gehört der Vergangenheit an
Die Infrastruktur von Rechenzentren hat sich in den letzten zehn Jahren grundlegend verändert. Zahllose Server und Appliances in Racks zu stapeln war früher üblich und die Verwaltung von Hardware galt früher als der schnellste Weg, um die benötigte Infrastruktur zu erhalten. Visionäre IT-Führungskräfte, Self-Service-Praktiker und CAPEX-bewusste Finanzteams spielten alle eine Rolle bei der Umstellung auf die Cloud. Investitionen in die Hardware-Infrastruktur sind heute seltener denn je. Anwendungsteams sind mehr daran interessiert, die benötigten Ressourcen zu erhalten, als darüber nachzudenken, woher sie diese geliefert bekommen. IT-Teams stehen somit vor der Herausforderung, die wachsende Nachfrage mit viel kleineren Budgets bewältigen zu müssen. Als Ergebnis all dieser Faktoren, haben sich die Dienste, das Geschäftsmodell und die Einstellung zur Infrastruktur grundlegend verändert – diese Änderungen machen die Multi-Cloud realistisch und realisierbar.
Für die Multi-Cloud ist ein anwendungsorientierter Lastausgleich erforderlich
Load Balancing hingegen, hat sich in den letzten zehn Jahren kaum verändert. Die wenigsten Innovationen, die wir von den etablierten Anbietern gesehen haben, waren die Neuverpackung ihrer Hardware-Appliance in eine virtualisierte Edition, damit sie in der Cloud ausgeführt werden kann. Die Architektur ist die gleiche, ohne den Vorteil proprietärer Hardware, was bedeutet, dass sie nicht in der Lage sind, Dienste bereitzustellen, die Anwendungen benötigen, um in einer Multi-Cloud-Welt erfolgreich zu sein. Diese Appliances, ob Hardware oder virtuell, sind nicht anwendungszentriert und unterstützen in keiner Weise Multi-Cloud-Initiativen.
Wie die meisten anderen Appliances müssen Load Balancer als Software-Services neu abgebildet werden – Dienste, die pro App bereitgestellt werden können und mit der Anwendung in die für die Anwendung am besten geeignete Umgebung verschoben werden. Multi-Cloud ist eine Anwendungsstrategie. Und der einzige Weg, diese Strategie zum Leben zu erwecken, besteht darin, Infrastruktur und Dienste zu nutzen, bei denen Anwendungen im Vordergrund stehen.
www.avinetworks.com
