Der Kern von DevOps besteht darin, die Trennung zwischen zwei Silos abzuschaffen:
Warum will man diese Trennung aufheben? Es geht um kürzere Vorlaufzeiten (von der Idee bis zum Produktivbetrieb) und insbesondere häufigere Releases. Also Dinge, die uns bei SoftwareLiefern.de sehr am Herzen liegen.
Traditionell gibt es einige Gründe, warum man einen gesonderten Bereich für den Betrieb der IT hat: Wenn ein Projekt “fertig” entwickelt ist, ziehen die Software-Leute zum nächsten Projekt weiter, und überlassen alles Weitere dem “Betrieb”. Spezialisierte Leute (Administratoren) kümmern sich dann um Themen wie neue Server einrichten, auf Lastspitzen reagieren, Sicherheit, Monitoring usw. Ungefähr so, wie die Bauleute weiterziehen und das fertige Gebäude den Hausmeistern bzw. dem Facility Management überlassen wird. Und genauso wie im Bauwesen ist es verlockend, mindestens eines von beiden per Outsourcing zu machen.
Wie es so geht zwischen zwei Silos: jedes optimiert seinen eigenen Bereich, ggf. auch auf Kosten das Nachbarsilos. Dabei könnte alles viel besser sein, wenn man eng zusammenarbeiten würde. Nehmen Sie z.B. ein System, das alle 4 Stunden so langsam wird, dass nur noch ein Neustart hilft. Könnte man nicht lieber den Ursachen für die Verlangsamung auf den Grund gehen und das Problem ein für alle Mal beheben? Schade nur, dass das Softwareteam längst weitergezogen ist. Es gibt auch kein sinnvolles Logging, das uns verraten könnte, warum es jetzt langsam wird (statt dessen Megabyte-weise nutzlose Information). Wir bekommen auch keine Entwicklungs-Kapazität mehr, um daran etwas zu ändern. Also bleibt es beim Neustart alle vier Stunden.
Umgekehrt haben die Softwareentwickler auch Wünsche an “den Betrieb”. So hätten sie sehr gern die Möglichkeit, schnell eine Testumgebung mit realistischen Daten aufzusetzen. Oder einen Teil des realen Webshop-Traffics auf ihre Testinstanz zu spiegeln. Oder eine Änderung schnell in Produktion zu geben, ohne auf ein Wartungsfenster Rücksicht zu nehmen.
Was passiert nun, wenn man beide Seiten, Dev und Ops, in ein DevOps-Team setzt? Beziehungsweise die Rollen Entwicklung und Betrieb gleich ganz verschmilzt? Natürlich bekommt man eine schnellere Zykluszeit und geringere Fehlerquote, weil die Reibungsverluste und Übergaben zwischen den Silos entfallen. Das Streben nach immer schnelleren Lieferzyklen hat noch weitere Auswirkungen:
Betrieb wird mehr wie Software-Entwicklung. Das Aufsetzen von Servern und anderer Infrastruktur wird automatisiert. Statt Dutzender manueller Schritte haben wir Skripte und Konfigurationen, die genauso wie der übrige Code verwaltet werden (“Infrastructure as Code”). Das Aufsetzen eines Servers wird damit 100% reproduzierbar, auditierbar usw. Wir wissen also jetzt genau, wer den Port 8080 auf dem Server aufgemacht hat, sowie wann und warum das geschah. Wir sehen, warum der Zeichensatz des Datenbankservers auf UTF8 gesetzt wurde, und wir können jetzt garantieren, dass das in Zukunft auf allen Datenbankservern genau so konfiguriert wird.
Softwareentwicklung übernimmt mehr Aufgaben des Betriebs. Möglichst reibungsloser Betrieb wird eine weitere Dimension der Anforderungen, so wie Performance oder Usability. Feedback aus dem Betrieb wirkt direkt in die Entwicklung hinein: Ein Softwareentwickler, der mitten in der Nacht von einem Server-Ausfall geweckt wird, hat ganz andere Anreize, solche Probleme in Zukunft zu vermeiden. Wer nicht nur für Features, sondern auch für die Performance des Systems zuständig ist, wird sinnvolles Logging einbauen und sich um realistische Lasttests bemühen.
Wenn Sie so wollen, ist DevOps gesunder Menschenverstand: es gibt Probleme, die aus der Trennung in die Silos Dev und Ops erwachsen, also legen wir sie zusammen.
Ist das nicht ineffizient? Mag sein, dass spezialisierte Abteilungen etwas effizienter wären, aber sie wären nicht in der Lage, so schnelle Lieferzyklen zu unterstützen, wie sie heutzutage gebraucht werden. Außerdem hat DevOps das Potenzial, den Aufwand für “Operations” im Laufe der Zeit immer weiter zu verringern.
Wie viele gute Konzepte wird auch DevOps zum Schlagwort. Alles, was die IT irgendwie schneller oder effektiver macht, bekommt das Etikett “DevOps”. Jede/r der/die schneller werden will, bekommt gesagt: Du brauchst DevOps. Und ja, es geht auch um einen Kulturwandel, wenn man DevOps erfolgreich einführen will. Wenn man nicht aufpasst, verdrängen Werkzeuge (Chef, Docker, Kubernetes) und Jargon das eigentliche Verständnis des Konzepts.
Wir hoffen, dass wir hier zumindest etwas Klarheit schaffen konnten. Falls Sie noch Fragen haben – antworten Sie einfach auf diese Email.
Matthias Berth