DevOps ist eine Sammlung von Methodiken und Werkzeugen, aber auch eine Kultur, eine Philosophie, eine Denkweise. Der Begriff ist eine Art Kofferwort, das sich aus Development (Entwicklung) und Operations (Betrieb) zusammensetzt.
Der Begriff wurde 2009 von dem belgischen IT-Berater Patrick Debois geprägt. Im gleichen Jahr organisierte er die erste DevOps-Konferenz, die devopsdays in Ghent, Belgien. DevOps ist kein geschützter Begriff und es existiert keine formale Definition. Dementsprechend gibt es eine Vielzahl an Meinungen darüber, was DevOps ist und was nicht.
Der Versuch einer Definition
DevOps bedeutet für mich eine enge Zusammenarbeit zwischen Entwicklung und Betrieb. DevOps bedeutet, Silodenken zu überwinden und einen kontinuierlichen Austausch zwischen Entwicklung und Betrieb zu etablieren. Statt „E-Mail-Ping-Pong“ und „Tickets schubsen“ (oder „über den Zaun werfen“) findet ein direkter Austausch statt. Entwicklung und Betrieb können dabei durchaus in verschiedenen Teams liegen, die dann sehr eng zusammenarbeiten, sich regelmäßig zu gemeinsamen Statusmeetings zusammenfinden und bei Problemen pragmatisch und spontan, gerne auch mal im Pair-Programming, zusammenarbeiten. Entwicklung und Betrieb können aber auch von einem crossfunktionalen Team gestemmt werden, in dem Kompetenzen aus beiden Feldern vorhanden sind, ggf. sogar in Form von Generalisten, die sowohl Entwicklungs- als auch Betriebserfahrung mitbringen.
Für DevOps spielt das Mindset (Mentalität, Denkweise) eine entscheidende Rolle. Ein gutes DevOps-Team ist im permanenten Austausch miteinander, vertraut einander, kann sich auf die anderen Teammitglieder verlassen, übernimmt Verantwortung und hat eine hohe psychologische Sicherheit in der Zusammenarbeit. DevOps ist mit anderen agilen Praktiken wie Kanban komplementär.
Ziele von DevOps
DevOps adressiert die immer schneller werdenden Entwicklungen unserer Welt. Mehrjährige Entwicklungszyklen sind in vielen Bereichen nicht mehr denkbar. Wer ein ganzes Jahr im Voraus plant und von dieser Planung nicht abweichen kann, hat oftmals schon verloren. Der DevOps-Ansatz soll Unternehmen dabei helfen, auch zukünftig in der Digitalisierung wettbewerbsfähig zu bleiben. DevOps verkürzt die time-to-market (TTM) und ermöglicht durch die enge Zusammenarbeit eine höhere Geschwindigkeit. Reibungsverluste werden minimiert und auf Veränderung kann schneller (flexibler) reagiert werden.
Automatisierung und kurze Releasezyklen haben in DevOps einen hohen Stellenwert und ermöglichen eine gute Qualität und Stabilität, was wiederum positiven Einfluss auf die Kundenzufriedenheit hat.
Praktiken und Werkzeuge
In diesem Abschnitt gehe ich in Kurzform auf einige Konzepte und Werkzeuge ein, die ich im DevOps-Umfeld sinnvoll finde. Die Liste kann als Ausschnitt verstanden werden und hat keinen Anspruch auf Repräsentanz.
CI/CD-Pipeline
Eine CI/CD-Pipeline (Continuous Integration/Continuous Deployment) kann sich extrem positiv auf die Qualität und den Zeitaufwand für ein neues Release auswirken. In der Pipeline, die nach jeder Code-Änderung im Versionskontrollsystem anlaufen sollte, können automatisierte Tests, Werkzeuge zur statischen Codeanalyse, zur Analyse von Sicherheitslücken, zur Messung der Testabdeckung (Code Coverage) und weitere Werkzeuge zur Qualitätsprüfung angewandt werden, um den Entwicklern ein schnelles Feedback zu geben, ob die Software den Qualitätsansprüchen genügt oder nicht. Die Software kann über die Pipeline neu gebaut, automatisch versioniert und auf einem Testsystem oder sogar in Produktion deployed werden.
Infrastructure as Code (IaC)
Der IaC-Ansatz funktioniert hervorragend in der Cloud (AWS, GCP, Azure…) und ermöglicht eine Reproduzierbarkeit der gesamten Infrastruktur, indem diese in Form von Code deklariert und im Versionskontrollsystem verwaltet wird. Ein populäres Werkzeug dazu ist HashiCorp Terraform. Die oben genannten großen Cloud-Anbieter ermöglichen es über Terraform und auch eigene Frameworks, das gesamte Netzwerk, Berechtigungen, Datenbanken, Containerplattformen und alles weitere per IaC zu verwalten. Andere Werkzeuge wie Ansible ermöglichen es zumindest, Softwarestände auf einem Server konfigurativ zu verwalten.
Infrastructure as Code über ein Versionskontrollsystem impliziert ein Auditing sämtlicher Infrastrukturänderungen. Kombiniert mit einer CI/CD-Pipeline können alle Änderungen sofort eingespielt und frühere Stände wiederhergestellt werden. Der Code ist damit gleichzeitig die Dokumentation der Infrastruktur.
Microservices, Container, Function as a Service
Zwar funktioniert DevOps auch mit monolithischer Software, in vielen größeren agil organisierten Softwareprojekten werden aber heutzutage Microservices eingesetzt. Dabei können viele Teams unabhängig voneinander entwickeln. Statt einer engen Abstimmung bei übergreifenden Refactorings und einem hohen Organisationsaufwand für Deployments, können die Spielregeln für die Interaktion zwischen den Services über definierte APIs (Application Programming Interface) festgelegt werden.
Anstatt wie früher z.B. WAR-Dateien (Web Application Resource) in einem Web Application Server zu deployen oder für jede Software eine virtuelle Maschine hochzufahren, hat sich die Containerisierung, z.B. mit Docker, im Microservice-Umfeld etabliert. Eine Container-Orchestrierungsplattform wie Kubernetes kann dabei die darunter liegenden Server abstrahieren, die Komplexität reduzieren und ein schnelles Ausprobieren verschiedenster Software, die als Docker-Image vorliegt, ermöglichen. Wird eine solche Plattform als Service bereitgestellt, spricht man von Plattform as a Service (PaaS).
Eine weiterer Abstraktionsebene ist Function as a Service (FaaS), z.B. in Form von AWS Lambda oder den GCP Cloud Functions. Hierbei werden nicht nur die Hardware- und Betriebssystemschicht abstrahiert, es gibt auch eine Plattform, auf der dauerhaft Services laufen. Funktionen sind an eine Laufzeitumgebung, z.B. Java/JVM oder Python gebunden, werden durch einen Auslöser wie etwa eine bestimmte Uhrzeit aufgerufen und sind in ihrer Dauer und ihrem Speicherbedarf begrenzt. Der theoretische Vorteil hierbei ist, dass Entwickler sich ganz auf den Code konzentrieren können und keine weiteren Faktoren mehr berücksichtigt werden müssen.
Für im DevOps-Umfeld populäre Cloud-Native Apps wurde die Methodik der Twelve-Factor App erfunden.
Kontiniuität und Komplexität
Continuous Integration, Continuous Testing, Continuous Deployment/Delivery, Continous Feedback, Continuous Improvement, Continuous Refactoring – Kontinuität hat eine große Bedeutung für DevOps, denn nur wer kontinuierlich am Ball ist und ein Bild der aktuellen Lage hat, kann schnell reagieren, umsteuern, die Richtung ändern.
Die heutige Softwareentwicklung ist komplex. Komplizierte Projekte benötigen keine Agilität. Sie sind im Voraus planbar und können nach diesem Plan abgearbeitet werden. Modernen Softwareprojekte sind dies in der Regel nicht. Sie müssen neue oder geänderte Kundenanforderungen und Entwicklungen im Markt kurzfristig berücksichtigen. Ein wichtiges Instrument in der Kontinuität sind meines Erachtens Experimente und das schnelle Scheitern (fail fast). Mit Experimenten wird erarbeitet, ob eine Änderung eine Verbesserung bewirkt. Das können Änderungen in der Architektur der Software sein, in der Teamorganisation und -zusammenarbeit, oder auch in der UX (User Experience) des Produktes. Das Scheitern muss als normaler Teil des Entwicklungsprozesses betrachtet werden und nicht als Versagen. Durch Scheitern erarbeitet man, ob etwas funktioniert oder nicht. Wichtig ist, dass diese Erkenntnis so früh wie möglich kommt, und nicht erst nach langer Entwicklungszeit. Wie man an komplexe Probleme grundsätzlich herangehen kann, habe ich in meinem Beitrag zum Cynefin-Framework beschrieben.
Die Entwicklung im DevOps-Umfeld sehe ich als Zyklus mit sehr kleinen Iterationen:
- Eine Software-Inkrement wird geplant
- Das Software-Inkrement wird gebaut
- Das Software-Inkrement wird deployed
- Das Software-Inkrement wird betrieben und bewertet
Die Bewertung einer Änderung kann über Metriken erfolgen. Zum Beispiel kann gemessen werden, wie sich eine andere Farbe für den „Warenkorb“-Button auf das Kaufverhalten auswirkt. Über Metriken können aber auch andere wichtige Parameter wie die Verfügbarkeit der Software oder die Performance gemessen werden.
You Build It, You Run It
Auch wenn DevOps nicht vorgibt, dass Entwicklung und Betrieb durch die gleichen Leute geleistet werden, handelt es sich dennoch um eine weitverbreitete Umsetzung von DevOps. Werner Vogels, CTO bei Amazon, hat dies in einem Interview mit dem Satz „You build it, you run it“ auf den Punkt gebracht. Vogels sieht den direkten Kontakt mit Endanwendern und Erfahrungen im täglichen Betrieb für Entwickler als essenziell, um hochqualitative Produkte zu entwickeln.
DevSecOps
DevSecOps ist eine Erweiterung des DevOps-Begriffes, um dem Aspekt Sicherheit (Security) mehr Bedeutung beizumessen. Grundsätzlich könnte man den Begriff DevOps um viele weitere Teile erweitern, da auch das Business und andere Gewerke ihren Part in der DevOps-Philosophie haben.
- Interview mit Werner Vogels (Amazon CTO, 2006)