„Infrastructure as code“ ist ein guter Weg eigene Infrastruktur sicher und reproduzierbar abzubilden. Dabei ist es egal welche Strategie gefahren wird: gitOps-Ansatz oder klassisch. Nehmen wir Tools zur automatischen Aktualisierung von Infrastruktur, systembedingte Abhängigkeiten bzw. Images hinzu, ist die Aktualisierung und Wartung von komplexen Infrastrukturen handhabbar und einfach.
Als Infrastrukturbetreiber gewinne ich, ohne die Übersicht über verschiedenste Update-Zyklen der jeweiligen Bestandteile der Infrastruktur zu verlieren, Aktualität in der Landschaft meiner Systeme und die notwendige Sicherheit für neueste Patches etc. Doch was ist eigentlich Voraussetzung für dieses attraktive Szenario?
In diesem Blog möchte ich unsere Vision und die dahinterliegende Strategie diesbezüglich aufzeigen und die jeweiligen Schlagwörter dazu in Relation setzen, um grob die strategischen Ziele dahinter aufzudecken. Vielleicht hilft es dem einen oder der anderen zu verstehen, worauf hier besonders zu achten ist, um in Zukunft sicher eine Infrastruktur betreiben zu können. Gewürzt mit ein paar konkreten Fallbeispielen und gefundenen Lösungsansätzen ist dies vielleicht wertvoll und regt zu Diskussionen an. Im ersten Beitrag geht es dabei vorrangig um die Grundlagen im Aufbau der Infrastruktur und warum manches besser zu lassen ist, obwohl es vielleicht dadurch Einschränkungen bei coolen Features geben mag.
Infrastruktur selbst on premise zu betreiben, was bedeutet dies?
Entscheidet sich eine Organisation eigene Infrastruktur selbst betreiben zu wollen oder zu müssen, so wächst diese Infrastruktur meist mit der Zeit und die Vernetzung von verschiedenen Systemen innerhalb dieser Infrastruktur steigt.
Der Anspruch aus der Architektur für die ‚lose Kopplung von Systemen‚ ist die erste Herausforderung für die Organisation. Coole Features für hohen Benutzerkomfort vernetzten gerne einzelne Systeme miteinander und sind dadurch integrativ wertvoll. Allerdings bedingt dies, dass mindestens zwei Systeme nicht mehr voneinander unabhängig sind und dies bei Updates oder Ersatz zu erhöhten Testaufwänden führt.
Eine klare Trennung ist aus Betriebssicht wünschenswert und es sollte abgewogen werden, wieviel Mehrwert solch ein integratives Feature wert ist gegenüber dem Mehraufwand für Wartung und Test.
Der zweite Anspruch geht einher mit ‚halte dich an die Standards‚ für die jeweilge Komponente der Infrastruktur. Das klingt auf den ersten Blick logisch und einfach, ist es aber meist nicht. Meiner Erfahrung nach hält diese Erkenntnis häufig erst spät bei Organisationen Einzug und dann wird es meist schmerzhaft, denn schließlich läuft es ja schon! Eine typische Antwort ist dann gerne: „Never change a running system!“
Warum ist das so? Vielfach werden Komponenten/Tools einer Infrastruktur einzeln/isoliert angeschafft. Manchmal hat jemand eine gute eine Idee, findet ein Tool zur Lösung eines spezifischen Problems und so wächst dieses Tool langsam in die Organisation und Infrastruktur hinein.
Ist ein Tool gut und wertvoll für die Organisation, wird es aus der Infrastruktur kaum wegzudenken sein und das auch zurecht.
Hier geht es im nächsten Schritt um den Know-how-Transfer für das Tool in das betreuende Team (‚keine Kopfmonopole bei einzelnen‚) und die Überführung in einen permanenten Wartungszyklus.
Idealbild für eine IaC-Umsetzung
Idealerweise wird aus der initial meist manuellen Installation eine Abbildung als Infrastructure as Code (IaC), möglichst ohne viele spezifische Anpassungen und Abhängigkeiten zu anderen Infrastrukturkomponenten oder auch Prozessen. Weicht eine Installation weit vom Standard ab, wird dies schnell aufgedeckt und zugehörige Tests bleiben einfach. Gibt es bereits hier eine starke Vernetzung innerhalb der Infrastrukturkomponenten sind schnell integrative treurere Test notwendig und die Erstellung der Tests wird aufwendig und schwierig. Die Komplexität sollte im Test also nicht zu hoch werden, ansonsten besteht die Gefahr, dass die Tests instabil/flaky werden, weil eine Komponente auf andere Systeme angewiesen ist oder diese kompliziert emuliert werden müssen.
Beispiel aus der Praxis und die Umsetzung für ein bereits in den Brunnen gefallenes System
An dieser Stelle möchte ich ein Beispiel nennen, das alle diese eben genannten Aspekte in sich beinhaltet.
Wir betreiben bei uns einen OpenGrok als Source-Code Suchmaschine/Indexer, sozusagen eine Suchmaschine für unseren gesamten Sourcecode. Der Erfolg bei den Entwicklern war bei der Einführung gewaltig und half ihnen unsere recht große Code-Basis bei notwendigen Refactorings etc. besser zu beherrschen.
Was war falsch daran?
Es entsprach also genau dem Aspekt „Wertvolles Tool für die Organisation von einem Einzelnen in die Infrastruktur eingebracht„. Der Wunsch der Entwicklung ging soweit, dass jeder für seinen Feature-Branch dort ebenfalls die Suchfunktion nutzen möchte.
Die Skalierung für über hundert Feature-Branches war entsprechend hoch und die Anforderungen an die Leistungsfähigkeit der Hardware entsprechend. Die Auslegung des OpenGrok war diesbezüglich speziell optimiert, in jedem Fall keine Standardinstallation des Tools.
Gleichfalls war die Anforderung ‚jeder Feature-Branch erhält auch eine Suchmöglichkeit‘ eine direkte Verknüpfung zu den jeweiligen Prozessen im Branch-Handling und damit keine ‚lose Kopplung von Systemen‚ sondern eine starke Abängigkeit im Prozess und bei den Systemen.
Um das ganze Beispiel perfekt zu machen, lag die Verantwortung ausschließlich bei einer Person (in diesem Fall bei mir), da keiner etwas mit dem Großgerät zu tun haben wollte. Dazu kamen noch organisationsspezifische Anpassungen (Corporate Identity u.a.), um die Nutzung noch weiter abzurunden. Dies griff direkt in die Codebasis des OpenGrok ein und war definitiv nicht ‚standard-konform‚ und damit wartungs- und updateunfreundlich. Ja, das war auch aus meiner persönlichen Sicht unschön, da es kein Backup-Szenario für Urlaub oder Krankheit gab. Das System war am Ende mit Selbstüberwachung ausgestattet und sehr robust, entsprach aber überhaupt nicht meinen eigenen Ansprüchen als auch den Teamansprüchen.
Und nun, weg damit?
Ja, das war die erste Diskussion bei uns im Team und nachgelagert auch in der Organisation mit den Entwicklern und anderen beteiligten Stakeholdern, die geführt wurde. Brauchen wir das Tool wirklich? Die Antwort war JA. Alternativen am Markt mit dem Funktionsumfang sind teuer und bedingen, dass ggf. der Code nicht on premise liegt. Für unsere Organisation so aktuell nicht vorstellbar. D.h. wir mussten uns als Team hinterfragen, wie denn zukünftig eine Lösung aussehen könnte.
Umsetzung für die Zukunft, strategische Ziele
Danach sind wir unsere Anforderungen an ein neu aufzusetzenden OpenGrok durchgegangen:
1. Bei uns gilt heute der Anspruch, dass es keine Kopfmonopole geben darf. Entsprechend ging ein Subteam diese Aufgabe gemeinschaftlich an, immer wieder im Austausch mit dem gesamten Team und Stakeholdern
2. Das Tool soll wenn irgendmöglich im Kubernetes Umfeld laufen (unser Standard für die Infrastruktur). Die neuen Versionen des OpenGrok gewährleisten dies. Eine damals angeschaffte gesonderte Maschine ist dadurch obsolet und der Betrieb des neuen OpenGrok ist viel kostengünstiger
3. Wir halten uns an die Standards für das System OpenGrok selbst und das System sollte einfach konfiguriert sein (KISS-Prinzip). Hierfür haben wir hinterfragt, ob en detail die bisherigen Features einen höheren Mehrwert bieten gegenüber dem Mehraufwand bei Updates und Wartung. Hier haben wir im engen Austausch bisherige Ansprüche der Entwicklung zurückgeschraubt oder Alternativen gefunden, die im Ergebnis nicht schlechter sind.
4. Die Installation sollte nicht wie vorher speziell optimiert sein sondern IaC konform abgebildet werden, s.d. Updates und Wartung einfach bleiben mit leichtgewichtigen Tests der Funktionalität
Das Ergebnis kann sich sehen lassen, es läuft die aktuelle Version des OpenGrok im Kubernetes-Cluster mit all den gewünschten Features aber wartungsarm und updatefreundlich.
Im nächsten Teil werde ich auf die Weiterführung des Themas Richtung IaC mit automatischen Updates eingehen, was genau wartungsarm meint sowie die dazugehörigen Tools und Tests. Also bleibt dran,
Euer Frank
