DevOps-Tools für Java-Entwickler

Kapitel 1. DevOps für (oder womöglich gegen) Entwickler

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Baruch Sadogursky

Während du hier schnarchend liegst,
Nimmt die Verschwörung mit offenen Augen seine Zeit.
Wenn du dich um dein Leben sorgst,
dann schüttle den Schlummer ab und pass auf:
Wache auf, wache auf!

William Shakespeare, Der Sturm

Manche mögen fragen, ob die DevOps-Bewegung einfach nur eine von den Ops inspirierte Verschwörung gegen die Entwickler ist.Die meisten (wenn nicht alle), die das tun, würden keine ernsthafte Antwort erwarten, nicht zuletzt, weil sie die Frage als ironische Neckerei verstehen. Es liegt auch daran, dass - unabhängig davon, ob du von der Entwicklungs- oder der Betriebsseite der Gleichung kommst - wenn jemand ein Gespräch über DevOps beginnt, es ungefähr 60 Sekunden dauert, bis jemand fragt: "Aber was ist DevOps wirklich?"

Und man sollte meinen, dass wir 11 Jahre nach der Prägung des Begriffs (ein Jahrzehnt, in dem Branchenexperten darüber gesprochen, debattiert und geschrien haben) alle eine einheitliche, klare und allgemein verständliche Definition gefunden haben. Aber das ist einfach nicht der Fall. Tatsächlich ist es höchst zweifelhaft, dass trotz der exponentiell steigenden Nachfrage von Unternehmen nach DevOps-Mitarbeitern fünf zufällig ausgewählte Mitarbeiter mit DevOps-Titel genau sagen können, was DevOps ist.

Es muss dir also nicht peinlich sein, wenn du dich immer noch am Kopf kratzt, wenn das Thema zur Sprache kommt. Das Konzept von DevOps ist vielleicht nicht leicht zu verstehen, aber es ist auch nicht unmöglich.

Aber unabhängig davon, wie wir den Begriff diskutieren oder auf welche Definition(en) wir uns einigen, gibt es vor allem eine Sache, die wir nicht vergessen dürfen: DevOps ist ein völlig neu erfundenes Konzept, und die Erfinder kamen von der operativen Seite der Gleichung.

DevOps ist ein Konzept, das von der Ops-Seite erfunden wurde

Meine Prämisse über DevOps mag provokant sein, aber sie ist auch beweisbar. Beginnen wir mit den Fakten.

Schaubild 1: Das Phoenix-Projekt

The Phoenix Project von Gene Kim et al. (IT Revolution) ist seit seiner Veröffentlichung vor fast zehn Jahren zu einem Klassiker geworden. Es ist kein Handbuch (jedenfalls nicht im herkömmlichen Sinne), sondern ein Roman, der die Geschichte eines hochproblematischen Unternehmens und seines IT-Managers erzählt, der plötzlich mit der Aufgabe betraut wird, eine unternehmenswichtige Initiative umzusetzen, die bereits weit über dem Budget und Monate hinter dem Zeitplan liegt.

Wenn du dich in der Welt der Software auskennst, werden dir die anderen Hauptfiguren des Buches bekannt vorkommen. Schauen wir uns aber erst einmal ihre Berufsbezeichnungen an:

• Direktor, IT-Service-Unterstützung

• Direktor, verteilte Technologie

• Manager, Einzelhandelsverkauf

• Leitender Systemadministrator

• Beauftragter für Informationssicherheit

• Chief Financial Officer

• Geschäftsführerin

Sie sind die Protagonisten eines der wichtigsten Bücher über DevOps, das je geschrieben wurde, und keiner von ihnen ist ein Entwickler. Selbst wenn Entwickler in der Handlung vorkommen, sagen wir einfach, dass sie nicht gerade in den höchsten Tönen erwähnt werden.

Wenn der Sieg eintritt, ist es der Held der Geschichte (zusammen mit einem unterstützenden Vorstandsmitglied), der DevOps erfindet, das Projekt aus dem Feuer holt, die Geschicke seines Unternehmens lenkt und mit einer Beförderung zum Chief Information Officer (CIO) des Unternehmens belohnt wird. Und alle leben glücklich - wenn nicht für immer, dann zumindest für die zwei oder drei Jahre, die solche Erfolge in diesem Geschäft dauern, bevor es Zeit ist, sich erneut zu bewähren.

Abb. 2: Das DevOps-Handbuch

Es ist besser, The Phoenix Project vor The DevOps Handbook von Gene Kim et al. (IT Revolution) zu lesen, denn das erste Buch versetzt dich in ein sehr glaubwürdiges, menschliches Szenario. Es ist nicht schwer, sich in die Persönlichkeitstypen, die beruflichen Schwierigkeiten und die zwischenmenschlichen Beziehungen der Charaktere hineinzuversetzen. Das Wie und Warum von DevOps entfaltet sich als unvermeidliche und rationale Reaktion auf eine Reihe von Umständen, die genauso gut zum Zusammenbruch des Unternehmens hätten führen können. Die Einsätze, die Charaktere und die Entscheidungen, die sie treffen, wirken allesamt sehr plausibel. Parallelen zu deinen eigenen Erfahrungen sind nicht schwer zu ziehen.

Das DevOps-Handbuch ermöglicht es dir, die konzeptionellen Bestandteile der DevOps-Prinzipien und -Praktiken genauer zu erforschen. Wie der Untertitel schon andeutet, geht das Buch einen weiten Weg, um zu erklären, wie man Agilität, Zuverlässigkeit und Sicherheit in Technologieunternehmen auf Weltklasseniveau schafft. Aber sollte es dabei nicht um die Entwicklung gehen? Ob es das sollte oder nicht, darüber kann man streiten. Unbestritten ist, dass die Autoren des Buches kluge, superbegabte Fachleute sind, die wohl die Väter von DevOps sind. In Anhang 2 geht es jedoch nicht darum, sie zu loben, sondern vielmehr darum, einen Blick auf ihren Hintergrund zu werfen.

Beginnen wir mit Gene Kim.Er gründete das Software-Sicherheits- und Datenintegritätsunternehmen Tripwire und war über ein Jahrzehnt lang dessen Chief Technology Officer (CTO). Als Forscher widmet er seine berufliche Aufmerksamkeit der Untersuchung und dem Verständnis des technologischen Wandels, der in großen, komplexen Unternehmen und Institutionen stattgefunden hat und stattfindet. Er ist nicht nur Mitautor von The Phoenix Project, sondern 2019 auch von The Unicorn Project (über das ich später noch mehr sagen werde). Seine gesamte Karriere ist von der Arbeit im operativen Bereich geprägt. Selbst wenn es in Unicorn heißt, dass es "um Entwickler geht", geht es immer noch um Entwickler, gesehen durch die Augen eines operativen Mitarbeiters!

Was die anderen drei Autoren des Handbuchs angeht:

• Jez Humble war in verschiedenen Positionen tätig, darunter Site Reliability Engineer (SRE), CTO, stellvertretender Direktor für Delivery Architecture and Infrastructure Services und Developer Relations. Ein Ops-Mann! Auch wenn sich der letzte seiner Titel auf die Entwicklung bezieht, geht es in seinem Job nicht darum. Es geht um die Beziehungen zu den Entwicklern. Es geht darum, die Kluft zwischen Entwicklung und Ops zu verringern, worüber er viel geschrieben, gelehrt und Vorträge gehalten hat.

• Patrick Debois war CTO, Director of Market Strategy und Director of Dev♥Ops Relations (das Herzstück ist sein Zusatz). Er beschreibt sich selbst als Fachmann, der "die Kluft zwischen Projekten und Betrieb überbrückt, indem er agile Techniken in Entwicklung, Projektmanagement und Systemadministration einsetzt." Das klingt ganz nach einem Ops-Typ.

• John Willis trägt derzeit den Titel VP of DevOps and Digital Practices ( ). Zuvor war er Director of Ecosystem Development, VP of Solutions und vor allem VP of Training and Services bei Opscode (jetzt Progress Chef). Auch wenn John Willis in seiner Laufbahn etwas mehr mit der Entwicklung zu tun hatte, drehte sich der Großteil seiner Arbeit um den Betrieb, vor allem in dem Maße, in dem er sich darauf konzentrierte, die Mauern einzureißen, die Entwickler und Betriebsmitarbeiter früher in getrennten Lagern hielten.

Wie du siehst, haben alle Autoren einen Einsatzhintergrund. Zufall? Ich glaube nicht.

Bist du immer noch nicht davon überzeugt, dass DevOps von den operativen Abläufen abhängt? Wie wäre es, wenn wir einen Blick auf die Führungskräfte werfen, die uns heute DevOps verkaufen wollen?

Google It

Wenn du derzeit "Was ist DevOps?" in eine Google-Suche eingibst, um zu sehen, was dabei herauskommt, findest du auf der ersten Seite wahrscheinlich die folgenden Ergebnisse:

• Agile Admin, ein Unternehmen für Systemadministration

• Atlassian, dessen Produkte Projekt- und Problemverfolgung, Listenerstellung und Plattformen für die Zusammenarbeit im Team umfassen

• Amazon Web Services (AWS), Microsoft Azure und Rackspace Technology, die alle eine Cloud-Ops-Infrastruktur anbieten

• Logz.io, das Dienstleistungen für Log-Management und -Analyse anbietet

• New Relic, dessen Spezialität die Anwendungsüberwachung ist

Ja, auf der ersten Seite gab es ein Unternehmen, das sich mehr auf die Entwicklung konzentrierte, und ein weiteres, das nicht direkt mit der Suche zu tun hatte. Der Punkt ist, dass die meisten Unternehmen, die du findest, wenn du nach DevOps suchst, eher in Richtung Ops gehen.

Was macht es?

DevOps ist ein Ding! Es ist sehr gefragt.Und deshalb werden viele konkret wissen wollen, was DevOps macht, was es im Wesentlichen bewirkt. Anstatt diesen Weg zu gehen, sollten wir es strukturell betrachten, indem wir es wie das seitliche Unendlichkeitssymbol in Form einer Acht betrachten. In diesem Licht sehen wir eine Schleife von Prozessen, die von der Programmierung über die Erstellung, das Testen, die Freigabe, die Bereitstellung, den Betrieb und die Überwachung bis hin zur Planung neuer Funktionen reicht, wie in Abbildung 1-1 dargestellt.

Abbildung 1-1. DevOps-Endlosschleife

Und wenn dies einigen Lesern bekannt vorkommt, sollte es das auch, denn es hat eine konzeptionelle Ähnlichkeit mit dem Agilen Entwicklungszyklus(Abbildung 1-2).

Abbildung 1-2. Agiler Entwicklungszyklus

Es gibt keinen tiefgreifenden Unterschied zwischen diesen beiden unendlichen Geschichten, außer der Tatsache, dass die Ops sich selbst in die alte Welt des agilen Kreises eingepfropft haben und ihn im Wesentlichen in zwei Kreise gedehnt haben, um ihre Sorgen und Nöte in die Domäne zu drängen, die früher ausschließlich den Entwicklern vorbehalten war.

Stand der Industrie

Seit 2014 gibt es einen weiteren Beweis dafür, dass DevOps ein ops-getriebenes Phänomen ist, und zwar in Form einer leicht zu lesenden jährlichen Zusammenfassung von Daten, die von Zehntausenden von Branchenexperten und Unternehmen weltweit gesammelt, analysiert und zusammengefasst wurden. Der Bericht "Accelerate: State of DevOps"-Bericht wurde in erster Linie von DevOps Research and Assessment (DORA) erstellt und ist das wichtigste Dokument in der Softwarebranche, um zu beurteilen, wo DevOps steht und wohin es sich entwickeln wird. In der Ausgabe 2018 können wir zum Beispiel einen ernsthaften Fokus auf Fragen wie diese erkennen:

• Wie oft setzen Organisationen Code ein?

• Wie lange dauert es in der Regel, bis der Code erfolgreich in der Produktion läuft?

• Wenn es zu Beeinträchtigungen oder Ausfällen kommt, wie lange dauert es in der Regel, bis der Dienst wiederhergestellt ist?

• Wie viel Prozent der vorgenommenen Änderungen führen zu einer Verschlechterung des Dienstes oder erfordern Abhilfemaßnahmen?

Beachte, dass dies alles sehr betriebliche Belange sind.

Was macht Arbeit aus?

Sehen wir uns nun an, wie die Arbeit im Bericht "Accelerate: State of DevOps"-Bericht und The Phoenix Project definiert wird.Zunächst einmal konzentriert sich die geplante Arbeit auf Geschäftsprojekte und neue Funktionen, die sowohl den Betrieb als auch die Entwicklung betreffen. Interne Projekte wie Servermigrationen, Software-Updates und Änderungen, die durch das Feedback zu laufenden Projekten ausgelöst werden, können sehr breit gefächert sein und müssen nicht zwangsläufig auf einer Seite der DevOps-Gleichung liegen.

Aber was ist mit ungeplanten Aktivitäten, wie Support-Eskalationen und Notausfällen? Das sind Ops-Aktivitäten, ebenso wie das Programmieren neuer Funktionen, Bugfixes und Refactoring - alles Dinge, die das Leben der Ops erleichtern können, indem sie die Entwickler in die DevOps-Geschichte einbeziehen.

Wenn es bei uns nicht um Einsatz und Betrieb geht, was ist dann unsere Aufgabe?

Es ist klar, dass DevOps nichts ist, was von den Entwicklern gefordert wurde (oder wird).Es ist eine Erfindung der Ops, um alle anderen härter arbeiten zu lassen. Und wenn wir diese Wahrheit annehmen, lasst uns darüber nachdenken, was passieren würde, wenn sich die Entwickler gemeinsam erheben und sagen würden: "Eure Ops-Anliegen sind eure, nicht unsere". Gut, aber dann wäre es nur recht und billig, die rebellierenden Entwickler nach ihrer Definition von "fertig" zu fragen. Welche Standards müssen sie ihrer Meinung nach erreichen, um sagen zu können: "Wir haben unsere Arbeit gut gemacht und unser Teil ist jetzt erledigt"?

Das ist keine leichtfertige Frage, und es gibt Quellen, in denen wir nach Antworten suchen können. Eine, wenn auch unvollkommene und nicht selten kritisierte, ist das Manifest für Software Craftsmanship, in dem vier grundlegende Werte genannt werden, die Entwickler motivieren sollten. Betrachten wir sie:

Gut durchdachte Software

Ja, in der Tat, Qualität ist wichtig.

Stetige Wertschöpfung

Das ist kein Argument. Natürlich wollen wir Dienste und Funktionen anbieten, die die Menschen brauchen, wollen oder mögen.

Gemeinschaft von Fachleuten

Im Großen und Ganzen, wer könnte da widersprechen? Höflichkeit unter Branchenkollegen ist einfach nur professionelle Nachbarschaft.

Produktive Partnerschaften

Zusammenarbeit ist das A und O. Die Entwickler sind nicht gegen die Qualitätssicherung (QA), den Betrieb oder die Produkte selbst. Es geht also darum, mit allen freundlich umzugehen (solange die anderen Teams nicht anfangen, ihnen vorzuschreiben, was ihre Aufgaben zu sein haben).

Was genau ist "erledigt"?

Nach allem, was wir bisher herausgefunden haben, können wir mit Sicherheit sagen, dass wir einen Code erstellen müssen, der einfach, lesbar, verständlich und leicht zu implementieren ist. Wir müssen sicher sein, dass nichtfunktionale Anforderungen (z.B. Leistung, Durchsatz, Speicherbedarf, Sicherheit, Datenschutz usw.) erfüllt werden, Leistung, Durchsatz, Speicherbedarf, Sicherheit, Datenschutz usw.) erfüllt sind. Wir sollten sorgfältig arbeiten, um technischen Ballast zu vermeiden, und wenn wir Glück haben, können wir ihn auf dem Weg loswerden. Wir müssen sicher sein, dass alle Tests erfolgreich sind. Und wir sind verpflichtet, gute Beziehungen zu den QA-Teams zu pflegen (wenn sie zufrieden sind, sind wir es auch).

Mit einem Produktteam, das Standards für den Wert und den Mehrwert definiert, können Benchmarks festgelegt werden. Durch ihr Feedback helfen die Product Owner dabei festzustellen, ob diese Benchmarks erreicht werden (oder nicht) und in welchem Umfang. Das ist eine ziemlich gute Kurzdefinition dafür, dass ein guter Softwareentwickler "getan" hat, was er tun musste. Es zeigt auch, dass "gut gemacht" nie angemessen gemessen werden kann (oder überhaupt bekannt ist), ohne die Einbeziehung und klare Kommunikation mit den Betriebsmitarbeitern.

Rivalität?

Auch wenn DevOps nachweislich nichts war, wonach die Entwicklerinnen und Entwickler schrien, so kann doch auch gezeigt werden, dass die unendliche Praxis allen zugute kommt. Und trotzdem gibt es immer noch Verweigerer; diejenigen, die sich eine Rivalität, ja sogar eine Feindschaft zwischen Entwicklern und beispielsweise QA-Testern vorstellen. Die Entwicklerinnen und Entwickler arbeiten hart an ihren Kreationen und haben dann das Gefühl, dass die QA-Teams fast wie Hacker sind, die nur darauf aus sind, etwas zu beweisen, und einfach graben und graben, bis sie ein Problem finden.

Hier kommt die DevOps-Beratung ins Spiel. Jeder gewissenhafte Entwickler möchte stolz auf das sein, was er produziert. Das Auffinden von Fehlern kann wie Kritik erscheinen, obwohl es in Wirklichkeit nur gewissenhafte Arbeit aus einer anderen Richtung ist. Eine gute, klare, offene und kontinuierliche Kommunikation zwischen Entwicklern und QS-Mitarbeitern trägt dazu bei, die Vorteile von DevOps zu verstärken, aber sie macht auch deutlich, dass alle letztlich auf dasselbe Ziel hinarbeiten. Wenn QA-Mitarbeiter Fehler finden, helfen sie ihren Entwicklerkollegen dabei, besseren Code zu schreiben und bessere Entwickler zu sein. Dieses Beispiel für das Zusammenspiel zwischen den Mitarbeitern auf der Ops- und den Entwicklern auf der DevSeite zeigt, dass die Unterschiede und Trennungen zwischen den beiden Welten verschwimmen. Ihre Beziehung ist notwendigerweise symbiotisch und funktioniert wiederum entlang eines endlosen Kontinuums von Aktivitäten, wobei die eine die andere zum gegenseitigen Nutzen beeinflusst.

Mehr als je zuvor

Die steigende Nachfrage nach DevOps kommt sowohl von außen als auch von den Softwareunternehmen selbst. Und das liegt daran, dass sich unsere Erwartungen, all unsere Erwartungen, als Menschen, die in einer Welt des 21. Jahrhunderts leben, immer schneller ändern. Je mehr wir auf immer bessere Softwarelösungen angewiesen sind, desto weniger Zeit haben wir für Informations- und Kommunikationslücken und Verzögerungen zwischen Entwicklern und Betriebspersonal.

Nehmen wir zum Beispiel das Bankgeschäft: Vor zehn Jahren hatten die meisten großen Banken eine halbwegs vernünftige Website. Du konntest dich einloggen, um deine Konten, deine Kontoauszüge und die letzten Transaktionen einzusehen. Vielleicht hast du sogar angefangen, deine Zahlungen elektronisch über die von deiner Bank angebotenen E-Services abzuwickeln. Und obwohl diese Services nett waren und einen gewissen Komfort boten, musstest du wahrscheinlich immer noch zu deiner örtlichen Filiale gehen (oder fühltest dich zumindest wohler dabei), um deine Bankgeschäfte zu erledigen.

Was es damals noch nicht gab, ist heute ein vollständig digitales Erlebnis - mit mobilen Apps, automatischer Kontoüberwachung und -benachrichtigung und genügend Diensten, die es für den durchschnittlichen Kontoinhaber immer üblicher machen, alles online zu erledigen. Vielleicht gehörst du sogar zu denjenigen, denen es nicht nur egal ist, ob sie ihre stationäre Filiale jemals wieder von innen sehen, sondern die auch gar nicht wissen, wo diese Filiale ist! Außerdem reagieren die Banken auf diese sich schnell ändernden Bankgewohnheiten, indem sie Filialen zusammenlegen und schließen und ihren Kunden Anreize bieten, ihre Bankgeschäfte online abzuwickeln. Dies hat sich während der COVID-19-Krise noch beschleunigt, als der Zugang zu den Filialen nur noch nach Terminvereinbarung, in begrenztem Umfang und zu kürzeren Öffnungszeiten möglich war.

Wenn vor 10 Jahren die Website deiner Bank für 12 Stunden wegen Wartungsarbeiten ausfiel, während die Bank eine bessere, sicherere Website einrichtete, hättest du das wahrscheinlich gelassen hingenommen. Was sind schon ein Dutzend Stunden, wenn sie zu einer besseren Servicequalität führen? Du brauchtest kein 24/7-Onlinebanking und außerdem war die Filiale vor Ort für dich da. Heute ist das einfach nicht mehr der Fall. Ein halber Tag Ausfallzeit ist inakzeptabel. Im Grunde erwartest du von deiner Bank, dass sie immer geöffnet und verfügbar ist. Das liegt daran, dass sich deine Definition von Qualität (und die der Welt) geändert hat. Und diese Änderung erfordert DevOps mehr denn je.

Volumen und Geschwindigkeit

Ein weiterer Druck, der das Wachstum von DevOps vorantreibt, ist die Menge an Daten, die gespeichert und verarbeitet werden. Und das ist nur logisch. Wenn immer mehr von unserem täglichen Leben von Software abhängt, wird natürlich auch die Menge an Daten, die dabei entsteht, enorm ansteigen. 2020 wird die gesamte globale Datensphäre fast 10 Zettabytes umfassen. Ein Jahrzehnt zuvor waren es 0,5 Zettabytes. Bis 2025 wird sie Schätzungen zufolge exponentiell auf über 50 Zettabytes anwachsen!

Dabei geht es nicht nur darum, dass Giganten wie Google, Netflix, Facebook, Microsoft, Amazon, Twitter und andere immer größer und besser werden und deshalb immer größere Datenmengen verarbeiten müssen. Diese Prognose bestätigt, dass immer mehr Unternehmen in die Welt der Big Data aufsteigen werden. Damit einher geht die Forderung nach einer enorm gestiegenen Datenmenge und die Abkehr von den traditionellen Staging-Server-Umgebungen, die exakte Replikate der Produktionsumgebungen darstellten. Und diese Abkehr beruht auf der Tatsache, dass die Aufrechterhaltung solcher Paar-zu-Paar-Schemata in Bezug auf Größe und Geschwindigkeit nicht mehr machbar ist.

Früher konnte alles getestet werden, bevor es in die Produktion ging, aber das ist heute nicht mehr möglich.Es werden immer mehr Dinge in die Produktion gegeben, denen die Softwarefirmen nicht zu 100 % vertrauen. Sollten wir deshalb in Panik geraten? Nein. Die Notwendigkeit, schnell zu veröffentlichen und wettbewerbsfähig zu bleiben, sollte uns zu Innovation und Kreativität inspirieren, wenn es darum geht, kontrollierte Rollovers, Testverfahren und mehr Tests in der Produktiondurchzuführen - das, was heute als progressive Auslieferung bezeichnet wird. Dies geht einher mit Feature Flags und Beobachtungswerkzeugen wie verteiltem Tracing.

Manche setzen die schrittweise Bereitstellung mit dem Explosionsradius einer Sprengladung gleich. Die Idee ist, dass wir bei der Bereitstellung in einer produktiven Umgebung mit Explosionen rechnen sollten. Um solche Rollouts zu optimieren, können wir daher bestenfalls darauf hoffen, die Verluste zu minimieren und den Explosionsradius so klein wie möglich zu halten. Und wenn wir uns einig sind, dass Qualität ein Anliegen der Entwickler ist und ihre Erreichung Teil der Definition von "fertig" ist, dann bedeutet das, dass es keine Pause oder Unterbrechung zwischen dem Entwicklungsmoment der Fertigstellung und dem nächsten, dem Produktionsmoment geben darf. Denn kaum ist dies geschehen, geht es wieder zurück in die Entwicklung, wo Fehler behoben, Dienste aufgrund von Ausfällen wiederhergestellt werden und so weiter.

Erledigt und Erledigt

Vielleicht wird langsam klar, dass die Erwartungen und Anforderungen, die weiterhin aus der Ops-Umgebung kommen, den Anstoß zu DevOps gegeben haben. Die gestiegenen Erwartungen und Anforderungen an die Entwickler kommen also nicht aus einem schwelenden Hass der Ops-Leute auf ihre Entwickler-Kollegen und sind auch nicht Teil eines Plans, ihnen den Schlaf zu rauben. Vielmehr ist alles, was DevOps ausmacht, eine realpolitische Antwort auf unsere sich verändernde Welt und die Veränderungen, die sie der Softwarebranche auferlegt hat.

Tatsache ist, dass jeder neue Verantwortlichkeiten hat, von denen einige erfordern, dass Fachleute (sicherlich viele Abteilungen) immer bereit sind, wenn die Pflicht ruft, denn unsere Welt ist nonstop. Ich will es anders ausdrücken: Unsere alten Definitionen von "erledigt" sind erledigt!

Unsere neue Definition lautet Site Reliability Engineering(SRE). Dieser von Google geprägte Begriff verbindet Dev und Ops für immer, indem er die vermeintliche Kluft zwischen den beiden überbrückt. Und obwohl SRE-Schwerpunkte von Mitarbeitern auf einer oder beiden Seiten der DevOps-Gleichung übernommen werden können, haben Unternehmen heutzutage oft eigene SRE-Teams, die speziell für die Untersuchung von Problemen im Zusammenhang mit Leistung, Effizienz, Reaktionsfähigkeit im Notfall, Überwachung, Kapazitätsplanung und mehr zuständig sind. SRE-Fachleute denken wie Softwareentwickler/innen, wenn es darum geht, Strategien und Lösungen für Probleme bei der Systemadministration zu entwickeln. Sie sind diejenigen, die zunehmend dafür sorgen, dass automatisierte Bereitstellungen funktionieren.

Wenn SRE-Mitarbeiter zufrieden sind, bedeutet das, dass Builds immer zuverlässiger, wiederholbarer und schneller werden, vor allem, weil die Landschaft aus skalierbarem, rückwärts- und vorwärtskompatiblem Code besteht, der in zustandslosen Umgebungen arbeitet, die sich auf ein explodierendes Universum von Servern stützen und Ereignisströme aussenden, um Echtzeitbeobachtung und Warnmeldungen zu ermöglichen, wenn etwas schief läuft. Wenn neue Builds erstellt werden, müssen sie schnell starten (in der vollen Erwartung, dass einige ebenso schnell wieder sterben). Die Dienste müssen so schnell wie möglich wieder voll funktionsfähig sein. Wenn Funktionen nicht funktionieren, müssen wir sie sofort über eine API programmatisch abschalten können. Wenn neue Software veröffentlicht wird und die Nutzer/innen ihre Clients aktualisieren, dann aber auf Fehler stoßen, müssen wir in der Lage sein, schnelle und nahtlose Rollbacks durchzuführen. Alte Clients und alte Server müssen mit neuen Clients kommunizieren können.

Und während SRE diese Aktivitäten bewertet und überwacht und strategische Antworten ausarbeitet, ist die Arbeit in all diesen Bereichen vollständig die der Entwickler. Während Dev-Mitarbeiter/innen also etwas tun, ist SRE die heutige Definition von erledigt.

Schwebe wie ein Schmetterling...

Zusätzlich zu all den bereits erwähnten Überlegungen muss Code in unserer modernen DevOps- (und damit verbundenen SRE-) Ära eine grundlegende Eigenschaft aufweisen: schlank. Und damit meinen wir Geld sparen. "Aber was", wirst du vielleicht fragen, "hat Code mit Geld sparen zu tun?"

Ein Beispiel dafür sind Cloud-Provider, die Unternehmen eine Vielzahl einzelner Dienste in Rechnung stellen. Einige dieser Kosten werden direkt durch den Code beeinflusst, den diese Unternehmen als Abonnenten von Cloud-Diensten ausgeben.Die Kosten können daher durch die Entwicklung und den Einsatz innovativer Entwicklerwerkzeuge sowie durch das Schreiben und Implementieren von besserem Code gesenkt werden.

Die Natur einer globalen, softwaregesteuerten Gesellschaft mit dem ständigen Wunsch nach neuen, besseren Softwarefunktionen und -diensten bedeutet, dass DevOps sich nicht nur mit der Produktion und der Bereitstellung befassen kann. Es muss auch auf das Endergebnis des Unternehmens selbst achten. Und auch wenn dies wie eine weitere Last erscheinen mag, die in den Mix geworfen wird, denk darüber nach, wenn der Chef das nächste Mal sagt, dass die Kosten gesenkt werden müssen. Anstelle negativer Lösungen wie Entlassungen oder Kürzungen von Gehältern und Sozialleistungen können die notwendigen Einsparungen durch positive, profilsteigernde Maßnahmen wie die Umstellung auf Serverless und die Verlagerung in die Cloud erzielt werden. Dann wird niemand gefeuert, und der Kaffee und die Donuts im Pausenraum sind immer noch kostenlos!

Lean zu sein spart nicht nur Geld, sondern gibt Unternehmen auch die Möglichkeit, ihren Einfluss auf dem Markt zu verbessern. Wenn Unternehmen Effizienzsteigerungen ohne Personalabbau erreichen können, können sie ein optimales Niveau an Teamstärke beibehalten. Wenn Teams weiterhin gut bezahlt und betreut werden, sind sie motivierter, ihre bestmögliche Arbeit zu leisten. Wenn diese Arbeit erfolgreich ist, freuen sich auch die Kunden. Solange die Kunden durch die schnellere Bereitstellung gut funktionierende neue Funktionen erhalten, werden sie immer wieder zurückkommen und anderen davon erzählen. Und das ist ein positiver Kreislauf, der Geld in die Kasse spült.

Integrität, Authentifizierung und Verfügbarkeit

Hand in Hand und Schulter an Schulter mit allen DevOps-Aktivitäten ist die ständige Frage nach der Sicherheit.Natürlich werden sich einige dafür entscheiden, dieses Problem zu lösen, indem sie einen Chief Information Security Officer einstellen. Und das ist gut so, denn dann gibt es immer einen Ansprechpartner, dem man die Schuld geben kann, wenn etwas schief läuft. Eine bessere Option wäre es, im Rahmen von DevOps zu analysieren, wie einzelne Mitarbeiter, Arbeitsteams und Unternehmen als Ganzes über Sicherheit denken und wie sie verbessert werden kann.

In Kapitel 10 erfahren wir mehr darüber, aber bedenke: Sicherheitslücken, Bugs, SQL-Injections (Structured Query Language), Pufferüberläufe und vieles mehr sind nicht neu. Der Unterschied ist die zunehmende Geschwindigkeit, mit der sie auftauchen, ihre steigende Anzahl und die Cleverness, mit der böswillige Individuen und Entitäten agieren können. Das ist nicht überraschend. Je mehr Code veröffentlicht wird, desto mehr Probleme gibt es, und jede Art von Problemen erfordert andere Lösungen.

Mit immer schnelleren Einsätzen wird es immer wichtiger, auf Risiken und Bedrohungen zu reagieren. Die Entdeckung der Sicherheitslücken Meltdown und Spectre im Jahr 2018 hat deutlich gemacht, dass einige Bedrohungen unmöglich zu verhindern sind. Wir befinden uns in einem Wettlauf, und das Einzige, was wir tun können, ist, so schnell wie möglich Korrekturen vorzunehmen.

Wilde Dringlichkeit

Es sollte inzwischen klar sein, dass DevOps kein Plan ist, sondern eine Reaktion auf den evolutionären Druck. Es ist ein Mittel zum Zweck, das Folgendes bewirkt:

• Liefert bessere Qualität

• Bringt Einsparungen

• Schnellere Bereitstellung von Funktionen

• Stärkt die Sicherheit

Dabei spielt es keine Rolle, wer es mag oder nicht, wer die Idee zuerst hatte oder sogar die ursprüngliche Absicht. Worauf es ankommt, wird im nächsten Abschnitt behandelt.

Die Software-Industrie hat DevOps voll und ganz verinnerlicht

Bу jetzt ist jedes Unternehmen ein DevOps-Unternehmen.Also, komm an Bord... denn du hast keine andere Wahl.

Das DevOps von heute, zu dem sich DevOps entwickelt hat, ist, wie bereits erwähnt, eine Endlosschleife. Das bedeutet nicht, dass es keine Gruppen und Abteilungen mehr gibt. Es bedeutet auch nicht, dass jeder für seine Bereiche und die aller anderen in diesem Kontinuum verantwortlich ist.

Es bedeutet, dass alle zusammenarbeiten sollten. Es bedeutet, dass Softwareexperten in einem bestimmten Unternehmen die Arbeit ihrer Kolleginnen und Kollegen kennen und angemessen berücksichtigen müssen. Sie müssen sich um die Probleme kümmern, mit denen ihre Kollegen konfrontiert sind, und um die Frage, wie sich diese Probleme auf ihre Arbeit, die Produkte und Dienstleistungen ihres Unternehmens auswirken können und wie sich das alles auf den Ruf ihres Unternehmens auf dem Markt auswirkt.

Aus diesem Grund ist der Begriff DevOps Engineer unsinnig, denn er impliziert, dass es jemanden gibt, der alles, was in der DevOps-Endlosschleife passiert, umfassend und kompetent erledigen kann (oder sich zumindest damit auskennt). Eine solche Person gibt es nicht und wird es auch nie geben. Schon der Versuch, ein DevOps Engineer zu sein, ist ein Fehler, denn er läuft dem zuwider, was DevOps ausmacht: die Abschaffung von Silos, in denen Codeentwickler von QA-Testern abgeschottet sind, die wiederum von Release-Mitarbeitern abgeschottet sind und so weiter.

DevOps ist ein Zusammenkommen von Bemühungen, Interessen und Feedback, um Code zu erstellen, zu sichern, zu verteilen und zu perfektionieren. Bei DevOps geht es um Kollaboration. Und da Kollaboration ein organisches, kommunikatives Unterfangen ist, gibt es weder Collaboration Engineering noch DevOps Engineering (egal, was irgendein Institut oder eine Universität versprechen mag).

Es manifestieren

Wenn du weißt, was DevOps ist (und was nicht), ist das nur ein Konzept.Die Frage ist, wie es sinnvoll und effektiv in Softwareunternehmen in aller Welt umgesetzt und aufrechterhalten werden kann. Der beste Rat? Hier ist er.

Erstens kannst du DevOps-Enabler, DevOps-Evangelisten, DevOps-Berater und -Coaches haben (ich weiß, dass Scrum diese Begriffe für uns alle verdorben hat, aber es gibt keine besseren).Das ist in Ordnung. Aber DevOps ist keine Ingenieursdisziplin. Wir wollen Site/Service Reliability Engineers, Production Engineers, Infrastructure Engineers, QA Engineers usw. Aber wenn ein Unternehmen erst einmal einen DevOps Engineer hat, ist das nächste, was es fast garantiert hat, eine DevOps-Abteilung, die nur ein weiteres Silo sein wird, das wahrscheinlich nichts anderes ist als eine bestehende Abteilung, die umbenannt wurde, damit es so aussieht, als ob das Unternehmen auf dem DevOps-Zug mitfährt.

Ein DevOps-Büro ist kein Zeichen von Fortschritt. Vielmehr ist es einfach eine Rückkehr in die Zukunft. Als Nächstes brauchen wir einen Weg, um die Zusammenarbeit zwischen Dev und DevOps zu fördern, wofür ein neuer Begriff geprägt werden muss. Wie wäre es mit DevDevOps?

Zweitens geht es bei DevOps um Nuancen und Kleinigkeiten. Wie bei Kulturen (vor allem Unternehmenskulturen) geht es um Einstellungen und Beziehungen. Du kannst diese Kulturen vielleicht nicht klar definieren, aber sie existieren trotzdem. Bei DevOps geht es auch nicht um Code, technische Praktiken oder technische Fähigkeiten. Kein Tool, das du kaufen kannst, keine Schritt-für-Schritt-Anleitung und kein Brettspiel für zu Hause können dir helfen, DevOps in deinem Unternehmen einzuführen.

Es geht um Verhaltensweisen, die in Unternehmen gefördert und gepflegt werden. Dabei geht es vor allem darum, wie die Mitarbeiter behandelt werden, um die Struktur des Unternehmens und um die Titel, die sie tragen. Es geht darum, wie oft Menschen die Möglichkeit haben, zusammenzukommen (vor allem außerhalb von Meetings), wo sie sitzen und essen, über Geschäfte und Nicht-Geschäfte reden, Witze erzählen usw. In diesen Bereichen, nicht in Rechenzentren, bilden, wachsen und verändern sich Kulturen.

Schließlich sollten Unternehmen aktiv nach suchen und in T-förmige Personen investieren (Ж-förmig ist noch besser, wie meine russischsprachigen Leser vielleicht vermuten). Im Gegensatz zu I-förmigen Personen (die absolute Experten auf einem Gebiet sind) oder Generalisten (die zwar über vieles Bescheid wissen, aber kein bestimmtes Fachgebiet beherrschen) verfügt eine T-förmige Person über Weltklasse-Expertise in mindestens einer Sache. Das ist die lange vertikale Linie des "T", in der ihr Wissen und ihre Erfahrung fest verankert sind. Das "T" wird oben von der Breite der angesammelten Fähigkeiten, des Know-hows und der Weisheit in anderen Bereichen gekreuzt.

Das Gesamtpaket besteht aus einer Person, die eine klare und starke Neigung zeigt, sich an die Umstände anzupassen, neue Fähigkeiten zu erlernen und die Herausforderungen der heutigen Zeit zu meistern. Tatsächlich ist dies eine nahezu perfekte Definition eines idealen DevOps-Mitarbeiters. T-förmige Mitarbeiter ermöglichen es Unternehmen, effektiv an priorisierten Arbeitslasten zu arbeiten, anstatt nur an dem, was sie glauben, mit ihren internen Kapazitäten bewältigen zu können. T-Folks können das große Ganze sehen und sind daran interessiert. Das macht sie zu hervorragenden Kollaborateuren, was in der Folge zum Aufbau von leistungsfähigen Teams führt.

Wir alle haben die Nachricht bekommen

Die gute Nachricht ist, dass ein Jahrzehnt, nachdem Ops DevOps erfunden hat, sie vollständig verstanden haben, dass es nicht nur um sie geht, sondern um alle. Wir können den Wandel mit eigenen Augen sehen. Zum Beispiel hat der 2019 "Accelerate: State of DevOps"-Bericht haben mehr Entwickler/innen an der Studie teilgenommen als Ops- oder SRE-Mitarbeiter/innen! Um noch mehr Beweise dafür zu finden, dass sich die Dinge geändert haben, kehren wir zu Gene Kim zurück.Der Mann, der mit The Phoenix Project dazu beigetragen hat, das Ops-Ende der Gleichung neu zu definieren, hat 2019 auch The Unicorn Project (IT Revolution) veröffentlicht. Während in dem früheren Buch die Entwickler/innen zu kurz kamen, ist unsere Heldin hier Maxine, die Chefentwicklerin (und ultimative Retterin) ihres Unternehmens.

DevOps begann mit Ops, keine Frage. Aber die Motivation war weder die Unterwerfung von Entwicklern noch die Vorherrschaft von Fachleuten aus dem operativen Bereich. Es ging und geht darum, dass jeder jeden sieht und seinen Wert und seinen Beitrag zum Unternehmen schätzt - und zwar nicht einfach aus Respekt oder Höflichkeit, sondern aus persönlichem Eigeninteresse und aus geschäftlichem Überleben, Wettbewerbsfähigkeit und Wachstum.

Und wenn du Angst hast, dass DevOps dich in einem Meer von Ops-Konzepten überwältigt, ist es wahrscheinlich genau umgekehrt. Schau dir einfach die SRE-Definition von Google an (dem Unternehmen, das die Disziplin erfunden hat):

SRE ist das, was du bekommst, wenn du den Betrieb so behandelst, als wäre er ein Softwareproblem.

Die Betriebsleute wollen jetzt also Entwickler sein? Willkommen. Software-Probleme gehören immer zu allen Software-Fachleuten. Wir sind in der Problemlösungsbranche tätig - was bedeutet, dass jeder ein bisschen SRE, ein bisschen Entwickler und ein bisschen Betriebsmann ist... denn das ist alles dasselbe. Das sind alles miteinander verwobene Facetten, die es uns ermöglichen, Lösungen für die Software von heute und die individuellen und gesellschaftlichen Probleme von morgen zu entwickeln.