Operations heute und morgen, Teil 2: DevOps im Jahre 2015
Seite 3: DevOps konkret
Missverständnisse über DevOps
- DevOps betrifft nur Development und Operations: Der Fokus von DevOps ist bei weitem nicht so eingeschränkt, wie es der Name vermuten lässt. Vielmehr verlangt DevOps eine übergeordnete Betrachtung des Lieferweges von Software und umfasst alle Bereiche, die darauf Einfluss haben. Es setzt auf dem Wissen aus Agilität und Lean auf.
- DevOps ist nur die Automatisierung von Build und Deployment: DevOps ist nicht Continuous Delivery, das sicherlich eines der geeigneten Mittel ist, wenn DevOps in einem großen Umfeld betrieben wird. Continuous Delivery ist jedoch nur ein hilfreiches Werkzeug. Bei Continuous Delivery geht es primär um die Automatisierung von Build, Test und Deployment mithilfe einer geeigneten Werkzeugkette. DevOps hingegen ist im Kern ein Wertesystem.
- Dev übernimmt Ops, das heißt, die Entwicklung macht den Betrieb mit: Es geht nicht darum, dass die Funktionen des Bereichs Operations übernommen werden. Jeder Entwickler wird mit seiner Feature-Entwicklung genug zu tun haben. Mit wachsendem Reifegrad der entwickelten Technikenkann das Plattformteam jedoch weitere Dienste nach und nach bereitstellen, wie Database as a Service oder Message Queue as a Service. Wichtig ist hierbei, dass Fachteams alle Dienstleistungen des Plattformteams über eine Self-Service-API oder ein intuitives Interface beziehen können. Ziel ist es, mit den "Kunden" (Entwickler sind nichts anderes als Kunden einer Dienstleistung) Infrastruktur zu entwickeln, die es allen ermöglicht, schnell die Produkte zu nutzen, die anderenfalls mit manuellem Aufwand zur Verfügung zu stellen wären.
T-Profil
Für den Erfolg von DevOps ist es wichtig, dass Menschen mit dem besten Skillset für eine Aufgabe zusammenkommen und ungestört an ihr arbeiten können. Es ist allerdings wenig zielführend, wenn etwa fünf Spezialisten einzeln an jeweils einem Problem arbeiten. Vielmehr muss es Schnittpunkte in den jeweiligen Interessengebieten geben. Die Spezialisten sollten voneinander lernen können und ausreichend Spezialwissen mitbringen, um komplexe Aufgaben in einem Projekt zu lösen. In diesem Kontext ist das T-förmige Profil relevant.
Entwickler sollten beispielsweise über ausreichend Breitenwissen verfügen, um die Erfordernisse und Bedürfnisse aller anderen beteiligten Bereiche verstehen zu können. Das ist eine Grundvoraussetzung für Zusammenarbeit im Allgemeinen. Die Kerndomäne ist allerdings immer noch die Softwareentwicklung. Hier haben Entwickler ihr Tiefenwissen. Wenn sie in anderen Bereichen über zusätzliches Tiefenwissen verfügen, ist das erfreulich, aber nicht zwingend notwendig.
Chris Johnson fasst den Zusammenhang in einem mittlerweile zurückgezogenen Blog zusammen: "To be a master of anything, you must understand two layers above and two levels below the layer you're targeting." Und er fährt fort (der leichteren Lesbarkeit halber hier übersetzt): "Wenn jemand der beste JavaScript-Entwickler werden möchte, sollte er ein fundiertes Verständnis davon haben, wie JavaScript-Parser und Browser funktionieren. Des Weiteren sollte ein guter Entwickler verstehen, welchen Einfluss seine Applikation auf die Ebenen oberhalb seines Tätigkeitsbereichs hat."
Die benötigten Fähigkeiten werden über die cross-funktionale Besetzung in das Team geholt. Das bedeutet für DevOps, dass dem Team auch Betriebsexperten angehören.
Nicht nur die Schnittmengen aus dem Spezialwissen und Breitenwissen der Teammitglieder sorgen dafür, dass das Team die maximale Leistungsfähigkeit hat, sondern auch deren soziale Fähigkeiten und Rollen (Katalysator, Experte). Aus der teamspezifischen Konstellation bildet sich ein "DevOps-Sweetspot", in dem das Team bestmöglich agieren kann.