DevOps: Agile Entwicklung und Betrieb Hand in Hand

DevOps steht schon seit einiger Zeit im Zentrum der Aufmerksamkeit, hat sich aber noch nicht so weit verbreitet, wie es sollte. Dies könnte sich aber ändern: Puppet Labs hat vor kurzem einen Bericht veröffentlicht, der die Verbindung zwischen der Performanz eines Unternehmens, der Performanz der Unternehmens-IT und der Verwendung von DevOps-Praktiken herstellt. Diese werden im folgenden genauer erklärt.

Was ist DevOps eigentlich?

DevOps ist die nächste Stufe von agilen, interdisziplinären Teams. Deren Zweck war schon immer, alle an der Gewinnschöpfung beteiligten Mitarbeiter:innen bzw. Funktionen zusammenzufassen (vgl. das erste Paper zu Scrum von Schwaber & Sutherland, 1995). Wenn man ein Produkt betreiben muss, um Gewinn zu erwirtschaften (etwa bei Web-Anwendungen), würde ein interdisziplinäres Team beispielsweise aus Mitarbeiter:innen bestehen, die jeweils für Deployment, Betrieb und Verwaltung zuständig sind.

Diese Idee ist nicht neu. Facebook arbeitete beispielsweise von Anfang nach diesem Muster. Ein weiterer Vertreter sind die 2-Pizza-Teams von Amazon: Die IT des Versandhändlers besteht aus interdisziplinären Teams, die jeweils nur so groß sind, dass ihnen 2 Pizzen zum Mittagessen reichen.

Zwei Aspekte sollen im Folgenden genauer beleuchtet werden: Warum wird diese Idee gerade heute relevant (und nicht schon vor Jahren)? Und wenn die Idee so gut ist, warum setzt nicht jeder auf DevOps?

Warum DevOps gerade jetzt relevant ist

Wenn Unternehmen Software-Entwicklung und -Betrieb nicht auf Team-Ebene integrieren, führt das aufgrund mehrerer Faktoren zu Probleme.

Die Cloud

Immer mehr Enterprise-Anwendungen nehmen die Form von Web-Apps oder mobilen Apps mit Web-Service-Backends an, deren Entwicklungslebenszyklus nicht mit der Auslieferung an den Kunden endet. Anbieter solcher Software müssen nun eine Dienstleistung statt eines Produkts vertreiben und werden dadurch zu Betreibern ihrer eigenen Software.

Die Etablierung agiler Arbeitsmethoden

Wenngleich es paradox klingt, hat die Etablierung agiler Arbeitsmethoden in der Software-Entwicklung das Kommunikationsproblem zwischen Produktmanagement – also der Geschäftsseite – und der Entwicklerseite für viele Teams gelöst.Häufig bleibt die Einführung einer agilen Methode wie Scrum aber auf diese beiden Bereiche beschränkt – das Scrum-Entwicklerteam umfasst zwar Entwickler und Tester, aber keine Betreiber (Ops’ler). Der Scrum-Product-Owner befasst sich mit Features und Kunden, kümmert sich aber wenig um den Betrieb (es muss einfach laufen).

Wenn aber ein Scrum-Team dieser Zusammensetzung seine Arbeit aufnimmt, wird die Zusammenarbeit zwischen Entwicklung und Betrieb durch die kontinuierliche Veröffentlichung von Software-Versionen belastet. Diese Stelle wird zum Engpass, der die Beteiligten zum finden einer Lösung zwingt.

Die verbreitete Anwendung vorgefertigter Komponente

Wenn man Software entwickelt, muss man sich auf eine Reihe von Komponenten verlassen können: Web Server, Anwendungscontainer, Datenbanken, usw. Solche Komponenten haben eines gemein: Sie sind nicht in die Software integriert wie Bibliotheken oder Frameworks. Sie stellen vielmehr die Umgebung dar, in der die Software läuft. Der entscheidende Unterschied zwischen Komponenten wie Tomcat und einem Framework wie Spring ist, dass ersteres selbst beachtlichen Aufwand für Deployment, Konfiguration und Instandhaltung erfordert. Diese Aufgaben gehören in der Regel nicht zum Repertoire eines gewöhnlichen Software-Entwicklers. Anschaulich lässt sich das auch am Beispiel von Netzwerken zeigen: Man muss nicht nur die Grundlagen der Netzwerktechnik verstehen (etwa den Unterschied zwischen Broadcast und Multicast), sondern den Aufbau der Infrastruktur (etwa wenn es mehr als ein Klasse D-Netzwerk gibt).

Da also Produkte immer mehr Komponenten beinhalten, die von Spezialisten bedient werden müssen, wird die Frage nach der Integration von Spezialisten in Entwicklerteams immer relevanter.

Warum dennoch nicht jeder DevOps anwendet

Die Grundidee von DevOps ist einfach – nicht aber die Durchführung. DevOps umfasst so viele Facetten, die korrekt umgesetzt werden müssen, um zu funktionieren: Die technischen Aspekte von automatisiertem Deployment und Konfigurationsmanagement, der technische Prozess, also Versionskontrolle, Build-Tools und ein effektives Ticketsystem und nicht zuletzt Organisation und kulturelle Integration.

Ein Team

Es ist einfach zu sagen wir brauchen ein interdisziplinäres Team, das alle Fähigkeiten und Kompetenzen hat, um Kundennutzen und Geschäftswert zu erzeugen. Dies umzusetzen dagegen ist schwierig. Einen Eindruck davon soll folgende Liste von organisatorischen und kulturellen Problemen bei der Einführung von DevOps geben:

• Das gesamte Entwicklungs- und Operations-Abteilung zu vereinen würde in einem Team resultieren, das zu groß ist, um effektiv zu arbeiten.
• Wenn man n Entwicklerteams hat und nur ein Operations-Team, wie erstellt man daraus DevOps-Teams?
• Wie geht man mit unvorhergesehenen Instandhaltungsaufgaben um? Nimmt man sie ins Backlog auf?
• Wie geht man mit Notfällen um?
• Wie integriert man Abrufbereitschaft und Rund-um-die-Uhr-Präsenz in agile Frameworks wie Scrum?
• Wie geht man regulatorischen Vorschriften wie begrenztem Zugriff auf Systeme um?
• Sehr verallgemeinernd mögen Entwickler eher neue Technologie während Sysadmins Wert auf Stabilität legen.

Da dieser Artikel nicht mit offenen Fragestellungen und Problemen enden soll, wird im Folgenden der erste Punkt dieser Liste behandelt.

Dev und Ops vereinen

Gehen wir von einem konkreten, wenngleich lehrbuchmäßigen Beispiel aus: Man hat ein Scrum-Entwicklerteam mit 7 Entwicklern. Zusätzlich hat man ein Operations-Team von 5 Personen. Würde man diese zu einem DevOps-Team vereinen, bestünde dieses aus 12 Mitgliedern – zu viel für effektive Kolaboration (7±2 ist die magische Zahl). Es ist also besser, 2 DevOps-Teams zu gründen, wodurch man wiederum mit Scrum at Scale konfrontiert wird, also Scrum mit mehr als einem Team.

Feature-Teams

Eine bekannte Möglichkeit, agile Entwicklung zu skalieren, sind Feature-Teams. Ein Feature-Team ist komplett verantwortlich für bestimmte Features, typischerweise auf allen Software-Layers und mit allen Komponenten. Der traditionelle Gegenentwurf hierzu wäre das Komponententeam, das nur für einen Layer bzw. eine Komponente verantwortlich ist.

Der Hauptvorteil von Feature-Teams sind weniger Abhängigkeiten zwischen Teams. Bei Komponententeams dagegen benötigt fast jedes neue Feature die Kollaboration zwischen allen Teams. Zwar sind auch Feature-Teams auf Kollaboration angewiesen, doch können die meisten Features komplett von einem Team allein entwickelt werden.

Dies passt natürlich sehr gut zur DevOps-Idee. Wenn man Infrastruktur als den grundlegendsten Layer einer Software betrachtet, dann sollte dieser Layer auch in jedem Feature-Team berücksichtigt werden. Et voilà: ein DevOps-Team!

Auf unser Beispiel angewendet bedeutet das, dass wir zumindest 2 Feature-Bereiche identifizieren und die Teams entsprechend einteilen müssen. Wenn wir etwa eine Software entwickeln, die Kleinunternehmern das Erstellen von Web-Shops ermöglicht, könnte ein Team alle Besucher-Features und das andere alle Unternehmer-Features behandeln. Oder ein Team übernimmt die Social-Media-Integraion, während das zweite den Rest erledigt.

Damit wäre das erste Problem gelöst. Und da wir jetzt agil arbeiten, brauchen wir immer nur den einen nächsten Schritt … an die Arbeit!