Abstraktion oder cloud-agnostisch? Zwei Ansätze für eine erfolgreiche Governance-Strategie

Anbieter zum Thema

Hyland Software Germany GmbH

Nutanix Germany GmbH

STACKIT GmbH & Co. KG

Immer mehr Unternehmen lassen Rechenzentren hinter sich und starten ihre Cloud Journey. Entscheidend für eine erfolgreiche Umsetzung ist dabei die richtige Governance-Strategie, die zur Arbeitsweise des jeweiligen Unternehmens passen sollte.

Statt sich ausschließlich auf einen einzigen Cloud-Provider zu beschränken, setzen bereits heute die meisten Unternehmen auf einen Multi-Cloud-Ansatz. Damit in einem solchen, potenziell komplexen Set-Up der Überblick nicht verloren geht und digitale Assets geschützt bleiben, benötigen Unternehmen eine Cloud-Governance-Strategie, die zu ihnen passt.

Im Allgemeinen gibt es hier zwei Möglichkeiten: den cloud-agnostischen Governance-Ansatz und die Resource Abstraction. Die Cloud-Provider bieten natürlich auch eigene Governance-Mechanismen an, welche jedoch für eine Multi-Cloud-Strategie kaum geeignet sind. Zusätzlich entsteht eine starke Abhängigkeit von den jeweiligen Cloud-Providern.

Ansatz 1: Resource Abstraction

Die Idee ist leicht zu fassen: Über alle eingesetzten Cloud-Plattformen wird eine Abstraktionsschicht gelegt. Ziel ist es, den Zugriff auf die jeweiligen Cloud-Plattformen durch die Abstraktion überflüssig zu machen. Stattdessen werden Cloud-Ressourcen über eine proprietäre Oberfläche provisioniert.

Das mag im ersten Moment sinnvoll erscheinen, weil in diesem Szenario volle Kontrolle über die Cloud-Aktivitäten herrscht. Kontrollen können technisch sehr detailliert umgesetzt werden und das sogar über verschiedene Cloud-Technologien hinweg.

Bei genauerem Hinsehen offenbaren sich allerdings einige Schwächen der Resource Abstraction. Was für ein zentrales Cloud-Foundation-Team viel Kontrolle bedeutet, nimmt DevOps-Teams die nötige Flexibilität und schränkt die Möglichkeiten in der Cloud-Entwicklung stark ein. Statt bekannter Standards und Tools muss ein neues System gelernt, beherrscht, akzeptiert und genutzt werden. Das ist problematisch, da am Markt vorhandene Skill-Pools oft nicht effektiv eingesetzt werden können. So kann zum Beispiel ein AWS-erfahrener Engineer nicht sofort mit den bekannten Tools loslegen, sondern muss sich erst mit den Eigenheiten der Abstraktionsschicht auseinandersetzen.

Hinzu kommt, dass die Abstraktionsschicht sich auf Standard-Services fokussiert. Dies beinhaltet meist traditionelle VMs, Netzwerke oder Datenbanken – klassisches IaaS. Neue und oft innovative Services der Cloud-Provider müssen also zunächst individuell integriert werden. Das macht das zentrale System zum Nadelöhr und verzögert damit nicht nur die Anwendungsentwicklung, sondern verursacht auch zusätzliche Kosten.

Option 2: Cloud-agnostic Governance

Auch beim zweiten Ansatz, der Cloud-agnostischen Governance wird in gewisser Weise abstrahiert, allerdings auf einer anderen Ebene. Insgesamt ist die Herangehensweise weniger komplex. Vor allem, weil sie sich auf die zentralen Aspekte der Cloud Governance beschränkt. Themen wie Tenant Management, Berechtigungsmanagement, Tagging oder die Abrechnung werden hier einheitlich und cloud-übergreifend geregelt, um Komplexität zu reduzieren. Oft wird der Ansatz auch als „Orchestration Abstraction“ bezeichnet.

Die cloud-agnostische Governance stellt damit eine Verknüpfung zwischen Organisation und den Cloud-Plattformen her und gibt dem zentralen Cloud Foundation Team die Kontrolle über die Cloud-Landschaft. In diesem Ansatz wird sichergestellt, dass alle Cloud-Umgebungen des Unternehmens zentral, einheitlich und konsistent dokumentiert sind und klar ist, wer die Kosten dafür trägt. Auch grundlegende Sicherheitsmechanismen werden zentral durchgesetzt. So behält das zentrale Cloud-Foundation-Team die Kontrolle über die Cloud-Landschaft.

Anders als bei der Resource Abstraction haben DevOps-Teams jedoch mehr Freiheiten in der technischen Gestaltung der Anwendung. Sie können frei auswählen, welche Services der Cloud-Provider sie nutzen möchten. Sie können bekannte Tools für Deployments oder die Interaktion mit den Cloud-Plattformen (z.B. Terraform oder CI/CD Tools) einsetzen und alle Plattform-APIs, sowie CLIs nativ nutzen. Wo es sinnvoll ist, können DevOps-Teams mit standardisierten modularen Komponenten, z.B. Landing Zones oder Infrastruktur-Services, unterstützt werden.

Die Cloud soll Enabler sein!

Mit der Resource Abstraction werden zahlreiche Lock-Ins gegen einen einzelnen Lock-In getauscht. Für klassische, eher statische Workloads kann das funktionieren. Die cloud-agnostische Governance hingegen ermöglicht DevOps-Teams mehr Freiheiten und trägt dem Paradigma der freien Technologiewahl für ein selbstverantwortliches Team Rechnung, was die Motivation und Handlungsfähigkeit der Teams erhöht.

Die Frage, welcher der beiden Ansätze die richtige Wahl ist, ist also eine Frage des organisatorischen Mindsets. Wird technologischer Fortschritt in einem Unternehmen häufig hinterfragt, ist der Abstraction Layer wahrscheinlich die geeignetere Lösung.

Wenn jedoch neue Technologien grundsätzlich als unternehmerische Chance gesehen werden, ist die cloud-agnostische Governance klar die bessere Wahl. Sie fungiert als Enabler für echte Innovation und stärkt die Verantwortung einzelner Teams. Außerdem reduziert sie die Abhängigkeit von den Cloud-Providern und gibt den Unternehmen das Ruder in die Hand.

* Die Autorin Christina Kraus ist Mitgründerin der Meshcloud GmbH und Expertin für cloud-basierte Geschäftsmodelle. Sie ist Vorstandsmitglied des Bitkom-Arbeitskreises Cloud Services & Digital Ecosystems und im Rat für Digitalethik der hessischen Landesregierung.

(ID:47845497)