Kolumne: Stropek as a Service

Teile und herrsche – die Cloud verlagert Verantwortung in eigenverantwortliche Teams
Keine Kommentare

Kürzlich habe ich bei einem größeren Kunden, den ich in Sachen Übergang zu Cloud-Computing beraten darf, einen schönen Punkt in einer Präsentation gesehen: „Vom Ticket zum Selfservice“. Gemeint war, dass Entwicklungsteams in Zukunft die für sie notwendigen IT-Ressourcen nicht mehr über Supporttickets anfordern müssen, sondern das selbstständig über entsprechende Portale, APIs oder Scripts in der Public Cloud erledigen können. Ziel sind die Reduktion der Wartezeit und die Steigerung der Produktivität, da das Kommunizieren der Anforderungen und die damit nicht selten verbundenen Missverständnisse entfallen.

Drang zur Zentralisierung

Dass dieser Ansatz sinnvoll ist, wird kaum jemand bestreiten. Was jedoch in einer kleinen Organisation problemlos umsetzbar ist, stellt größere vor große Herausforderungen. Hier ein paar Beispiele:

  • Nicht alle Benutzer dürfen vollen administrativen Zugriff auf die Public-Cloud-Umgebung erhalten. Zentral verwaltete, sicherheitskritische Komponenten (z. B. VNet mit Zugriff auf IT-Ressourcen, die nicht in der Public Cloud, sondern im Firmenrechenzentrum liegen) sind beispielsweise besonders zu schützen und dürfen nur von wenigen Personen verändert werden.

  • Kostenvorteile durch gemeinsame Nutzung von relativ teuren Ressourcen (z. B. Datenbanken, Webfarmen, Firewalls) müssen ausgenutzt werden.

  • Die Einhaltung von firmenweiten Richtlinien bezüglich Entwicklungsprozessen, Softwarearchitektur und Sicherheitsrichtlinien muss sichergestellt sein (z. B. muss vor jeder Webanwendung eine Web Application Firewall stehen).

  • Kosten müssen Teams einfach zuzuordnen sein.

  • Irrtümlich verursachte Kosten (z. B. das Löschen einer nicht mehr notwendigen Ressource wird vergessen, falsch konfiguriertes Autoscaling) müssen vermieden oder zumindest frühzeitig erkannt werden.

Viele große Organisationen reagieren auf solche Anforderungen mit Zentralisierung: Eine Gruppe von Personen wird speziell ausgebildet und ist besonders vertrauenswürdig. Sie erhalten weitgehende Rechte in der Public-Cloud-Umgebung. Die Mitglieder der DevOps-Teams sind in ihren Möglichkeiten eingeschränkt. Diese Vorgehensweise konterkariert leider das ursprüngliche Ziel, die Agilität der Organisation zu steigern, indem Selfservice gefördert und Supporttickets reduziert werden.

Radikale Dezentralisierung ist keine Lösung

Man könnte behaupten, dass Zentralisierung ein Merkmal von Großkonzernen sei, die im letzten Jahrtausend steckengeblieben wären, und als einzige Lösung eine radikale Dezentralisierung bliebe. Man könnte jedem Team eine Kreditkarte und die Erlaubnis geben, in der Public Cloud zu machen, was es will. Teamübergreifenden Richtlinien wird mit dem Verweis auf die Eigenverantwortung der Teams eine Absage erteilt. Es gibt eine Menge Start-ups, die genau so arbeiten. Ein großes Unternehmen ist schließlich nichts anderes als die Zusammenarbeit vieler kleiner, autonomer Teams, oder nicht?

Meiner Erfahrung nach klingen solche Aussagen zwar modern und disruptiv, sie gehen aber an der Realität vorbei. UnternehmerInnen und Führungskräfte haben die Pflicht, für die Einhaltung von Gesetzen und Richtlinien zu sorgen (z. B. Datenschutz), und sie sind dafür verantwortlich, die Interessen des Unternehmens zu schützen (z. B. Abfluss von Know-how zu verhindern). Man kann viel durch Vorbildwirkung, durch das Appellieren an Eigenverantwortung und Verantwortungsbewusstsein und ähnliches erreichen. Ganz ohne Einschränkungen und Überwachungsmechanismen geht es in der Praxis aber nicht.

Goldene Mitte

Wie so oft ist die Lösung der goldene Mittelweg. Wer sich von der Flexibilität und Geschwindigkeit der Public Cloud erschrecken lässt, Angst hat, dass die Teams damit nicht umgehen können, und darauf mit einem rigiden Rechteeinschränkungsprogramm antwortet, verspielt eine Menge Vorteile der Public Cloud. Die Organisation wird träge und die Mitarbeiterinnen und Mitarbeiter werden angesichts für sie nicht nachvollziehbarer Wartezeiten und Barrieren frustriert.

Ich empfehle, technische Einschränkungen mit organisatorischer Zentralisierung auf ein Minimum zu begrenzen und sie nur dort einzusetzen, wo sie unumgänglich sind. Das Anlegen neuer Benutzerkonten für EntwicklerInnen wäre ein solches Beispiel. Es ist sinnvoll, diese Aktion nur durch zentrale AdministratorInnen durchführen zu lassen.

In allen anderen Bereichen schränkt man nicht ein, sondern legt das Augenmerk auf die Ausbildung und das Bereitstellen von Anleitungen und Codebeispielen, um Teams ohne Druck in die gewünschte Richtung zu lenken. Abweichungen und Vielfalt sind erlaubt, aber vielleicht etwas unbequem, und als Team muss man bereit sein, ihre Notwendigkeit zu erklären und im Sinne des DevOps-Credos „You build it, you run it“ die betrieblichen Konsequenzen zu tragen.

Konkrete Maßnahmen in Azure

In Zusammenhang mit Microsoft Azure gibt eine Reihe konkreter Maßnahmen, die man treffen kann, um dezentrales Cloud-Management zu ermöglichen, ohne ins Chaos zu stürzen. Hier die aus meiner Sicht wichtigsten zehn:

  1. Eine Organisation sollte einen modernen, zentralen Identitätsdienst (z. B. Azure Active Directory, AAD) einsetzen, der Single Sign-on lokal und in der Cloud mit Multi-Factor Authentication (MFA) unterstützt. Zahlreiche verschiedene Benutzerkonten je MitarbeiterIn sind ein großes Risiko. Legen Sie Wert auf Benutzerfreundlichkeit (z. B. das Entfallen von MFA im Intranet mit Hilfe von Azure AD Conditional Access), um das Entstehen von Tricks zur Umgehung von Sicherheitsmaßnahmen zu vermeiden. Für SaaS-Dienste, die die Entwicklungsteams erstellen, sollte es eigene AADs geben, in denen die Teams bei Bedarf Administrationsrechte haben. Die Entwickler werden als Gastnutzer im SaaS AAD eingebunden. Das eigene AAD ist notwendig, um den Teams Flexibilität bezüglich Provisionierung von Ressourcen in Azure (inklusive Service Principals) zu geben.

  2. Es muss eine klare Unterscheidung zwischen produktiven und nicht produktiven Umgebungen geben. In Azure lässt sich die Trennung am besten durch getrennte Subscriptions und/oder Ressource Groups abbilden. Für produktive Umgebungen gelten viel höhere Ansprüche an Professionalität und Datenschutz. Schützenswerte Echtdaten haben in nicht produktiven Umgebungen nichts zu suchen. Das muss durch Ausbildungsmaßnahmen und eventuell auch durch automatisierte Prüfroutinen sichergestellt werden. Teams brauchen für Experimente und Entwicklungsarbeit getrennte Spielplätze, in denen sie Administratorrechte haben.

  3. Die Einhaltung von Sicherheitsrichtlinien, die vom Cloud-Hersteller empfohlen werden oder die sich das Unternehmen auferlegt hat, müssen für Produktivumgebungen automatisiert überprüft werden. Azure bietet dafür die Komponente Azure Security Center. Mangelhafte Sicherheitskonfigurationen, die Teams beispielsweise aufgrund fehlenden Wissens gemacht haben, werden so rasch erkannt und können hinterfragt bzw. korrigiert werden.

  4. Die Cloud-Kosten müssen durch ein Überwachungssystem laufend kontrolliert werden. In Azure übernimmt diese Aufgabe Azure Cost Management. Dort können auch Grenzen eingestellt werden, bei deren Überschreitung automatische Warnungen versendet werden. Hilfreich sind meiner Erfahrung nach auch individuelle Skripts, die speziell in nicht produktiven Umgebungen auf teure Azure-Ressourcen hinweisen, die dort eigentlich nicht langfristig liegen sollten.

  5. Infrastructure as a Service (kurz IaaS) ist soweit möglich zu vermeiden. PaaS- und Serverless-Dienste sind in der Public Cloud bei den großen Anbietern Secure by Design. Wenn sich ein Team auf sie beschränkt, fallen viele Fehlerquellen von Haus aus weg. Die Verwendung von IaaS kann – zumindest für Neuprojekte – ruhig unbequem gemacht werden.

  6. Dem Thema Speicherung von Geheimnissen (z. B. Zertifikate, Passwörter, Access Keys, Verbindungszeichenfolgend etc.) muss besondere Beachtung geschenkt werden. Nutzt man als Unternehmen in Azure generell Managed Identities, erledigt sich vieles von selbst. Dort, wo Secrets unvermeidbar sind, müssen diese in Azure Key Vault gespeichert werden, und der Zugriff auf Key Vault wird durch Managed Identities abgesichert. Diese relativ einfache Regel löst viele Sicherheitsprobleme, macht virtuelle Netzwerke oft unnötig und trägt dadurch entscheidend zur Flexibilität in der Public Cloud bei.

  7. Die Verwendung von Ressourcenpools (z. B. Azure SQL DB Elastic Pools, Azure App Service Plans) ist sinnvoll, man sollte es aber nicht übertreiben. Wenn in größeren Organisationen getrennte Microservice-Teams gemeinsame Ressourcenpools verwenden, entsteht dadurch eine organisatorische Abhängigkeit, die bremst. Mein Tipp ist, gemeinsam genutzte Azure-Ressourcen über Microservice-Teams hinweg zu vermeiden und sie wirklich nur dort in Kauf zu nehmen, wo die Kostenvorteile deutlich spürbar sind.

  8. Infrastructure as Code sollte konsequent eingesetzt werden. Gerade bei zentral verwalteten und von mehreren Teams genutzten Cloud-Komponenten (z. B. Azure Front Door, Ressourcenpools) sollte die Abstimmung in Form von Git Pull Requests statt durch Supporttickets und manuelle Konfigurationsänderung erfolgen.

  9. Die Public Cloud bietet mächtige APIs für die Automatisierung von Administrationstätigkeiten. Wenn es gewisse Aktivitäten gibt, die zwecks Kontrolle von Richtlinien nur ein zentrales Team durchführen kann, sollte man diesem Team die Arbeit so leicht wie möglich machen und wiederkehrende Aufgaben beispielsweise durch ein individuell entwickeltes Administrationsportal unterstützen, das im Hintergrund Dienste wie Azure Automation oder administrative Azure Functions verwendet.

  10. Gute und leicht erreichbare Dokumentation ist ein weiterer wichtiger Puzzlestein zum Erfolg. Nur wenn die Spielregeln bekannt sind, kann man sich auch daran halten.

Fazit

Autonome Teams sind ein wichtiges Erfolgsrezept, das mit DevOps und Microservices Einzug gehalten hat. Die Public Cloud gibt den Teams die notwendigen Werkzeuge, die sie zum eigenverantwortlichen Umsetzen ihrer Anforderungen brauchen. Gerade größere Organisationen müssen eine Balance finden zwischen notwendigen Einschränkungen und freier Nutzung der Möglichkeiten der jeweiligen Cloud-Umgebung. Geld, das man in diesem Bereich investiert, ist gut angelegt, da der richtige Mittelweg entscheidend sein kann, ob eine Organisation trotz Cloud starr und langsam bleibt – oder agiler wird.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -