Software Engineering

Bastel Brothers oder der Weg vom Best Practice zum DevOps

Michael Krebs
Michael Krebs

In Sachen Handwerk stehe ich mit meinem Know-How generell auf einer Stufe mit den Bastel Brothers. Wer diese nicht kennt, hier ein kleines Video.

In letzter Zeit kann oft folgendes beobachtet werden: je mehr in der IT über DevOps, Containerplattformen und agiler Kultur gesprochen wird, desto seltener können Entwicklerteams bei neuen Projekten auf Best Practices setzen und mutieren vielmehr in Richtung IT-Bastel-Brothers.

Gewagte These, denn eigentlich sollte alles einfacher, besser und schneller werden. Auch im Kontext digitale Kultur wird immer öfter der „Cost of Delay“ angeführt und neue Geschäftsmodelle gelten nur dann als erfolgreich, wenn in kurzen Zyklen und mit schnellen, den Kundenanforderungen angepassten Releasezyklen gearbeitet wird.

Application Engineering in Zeiten von DevOps – Mehr fertiger Bausatz oder Bastelheft?

Zu beobachten ist im Kern folgendes:

Durch die Einführung von Containern oder Containerplattformen grenzt man Operations und Development durch die klaren Verantwortlichkeiten strikt voneinander ab. Durch CI & CD Toolchains wird der Weg vom Service oder Produkt hin zur Plattform klar definiert.

Trotzdem muss der „einfache“ Developer in der Lage sein, die gesamte Toolkette zu beherrschen. Noch dazu gibt man den Teams die Freiheit, innerhalb der Services die Werkzeuge, Sprachen oder Toolsets zu nutzen, mit denen das Team am besten die Anforderungen umsetzen kann oder das umfangreichste Know-how mitbringt. So die Theorie. In der Praxis zeigt sich aber, dass gerade in der oft propagierten Automatisierung im CI aber auch im CD Umfeld teilweise jede Menge Zeit mit „Basteln“ vergeht, bis das Team wirklich an Geschwindigkeit gewinnt und sich auf den Kern – nämlich das „dev(elopment)“ fokussieren kann.

Standardisierte Dev-Plattformen vs. „Container Infrastruktur“

Betrachten wir das Problem eine Stufe tiefer: Container Plattform ist nämlich ein breiter Begriff und ein Kubernetes Cluster allein mag zwar die „Infrastruktur-Dudes“ begeistern, die Developer Teams sind aber noch weit weg von der wirklichen Automatisierung. Denn durch Container und eine Vielzahl von Trends im Bereich der Development Werkzeuge, neuer Sprachen und Tools zum Monitoring, wird die Welt des Developers nicht einfacher, sondern eher immer unüberschaubarer. Da reicht auch nicht mehr der Schraubenzieher als Universalwerkzeug. Heute soll es dann schon der große Hilti-Koffer sein, auch wenn der zu montierende Schrank am Ende auch nicht anders aussieht, respektive für den Endwender der Fortschritt erstmal nur bedingt zu greifen ist.

Ach ja, der Anwender – den haben wir ja noch gar nicht berücksichtigt: Was bringen uns im Projekt agile Methoden und Deployments mehrmals täglich auf Knopfdruck, wenn der Kern des Unternehmens noch fernab von digital lebt und mit agilen Methoden so überfordert ist, wie ich auf der Webseite vom Baumarkt?

Meine Empfehlungen: Die agile Lernkurve

Erfahrungen aus vielen Kundengesprächen zeigen, dass es natürlich wie immer kein Schwarz oder Weiß gibt, sondern die Entwicklungsstufen von Unternehmen sich auf den „Stairways“ Innovation, Digitale Kultur und Application Engineering immer in einem Mix verschiedener Reifegrade bewegen. Folgende Regeln und Empfehlungen sind aber gute Anhaltspunkte, um sowohl Business als auch IT mit den nötigen Basiswerkzeugen auszustatten und eine stabile Lernkurve sicherzustellen.

1) Train your business  – Digitale Kultur und Innovation

Da das Business oft bei der Einführung agiler Methoden vergessen wird oder nur durch einzelne Köpfe wie den Product Owner nah am agilen Prozess ist, sollten agile Methoden aber auch Innovations-Entwicklung verankert werden. Eine detaillierte Beschreibung der Methoden und Vorgehen würde an dieser Stelle zu weit führen, mehr dazu aber auch hier:

Innovation 

2) Train your developers: Development Labs

Die Einführung von DevOps Prozessen, Cloud- oder Container Development Plattformen und zusätzlich neuer Sprachen/Frameworks,  wie Angular oder Spring stellt Teams oft vor große Anfangshürden. Um schnell zum Erfolg zu kommen, bieten sich Coachings im Rahmen gemeinsamer Labs an. Hier werden die Teams durch erfahrene Experten im Rahmen von Pair-Programming – Extreme Programming oder Shadowing Konzepten unterstützt und erzielen somit schnelle Erfolge. Meist ziehen sich solche „Labs“ über 1 bis 2 Sprints, in denen nach festen Regeln und Zeiten zusammen und in einem extra dafür ausgelegten Arbeitsbereich eine enge Zusammenarbeit und effektives Coaching möglich ist.

Durch die klaren Regeln der Labs wird nicht nur technisches Know-how aufgebaut, sondern durch eine hohe Lernkurve die Begeisterung der Development Teams geweckt.

Spoiler: Mit einem neuen Gebäudebereich setzt esentri diese Labs-Philosophie für interne Projekte aber auch für Kunden-spezifische Labs ab Sommer um. Stay tuned!

Links:
Pair Programming
Labs Process am Beispiel Pivotal & Extreme Programming

3) Provide the right dev plattform not only a container cluster

Docker, Kubernetes und viele Plattformen, die diese „quasi-Standards“ unterstützen, sind heute bereits in vielen IT-Plattformen „Best Practice“. Doch der Weg von der Container Plattform bis zur echten „DevOps – Umgebung“ ist weit. So müssen sowohl alle Werkzeuge im Bereich CI & CD ausgewählt und die gesamte Prozesskette definiert werden. Zudem sind die Rollen im Unternehmen für Management und Monitoring inkl. der Verantwortlichkeiten zu definieren.

Am Ende ist es vor allem eine Frage der „Developer Experience“, welche Plattform am Besten geeignet ist. Je mehr Freiheiten geboten werden, desto mehr Know-how muss im DevOps Team in Sachen Plattform und Infrastruktur vorhanden sein.

Plattformen wie Cloud Foundry setzen darauf, dass sich der Developer tatsächlich nur auf das Development konzentrieren kann und alle anderen Aufgaben rund um Skalierung, Konfiguration und Management im Bereich der Infrastruktur oder durch die Plattform möglichst im Hintergrund „gemanaged“ werden. Für schnelle Erfolge im Cloud Native Development sicher einer der besten Wege, die Performance von DevOps Teams zu maximieren.

Fällt die Wahl in Richtung Kubernetes, reicht ein einfacher cf-push für das Deployment nicht mehr aus, hier muss im DevOps Team mehr Expertise in der Konfiguration von Containern und in der Automatisierung vorhanden sein.

Ausblick – Stabile Zukunft oder instabile kurze Zyklen?

Die Zeiten, in denen Unternehmen mit einem Horizont von 10 bis 15 Jahren für die Nutzung einer Technologie oder Sprache kalkulieren konnten,  sind sicher vorbei. Vor allem im Frontend  ist damit zu rechnen, dass in kurzen Zyklen von zwei bis drei Jahren immer wieder neue Frameworks für spezielle Anforderungen und Anwendungen in Co-Existenz benutzt werden. Durch die Nutzung von Services oder sogar FaaS-Konzepten kann aber zumindest in der Backend-Anbindung auch in Zukunft für Stabilität und somit Investitionssicherheit gesorgt werden.

Der Einsatz von Methoden zur digitalen Kultur in Kombination mit  Cloud-/Container Development Plattformen sorgen dafür, dass sowohl das Business in agilen Zyklen denkt aber auch Entwickler im Rahmen von Labs in der Lage sind, neue Methoden und Werkzeuge in kurzer Zeit zu verstehen und durch die hohe Lernkurve maximal motiviert sind.