Da 81% der Unternehmen, die öffentliche Cloud-Dienste nutzen, gleich mehrere Anbieter einsetzen, wird eine Cloud-agnostische Entwicklungsstrategie zur absoluten Notwendigkeit. Die Anwendungen und die Infrastruktur müssen über öffentliche und private Clouds hinweg kompatibel sein, um hierdurch ein gewisses Maß an Flexibilität zu erreichen.
Selbst für Unternehmen, die derzeit nur einen einzigen öffentlichen Cloud-Anbieter nutzen, ist die Cloud-agnostische Entwicklung die einzige Möglichkeit, sich gegen zukünftige Probleme und Kosten zu versichern, die durch die Bindung an einen einzigen Anbieter entstehen können.
Sollte die Infrastruktur sowie die Architektur und Entwicklung von Anwendungen nicht Cloud-agnostisch sein, werden mögliche zukünftige Entscheidungen, auf eine Multi-Cloud-Lösung umzuschwenken oder einfach von einem Anbieter zum anderen zu wechseln, eingeschränkt und kompliziert.
Im folgenden Artikel zeigen wir:
K&C – WIR KREIEREN EINZIGARTIGE TECH-LÖSUNGEN SEIT ÜBER 20 JAHREN. WIR VERSCHAFFEN IHNEN IHREN WETTBEWERBSVORTEIL!
Schreiben Sie uns eine Nachricht, um Ihre individuellen Bedürfnisse oder das nächste Projekt zu besprechen.
Im Jahre 2020 nutzten bereits sage und schreibe 90% aller Unternehmen einen Cloud-Service für ihre Arbeitsabläufe. Clouds werden hierbei nicht nur für spezifische Aufgaben genutzt – ganze 60% des gesamten Arbeitsaufkommens liefen im Jahre 2019 über die Cloud, gegenüber 45% im Vorjahr. Die Zahlen für das Jahr 2021 werden, sofern sie vorliegen, mit an Sicherheit grenzender Wahrscheinlichkeit zeigen, dass sich dieses Wachstum fortsetzen wird.
Zweistellige Zuwachsraten für das Arbeitspensum, das nun in der Cloud stattfindet sowie die Tatsache, dass bereits heute deutlich über 50% der Arbeitslasten in der Cloud ausgeführt werden, sind aussagekräftige Statistiken. Sie machen deutlich, dass die Cloud-Services zum Standard für digital arbeitende Unternehmen geworden ist. Die Hälfte der großen Unternehmen gibt jährlich mehr als 1,2 Millionen Dollar für ihre öffentlichen Cloud-Services aus, und 30% aller IT-Budgets werden für Cloud-Computing-Ressourcen aufgewendet.
Öffentliche Cloud-Dienste, wie beispielsweise Rechenleistung, Speicher und Software auf virtuellen Maschinen werden online von Drittunternehmen bereitgestellt. Die 10 größten öffentlichen Cloud-Anbieter – angeführt von AWS, Microsoft Azure, Google Cloud Platform & Alibaba – kontrollieren über 50% des öffentlichen Cloud-Marktes.
„Organisationen nutzen im Schnitt 5 verschiedene Cloud-Plattformen.” – Hostingtribunal.com, Cloud-Einsatz-Statistiken 2020.
Warum nutzen Organisationen mehr als nur eine öffentliche Cloud-Plattform zur Ausführung von Arbeitslasten? Eine weitere Statistik wirft Licht auf diese Frage:
„Die Verwaltung von Cloud-Kosten stand 2019 das dritte Jahr in Folge ganz oben auf der Prioritätenliste der Unternehmen.“ – Rightscale, State of The Cloud Survey 2019
Für Organisationen stellen öffentliche Cloud-Computing-Dienste in den meisten Fällen eine kosteneffizientere Möglichkeit dar, Arbeitslasten zu bewältigen, anstatt in eine eigene Infrastruktur zu investieren. Eine private Infrastruktur muss nämlich in der Lage sein, Nachfragespitzen zu bewältigen, auch wenn diese relativ selten vorkommen. Eine öffentliche Cloud-Infrastruktur bietet eine automatische Skalierung an, die nutzungsabhängig bezahlt wird.
Das bedeutet, dass zusätzliche Ressourcen für gelegentliche Nachfragespitzen nur bei Gebrauch bezahlt werden. Unternehmen müssen somit nicht die Wahl treffen zwischen entweder einer oftmals sehr teuren, selten in vollem Umfang gebrauchten Infrastruktur oder Unterbrechungen und Ausfallzeiten bei Arbeitsspitzen.
Eine Cloud-agnostische Strategie bringt die Flexibilität von Cloud-Diensten auf ein neues Level. Wenn Arbeitslasten und Anwendungen so aufgebaut sind, dass sie in jeder öffentlichen Cloud laufen, können Präferenzen bezüglich des Anbieterwechsels gewählt werden, die auf Grundlage von Leistung und Kosteneffizienz und im Kontext dynamischer Faktoren wie Geografie und den Stärken und Angeboten der jeweiligen Anbieter getroffen werden.
Cloud-Neutralität bietet ein Maß an Flexibilität, das die Kosteneffizienz noch weiter verbessert als eine einfache Nutzung der öffentlichen Cloud. Insbesondere für Organisationen mit hoher Arbeitsbelastung können sich selbst kleine Kostenunterschiede zu erheblichen Summen addieren. Und für viele digital arbeitende Unternehmen sind schrittweise Leistungssteigerungen und Versicherungen gegen technische Probleme aufseiten des Anbieters ebenso ein Anreiz wie der finanzielle Faktor, Cloud-agnostisch zu werden.
Ein Bericht von Bain & Company ergab, dass 22% der Unternehmen, die öffentliche Cloud-Services nutzen, das Risiko der Anbieterbindung als eine ihrer größten Risiken ansehen. Der Begriff „Anbieterbindung“ (Vendor Lock-in) bezieht sich auf eine übermäßige Abhängigkeit gegenüber den Produkten oder den Dienstleistungen eines bestimmten Anbieters. Dadurch ist das Unternehmen Risiken ausgesetzt, wie beispielsweise Preiserhöhungen, Änderungen und Abschaffung bestimmter Angebote und im schlimmsten Fall sogar die Einstellung des Betriebes aufseiten des Anbieters.
Das bedeutet, dass selbst Organisationen, die aufgrund von guter Preisgestaltung, Leistung, Funktionalität, Kompetenz und Zuverlässigkeit nur einen einzigen öffentlichen Cloud-Anbieter nutzen, ihre Anwendungen und Infrastruktur dementsprechend ausbauen sollten, sodass ein einfacher Wechsel möglich ist, falls sich die Umstände ändern.
Selbst in diesen noch relativ frühen Tagen der Cloud-Migration gab es bereits zahlreiche Beispiele für die Kehrseite der Herstellerbindung. Eines der bekanntesten Beispiele ist der Fall des öffentlichen Cloud-Datenspeicher-Pioniers Nirvanix, der 2013 seine Geschäftstätigkeit einstellte. Die Benutzer hatten nur 2 Wochen Zeit, um ihre Daten zu sichern und zu übertragen.
Auch wenn es unwahrscheinlich ist, dass die großen Unternehmen wie AWS, Microsoft Azure, Google Cloud Platform oder Alibaba bankrottgehen werden, so genügt ein kurzer Blick zurück in die Geschichte von AOL, um zu sehen, dass es keine Garantie gibt. Viel wahrscheinlicher ist es, dass sich bestimmte Anbieter bei zunehmendem Wettbewerb dazu entschließen werden, ihr Geschäftsmodell für ein bestimmtes Klientel zu ändern beziehungsweise zu variieren.
Letztendlich wird sich die Großzahl der Lock-in-Szenarien durch mangelnde Cloud-agnostische Flexibilität ereignen, die zu einem Verlust von Betriebs- und Kosteneffizienz führt; Weltuntergangsszenarien, bei denen ein Cloud-Anbieter unerwartet aus dem Geschäft ausscheidet, sind eher unwahrscheinlich. Aber für eine wachsende Zahl von Cloud-unterstützten Unternehmen ist diese Bedrohung mehr als nur ein Anreiz, eine Cloud-agnostische Strategie umzusetzen.
Ein perfektes Beispiel dafür ist die Situation, in der sich Snapchat-Besitzer Snap kürzlich befand. Pläne für eine Umstrukturierung, die ein reibungsloses zukünftiges Wachstum ermöglichen sollten, wurden dadurch blockiert, dass die Infrastruktur der Social-Media-App direkt an die Google-Cloud angebunden war. Dies bedeutete, dass die notwendigen Geschäftsübergänge wesentlich höhere Kosten und eine übermäßige Ressourcenzuweisung als erwartet verursacht hätten. Die Antwort von Snap war die Investition in die Infrastruktur der Amazon Web Services (AWS), die das Anbieter-Portfolio diversifizieren und das Risiko reduzieren sollte.
Als Snap ursprünglich die Anwendung und Infrastruktur aufbaute, wäre ein Cloud-agnostischer Ansatz praktisch unmöglich gewesen. Glücklicherweise ist das heute nicht mehr der Fall, was bedeutet, dass wachsende Unternehmen von heute die Kosten und Komplikationen von Snap vermeiden können.
Die Hauptvorteile der Nutzung einer Cloud-agnostischen Strategie lassen sich wie folgt zusammenfassen:
Eine Cloud-agnostische Strategie ermöglicht es, den Cloud-Anbieter mit minimalen Schwierigkeiten zu wechseln, falls sich Preis, Leistung oder das Angebot ändert. Gleichermaßen bietet sich ein Multi-Cloud-Ansatz dazu an, die Arbeitslasten zwischen den Anbietern aufzuteilen.
So können nützliche Funktionen, die ausschließlich bei einem oder einer begrenzten Anzahl von Anbietern erhältlich sind, genutzt werden. Führen Sie einfach die Arbeitslasten bei dem Anbieter aus, der Ihnen die größten Vorteile bietet. Andere Arbeiten können auf dem Cloud-Service jener Anbieter durchgeführt werden, die hierzu ein optimales Angebot liefern.
Die Verteilung von Systemen und Arbeitslasten auf mehr als nur eine Cloud-Plattform vermeidet das Risiko von Redundanz und Ausfallzeiten, falls es zu Problemen kommt.
Ein weiterer Vorteil, der sich mit den beiden vorhergehenden überschneidet: Cloud-agnostische Organisationen verfügen über ein Risikomanagement, das sie im Allgemeinen robuster gegenüber Veränderungen in der IT-Landschaft macht.
Da jede Medaille zwei Seiten hat, widmen wir uns im Folgenden den Nachteilen einer Cloud-agnostischen Strategie:
Obwohl ein Cloud-agnostischer Ansatz eine Menge Zeit, Kosten und Stress spart, ist er mit mehr Vorleistungen verbunden. Der Aufbau einer agnostischen Cloud-Strategie von Grund auf, entweder für bestimmte Arbeitslasten oder innerhalb einer Organisation, dürfte die anfänglichen Entwicklungskosten und die Komplexität erhöhen.
Ein strikter Cloud-agnostischer Ansatz könnte bedeuten, dass eine Organisation sich darauf beschränkt, nur die Dienste zu nutzen, die bei allen öffentlichen Cloud-Anbietern der Multi-Cloud-Strategie verfügbar sind. Wenn einer der Anbieter AWS, Microsoft Azure, Alibaba, die Google Cloud Platform oder ein anderer größerer Anbieter eine praktische neue Funktion einführt, kann eine strikte Cloud-agnostische Strategie bedeuten, dass man zögert, die Funktion zu nutzen, weil sie nicht auf eine andere Plattform übertragen werden kann.
Bei den meisten Organisationen, insbesondere auf Unternehmensebene, wird eine größere Auswahl im Allgemeinen als Vorteil angesehen. Wenn man sich jedoch weigert, auch nur eine kleine Anzahl spezifischer Arbeitslasten an einen Anbieter zu binden, der eine einzigartige und vorteilhafte Funktion liefert, könnte sich dies unter bestimmten Umständen auch als Einschränkung herausstellen.
Der Amazon Relational Database Service (Amazon RDS) zum Beispiel „erleichtert Ihnen die Einrichtung, Verwaltung und Skalierung einer relationalen Datenbank in der Cloud. Dieser Service stellt kosteneffiziente und anpassbare Kapazitäten zur Verfügung und automatisiert zeitaufwendige Verwaltungsaufgaben wie Hardwarebereitstellung, Datenbankeinrichtung, Einlesen von Patches und Backups. Sie können Sich auf ihre Anwendungen konzentrieren und sich darum kümmern, dass sie die Vorgaben für Performance, Hochverfügbarkeit, Sicherheit und Kompatibilität erfüllen.“
Eine Organisation, die versucht, ihre eigene Datenbankinstanz auf einer EC2-Instanz zu hosten, müsste auch die Verwaltung übernehmen. Um dasselbe Niveau an Stabilität oder Leistung zu erreichen, wären möglicherweise Hunderte von Stunden an Entwicklungszeit nötig. Für viele Organisationen, insbesondere für solche, die kleiner als die Unternehmensebene sind, ist dies möglicherweise kein vertretbarer Kompromiss.
Werfen wir einen Blick auf zwei sehr unterschiedliche Unternehmen, von denen das eine ein technisches Start-up und das andere ein renommiertes Finanzdienstleistungsunternehmen ist und zum FTSE 100-Index der Londoner Börse gehört, welcher die 100 größten Aktiengesellschaften Großbritanniens umfasst:
Cuddle.ai, die auf KI basierende Geschäftsdaten-Analyse-App, hat die Entscheidung getroffen, ihre Anwendungen Cloud-agnostisch zu entwickeln.
„Wir haben uns dazu entschieden, Organisationen auf der ganzen Welt anzusprechen. Einige Kunden bevorzugten einen bestimmten Cloud-Anbieter aufgrund von früheren Erfahrungen oder aufgrund ihrer Geschäftsinteressen.“
Da das Team erreichen wollte, dass die Anwendung auf jeder beliebigen Cloud-Plattform läuft, entschied sich Cuddle dafür, die Cloud-agnostische Entwicklung von Anfang an voranzutreiben:
„Eine Cloud-agnostische Architektur ist durchführbar. Es ist nicht ganz einfach, aber durchaus realistisch. Wir müssen frühzeitig einige Entscheidungen treffen und uns an die Prinzipien des Systemdesigns halten, um mehrere Clouds unterstützen zu können“, so Cuddle abschließend.
Hier können Sie die vollständige Fallstudie lesen, einschließlich der Art und Weise, wie die Geschäftsentscheidung getroffen wurde und wie die Wahl der Technologien und DevOps-Prozesse umgesetzt wurde.
Experian ist ein international renommiertes Finanzdienstleistungsunternehmen, das an der Londoner Börse notiert und Teil des FTSE 100 ist.
Im Jahre 2015 ernannte das Unternehmen Barry Libenson, ehemals von Cisco und dem US-Einzelhandelsriesen Safeway, zum neuen CIO der Firma. Eine seiner Prioritäten, die heutzutage als eine seiner wichtigsten Errungenschaften angesehen wird, war die Schaffung eines standardisierten Ansatzes bei der Softwareentwicklung.
Zwar stand ihm seiner Ansicht nach ein starkes Team von Entwicklern zur Verfügung, doch die Herausforderung machte sich in der Dezentralisierung von Entwicklern an unterschiedlichen Standorten auf der ganzen Welt deutlich, die darüber hinaus eine Reihe von Kodierungsstandards, Datenbanken und Plattformen verwendeten:
„Ich wollte, dass alle die gleichen Techniken verwenden – wir haben viel mehr auf Open Source standardisiert„, sagte Libenson in einem Interview mit Computer Weekly. Er wollte es den Entwicklern von Experian erleichtern, über Cloud-Plattformen hinweg zu arbeiten.
Experian hat diesen Strategiewechsel durch Container unterstützt, sowie durch die Einführung der OpenShift-Plattform von Red Hat und Kubernetes, um die Bereitstellung und Verwaltung der Container zu erleichtern.
„Der Grund, warum wir das getan haben, war, dass wir Cloud-Agnostiker sein wollten, sodass wir vor Ort gestalten können, auf Microsofts Cloud, auf Googles Cloud, auf Amazons Cloud und bei Bedarf Dinge zu verschieben. Ich denke, dass wir bei der Erreichung unserer Ziele in der Softwareentwicklung weit gekommen sind.“
Es gibt immer mehr Auswahlmöglichkeiten, wenn es um Cloud-agnostische Entwicklungs-Technologien geht. Im Folgenden zeigen wir die beliebtesten Methoden auf, die unsere Ingenieure bei K&C verwenden, um Apps zu entwickeln, die auf einer Cloud genauso gut funktionieren wie auf jeder anderen:
Da eine Cloud-agnostische Strategie von Natur aus die Arbeitsbelastung von DevOps erhöht, ist ein Vorgehen nach dem Prinzip „zuerst automatisieren“ von entscheidender Bedeutung. Die Infrastruktur sollte mit wenig bis gar keinem manuellen Aufwand rotierbar sein und die Tests und die Integration sollten über eine geplante CI-Pipeline verwaltet werden, die Genehmigungen erfordert.
Die Arbeit von DevOps nimmt mit einer Cloud-agnostischen Strategie erheblich zu. Wir haben daher mit einer Zuerst-Automatisieren-Mentalität begonnen. Die Infrastruktur sollte einfach und fast ohne manuelle Eingriffe geschaffen werden; eine CI-Pipeline für eine einfache Integration und Tests sowie Deployment-Pipelines, um die geplante Softwarebereitstellung mit Genehmigungen unter Dach und Fach zu bringen.
Die Architektur von Mikrodiensten strukturiert eine Anwendung als eine Sammlung von Diensten, die in weitere kleinere Einheiten unterteilt sind, von denen jede eine bestimmte Geschäftsfunktion erfüllt und die miteinander interagieren. Anwendungen, insbesondere wenn sie als Cloud-agnostisch konzipiert wurden, sind leichter zu erstellen und zu warten, wenn sie in besser verwaltbare Mikroservice-Einheiten unterteilt sind. Mikro-Dienste sind:
Die Mikrodienst-Architektur ermöglicht eine schnelle, häufige und zuverlässige Bereitstellung großer, komplexer Anwendungen. Außerdem ist es für eine Organisation um einiges einfacher, Änderungen oder Ergänzungen an ihrem Technologiestack innerhalb einer Mikrodienst-Umgebung umzusetzen.
Als Containerisierungs-Technologie reduziert Docker die Probleme bei der Migration von Arbeitslasten von einer Cloud-Plattform auf eine andere. Innerhalb des Docker-Containers werden Anwendungsanforderungen wie Laufzeit, Umgebungsvariablen und Setup-Skripte definiert. Das bedeutet, dass der Container, von geringfügigen Ausnahmen abgesehen, fast überall gestartet werden kann.
Wenn Container dann in eine Container-Orchestrierungsplattform gesetzt werden, verwaltet diese den Lebenszyklus sowie, falls gewünscht, die Protokollierung und Überwachung. Die OCI-konforme Container-Laufzeit gleicht dann jede Diskrepanz zwischen den Hosts während der Ausführung aus.
HashiCorp Terraform, eine relativ neue Befehlszeilenschnittstelle (CLI), hilft bei der Definition der Infrastruktur als Code. Es ermöglicht die Spezifizierung von Cloud-Anbieter, Zugriffsschlüssel und Geheimschlüssel bei der Ausführung von terraform apply. Die CLI aktiviert anschließend die Infrastruktur, die der Entwickler darüber hinaus einsetzt.
Diese Infrastruktur bei Bedarf wieder herunterzufahren ist so einfach wie das Ausführen des Befehls terraform destroy.
Solch eine Verwendung von Hashicorp Terraform bedeutet, dass bei einer Multi-Cloud-Strategie mehrere Terraform-Skripte für jeden einzelnen Cloud-Anbieter geschrieben werden müssen, um Cloud-agnostisch zu sein. Diese Skripte müssen auch aktualisiert werden, wenn die Organisation die Möglichkeit haben möchte, den Anbieter jederzeit zu wechseln.
Entwickler, die Skripte für verschiedene Cloud-Anbieter schreiben, benötigen ein gewisses Maß an Kenntnissen jeder Plattform bezüglich der hochzufahrenden Instanztypen und über deren korrekte Größe.
Ansible, Chef und Puppet sind weitere Beispiele für Konfigurationswerkzeuge, die ähnliche Kernfunktionalitäten haben, wobei jedes seine eigenen Besonderheiten aufweist, die alle als Teil einer Cloud-agnostischen Strategie verwendet werden können.
Im Folgenden lässt sich das Video Best Practices of Infrastructure as Code with HashiCorp Terraform ansehen.
Kubernetes kann in Kombination mit Docker und Terraform eine Cloud-agnostische Strategie weiter ausbauen, wenn es als Teil der neuen Generation von verwalteten Multi-Cloud-Kubernetes-Lösungen wie Istio eingesetzt wird. Istio fasst Kubernetes-Cluster so zusammen, dass sie Container-basierte Anwendungen ausführen und verwalten. Dies abstrahiert von der Infrastruktur, auf der der Code ausgeführt wird, und bedeutet, dass sich die Entwickler darauf konzentrieren können, wie die Anwendung aussieht.
Cloud-agnostische Technologien brauchen noch einige Zeit, um zu reifen, und sind noch nicht für jede Art von Organisation, Unternehmen oder individueller Anwendung perfekt geeignet. Aber selbst wenn eine vollständige Cloud-Neutralität nicht erreicht wird, können Container- und verwaltete Datenbanktechnologien immer noch einen großen Beitrag dazu leisten, Ihre Organisation flexibler und anpassungsfähiger an zukünftige Veränderungen in einer dynamischen IT-Umgebung zu machen.
Wenn Sie sich Gedanken darüber machen, ob eine Cloud-agnostische Strategie für Ihre Organisation oder eine bestimmte Anwendung, die Sie entwickeln, sinnvoll ist, und Sie die Vor- und Nachteile mit Experten besprechen möchten, die einen reichhaltigen Erfahrungsschatz mitbringen, würden wir gerne mit Ihnen ins Gespräch kommen.
Nehmen Sie Kontakt zu uns auf, um alle Einzelheiten zu besprechen und lassen Sie uns gemeinsam schauen, ob ein Cloud-agnostischer Ansatz für Sie infrage kommt!
Wann gelingt IT Outsourcing?
(und wann nicht?)