In einer Welt, in der die Digitalisierung rasant fortschreitet, stellt sich die Frage: Wie können wir Softwarelösungen schneller und effizienter bereitstellen?
Cloud-Migrationen stehen oft im Mittelpunkt von Projekten, doch hinter diesen Entscheidungen steht eine tiefgreifende Vision. Diese Vision verbindet das Potenzial der Cloud-Technologie mit den Prinzipien von DevOps, um eine maximale Geschwindigkeit in der Entwicklung und Bereitstellung zu erreichen. In dieser Blogserie beleuchten wir, wie DevOps direkt die Entscheidungen und Prozesse einer Cloud-Migration beeinflusst und warum es entscheidend ist, diesen Ansatz zu verstehen und zu adaptieren.
Dies ist der erste Beitrag in unserer Reihe zum Thema DevOps. Freuen Sie sich auf weitere vertiefende Artikel in den kommenden Wochen.
Die Vision: Mit Warp 9,99 in die Zukunft
Heutzutage steht in vielen Projekten eine Cloud-Migration im Vordergrund. Werden allerdings Projektbeteiligte nach der Motivation dieser Cloud-Migration befragt, wird schnell klar, dass diese Entscheidung „irgendwo anders“ getroffen wurde. Diese Entscheidung hat allerdings eine fundamental wichtige Grundlage, die anhand dieser Blogserie herausgearbeitet wird.
Der Einfluss von DevOps, dessen Vision und Ziele unmittelbare Auswirkungen auf die Entscheidungen einer Cloud-Migration haben, soll hierbei im Fokus der Beschreibung liegen.
Eines der beliebtesten Planungstools ist nach wie vor die Tabellenkalkulation Excel von Microsoft oder deren Alternativen. Einer der Gründe, warum Excel – nicht nur ausschließlich in der Planung – sehr beliebt ist, ist die Schnelligkeit, mit der Fachbereiche selbständig Aspekte (d.h. Berechnungen, Auswertungen, Datenmanipulationen, etc.) vornehmen können.
Die Möglichkeit einer maximalen Umsetzungsgeschwindigkeit von vereinzelten Features in Excel diente einem Fachbereich noch vor einigen Jahren dazu, dieses als Vergleich zur Softwareentwicklung heranzuziehen. So lief eine Diskussion über Verzögerungen in der Entwicklung von Features für ein bestehendes System zwischen Fachbereich und Softwareentwicklung üblicherweise annähernd folgendermaßen ab:
Fachbereich: „Warum dauert die Umsetzung bei Ihnen in der Softwareentwicklung eigentlich immer so lange? In Excel erstellen wir uns ganz einfach ein neues Datenblatt und schon können wir arbeiten. Nun sitzen Sie hier und erzählen mir, dass ich das Feature XY erst in einigen Monaten in unserem System realisiert bekomme. Das verstehe ich nicht, bitte erklären sie mir dieses.“
Softwareentwicklung: „…“ (Erklärt häufig die umständlichen und komplexen Prozesse in der Entwicklung und die dadurch zustande kommenden Verzögerungen).
Zu Unrecht wird obige Excel-Analogie auch heute immer noch als das ultimative Unverständnis der Fachbereiche über die Prozesse in der Softwareentwicklung belächelt und als unrealistisch und utopisch abgestempelt. Dabei drückt diese Analogie im Kern ihrer Aussage eine fundamental-innovative Vision aus:
Einzelne Features oder Anforderungen unserer Auftraggeber, die an die zu realisierenden Systeme adressiert werden, müssen ebenso schnell und effizient in Produktion gebracht werden wie die Erstellung eines neuen Datenblatts in Excel – idealerweise gesteuert durch den Auftraggeber selbst und ohne dabei umständlichen (Freigabe-)Prozessen oder Downtimes (Zeitraum, in dem ein System nicht verfügbar ist) zu unterliegen.
Im Idealfall bedeutet dieses, dass jeder Commit in ein Versionskontrollsystem ein potenzielles Produktionsrelease ausmacht (dazu im Verlauf dieser Serie mehr). In einer weiteren Fassung dieser Vision befinden sich die Features zu einem definierten Zeitpunkt bereits in Produktion und können dort einfach von den Fachverantwortlichen selbst zu einem Stichtag (oder Zeitpunkt) freigeschaltet werden.
Die inhaltlichen Aspekte dieser Vision werden im Verlauf dieser Blogserie ausführlich dargestellt. Ihre Verwirklichung setzt jedoch eine fundamental andere Sichtweise auf den Gesamtprozess der Softwareentwicklung voraus – insbesondere und gerade unter dem Aspekt der Überwindung eines klassischen Konfliktes zwischen Softwareentwicklung und Betrieb, aus dem einige Erkenntnisse für die Ausgestaltung der Vision gewonnen werden können.
Das Kofferwort DevOps als Resultat eines klassischen Konflikts
In klassischen, hierarchisch aufgebauten Unternehmensstrukturen existiert auch heute noch eine siloartige Trennung von Funktions- und Verantwortungsbereichen, die auf das sog. Taylorismus-Prinzip zurückzuführen sind. Durch das von F. W. Taylor entwickelte Prinzip einer Prozesssteuerung von Arbeitseisabläufen begründet sich u.a. auch die Auftrennung dieser in hierarchisch organisierte, getrennte Bereiche:
Abbildung 1: Hierarchisch organisierte Unternehmensstruktur (Ausschnitt)
In Abbildung 1 ist die funktionale Trennung zwischen Einkauf, Marketing & Vertrieb, IT, Produktion sowie Person & Verwaltung exemplarisch dargestellt. Eine explizite Gefahr, die sich durch solch eine Organisationsform ergibt, ist, dass einzelne Funktionsbereiche abgegrenzt oder herauslöst werden. Ein extremes Beispiel wäre die Auslagerung der gesamten IT in eine externe Firma aufgrund der Ansicht, dass IT ein „notwendige Übel“ eines Unternehmens sei. Dabei durchdringt doch gerade die IT heutzutage sämtliche Prozesse und Arbeitsabläufe eines Unternehmens, was unter einer alternativen Betrachtung, ein solches Unternehmen zu einem IT-Unternehmen macht (dazu jedoch später mehr).
Eine weitere, beispielhafte Unterteilung der IT in hierarchisch organisierte Funktionsbereiche ist in Abbildung 2 illustriert:
Abbildung 2: Hierarchisch, in Funktionsbereiche untergliederte IT
Analog zu der oben angesprochenen Gefahr der Abgrenzung und Isolierung der IT in einem Unternehmen, resultiert aus der Abgrenzung von Entwicklung (Development, DEV) und Betrieb (Operations, OPS) – häufig auch als „Wall of Confusion“ bezeichnet – ein sich über Jahrzehnte ausgeprägter Konflikt, dessen Dimensionen sich in unterschiedlich starken Ausprägungen gegenüberstehen und manifestieren.
Im Folgenden sind fünf dieser konträren Dimensionen erläutert:
Ziele und Prioritäten:
Die Ziele der Softwareentwicklung liegen primär auf der Umsetzung von Anforderungen der Auftraggeber. Dabei ist die Softwareentwicklung ein an sich kreativer Prozess: Neue Features werden idealerweise mit einem Fokus auf die Einführung oder Nutzung bzw. auch Erfüllung von innovativen Ansätzen/Sprachen/Frameworks etc. realisiert. Diese Erfüllung erfolgt im Rahmen von Iterationen, in denen die Inkremente in den Systemen erzeugt/umgesetzt werden. Im Vergleich zu der Verwirklichung von oben genannten Zielen, sind Betriebsteams dafür verantwortlich, dass die bestehenden Systeme stabil, zuverlässig und sicher sind. Ihr Fokus liegt daher eher auf der Stabilität und Verfügbarkeit der umgesetzten Features in der Anwendung.
Geschwindigkeit und Stabilität
Allzu häufig stehen Softwareentwicklungsteams unter enormem Druck die Anforderungen schnell umzusetzen und auszuliefern. Dabei müssen neue Features, Updates oder Bugfixes so schnell wie möglich bereitgestellt werden. Betriebsteams hingegen bevorzugen eine langsamere, vorsichtigere Herangehensweise, um das Risiko von Ausfällen oder Problemen zu minimieren und somit die Stabilität aufrecht zu erhalten oder zu erhöhen.
Tools und Technologien
Auf der einen Seite werden in der Softwareentwicklung häufig die neuesten Tools und Technologien verwendet, während auf der anderen Seite Betriebsteams möglicherweise ältere, bewährte Technologien bevorzugen, um die Stabilität und Sicherheit des Gesamtsystems zu gewährleisten.
Verantwortung und Eigentum
Zum einen können sich Softwareentwicklungsteams für den Code, den sie erzeugen, verantwortlich fühlen, während Betriebsteams sich zum anderen für das gesamte System verantwortlich fühlen und Eigentumsrechte ausdrücken.
Kommunikation und Zusammenarbeit
Sowohl die Softwareentwicklungsteams als auch die Betriebsteam arbeiten in ihren jeweiligen Silos (siehe Abbildung 2). Informationen werden daher nicht immer effektiv weitergegeben.
Um die einleitend erwähnte Vision zu erfüllen, d.h. die Bewerkstelligung der Auslieferung umgesetzter Anforderungen mit maximaler Geschwindigkeit, müssen diese Konflikte überwunden werden. Der erste Ansatz zur Überwindung ist die Entwicklung und Umsetzung eines Zusammenarbeitsmodells zwischen Entwicklung und Betrieb.
Die beiden Namensbestandteile (dev und ops) aus der englischen Übersetzung dieser beiden Verantwortungsbereiche- development und operations – werden dabei zu einem Schachtelwort verbunden: DevOps.
Die Etablierung und Förderung einer DevOps-Kulutur in einem Unternehmen, die insbesondere auf den Dimensionen Verantwortung, Eigentum, Kommunikation und Zusammenarbeit basiert, steht bei der Einführung der zugrundeliegenden Kultur zunächst im Vordergrund, welches im späteren Verlauf dieser Blog-Serie wieder aufgegriffen wird.
Diese Kultur wiederum führt zu einem gemeinsamen Verständnis über die anderen konfliktären Aspekte, die gemeinsam angegangen und gelöst werden müssen. Technologische Entscheidungen und Ausprägungen spielen hierbei eine fundamentale Rolle, um insbesondere die Konflikte der Dimensionen „Geschwindigkeit und Stabilität“ sowie „Tools und Technologien“ aufzulösen. Bei der weiteren Betrachtung der Möglichkeiten den Konflikt auf diesen Dimensionen optimal zu lösen, muss auf die drei wesentlichen Flüsse, aus denen sich sämtliche, weitergehende Konzepte ableiten lassen, eingegangen werden.
Die drei Flüsse bzw. Wege (Flows)
Die im Folgenden zusammengefassten Flüsse sind durch Gene Kim sowie im DevOps-Handbuch ausführlich erläutert.
Der erste Weg ermöglicht einen möglichst schnellen Fluss der Arbeit von links nach rechts (siehe Abbildung 3):
Abbildung 3: Der Fluss von Dev nach Ops
Bei diesem Weg liegt die explizite Betonung auf der Leistung des Gesamtsystems und nicht auf der Arbeit von einzelnen Silos (Abteilung oder einzelner Mitarbeiter). Sämtliche geschäftlichen Wertströme, die durch die IT ermöglicht werden, werden hier aufgenommen – angefangen bei den Anforderungen bis hin zu der Auslieferung. Diese Auslieferung stellt somit für den Kunden einen Wert in Form einer Dienstleistung dar.
Exkurs: Durchlaufzeit
Gene Kim et. al. unterscheiden explizit die Durchlaufzeit von der Verarbeitungszeit. Während die Durchlaufzeit bei der Anlage oder durch das Stellen einer Anforderung beginnt und mit der finalen Auslieferung abgeschlossen ist, stellt die Verarbeitungszeit die Zeitspanne vom tatsächlichen Beginn der Arbeit an dem entsprechenden Ticket im Backlog dar (siehe Abbildung 4).
Abbildung 4: Verarbeitungs- und Durchlaufzeit
Insbesondere geht es im ersten Fluss darum, die Durchlaufzeit einer Anforderung durch das Gesamtsystem zu optimieren.
Im zweiten Fluss werden Feedback-Schleifen schnell und kontinuierlich gewonnen. Dieser Feedback-Fluss wird über den gesamten, ersten Weg etabliert (siehe Abbildung 5).
Abbildung 5: Feedback-Schleifen
Im Rahmen des zweiten Weges liegt der Fokus darauf, diese Feedback-Schleifen kontinuierlich zu korrigieren und zu verbessern, d.h. ihre Dauer zu verkürzen und Wissen dort zu verankern, wo es benötigt wird.
Der dritte Fluss beschäftigt sich mit der Schaffung einer Kultur des Experimentierens und Eingehens von Risiken. Ziel dieses Weges ist es, eine Lernkultur zu schaffen, die aus den resultierenden Fehlern lernt, Schritte wiederholt und übt, um das Entstehen einer vertrauensvollen Kultur zu fördern (siehe Abbildung 6).
Abbildung 6: Schaffung einer Experimentier- und Lernkultur
Gerade die Bereitstellung von Zeit für Verbesserungen, oder das Schaffen von (Belohnungs-)Ritualen, die aus dem Eingehen von Risiken resultieren können, helfen dabei, die Widerstandsfähigkeit der Kultur vor negativen Einflussfaktoren zu erhöhen.
Und Cloudnative?
DevOps stellt gerade im Kontext von Cloudnative eine von vier Säulen dar (siehe Abbildung 7). Diese sind: DevOps, Microservices, Container und Continuous Delivery.
Abbildung 7: Die vier Säulen von Cloudnative
Diese vier als Säulen von Cloudnative dargestellten Grundprinzipien üben jede für sich genommen einen erheblichen Einfluss auf die Geschwindigkeit, wie umgesetzte Anforderungen produktiv gestellt werden können aus und haben somit jeweils eine massive Auswirkung auf die Realisierung der einleitend genannten Vision.
In weiteren Verlauf dieser Blog-Serie wird auf die einzelnen Säulen und die Rahmenbedingungen hierzu vertieft eingegangen.
