DevOps: Standardisierung der Infrastruktur oder You build it, you run it?

Gender-Hinweis: Aus Gründen der besseren Lesbarkeit wird in diesem Beitrag das generische Maskulinum verwendet. Die in diesem Artikel verwendeten Personenbezeichnungen beziehen sich – sofern nicht anders angegeben – auf alle Geschlechter.

Der DevOps-Leitgedanke ‘You build it, you run it’ betont die durchgängige Verantwortung des Entwicklungsteams für den Lebenszyklus einer Anwendung. Dies fördert nicht nur die agile Reaktion auf Probleme und beschleunigt den Entwicklungsprozess, sondern beeinflusst auch das Mindset der Teammitglieder positiv. Bei komplexer Unternehmenssoftware stoßen wir jedoch auf Herausforderungen in der Realität. Im Folgenden werfen wir einen Blick auf zwei zentrale Herausforderungen, die sich bei der Umsetzung von “You build it, you run it” in der Praxis zeigen und stellen Lösungsansätze vor, die wir bei mgm erfolgreich umsetzen.

Bei mgm haben wir in unseren Projektrealitäten immer wieder die Erfahrung gemacht, dass sich Herausforderungen bei der Umsetzung von „You build it, you run it“ meist auf zwei Kern-Probleme zurückführen lassen. Bislang wenden wir den „You build it, you run it“-Ansatz immer dann an, wenn das erforderliche Know-how für alle Aspekte des Prozesses durch entsprechendes Personal im Projekt sichergestellt ist. Doch leider ist dies nicht die Regel.

1. Das DevOps-Personal-Dilemma

In der Branche ist das Personal-Dilemma kein unbekanntes Problem: DevOps-Ingenieurinnen und -Ingenieure sind rar und kleinere Projekte müssen oft ohne entsprechendes Personal auskommen. Schulungen allein reichen in der Regel nicht aus, da die Kapazitäten in den Projektteams begrenzt sind und einmalige Schulungen nicht den gewünschten Effekt erzielen genügen.

Von einer teilweisen Implementierung oder vereinfachten Grundannahmen sollte man absehen, da dies zu massiven Problemen führen kann: Beispielsweise kann es vorkommen, dass eine Software, die in der Entwicklungsumgebung einwandfrei funktioniert, beim Kunden nicht lauffähig ist, weil grundlegende Annahmen außerhalb der Entwicklungsumgebung nicht zutreffen.

2. Zu wenig projektübergreifender Austausch

Unsere Erfahrung hat gezeigt, dass der DevOps-Leitgedanke „You build it, you run it“ einerseits hohe Autonomie und Verantwortlichkeit mit positiven Effekten für die Softwareentwicklung fördert, anderseits aber auch dazu führen kann, dass zu wenig projektübergreifender Austausch stattfindet. In der Projektrealität wurden bereits gelöste Probleme erneut und häufig anders gelöst. Obwohl diese Probleme durchaus interessant sein können, lenken sie oft stark vom eigentlichen Ziel ab, nämlich der Schaffung funktionaler Lösungen, im Volksmund auch Business Value genannt.

Um diesen Herausforderungen gerecht zu werden, setzt mgm bei der Entwicklung von Enterprise Applications auf Effizienz durch eine Kombination von Fachwissen, unserer Enterprise Low Code Plattform A12 und einen kontinuierlichen, projektübergreifenden Austausch.

Unsere Lösung: Standardisierung der technischen Infrastruktur

Um diesen Herausforderungen zu begegnen, wurde bei mgm ein Kompetenzteam für standardisierte Infrastruktur der Projekte eingeführt, das sogenannte TPI-Team (TPI = Technical Project Infrastructure). Teamleiter Ralf Brauwers erklärt:

„Wir stellen den Projekten standardisierte Infrastrukturen, projektübergreifende Standards und Best Practices zur Verfügung. Durch DevOps-Schulungen und die Bereitstellung automatisch generierbarer Infrastrukturen ermöglichen wir den Projekten den Zugang zu diesen Ressourcen. Im Idealfall steht der gesamte Infrastruktur-Stack automatisch zur Verfügung, sobald die Anforderungen zu Projektbeginn geklärt sind. Dies ermöglicht es den Projekten, Funktionen von Anfang an zu implementieren und lokal oder auf dem TPI Dev Cluster zu testen.“

Projektübergreifende Standards bringen viele Vorteile mit sich:

• Kohärenz und Konsistenz: Projekte müssen nicht jedes Mal die gleichen Fragen beantworten, sondern können auf bewährte Best Practices zurückgreifen.
• Effiziente Entwicklung: Teams können sich auf die Entwicklung von Funktionalität konzentrieren.
• Effizientes Onboarding: Die Einarbeitungszeit bei Teamwechseln wird verkürzt, da projektübergreifende Konventionen existieren.
• Interoperabilität: Die Migration von Source Code von einem Projekt ins andere vereinfacht sich deutlich, da die Infrastruktur standardisiert ist.
• Kollaboration: Die Zusammenarbeit und der Wissensaustausch zwischen den Teams werden durch die Querschnittsfunktion gefördert.

Auch aus Sicht der Infrastrukturteams gibt es Vorteile:

• Automatisierung: Die Infrastruktur lässt sich automatisiert bereitstellen.
• Patch Management: Die Automatisierung erleichtert die regelmäßige Aktualisierung, was die Sicherheit deutlich erhöht.
• Inkrementelle Änderungen: Häufig sind kleine Änderungen weniger fehleranfällig als große Migrationen und sorgen für ruhigere Nächte.
• Infrastructure as Code: Infrastrukturkonfigurationen liegen als Code vor, sodass sich Änderungen nachverfolgen lassen und sich bei Bedarf rückgängig machen lassen.
• Effizienz: Durch ein Team aus Experten und den Fokus auf die automatisierte Bereitstellung der Infrastruktur kann dies sehr effizient erfolgen.

Ein Beispiel:

Vor kurzem standen wir vor einer Herausforderung, die unsere ganze Aufmerksamkeit erforderte: Ein kritischer Fehler im Continuous Integration/Continuous Deployment (CI/CD)-System (Jenkins), erforderte schnelles Handeln. Innerhalb weniger Stunden konnten wir den Fehler dank automatisierter Patch-Deployments auf nicht weniger als 60 Instanzen erfolgreich beheben.

Tipps und Strategien für die Umsetzung

Es gibt jedoch auch Projektteams, die bei der Umsetzung dieser Standards auf Schwierigkeiten stoßen. „Der Prozess entspricht eben nicht immer in idealer Weise den individuellen Bedürfnissen eines jeden Projektes”, so Brauwers. Es kann auch sein, dass Projektteams nicht in der Lage sind, angemessen auf sich entwickelnde Standards zu reagieren. Dies kann insbesondere dann der Fall sein, wenn Änderungen unvorhersehbar sind, finanzielle Einschränkungen bestehen oder die Änderungen kurz vor der Veröffentlichung Releaseterminen der Projekte erfolgen. Um dieser Herausforderung zu begegnen, ist es ratsam, sich auf die bestmögliche Unterstützung bei Migrationsprozessen zu konzentrieren und dabei flexible Zeitrahmen vorzusehen. „Die Argumente gegen eine projektübergreifende Standardisierung sind zwar verständlich, aber es gibt Wege sie zu umgehen“, hat Ralf Brauwers festgestellt.

Tipp 1: Zum Beispiel sollte immer ein kleines Budget für Anpassungen der Infrastruktur von Anfang an im Projektbudget berücksichtigt werden, um finanzielle Probleme zu vermeiden. Ist dies nicht der Fall, kann das Projekt, insbesondere bei längerer Laufzeit, in finanzielle Schwierigkeiten geraten oder es müssen Nachverhandlungen geführt werden.“

Tipp 2: Ein Klassiker im Projekt kurz vor dem Release: der „breaking change“, eine Änderung an einem Teil der Infrastruktur, die Anpassungsarbeiten im Projekt benötigt. Kompetenzteams die Infrastruktur zu Verfügung stellen, sollten darauf achten, einen breaking change rechtzeitig anzukündigen und ausreichende Zeitfenster für die Migration der Projekte anzubieten. So können sich alle darauf einstellen und ihre Anpassungen in diesem Zeitraum vornehmen. Das beugt unliebsamen Überraschungen vor und sorgt für Planungssicherheit.

Fazit

Die Einführung eines zentralen Teams, welches Devop-Services zur Verfügung stellt (Cluster, Build-Infrastruktur, SCM, etc.) sowie projektübergreifenden Standards und Best Practices bietet klare Vorteile für die Softwareentwicklung in großen Unternehmen. Sie ermöglicht es Projektteams, sich auf die Entwicklung von Funktionalitäten zu konzentrieren, und sorgt für eine effizientere und sicherere Entwicklung. Entscheidend ist dabei, die Einführung gemeinsamer Richtlinien und die Klärung wichtiger Fragen im Vorfeld, um eine unternehmensweite Standardisierung zu gewährleisten. De-facto Industriestandards wie SemVer und Gitflows bieten bewährte Modelle, während Unternehmen für spezifische Anforderungen wie den Kickoff-Prozess eigene Standards entwickeln müssen. Diese strategische Standardisierung fördert nicht nur Kohärenz und Effizienz, sondern schafft auch eine klare Grundlage für die Zusammenarbeit und Entwicklung im gesamten Unternehmen.