Behandeln Sie auch Ihren IT-Automatisierungscode wie Nutzvieh.

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Die IT muss die Standardisierung des Codes vorantreiben, auf dem sie basiert. Andernfalls besteht die Gefahr, dass Systeme entstehen, die die finanziellen Vorteile und Effizienzgewinne der IT-Automatisierung zunichtemachen.

Ich habe fast ein Jahrzehnt lang Software entwickelt: eingebettete Software, Websoftware, Client-Server-Software sowie Middleware und Mainframe-Software. Beruflich habe ich in neun verschiedenen Programmiersprachen Code geschrieben. Interessanterweise kann ich mich nicht daran erinnern, in ein und demselben Unternehmen mehr als zwei Sprachen verwendet zu haben.

Die meisten Großunternehmen standardisieren nicht nur Server, Plattformen und Frameworks, sondern auch Programmiersprachen. Ziel ist es, Software wartbar zu halten, deren Lebensdauer nicht nur wenige Minuten beträgt, sondern mitunter in Jahrzehnten gemessen wird. Wartbarkeit ist die Eigenschaft von Software, die es anderen ermöglicht, sie zu übernehmen und über ihren gesamten Lebenszyklus hinweg zu betreuen – unabhängig davon, wie lang dieser auch sein mag. Gründe dafür sind häufig die Fluktuation unter Entwicklern, die Verfügbarkeit entsprechender Sprachkenntnisse auf dem Arbeitsmarkt sowie die Kosten für Schulungen und die allgemeine Wartung. Grundsätzlich standardisieren Unternehmen ihre Programmiersprachen.

Das steht im Widerspruch zu aktuellen Trends bei Microservices und Serverless Computing, die ihre Fähigkeit zur Unterstützung einer äußerst vielfältigen (polyglotten) Sprachenlandschaft als Vorteil anpreisen. Bob und sein Team können in Go programmieren, während Alice und ihr Team in C, Java oder Lambda entwickeln. Für Entwickler, die alle ihre bevorzugte Sprache haben, ist das sicherlich ein Pluspunkt, für Unternehmen, die diese Software langfristig warten müssen, jedoch weniger vorteilhaft. APIs ermöglichen die Integration und Nutzung der Software, sodass ihre Implementierungssprache für die Anwendungsentwicklung weitgehend irrelevant ist. In einem Unternehmen muss der zugrunde liegende Code jedoch weiterhin gewartet werden.

Bei der IT-Automatisierung – der internen digitalen Transformation, die auf der Produktionsseite des Unternehmens stattfindet – ist es für Unternehmen wichtig, nicht nur die Vorteile der Standardisierung der dafür entwickelten Skripte und Systeme zu erkennen, sondern auch die Fallstricke, die entstehen, wenn darauf verzichtet wird. Schließlich werden diese Systeme nicht mit der Absicht entwickelt, sie nächste Woche, nächsten Monat oder auch nur nächstes Jahr wieder zu verwerfen. Sie sind eine langfristige Investition, die die Digitalisierung der Bereitstellung über viele Jahre hinweg unterstützen soll. Dafür muss ein flexibles, aber solides Fundament geschaffen werden, das auf bewährten Verfahren beruht, die in der Anwendungsentwicklung von Unternehmen weltweit über Jahrzehnte hinweg erarbeitet wurden. An erster Stelle steht dabei die Standardisierung.

1. Wartbarkeit

Ich weiß, dass Sie gerne in PERL programmieren, aber alle anderen verwenden Python. Wenn Sie Automatisierungen in Ihrer Lieblingssprache entwickeln, machen Sie sie zu Ihrem persönlichen Projekt, das künftig niemand sonst warten kann. Das ist schlecht für Sie, denn dann bleiben Sie jahrelang darauf sitzen – genau wie auf dem Goldfisch, um den Sie Ihre Eltern mit acht Jahren angefleht haben. Das ist auch schlecht für das Unternehmen, denn wenn Sie es verlassen, bleibt es auf Code sitzen, den niemand warten kann und dessen Support möglicherweise nur schwer zu gewährleisten ist. Eine 2016 von SIG und O’Reilly durchgeführte Umfrage ergab, dass „70 % der Befragten die Wartbarkeit für den wichtigsten messbaren Aspekt von Code halten – noch vor Leistung oder Sicherheit.“

So wichtig ist das. Betrachten Sie Skripte und Systeme als gemeinsam genutzte Ressourcen, die sich heute und in Zukunft von der Mehrheit der IT-Fachkräfte problemlos anpassen und betreuen lassen.

2. Kompatibilität

Da immer mehr IT-Dienste als Software umgesetzt werden, wächst auch der Aufwand, sie auf dem neuesten Stand und mit anderen Systemen kompatibel zu halten. Falls Sie glauben, REST-APIs würden das Problem der „Abwärtskompatibilität“ beseitigen, sollten Sie noch einmal darüber nachdenken. APIs sind Produkte (oder sollten es sein) und entwickeln sich daher ebenfalls ständig weiter. Noch schlimmer ist es „im Netzwerk“, wo selbst innerhalb derselben Produktreihe Unterschiede bestehen und sich die APIs von Version zu Version ändern, sodass die Standardisierung zu einer Sisyphusarbeit wird. Das Problem ist so weit verbreitet, dass die API-Standardisierung bei jedem vierten Befragten auf Platz drei der Liste der technologischen Herausforderungen stand, die in den kommenden Jahren gelöst werden müssen – so das Smart Bear’s State of API 2016-Gutachten.

Und da so viele der in der IT verwendeten Sprachen interpretiert werden, können Änderungen zwischen verschiedenen Versionen sorgfältig entwickelte Automatisierungsskripte und -systeme unbrauchbar machen. Der Wechsel von einer node.js-Version zu einer anderen kann gravierende negative Auswirkungen haben – von nicht mehr funktionierenden Skripten bis hin zu unerwartetem Verhalten. Die Standardisierung auf stabile Versionen von Skriptumgebungen und -sprachen trägt dazu bei, die Auswirkungen solcher Änderungen zu minimieren.

Und Sie müssen weiterhin Patches und Upgrades für jedes zugrunde liegende System verwalten, auf dem diese Automatisierung basiert – je weniger Systeme es also sind, desto besser.

3. Fehlerbehebung

Wer die Standardisierung über Bord wirft, erschwert die Fehlerbehebung. Dies ist besonders wichtig, wenn Sie auf eine auf der Lösungszeit basierende Kennzahl für IT-KPIs umstellen. Je länger es dauert, das Problem zu finden, desto schlechter fällt diese Kennzahl aus. Standardisierung ist ein wichtiger Faktor, um die Lösungszeit zu verkürzen. Wenn Bob der einzige Python-Experte im Team ist, Urlaub hat (und nicht erreichbar ist) und sein Skript nicht mehr funktioniert, steht derjenige, der mit der Fehlerbehebung beauftragt wird, vor einer langen Woche. Wenn Sie die IT-Mitarbeiter dazu ermutigen, ihre jeweilige Lieblingssprache zu verwenden, schränken Sie die Möglichkeiten anderer, Fehler zu beheben und Probleme zu lösen, erheblich ein. Selbst wenn Bob nicht im Urlaub ist und das Problem nicht finden kann, gibt es nur wenige, die helfen können.

In diesem Bereich sollten Sie nichts dem Zufall überlassen. Laut InitialState dauert es 30-mal länger, einen Fehler zu beheben, als eine einzige Codezeile zu schreiben. Stellen Sie sich vor, wie das Geld langsam im Aktenvernichter verschwindet, während Sie mühsam versuchen, einen Fehler in einem Ihnen unbekannten Code zu finden und ihn anschließend zu beheben. Kein schöner Gedanke. Die Kosten der Fehlerbehebung lassen sich nicht vollständig vermeiden, aber Sie können sie begrenzen, indem Sie den zusätzlichen Zeitaufwand vermeiden, der entsteht, wenn jemand die verwendete Sprache nicht kennt. Im Produktivbetrieb ist Zeit Geld. Daher ist alles, was die Lösungszeit verkürzt, von enormer Bedeutung.

Da die IT nach und nach Skriptsprachen, Tools und Systeme einführt, ist es daher keine schlechte Idee, sich mit der Anwendungsentwicklung abzustimmen. Wenn die IT dieselben Systeme und Sprachen (oder zumindest einige davon) standardmäßig nutzt, steht Ihnen eine ganze Schar von Fachleuten zur Seite, die bei der Fehlerbehebung und anderen entwicklungsbezogenen Prozessen wie Code-Reviews helfen können. Denn Sie setzen Code-Reviews ein, um Fehler zu finden, bevor sie Probleme verursachen, richtig? Richtig?

Standardisierung wird häufig als Mittel zur Bekämpfung steigender Kosten angeführt und leistet zweifellos einen wichtigen Beitrag dazu. Sie bietet jedoch noch zahlreiche weitere Vorteile, darunter die Minimierung technischer Schulden, die Verkürzung der Lösungszeiten und die Vereinfachung der täglichen betrieblichen Wartung. Ein vollständiger Verzicht auf Standardisierung wirkt sich dagegen negativ auf Budgets und Zeitaufwand aus: Er schafft Komplexität und Engpässe, die die Vorteile der Automatisierung zunichtemachen und Unternehmen daran hindern, die für ihr Wachstum erforderlichen Gewinne und Produktivitätssteigerungen zu erzielen. Wenn Sie Ihre Reise zur IT-Automatisierung beginnen oder fortsetzen, sollten Sie diese Skripte und Systeme eher wie Nutztiere und nicht wie persönliche Haustiere behandeln. Denn Haustiere erfordern ständige persönliche Aufmerksamkeit, die sich die IT künftig nicht leisten kann.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie