2    Was ist DevOps?

DevOps ist schon lange kein Hype mehr. Viele Personen machen »irgendetwas mit DevOps« und haben ihre Meinungen und Einschätzungen dazu. Fragt man sie, was genau hinter diesem Wort steckt, hört man zwar oft zunächst eine Erklärung, was sich hinter diesem Begriff verbirgt und wofür DevOps gut ist, aber genaueres Nachfragen offenbart dann eher eine Mischung aus gefährlichem Halbwissen, einer losen Aufzählung von expliziten Technologien und Buzzwords.

Gut, dass Sie dieses Buch lesen: Sie scheinen Interesse am Thema zu haben, dürften sicherlich schon etwas darüber gehört haben und wollen sich jetzt ein genaueres Bild machen, ob DevOps auch was für Sie etwas ist. Gute Idee!

Falls Sie vielleicht etwas skeptischer sind, dann ist das natürlich auch gut. Ich bin kein großer Fan von Buzzwords und Superlativen. Und genauso halte ich es auch hier: Natürlich ist nicht alles super und schön, sobald man DevOps-Prinzipien umsetzt. Natürlich ist nicht alles schlecht, sobald mal keine DevOps-Prinzipien umsetzt. Natürlich ist auch weiterhin nicht alles DevOps, nur weil man DevOps dranschreibt.

Häufig kann ich es den Leuten gar nicht übelnehmen, wenn sie keine klare Vorstellung von der Idee hinter DevOps haben und dementsprechend skeptisch sind. Mittlerweile schreiben viele Firmen »DevOps« an ihre Produkte oder an die Job-Titel ihrer Mitarbeitenden, weil es gleich viel moderner klingt. Was früher »Agile« und »Scrum« war, ist heute »DevOps«. Hauptsache, es wirkt so, als ob man mit der Zeit geht.

Ob in solchen Firmen die DevOps-Umsetzung wirklich beispielhaft gelungen ist, kann man teilweise von außen erkennen, teilweise aber auch nicht. Mein Lieblingsbeispiel ist der »DevOps-Engineer«, den gefühlt jede Firma sucht, die sich moderner aufstellen will. Praktisch für diejenigen, die sich auf diese Stellen bewerben: Diese Jobs werden meistens anständiger bezahlt, als wenn kein DevOps dranstehen würde. Bitte verstehen Sie mich nicht falsch: Es gibt einige triftige Gründe, einen Job mit »DevOps-Engineer« zu betiteln! Leider steckt nur meist nicht das dahinter, was man erwartet. Dieses Thema wird in Abschnitt 14.3 näher betrachtet.

Steigen wir jetzt also in das Thema direkt ein, und schauen wir uns an, was DevOps überhaupt ist.

2.1    DevOps: Das große Ganze

DevOps als Ganzes ist im Wesentlichen eine Arbeitskultur. Es ist keine Technik, kein Tool, keine Job-Bezeichnung und, ja, es ist im Grunde auch keine Team-Bezeichnung, obwohl es sich von den beiden Begriffen Development und Operations ableitet, mit denen klassischerweise die Entwicklung und der Betrieb bezeichnet werden. Um erfolgreich nach den DevOps-Prinzipien arbeiten zu können, müssen die Prinzipien dieser Kultur möglichst umfassend in der Firma gelebt werden.

Das heißt also: Nicht nur die einzelnen Teams sollten nach DevOps-Prinzipien arbeiten, sondern die ganze Firma, denn ansonsten sind ihre Erfolgschancen gering. Daher ist es nicht sinnvoll, wenn einzelne Teams als »DevOps-Teams« bezeichnet werden und andere Teile wiederum gar nicht existieren. Schließlich geht es um das große Ganze und nicht um einzelne Teams.

Außerdem ist DevOps unabhängig von den Tools, die verwendet werden. Wer sich wundert, warum ich das hier abermals erwähne: Das ist essenziell und wird – obwohl es bekannt ist – immer wieder ignoriert. Es ist nämlich andersherum: Die Tools unterstützen die Prozesse, was wiederum die Menschen unterstützt. Es wäre also ein falscher Ansatz, die Prozesse umzustellen, nur weil man überzeugt ist, dass man endlich Kubernetes in der Firma einführen sollte.

Während die agile Software-Entwicklung eine gute Basis darstellt, geht es bei DevOps darum, den ganzen Software-Development-Lifecycle (SDLC) zu betrachten. Dieser beginnt mit der Projektplanung, geht mit dem Programmieren und dem Ausrollen an die Endnutzer weiter, um anschließend das Feedback aus dem Betrieb für die weiteren Entwicklungsarbeiten zu nutzen. Eigentlich könnte man auch gleich vom Software-Delivery-Lifecycle sprechen, schließlich ist ein Development ohne Delivery reichlich witzlos.

Grundsätzlich geht es bei DevOps darum, den agilen Software-Entwicklungsprozess deutlich auszuweiten. Die agile Software-Entwicklung zielt darauf ab, dass nicht alles im Voraus haargenau geplant wird, sondern dass in kürzeren Iterationen und in Inkrementen gearbeitet wird, um flexibler mit den sich ändernden Anforderungen zurechtzukommen. Ein etwas tieferer Einstieg in die agile Software-Entwicklung erfolgt gleich in Abschnitt 4.1.

Obwohl DevOps eigentlich eine gelebte Kultur sein soll, kann man sich ihr natürlich theoretisch nähern und versuchen, sie durch Definitionen zu fassen. Es muss Ihnen aber klar sein, dass diese Zusammenfassungen immer nur Ideale und Abstraktionen darstellen, die Sie konkret an Ihre Umgebung anpassen müssen.

Dennoch ist es sinnvoll, diese Prinzipien zu kennen, da sie ein gutes Gerüst bilden, an dem Sie sich bei der Umsetzung orientieren können. In der Praxis haben sich zwei Methodiken und Definitionen etabliert. Das sind einmal die Grundwerte von DevOps, nämlich das CA(L)MS-Modell sowie die sogenannten Drei Wege, wobei der Begriff meistens im englischen Original genutzt wird: The Three Ways.

Beide Aspekte werden Sie im Laufe des Buches immer wieder erkennen, und ich werde mich wiederholt auf diese Punkte zurückbesinnen, damit bei den jeweiligen Aspekten klar ist, wozu ein jeder gehört. Lassen Sie uns nun zunächst erst mal in die Prinzipien einsteigen, damit klar ist, worum es geht, ohne uns allzu sehr in den Details zu verlieren. Sowohl CA(L)MS als auch The Three Ways nähern sich DevOps auf unterschiedlichen Arten.

2.1.1    CA(L)MS

Das CA(L)MS-Modell enthält die Leitprinzipien von DevOps. Aber jetzt erst einmal einen Schritt zurück: Wofür steht überhaupt CA(L)MS?

CA(L)MS ist eine Abkürzung von vier oder fünf Werten:

• C für Culture

• A für Automation

• L für Lean

• M für Measurement

• S für Sharing

Die Thematik rund um »Lean« wird oft als optional betrachtet, weswegen die Grundwerte als CAMS und die Erweiterung als CALMS zu finden ist.

Abbildung 2.1     Das CALMS-Modell

Bei Ihrer DevOps-Transformation hilft Ihnen das CALMS-Modell, da es betont, dass alle Aspekte gleichmäßig aufgebaut werden und somit gemeinsam wachsen müssen. Sie stehen auf dem Fundament der Kultur, denn ohne diese geht es nicht.

Auf jeden dieser Punkte gehe ich hier zunächst einmal relativ oberflächlich ein. In den folgenden Kapiteln werde ich allerdings immer wieder auf die einzelnen Bestandteile des CALMS-Modells verweisen, damit klarer ist, was die einzelnen Aspekte jetzt mit DevOps zu tun haben und wo sie sich in dem CALMS-Modell wiederfinden.

C für Culture

Das C steht für Culture, also Kultur. Hier ist vordergründig die Arbeitskultur gemeint: Wie erfolgt die Zusammenarbeit im Team und innerhalb der Organisation, ganz unabhängig von den verschiedenen Rollen und Aufgabengebieten im Team?

Ein Team, das nach den DevOps-Prinzipien arbeitet, besteht stark vereinfacht gesprochen im Wesentlichen aus Entwicklung (Dev) und Betrieb (Ops), die zusammenarbeiten und nicht, wie so häufig, gegeneinander antreten. Anstatt dass beide Teams getrennt voneinander in Silos hocken und mit großen, hohen Wänden voneinander abgeschottet sind, setzen sich beide Gruppen bei ihren Aufgaben für ein gemeinsames Ziel ein.

Aber hier kommt es schon zum ersten Problem: Die Entwickler müssen neue Features entwickeln, die möglichst wenig Fehler aufweisen. Das Hauptaugenmerk des Betriebsteams liegt auf dem sicheren und stabilen Einsatz der Software, die vom Entwicklungsteam geschrieben wurde.

Die Kultur des Teams ist entscheidend, da alle Menschen aus dem Team nicht nur organisatorisch, sondern auch hinsichtlich der Ziele zusammengeführt werden müssen. Für beide Gruppen ist es wichtig, beide Aufgaben zu erfüllen.

Ein klassisches Entwicklungsteam kann die neuen Features nicht ausrollen, weil das Deployment zu kompliziert und fehleranfällig ist. Hier ist Teamwork gefragt, nicht »Works for me«.

Ein wesentlicher Aspekt ist das häufige Ausrollen von Releases, um die Zeit von der Fehlerkorrektur bis zum Ausrollen möglichst kurz zu halten. Für diese Aufgabe ist Automatisierung notwendig. Und diese hilft auch nur dann, wenn man sich auch wirklich traut, die Software auszurollen. Hier spielen noch weitere Aspekte hinein, wie ausführliche Tests, um sicher und regelmäßig Änderungen veröffentlichen zu können.

Und genau deshalb ist es wichtig, dass nicht nur diese beiden Gruppen an der Arbeitskultur...