Wissenstransfer bei der Cloud-Entwicklung

Zu Beginn unserer Cloud-Projekte wird mit dem Kunden viel über Technik geredet. Aber selten über die Team-Kultur und die Verteilung des neu erworbenen Wissens zwischen den Teams.

Was bedeutet „Wissen“ in der Cloud-Entwicklung?

Im Cloud-Umfeld hat nach wenigen Jahren eine erstaunliche Gleichschaltung von Entwicklungstätigkeiten stattgefunden – d. h. verschiedene Cloud-Umgebungen lassen sich gleich bedienen:

  • über die Kommandozeile (CLI)
  • über eine Web-Console (UI)
  • über Programmierung über SDKs (Java, .NET, Python,…)

Im DevOps Prozess spielt dabei die CLI-Variante die wesentliche Rolle, da sie sich am Besten für die Integration in Tools wie Jenkins oder GitLab CI eignet.

Prinzipiell sind für jede Entwicklungsaufgabe immer die gleichen Arbeitsschritte notwendig – egal ob diese nun manuell in einem Konsolenfenster oder von einem bash-Script aus ausgeführt werden:

Es werden die Parameter für einen Methodenaufruf in YAML-Dateien abgelegt, die dann in Konsolenbefehlen wie CREATE, UPDATE etc. referenziert werden. Die CLI wird im Kontext eines Cloud-Accounts ausgeführt und ruft intern die REST-API des Cloud-Providers auf, um dort Ressourcen wie z. B. Datenbanken, Gateways oder Service-Instanzen zu erstellen oder zu modifizieren.

Betrachtet man diese Abläufe über mehrere Entwickler hinweg ergeben sich Abhängigkeiten zwischen den einzelnen Abläufen: z. B. wird zunächst eine PostgreSQL-Instanz gescriptet und dann im Anschluss eine Dateninitialisierung durchgeführt bevor in einem anderen Script der entsprechende Microservice gestartet wird.

Die gesamte DevOps-Toolchain tut letztendlich nichts anderes, als dieses Netzwerk von abhängigen Teilaufgaben zu koordinieren und automatisieren.

Wie die Abbildung zeigt, ist das technische Wissen ein Netzwerk. Das Netzwerk lässt sich durch Lektüre von Confluence oder anderen firmeninternen Wikis im nachhinein wieder „erforschen“ – was aber nicht wirklich DevOps ist. Um zu verstehen, wie das Netzwerk entstanden ist, muß man die Arbeitsorganisation während der Entwicklung betrachten:

Der typische Enterprise-Kontext

Häufig finden wir folgendes Muster in Unternehmen, die bisher mit einer zentralen IT gearbeitet haben und nun versuchen, das bisher gelebte Modell auch im Cloud-Umfeld zu konservieren:

Dabei arbeiten die Teams weiter wie bisher: Entwickler sehen nur Git und Jenkins, während die eigentlichen Interna der Cloud (im Bild als Beispiel AWS) vor ihnen verborgen bleiben. Ein oder mehrere technische User („Functional accounts“) sind als AWS user angelegt und berechtigt. Im Prinzip dient Jenkins als Wrapper um einen oder mehrere AWS CLI-Aufrufe, die automatisiert durch den technischen User abgesetzt werden.

In diesem Kontext wird das Cloud-Wissen wieder zentralisiert und in Form von gemeinsam genutzten Jobs oder Pipelines in Jenkins abgelegt.

Die echte DevOps Umgebung

Eine Team-Aufteilung, die der IT-Leitung wesentlich mehr Mut abverlangt, ist die vollständig vertikal orientierte Organisation, bei der jedes Team seinen Teilbereich in der Cloud hat und diesen individuell (bezgl. der verwendeten Technologien) ausgestaltet:

Hierbei arbeiten die Teams autonom und tauschen sich über Communities of practice in bestimmten Abständen aus, um für gemeinsame Probleme eine effektive Lösung zu finden. Dabei werden oft Lösungen mehrere Male auf unterschiedliche Weise entwickelt und eine Zeit lang betrieben (in mehreren Teams parallel) und nach einiger Zeit gegeneinander verglichen. Dies hat zwar den Nachteil, das anstatt eines typischen POC-Projekts mehrere tatsächliche Implementierungen entstehen – jedoch ist der Erkenntnisgewinn oft viel tiefgehender, was zu mehr Fortschritt in weniger Iterationen des Gesamtprodukts führt.

Das Wissen wird in der Unternehmenskultur verankert und findet sich in den vielen Cloud-Code-Schnipseln in den verschiedenen Teams wieder.

Wissen in Tools konservieren

Da das Lesen von Wiki-Artikeln während der Lösung von Problemen in einem Cloud-System, das komplett über APIs gesteuert wird, sich irgendwie „retro“ anfühlt, bietet sich die Konservierung des aktuellen Entwicklungswissen in Tools an. Konkret findet man heute folgende Arten der Konservierung:

  • ChatOps: Das Wissen wird über sog. Integrations und Bots in ein Tool wie Slack oder Mattermost codiert
  • ToolOps: Das Wissen wird in eigene Bedienoberflächen/Tools codiert, über die sich die unterlagerten APIs in Prozessen graphisch steuern lassen – das zeigt das Titelbild dieses Artikels
  • CLIs und SDKs: Das Wissen wird in eigenen „verlängerten und spezialisierten Armen“ der bekannten AWS oder Azure CLIs codiert

Welchen Ansatz man wählt, hängt von den Kompetenzen im Team (CLIs sind einfacher zu entwickeln als Angular-UIs) und dem zur Verfügung stehenden Budget ab. Die Consort Group unterstützt den ChatOps-Ansatz in frühen Projektphasen, wohingegen wir den ToolOps-Ansatz für komplexe Plattform-Produkte mit vielen internen Kunden empfehlen.

 

Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.