Um die DevOps-Bewegung kursieren viele Mythen. Das ist keine Überraschung, wenn man bedenkt, wie populär und auch inflationär der Begriff in den letzten Jahren geworden ist und dadurch auch nahezu bei jeder Gelegenheit verwendet wird. Daher möchten wir heute ein paar der kritischsten "Erzählungen" genauer unter die Lupe nehmen, damit Du weißt, worum es bei DevOps geht und wie man es richtig ein/umsetzt. In diesem Blogpost setzen wir uns damit auseinander.
Mythos 1: DevOps ist nur für Dev und Ops
Der Begriff begann zwar im ursprünglichen Sinne „nur“ mit Dev und Ops, allerdings war das dem Hintergrund geschuldet, dass zur dortigen Zeit die größten Probleme gesehen wurden. Die sogenannte Wall of Confusion hatte zur Entstehungszeit von DevOps den größten Effekt bei den beiden Fachrichtungen. Nichtsdestotrotz befinden wir uns in einer sich stetig wandelnden und umfangreicher werdenden Welt. Wo früher noch ein Entwickler für den gesamten Produktlebenszyklus zuständig war, braucht es heute dedizierte Experten für die jeweiligen Fachbereiche (Dev, Ops, QA, Sec, Agile, etc.). Diese steigende Komplexität erfordert eine außerordentliche Kommunikation, um weiterhin produktiv sichere und qualitativ hochwertige Software auszuliefern. Demnach wird schnell ersichtlich, dass DevOps nicht nur für zwei der mittlerweile unzähligen Bereiche angewendet werden darf. Ansonsten laufen wir Gefahr, eben das zu erzeugen, was wir mit DevOps eigentlich auflösen wollten: schlechte Kommunikation, Silos, eine „wir und die“ Mentalität, etc.
Im Kern der Problematik steht oftmals die Benamung des Prozesses. DevOps als Kofferwort impliziert, dass es sich nur um Dev und Ops handelt. Damit sind Mythen wie diese vorprogrammiert. Das ist einer der Gründe, warum wir den Begriff DevOps innerhalb der Novatec mehr und mehr zum “perfect Flow” migrieren wollen. Das hilft uns nicht zuletzt dabei, den ganzheitlichen Transformationsprozess für uns intern, sondern auch bei unseren Kunden zu etablieren und stetig zu verbessern.
Mythos 2: DevOps ist nur ein Tool
Der Markt rundum DevOps wächst stetig an. Das liegt nicht zuletzt daran, dass der Begriff in den vergangenen Jahren stark popularisiert wurde. Tools wie Azure DevOps versuchen gezielt auf die Bedürfnisse bei der Vollziehung einer DevOps Transformation einzugehen. Der Mittelpunkt von Azure DevOps ist hierbei tendenziell alle notwendigen einzelnen Tools, welche zur Entwicklung des gesamten Produktlebenszyklus notwendig sind, zentral an einem Ort nutzbar zu machen. Die häufige Annahme ist nun: “Wenn ich Azure DevOps nutze, mache ich DevOps”. Das ist leider nicht korrekt, da der Prozess hin zu einem DevOps organisierten Unternehmen wesentlich schwieriger und komplexer ist.
Azure DevOps ist zwar enorm hilfreich, deckt in dem Kontext allerdings nur einen Großteil der technischen Aspekte ab. Ebenso wichtig sind in diesem Rahmen die kulturellen Gegebenheiten, welche erfüllt sein müssen, um eine Transformation zu gewährleisten. Ohne eine Anpassung der firmeninternen Prozesse und Strukturen, um diese mit den neuen technischen Gegebenheiten zu matchen, werden diverse positive Chancen außer Acht gelassen. Innerhalb der Novatec betrachten wir DevOps unter den drei Säulen: Business, Kultur und Technik. Wird nun rein auf der Tool- bzw. technischen Ebene agiert, verlieren wir die Trinität und damit zwei Drittel der Thematik.
Mythos 3: DevOps Engineer
Das ewige Suchen nach der Eier legenden Wollmilchsau existiert natürlich auch im DevOps Kontext. Historisch betrachtet war der Grundansatz hinter dem DevOps Engineer ein guter Gedanke. Es galt eine neu entstandene Lücke rundum den Bereich der Automatisierung zu füllen. DevOps Engineers sind daher Entwickler, welche ihren Fokus auf die Automatisierung gesetzt haben oder Ops’ler welche einen stärken Fokus auf die Entwicklung legen. Durch die immer weiter wachsende Komplexität wächst daher auch das Aufgabenfeld eines DevOps Engineers.
Im Kern des Problems liegt daher auf der einen Seite der sehr aufgeblasene DevOps Begriff welcher in seiner Gesamtheit nicht vollends verstanden werden kann und auf der anderen Seite der Wunsch, die zuvor genannten Lücken so breit wie möglich zu befüllen. Die Problematik zieht sich damit leider auch in das Recruiting. Wie finde ich genau den einen DevOps Engineer, welchen ich spezifisch für bspw. Pipelines benötige?
Hilfreich sind hier Job Bezeichnungen wie “DevOps Engineer mit Fokus auf Pipelines”, um den Markt entsprechend einzugrenzen. Es gilt daher den überladenen Begriff sauber in Kategorien zu strukturieren, zu schneiden und damit Raum für eine genau Aufgabenbeschreibung zu sorgen.
Mythos 4: Ich kann ein DevOps-Team gründen und “betreibe” dann DevOps
Ähnlich wie der zuvor aufgeführte Mythos des DevOps Engineers verursacht die bloße Einführung eines DevOps Teams den Aufbau von Silos, welche wir ursprünglich reduzieren und verhindern wollten. Durch ein dediziertes DevOps Team grenzen wir die Vorteile rundum DevOps bewusst ab, kapseln sie in einem Team und sperren es, übertrieben gesprochen „weg“. Das trägt nicht nur dazu bei, dass wir die gewünschte Transparenz, Zusammenarbeit und den Wissensaustausch blockieren, sondern auch einen weiteren Riegel für die Kommunikation zwischen den einzelnen Teams schieben. Wo es zuvor ein Operationsteam und ein Entwicklungsteam gab, welche nicht ausreichend miteinander kommunizieren konnten, existieren nun drei Teams, welche das noch viel weniger können. Damit wurde nichts gewonnen außer einem Schein an DevOps.
Mythos 5: DevOps ist ein endlicher Prozess
DevOps bzw. die sogenannte “DevOps Transformation” ist ein sich stetig wandelnder, iterativer Prozess. Es wird immer die Chance für neue Verbesserungen und neue Ideen geben. Prozesse können weiter verschlankt, Silos weiter aufgebrochen und Kommunikationswege weiter verbessert werden. Einfacher vorzustellen geht es, indem wir DevOps als einen Güterzug betrachten, der zunächst betankt werden muss, seine Reise antritt, aber sein Ziel nie vollends erreicht. Der DevOps-Zug hat viele Zwischenhaltestellen, bei denen er seine Güter für die jeweiligen Orte abliefert, wo sie auf (hoffentlich) fruchtbaren Boden stoßen. An jeder Haltestelle muss der Zug neu betankt werden, damit er nicht auf halber Strecke zum Stopp kommt. Dieser fruchtbare Boden bedeutet oftmals schlicht eine Offenheit innerhalb eines Teams für neue Veränderungen zu besitzen.
Die weiterführende Betankung unseres DevOps-Zugs sorgt dafür, dass die Transformation den nötigen Rückhalt erhält. Das interessante und spannende an dieser Analogie ist, dass kein DevOps-Zug gleich aussieht oder gar ausschließlich die gleichen Routen fährt. Für jedes Unternehmen, welches DevOps etablieren möchte, sieht der Startpunkt sowie alle Zwischenstopps unterschiedlich aus. Jede Firma hat ihre persönlichen Eigenheiten und Probleme, welche es differenziert in einem sich immer weiter bewegenden Prozess zu lösen gilt. Vielmehr ist auch hier wieder der Weg das Ziel!
Mythos 6: Ich kann die gleichen Prozesse wie Amazon, Google, Netflix und Co. integrieren
Wie bereits unter dem “Mythos 5” begonnen, muss jede Firma ihren eigenen Weg finden. Es wäre wundervoll, wenn es nur diesen einen Prozess gäbe, an welchen man sich für die erfolgreiche Etablierung einer DevOps Transformation halten müsste. Das würde unseren Arbeitsalltag als DevOps Berater erheblich erleichtern. Doch leider ist dem nicht so. Einzigartige Strukturen, Prozesse, Probleme, Kommunikationswege, Firmenpolitiken, etc. sorgen dafür, dass jede Transformation neu gedacht, sorgfältig geplant und letztlich genau auf die Bedürfnisse zugeschnitten werden muss. Wo drückt der Schuh aktuell am meisten? Um beispielsweise das notwendige Management-Buyin sicherzustellen, macht es Sinn, den größten Schmerz zu lösen und zeitgleich den größten Mehrwert zu erzeugen. Durch solche Entscheidungen wird eine klare Richtung eingeschlagen, welche einzigartig für jede Firma ist.
Mythos 7: DevOps vs Agile
Sowohl DevOps als auch Agile sind Mindsets, welche für die Entwicklung von Software genutzt werden können. DevOps baut in vielerlei Hinsichten auf Konzepten von Agile auf und nutzt diese. Nichtsdestotrotz muss man nicht agil sein, um DevOps etablieren zu können. Selbstverständlich hilft es enorm und folgt dem natürlichen Flow der Prozesse. Allerdings muss es innerhalb einer Firma auch den Raum für die Anwendung von agilen Methodiken geben. In einigen Branchen ist es noch immer durch äußere Gegebenheiten nicht möglich, Arbeitspakete in einzelne Teile zu schneiden und diese in definierten Zyklen abzuarbeiten. Daher ist hier die Realität noch immer, dass die Wasserfallmethodik im Projektmanagement für eben solche Firmen ihre Daseinsberechtigung besitzt.
Dennoch raten wir dazu: Wenn es die äußeren Gegebenheiten zulassen, sollten Agile und DevOps gemeinsam genutzt werden. DevOps funktioniert besonders gut mit Agile, da die Grundprinzipien kleiner Teams, welche iterativ Software ausliefern, als Fundament genutzt werden kann, um DevOps nicht nur zum Beginn einer Transformation zu prototypisieren, sondern auch langfristig skalierbar auszurichten.
Fazit:
Wir hoffen, wir konnten ein wenig mit einigen der Mythen rundum DevOps aufräumen. Unser Anliegen ist, dass sich unsere Leser vor dem Beginn einer Transformation genau mit den möglichen Mythen vertraut machen und diese hoffentlich vollends vermeiden. Studien wie von DORA oder Puppet durchgeführt, zeigen deutlich, dass die oben genannten Stolpersteine nicht nur enorm zeitintensiv, sondern auch sehr teuer sind. Im schlimmsten Fall wird mit den aufgezeigten Fallgruben der Begriff vollends verbrannt, wodurch der DevOps-Zug leider zum längerfristigen oder gar finalen Stopp kommt.
Lass uns gerne wissen, über welche DevOps Mythen du bisher gestolpert bist.
In Zukunft werden hier übrigens noch weitere Blogbeiträge rundum DevOps Themen erscheinen. Also: Stay tuned!
Top comments (0)