Suche
Kolumne

DevOps Stories: Wie halten wir’s mit dem Betrieb?

Konstantin Diener

Das eine Modell für die Kollaboration zwischen Dev und Ops gibt es nicht. Ganz grundsätzlich gibt es drei Möglichkeiten: Collaboration, Embedding und X as a Service. Aber welche davon ist die richtige? Auch hier sind die Kommunikationswege das entscheidende Kriterium.

Vor einigen Monaten haben sich die Backend-Entwickler der verschiedenen Teams in einer Community of Practice organisiert. Denn die Entwickler hatten festgestellt, dass in allen crossfunktionalen Produktteams unterschiedliche Frameworks und Technologien für Build und Deployment von Backend-Services verwendet werden. Die Mitglieder haben bei einem ihrer ersten Treffen auch direkt auf die Tagesordnung gesetzt, über eine mögliche Vereinheitlichung zu sprechen. Dabei entwickelt sich eine Diskussion über die verschiedenen Betriebsmodelle (Abb. 1):

Lars: „Wir haben sehr gute Erfahrungen mit GitLab CI gemacht. Haben dort verschiedene Pipelines konfiguriert, die auf unser Git Repo lauschen. Bauen, testen, deployen, Integrationstests und Produktions-Deployments – passiert jetzt alles automatisiert.“

Gordon: „Wo ist eure Anwendung gehostet?“

Lars: „Wir haben verschiedene Maschinen, eine Datenbank und Storage in der Cloud. Alle Ressourcen sind über Infrastructure as Code beschrieben.“

Gordon: „Da fängt es ja schon an! Wir sind eines der letzten Produkte, dass noch On-Prem bei uns im Haus läuft. Ihr wisst, was das bedeutet?“

Lukas: „Ihr habt noch die alten Organisationsstrukturen und verwendet Maschinen, die nicht unter eurer Hoheit liegen, sondern von den restlichen Kollegen im Betriebsteam betrieben werden.“

Gordon: „Genau.“

Lukas: „Wie deployt ihr denn eure Software?“

Gordon: „Gar nicht. Wir schicken den Kollegen einen Link, unter dem sie das Paket herunterladen können. Sie deployen es dann für uns.“

Christian: „Oh Gott, und wie bekommt ihr mit, ob das Deployment erfolgreich war?“

Gordon: „Die Kollegen schicken uns eine Mail mit dem Logfile des Servers.“

Lukas: „Wie oft liefert ihr neue Software in Produktion aus, Gordon?“

Gordon: „Maximal einmal alle drei Monate. Das ist uns einfach zu viel Zirkus.“

Lukas: „Und ihr, Lars?“

Lars: „Bis zu zehnmal am Tag, Tendenz steigend. Aber manchmal würde ich mir auch ein Betriebsteam wünschen.“

Christian: „Das ist nicht dein Ernst!“

Lukas: „Wieso, Lars?“

Lars: „Wir liefern unsere Services alle in Docker-Containern aus. Die komplette Infrastruktur zum Betreiben dieser Container mussten wir uns schrittweise selber bauen. Die ersten paar waren noch kein Problem, aber mittlerweile sind wir bei rund sechzig Containern. Seit letzter Woche hosten und warten wir sogar ein Kubernetes selber, um die ganzen Container zu betreiben!“

Gordon: „Ihr seid ja heiß drauf! Davon kann ich nur träumen. Wir hosten gar nichts selber. Wir haben nur ein paar inoffizielle Testumgebungen, von denen die Betriebsjungs nichts wissen dürfen.“

Lars: „So traumhaft finde ich das gar nicht. Wir entwickeln eigentlich ein E-Book-Produkt und wollen uns darauf konzentrieren. Und jetzt müssen wir ein Kubernetes betreiben – selber patchen, updaten usw. Das machen bei eurer Infrastruktur alles die Betriebsjungs für euch.“

Lukas: „Wir haben langsam auch so viele Services, dass sich ein Kubernetes lohnen würde. Vielleicht können wir hier in der Community of Practice unsere Anstrengungen bündeln.“

 

Abb. 1: In der Community of Practice diskutieren die Kollegen verschiedene Betriebsmodelle

Es gibt nicht das eine Modell für die Kollaboration zwischen Dev und Ops

Die meisten Unternehmen beschäftigen sich mit den Themen DevOps und Cloud, weil sie einen Lieferrhythmus wie Lars’ Team erreichen möchten. Bugfixes und neue Features sind dann nach sehr kurzer Zeit am Markt verfügbar. Im Buch „The Phoenix Project“ [1] muss die fiktive Firma Parts Unlimited die Erfahrung machen, dass sich diese Geschwindigkeit nur erreichen lässt, wenn man die Silos für Entwicklung und Betrieb auflöst. Dieselbe Erfahrung macht auch Gordon mit seinem Team. Die Firma hat ihre Arbeitsweise Schritt für Schritt auf DevOps umgestellt. In Gordons Team ist diese Umstellung noch nicht vollzogen, und es besteht weiterhin eine strikte Trennung zwischen Entwicklung und Betrieb. Das führt zu einer wesentlich niedrigeren Auslieferungsfrequenz als in Lars’ Team.

DevOps bedeutet eine enge Zusammenarbeit zwischen Entwicklung und Betrieb. Nach Matthew Skelton gibt es dafür drei grundlegende Möglichkeiten: Collaboration, Embedding und X as a Service. Dabei wird wiederum zwischen folgenden Arten von Tätigkeiten unterschieden: Dev als reine Entwicklung von Businesslogik, Ops als Betrieb und Wartung von Infrastruktur (Updates, Patches, Failover etc.) und DevOps als Konfiguration von Infrastrukturkomponenten, die für die Applikation gebraucht werden (beispielsweise in Form von Infrastructure as Code). Auf seiner Webseite stellt Skelton eine ganze Reihe möglicher Ausprägungen für Teams vor.

Lars’ Entwicklungsteam übernimmt Dev- und DevOps-Tätigkeiten. Die Entwickler schreiben ihren Anwendungscode und beschreiben die notwendigen Infrastrukturkomponenten wie Server, Datenbank und Storage in Form von Infrastructure as Code. Das zugehörige Ops-Team sitzt in diesem Fall außerhalb des Unternehmens beim Cloud-Anbieter. Die Mitarbeiter dort stellen Server, Datenbank und Storage über ein API als Infrastructure as a Service bereit (Abb. 2).

Abb. 2: Das Ops-Team stellt Infrastructure as a Service bereit

Das Team verwendet für die Paketierung seiner Services Docker-Container. Mit steigender Zahl wurde das Deployment und Management der Container in der Cloud unhandlich. Das Team hat sich deshalb entschlossen, selbst ein Kubernetes aufzusetzen und zu betreiben. Für diese Plattform fallen in Lars’ Team also auch Ops-Tätigkeiten an. Weil das Betreiben von Kubernetes nicht zu ihren originären Teamzielen gehört, sind sie mit diesem Zustand allerdings unzufrieden. Da Lukas und Christian auch Interesse an Kubernetes zeigen, denken die Kollegen darüber nach, Kubernetes intern als Platform as a Service anzubieten. Damit wären sie hierfür beim selben Modell wie für die übrigen Infrastrukturkomponenten. Mit dem Unterschied, dass die PaaS von einem internen Ops-Team bereitgestellt würde (Abb. 3).

Abb. 3: Betriebstätigkeiten sind in das Entwicklungsteam eingebettet

In Gordons Team erleben wir, wie die Zusammenarbeit zwischen Entwicklung und Betrieb nicht ablaufen sollte. Zwei getrennte Abteilungen kommunizieren nur über Softwareartefakte und E-Mail miteinander. Enger zusammenarbeiten können sie z. B., indem die Entwickler detaillierter die benötigte Infrastruktur beschreiben und nicht nur ein JAR an den Betrieb übergeben, und der Betrieb seinerseits den Entwicklern Freiheiten beim Aufbau eigener Testumgebungen lässt. Damit diese Testumgebungen auch repräsentativ für die spätere Produktivumgebung sind, stellt das Betriebsteam Skripte bereit, die unter anderem prüfen, ob die für die Testumgebung verwendeten Versionen für Frameworks, Server oder Images nicht veraltet sind.

Abb. 4: Entwicklung und Betrieb kollaborieren sinnvoll miteinander

Der gewählte Ansatz hängt von den Kommunikationsbeziehungen ab

Welche der drei DevOps-Varianten sollte man nun wählen? Wie bei crossfunktionalen Teams üblich, hängt die Antwort mit den Kommunikationsbeziehungen zwischen den Kollegen aus Entwicklung und Betrieb zusammen. Wenn bestimmte Betriebsmitarbeiter viel häufiger mit den Kollegen aus der Entwicklung als mit anderen Mitarbeitern im Betrieb kommunizieren, sollten sie ein Teil des crossfunktionalen Produktteams sein. Das kann passieren, wenn es sich um eine spezielle Infrastrukturkomponente handelt, die nur von einem Team verwendet wird. Ist die Kommunikation innerhalb des Betriebsteams allerdings intensiver, sollten diese Mitarbeiter ein Team bilden, das mit den Entwicklungsteams eng zusammenarbeitet. Das Betriebsteam sollte sich aber immer überlegen, ob sich die Infrastrukturkomponenten und deren Verwendung so weit standardisieren lassen, dass sie den übrigen Teams als Infrastructure as a Service oder Platform as a Service angeboten werden können. Das verwendete Modell für die Zusammenarbeit kann sich mit der Zeit verändern und steht in der Regel im Zusammenhang mit dem Reifegrad des Produkts, das das crossfunktionale Team entwickelt (Kasten: „Entwicklungspfad für die Infrastruktur“).

Entwicklungspfad für die Infrastruktur

DevOps-Kultur propagiert Experimente. Jedes neue Produkt ist ein solches Experiment. Damit das Produktteam möglichst wenig Aufwand mit Infrastrukturarbeiten hat, wählt cosee für ein neues Produkt oft Plattformen wie Heroku. Wenn sich herausstellt, dass sich eine Skalierung des Produkts lohnt, steht nach einer gewissen Zeit der Umzug auf eine flexiblere, aber aufwendigere Plattform wie AWS und die Nutzung von Containern an. Ähnlich wie in Lars’ Team entstehen dabei immer wieder Infrastrukturservices, die von mehr und mehr Teams verwendet werden, und bei denen cosee über ein dediziertes internes Ops-Team nachdenkt.

Lars, Christian und Lukas haben beschlossen, beim Management die Gründung eines internen Ops-Teams für Kubernetes as a Service anzuregen. Und natürlich Gordon und sein Team dabei zu unterstützen, möglichst schnell zu einer besseren Zusammenarbeit mit den Kollegen aus dem Betrieb zu kommen.

DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.