DevOps (eBook)
459 Seiten
Rheinwerk Computing (Verlag)
978-3-8362-9101-9 (ISBN)
DevOps bedeutet nicht, dass Entwickler und Admins nun die gleichen Jobs erledigen. DevOps bedeutet auch nicht, dass man beim Programmieren tägliche neue Tools einsetzen muss, es keine geplanten Deployments mehr gibt und Software nur noch in Containern läuft. DevOps ist viel größer: Es verspricht eine neue Kultur der Zusammenarbeit sowie bessere Prozesse und Workflows. So liefern Sie Änderungen schneller aus und sorgen für kürzere Feedback-Schleifen zwischen Usern, Operations und Developern.
In zahlreichen Projekten hat Sujeevan Vijayakumaran gelernt, was in der Entwicklung und im Betrieb moderner Software gut funktioniert. Mit vielen Beispielen und Praxistipps zeigt er Ihnen, wie Sie eine moderne und zeitgemäße Arbeitsumgebung für Ihre IT-Projekte schaffen und die DevOps-Transformation in Ihrem Team gelingt.
Aus dem Inhalt:
- Effizientes Zusammenarbeiten beim Programmieren
- Schlanke Build-Prozesse
- Frühe, schnelle und automatisierte Qualitätssicherung
- Schnellere Releases erstellen und deployen
- Den Dienst betreiben und überwachen
- Sicherheit und Compliance unter einen Hut bringen
- Continuous Integration: Tools richtig einsetzen
- Continuous Delivery praktisch umsetzen
- Monitoring und Observability für mehr Durchsicht
- Mit DevOps-Plattformen die Toollandschaft vereinfachen
- Jenseits von Kultur und Tools
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...
Erscheint lt. Verlag | 5.3.2024 |
---|---|
Sprache | deutsch |
Themenwelt | Mathematik / Informatik ► Informatik ► Netzwerke |
Mathematik / Informatik ► Informatik ► Software Entwicklung | |
ISBN-10 | 3-8362-9101-0 / 3836291010 |
ISBN-13 | 978-3-8362-9101-9 / 9783836291019 |
Haben Sie eine Frage zum Produkt? |
Größe: 7,5 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich