Wie die Cloud Foundation Ihr Dev(Sec)Ops beschleunigt
DevOps – eine Verschmelzung von Entwicklung und Betrieb – erweitert das traditionelle Verständnis von Software-Entwicklung und integriert mit DevSecOps auch Aspekte der IT-Sicherheit und des Testings in einen zusammenhängenden, kontinuierlichen und performanten Prozess. Viele betrachten DevOps als die nächste Evolutionsstufe der Agilität: Sie soll Menschen, Prozesse und Technologien zusammenführen, um Silos zu durchbrechen und kontinuierlichen Mehrwert für Kunden zu liefern. Wir werden in diesem Artikel vor allem den organisatorischen und teamformenden Aspekt von DevOps näher beleuchten.
Parallel dazu bildet eine solide Cloud Foundation das Fundament einer erfolgreichen Cloud-Implementierung. Eine Cloud Foundation bündelt notwendige Ressourcen, Prozesse und Richtlinien auf einer Plattform, mit dem Ziel, eine sichere, effiziente und skalierbare Cloud-Landschaft zu schaffen.
Diese beiden Konzepte – DevOps und die Cloud Foundation – bilden den Rahmen für die folgenden Abschnitte, in denen wir tiefer in die Verbindung zwischen DevOps- und Plattform-Teams eintauchen, die Bedeutung der Standardisierung bestimmter Produkte durch das Plattform-Team erörtern und die Rolle der Cloud Foundation sowie ihre Vorteile herausarbeiten. Abschließend zeigen wir auf, wie durch die Implementierung einer Cloud Foundation das DevOps-Konzept um den Security-Aspekt zu DevSecOps erweitert werden kann.
Organisationsstrukturen für DevOps: Produkt- und Plattform-Teams
In den vergangenen Jahren wurde deutlich, dass DevOps in Unternehmen einen breiten Interpretationsspielraum besitzt. Das äußert sich in der Vielfalt der Teamstrukturen, der Anwendung verschiedener DevOps-Methoden und der Einführung zahlreicher moderner Tools, die nicht immer das gewünschte Ergebnis erzielen. Es gibt also kein universelles Modell zum Erfolg. Die Anpassungen folgen den individuellen Gegebenheiten eines Unternehmens. Umso wichtiger ist es, einen guten Überblick zu behalten und Schnittstellen zwischen Teams, Tools und Prozessen klar zu definieren, um die gewünschten Ergebnisse zu erzielen.
Mit dem übergeordneten Ziel, Silos aufzubrechen und Betrieb, IT-Sicherheit, Testing und Entwicklung enger zu verzahnen, präsentieren wir in diesem Artikel einen entscheidenden Erfolgsfaktor, der sich in unserer Praxis bewährt hat.
Die Entwicklung von Produkt-Teams
Produkt-Teams, in der Literatur auch of stream-aligned Teams genannt, sind Teams die nach Wertschöpfungsketten organisiert werden, um eine schnellere und effektivere Bereitstellung von Software zu ermöglichen. Sie entstehen durch die Auflösung von organisatorischen Silos und verantworten dann nicht nur die Entwicklung ihrer Produkte, sondern auch deren Testing, IT-Sicherheit und Betrieb und damit den End-to-End-Prozess. Ziel eines Produkt-Teams ist es, einen effektiven digitalen Arbeitsprozess, sei es für die Entwicklung eines Produkts oder die Bereitstellung einer Dienstleistung, anzubieten.
Um sicherzustellen, dass diese Teams nicht auch noch die Einrichtung ihrer Entwicklungsumgebung, der Infrastruktur und aller eingesetzten Tools übernehmen müssen, entsteht die Notwendigkeit eines unterstützenden Plattform-Teams. Die Hauptaufgabe des Plattform-Teams ist es, eine Plattform bereitzustellen, welche die Produktivität der Produkt-Teams steigert und gleichzeitig die kognitive Belastung reduziert. Die Produkt-Teams sind Konsumenten dieser Plattform, was ihre Konzentration auf die Wertschöpfung erhöht.
Rolle und Bedeutung von Plattform-Teams
Das Plattform-Team strebt nach konsolidierter Expertise, die oft auf dem Gebiet von DevOps liegt. Dieses Team betreibt eine interne Plattform, über die interne Kunden Services per Self-Service oder API ("as a Service") beziehen können. Die angebotenen Services umfassen oft grundlegende Infrastruktur- und Plattform-Services, die in der gesamten Organisation benötigt werden. Beispiele hierfür sind zentral bereitgestellte, möglicherweise individualisierbare CI/CD-Pipelines oder Cloud-Umgebungen wie AWS-Accounts, Azure-Subscriptions oder GCP-Projects. Darüber hinaus gehören dazu auch "Golden Paths", also Better-Practice-Konfigurationen spezifischer Cloud-Services wie Datenbanken oder Storage Buckets. Die Bereitstellung dieser Services entlastet die Produkt-Teams, weil sie ihnen die Aufgabe der korrekten Konfiguration abnimmt und dadurch die Anzahl der Remediations reduziert und die Time-to-Market beschleunigt.
Der Bedarf für solche Plattform-Teams ergibt sich demnach aus drei Haupttreibern: Reduzierung kognitiver Belastung, fehlende Ressourcen und mangelnde Governance.
- Reduzierung kognitiver Belastung: Durch die Zusammenarbeit mit Plattform-Teams können Produkt-Teams sich auf ihre spezifischen Geschäftsprozesse und Anforderungen konzentrieren, anstatt sich um die Implementierung von Infrastruktur und Tools kümmern zu müssen, wodurch ein Teil der Komplexität des Systems entfällt bzw. in das Plattform-Team verlagert wird.
- Fehlende Ressourcen: In der heutigen Zeit verfügen nur wenige Organisationen über ausreichendes DevOps-Know-how, um vollständig autonome Produkt-Teams zu schaffen, die eine End-to-End-Verantwortung für die Entwicklung und den Betrieb einer Anwendung tragen könnten. Im Gegensatz zu den funktionalen Bereichen einer Anwendung, die durch Einzigartigkeit und tiefe Fachexpertise gekennzeichnet sind, ähneln sich DevOps-Aspekte rund um Deployment, Testing und Betrieb oft über verschiedene Anwendungen hinweg. Die Konsolidierung dieses seltenen DevOps-Know-hows und die Bereitstellung in der Breite bieten daher einen effektiven Ansatz, um eine Vielzahl funktional unterschiedlicher Anwendungen innerhalb einer Organisation zu unterstützen.
- Mangelnde Governance: Die Konsolidierung von DevOps-Expertise in einem Plattform-Team bringt weitere Vorteile mit sich. Obwohl DevOps-Fähigkeiten auf den ersten Blick wenig mit Governance zu tun haben, führt ein einheitlicher Ansatz zu mehr Homogenität. Es werden einheitliche Toolchains eingesetzt, Best Practices wie die konsequente Nutzung von Infrastructure-as-Code und Versionierung werden gefördert oder sogar eingefordert, und es entsteht Transparenz darüber, welche Services in welchem Umfang konsumiert werden. Das reduziert die Komplexität und erleichtert es den verantwortlichen Teams, einen Überblick über die gesamte Infrastruktur zu erhalten, was andernfalls mit erheblichem Mehraufwand, beispielsweise durch die Erforderlichkeit von Einzelassessments, verbunden wäre.
Cloud-Migration meistern mithilfe einer Cloud Foundation
Die Cloud Foundation als interne Plattform
Eine Cloud Foundation ist eine spezifische Ausprägung einer internen Plattform. Wie der Name schon sagt, hat sie das Ziel, ein Fundament für die entstehende Cloud-Landschaft aufzubauen. Je stabiler und sicherer sie aufgebaut und entwickelt wird, desto leichter lassen sich neue, innovative Applikationen darauf entwickeln.
Im Zuge der Implementierung ihrer Cloud-Strategie stehen Unternehmen vor der Herausforderung, dass sie eine große Anzahl an Applikationen in die Cloud bringen wollen, zum Beispiel durch die Neuentwicklung digitaler Anwendungen oder Rechenzentrumskonsolidierung. Zwar werden die einzelnen Applikationen durch individuelle Produkt-Teams betreut, meist sind sie jedoch auf Leistungen der internen IT angewiesen: Zugriffe, Infrastruktur, Netzwerkanbindung etc.
Um eine solche Transformation aus der internen IT heraus bestmöglich zu unterstützen und gleichzeitig eine Harmonisierung der eingesetzten Technologien sicherzustellen, bietet es sich an, ein Plattform-Team zu etablieren, das grundlegende Bausteine für den Aufbau der Applikationen in der Cloud bereitstellt: Ein Cloud-Foundation-Team.
Sechs Handlungsfelder einer Cloud Foundation
Trotz der unterschiedlichen Anforderungen und Startvoraussetzungen für die Applikationen eines Unternehmens können die Handlungsfelder einer Cloud Foundation in sechs Themenbereiche unterteilt werden [1]. Sie umfassen alle Themen, die Produkt-Teams für die Entwicklung und den Betrieb ihrer Applikation in der Cloud benötigen. Entlang der Themenbereiche bauen Cloud-Foundation-Teams kontinuierlich Kompetenzen und Fähigkeiten auf. Gehen wir also darauf ein, welche Fragen im Rahmen dieser Themenfelder beantwortet werden sollten:
- Tenant Management: Was für eine Umgebung erhält das Produkt-Team? Nativen Zugriff auf eine Cloud-Umgebung, wie einen AWS Account oder eine Azure Subscription oder eingeschränkten Zugriff auf einzelne Infrastruktur-Ressourcen wie z. B. eine VM oder ein Kubernetes-Cluster? Welche Informationen benötigt eine Cloud Foundation, um Kontrolle über die Cloud-Landschaft zu bewahren? Hier ist relevant, wer die Verantwortung für die Kosten oder die Sicherheit in den jeweiligen Umgebungen trägt.
- Identity und Access Management: Wie erhält das Team Zugriff auf die entsprechende Umgebung? Was ist der Prozess, welche Rechte gibt es, wie werden Missbrauch verhindert und das Principle of Least Privilege durchgesetzt?
- Security & Compliance: Wie kann die Umgebung standardisiert abgesichert werden? Welche Kontrollen müssen erfüllt werden, zum Beispiel im Rahmen branchenspezifischer Anforderungen der Bafin für den Financial-Services-Bereich oder GxP im Pharma-Umfeld? Wie werden die entsprechenden Policies in den jeweiligen Cloud-Providern implementiert und durchgesetzt? Wie kann die Cloud Foundation es nachweisen?
- Service-Angebot: Welche Plattform-Services werden benötigt? Häufige Beispiele sind hier CI/CD Tooling für eine konsequente Nutzung von Infrastructure-as-Code oder aber Netzwerkservices für DNS oder On-Premise Connectivity.
- Kostenmanagement: Wer bezahlt die Cloud-Rechnung? Wie werden den Produkt-Teams die von ihnen verursachten Kosten transparent gemacht? Wer steuert Maßnahmen zur Kostenoptimierung wie den Einsatz von Saving Plans oder Reserved Instances?
- Knowledge: Neben der technischen Umsetzung ist auch das Change-Management kritisch. Kommunikation sollte aktiv betrieben werden, um Transparenz und Vertrauen in die Cloud als Technologie und die Cloud Foundation als internes Angebot herzustellen. Hinzu kommt, dass das Cloud-Know-how in den Produkt-Teams oft noch nicht ausgeprägt ist. Ein gezielter Aufbau von Know-how in der Organisation darf in der Cloud-Transformation daher nicht fehlen. Von einem simplen Support-E-Mail-Postfach hin zum Aufbau interner Communities gibt es dann zahlreiche Instrumente, um das Wissen effizient in der Organisation zu verteilen.
So wird die Cloud Foundation zum Katalysator für DevOps-Organisationen
Bündelt man die oben beschriebenen Handlungsfelder in einer Cloud-Foundation-Plattform mit dem Ziel, die Produktivität der Produkt-Teams zu steigern und ihre kognitive Belastung zu reduzieren, kann die Cloud Foundation als wahrer Katalysator für DevOps-Organisationen dienen.
Die Cloud Foundation schafft eine gute Balance zwischen Agilität und automatisierter Compliance.
Während Produkt-Teams früher häufig vor der Herausforderung standen, dass sie einzelne Komponenten mit individuellen Abteilungen der internen IT abstimmen mussten – also ihre Berechtigungen von einem IAM-Team erhielten, ihre On-Premise-Connecitivity vom Netzwerk-Team und ihr CI/CD-Tooling aus einem DevOps-Team – birgt die Bündelung und auch die klar definierte Schnittstelle zur Bereitstellung dieser Services in einer Plattform, zum Beispiel über ein Self-Service-Portal, enormes Beschleunigungspotenzial. Die Cloud Foundation schafft eine gute Balance zwischen Agilität einerseits und automatisierter Compliance andererseits [2].
Eine Herausforderung bleibt: Fast jedes Unternehmen betreibt für verschiedene Geschäftsbereiche wie Produktion, Vertrieb, HR etc. eine Vielzahl verschiedener Applikationen. Eine gemeinsame Foundation für diese Applikationen zu definieren ist nicht leicht. Schließlich haben die Applikationen unterschiedliche Anforderungen an die darunterliegende Cloud-Infrastruktur. Hinzu kommen Unterschiede bei den technologischen Vorlieben, Erfahrungen und Skill-Level der dazugehörigen Produkt-Teams. Eine gute Foundation berücksichtigt diese Unterschiede. Ähnlich wie Unternehmen im Startup-Umfeld den Kundenbedarf identifizieren und bedienen müssen, um erfolgreich zu sein, sollten auch Cloud Foundations ihre Kunden verstehen und auf deren Bedarfe ausgerichtet ihren Product-Market-Fit finden. Ein etablierter Ansatz hierfür ist die Bereitstellung mehrerer Landing Zones, die unterschiedliche Anwendungstypen adressieren [3].
Die Landing Zone als konkretes Offering des Cloud-Foundation-Teams
Eine Landing Zone ist die modulare und skalierbare Konfiguration einer Cloud-Plattform. Sie dient als Grundlage für die Adoption der Cloud durch Produkt-Teams. Die konsistente Konfiguration erleichtert die Governance.
Je nach Anwendungsfall kann ein Cloud-Foundation-Team passende Landing Zones bereitstellen. Die Konfigurationen werden automatisiert ausgerollt, um dem Anspruch der Skalierbarkeit gerecht zu werden. Manuelle Konfigurationen im Cloud-Portal bergen das Risiko einer heterogenen Konfigurationslandschaft, die die Übersichtlichkeit erschwert und die Einhaltung von Compliance-Richtlinien beeinträchtigen kann. Ein gängiges Beispiel für eine Landing Zone ist die "Sandbox", die typischerweise von Produkt-Teams zum Ausprobieren neuer Ideen verwendet wird. Der Gedanke ist, dass in der Sandbox – in der Regel ein AWS Account, eine Azure Subscription oder ein Google Cloud Project – keine kritischen Daten genutzt werden und keine Verbindung ins Firmennetzwerk besteht. Aus diesem Grund sind die ansonsten angewandten Restriktionen via Policies überschaubar. Das Experimentieren mit neuen Technologien soll mit niedriger Hürde ermöglicht werden. Dabei sollte das Budget eingeschränkt und eine automatisierte Löschung des Accounts umgesetzt werden, um die experimentelle Nutzung sicherzustellen.
Ein weiterer Anwendungsfall ist die Landing Zone für Container-Applikationen. Um den Aufwand für das Produkt-Team möglichst gering zu halten, werden hierzu oft zentral gemanagte Kubernetes-Cluster betrieben. Das Team erhält keinen ganzen Account als Tenant, sondern lediglich einen Kubernetes-Namespace. Das hat den großen Vorteil, dass kein tiefgehendes Kubernetes-Know-how im Produkt-Team vorhanden sein muss, um Kubernetes-Cluster zu betreiben. Es wird von der Cloud Foundation in der Landing Zone gebündelt und gleich für mehrere Produkt-Teams zur Verfügung gestellt.
Damit kann dieser teamtopologische Ansatz Unternehmen dazu befähigen, gebündelte und performante, standardisierte Plattformen zu entwickeln und zu betreiben. Zudem können weitere DevOps-Praktiken, wie Automation und Tool-Unterstützung, dabei helfen, diesem und allen Produkt-Teams eine höhere Produktivität und eine geringere Time-to-Market zu ermöglichen.
Von Landing Zones zu DevSecOps
Das Zusammenspiel von DevOps und Landing Zones bringt den Produkt-Teams somit einen hochgradig automatisierten Software-Entwicklungszyklus mit der Möglichkeit, dynamische Umgebungen zu provisionieren, welche jederzeit den Compliance-Anforderungen des Unternehmens entsprechen. Wieso also nicht auch bereits Security-Anforderungen abfangen? Damit kann Security nicht als nachgelagerter Schritt, sondern als zentraler Baustein betrachtet werden. In diesem Fall wird aus dem DevOps-Ansatz ein DevSecOps-Ansatz. Hierbei werden Security-Praktiken direkt in den DevOps-Zyklus eingebettet, statt sie isoliert im Nachgang zu betrachten.
Man spricht auch von einem "Shift-Left", also einer Verschiebung der Security an den Beginn des Entwicklungszyklus und darin fest eingebauten Sicherheitsaspekten. Für den Erfolg ist die frühzeitige Einbindung der Security-Verantwortlichen essentiell, um gemeinsam ein abgestimmtes Vorgehen zu definieren, so dass beide Perspektiven berücksichtigt und ihre jeweiligen Anforderungen erfüllt werden. Hierbei können wieder Landing Zones unterstützen, da sie ein mögliches Instrument sind, um Security-by-Design umzusetzen. So können zum Beispiel für die zuvor beschriebene Container-Plattform-Landing-Zone vordefinierte Container-Images in einer zentralen Container-Registry bereitgestellt werden, um diese konsequent auf mögliche Sicherheitslücken zu scannen. Damit lassen sich auch hier wieder neue Umgebungen über alle Ressourcen hinweg, automatisch und nach den neuesten Sicherheitsstandards und Best Practices des Unternehmens erstellen.
Fazit und Ausblick
Die Verschmelzung von DevOps und Cloud Foundation ist von entscheidender Bedeutung für Organisationen, die eine effiziente und sichere Cloud-Infrastruktur aufbauen möchten. Durch die Integration von DevOps-Praktiken in die Cloud Foundation können Unternehmen die Skalierbarkeit, Compliance, Sicherheit und Geschwindigkeit ihrer Cloud-Umgebungen und auch ihre Zusammenarbeit verbessern. Zudem unterstützen Cloud Foundations Unternehmen dabei, DevOps in die Organisation zu tragen.
Die Einführung von Plattform-Teams ist nur ein kleiner Teil von dem, was DevOps ausmacht und damit die Cloud-Transformation beeinflusst. Weitere Themenfelder wie "Automation im Software-Entwicklungszyklus" und "Veränderungen der bestehenden Prozesse" sollten ebenfalls berücksichtigt werden. Insgesamt stellt die Cloud Foundation eine wichtige Grundlage für eine robuste Infrastruktur, die den Anforderungen moderner Anwendungen gerecht wird, dar und skaliert hervorragend mit DevOps-Praktiken. Durch die Nutzung von Landing Zones und die Integration von Compliance- und Security-by-Design-Prinzipien können Organisationen sicherstellen, dass ihre Cloud-Infrastruktur von Anfang an compliant und sicher ist und potenzielle Sicherheitsrisiken präventiv abgewendet werden.
Es ist wichtig, zentrale Plattform-Teams mit ausreichenden Ressourcen und dem Mandat, Entscheidungen treffen zu können, auszustatten.
Die Cloud-Transformation hat in den vergangenen Jahren erhebliche Fortschritte gemacht. Cloud-Provider haben ihre Services kontinuierlich verbessert und Organisationen haben durch die starke Nutzung der Cloud Better-Practices ausgearbeitet. Diese Entwicklungen ermöglichen eine beschleunigte Cloud-Adoption und unterstützen damit eines der Ursprungsziele der Cloud-Transformation: die Beschleunigung der Applikationsentwicklung.
Obwohl Dev(Sec)Ops vielen Unternehmen mittlerweile vertraut ist, kann es in einer eingespielten, durch Silos geprägten Organisation schwierig sein, eine Verschiebung der Verantwortlichkeiten durch die Schaffung von Produkt-Teams umzusetzen. Zentrale IT-Teams haben oft Bedenken, die Kontrolle zu verlieren, während Produkt-Teams nach technologischer Freiheit streben.
Daher ist es wichtig, zentrale Plattform-Teams wie die Cloud Foundation mit ausreichenden Ressourcen und dem Mandat, Entscheidungen treffen zu können, auszustatten. In enger Zusammenarbeit mit ersten Produkt-Teams können sie den Scope einer passenden Cloud-Foundation-Plattform definieren und ihre Plattform so eng am Bedarf der tatsächlichen Nutzer entwickeln.
Um diesen Ansatz langfristig in der gesamten Organisation zu etablieren, ist eine gute Kommunikation von großer Bedeutung. Erfolgsgeschichten sollten geteilt und Fragen und Unsicherheiten schnell geklärt werden. Je mehr Produkt-Teams in einer Organisation die Cloud nutzen, desto einfacher wird der Einstieg und das Angebot der Cloud Foundation. Über die Zeit werden mehr Anwendungsfälle abgedeckt und Anfangshürden abgebaut. So können mit der Zeit neben den erfahrenen "Cloud-Natives" auch Cloud-Neulinge sicher und effizient in die Cloud gebracht werden.
Es ist davon auszugehen, dass der Trend zur weiteren Integration von DevOps und Cloud Foundation sich fortsetzt, weil Unternehmen zunehmend auf agile und skalierbare Infrastrukturen angewiesen sind, um mit den Anforderungen der Digitalisierung Schritt zu halten. Dabei ist künftig, mit Fortschritt der Transformation und steigender Reife der Technologien in diesem Umfeld, mehr Standardisierung im Zusammenspiel von Cloud-Providern, Tooling und den passenden Organisationsformen sowie Zusammenarbeitsmodellen zu erwarten.
- Cloud Foundation Maturity Model
- KPMG: Cloud Foundation: Agilität und Compliance ohne Kompromisse
- meshcloud: Cloud Landing Zone Lifecycle explained!
