Wie der Titel andeutet, geht es in diesem Text um Release-Zyklen von Betriebssystemen und Zeiträume, in denen diese unterstützt werden. Ich möchte meine großartige Idee mit euch teilen und bin daran interessiert, zu erfahren, wie ihr darüber denkt.
Transparenzhinweis 1: Ich arbeite als Technical Account Manager bei Red Hat. Zuvor habe ich mehrere Jahre als Systemadministrator mit Red Hat Enterprise Linux (RHEL) gearbeitet. Dieser Text spiegelt ausschließlich meine persönliche Meinung wieder.
Transparenzhinweis 2: „Großartige Idee“ ist Code für eine Idee, die andere als Spinnerei, Wahnsinn, verrückt oder anderweitig dispektierlich bezeichnen würden. Mein bester Freund und ich hatten in unserem Leben schon viele großartige Ideen. Wir haben sie bisher alle überlebt. ;-) Nehmt das hier Geschriebene daher vielleicht nicht bierernst und mit einer Prise Ironie und Humor.
Wann? Wie oft? Wie lang?
Ca. alle 2-5 Jahre ist bei den bekannten Linux-Distributionen mit einem neuen Major-Release zu rechnen. Für jedes Major-Release bekommt man bis zu 10 Jahre und länger Unterstützung. Der Umfang der Unterstützung schwankt dabei je nach Support-Phase deutlich.
Die folgenden Abbildungen geben einen kleinen Überblick.
Betrachtet man diese Release-Zyklen und Unterstützungszeiträume, ist es problemlos möglich, ein Release zu überspringen, während sich die Unterstützungszeiträume für das alte und neue Release überschneiden.
Was sagen verschiedene Teams zu neuen Releases?
Die folgende Liste gibt eine Auswahl von Aussagen und Kommentaren wieder, die ich während der letzten 15 Jahre immer wieder in ähnlicher Form gehört habe.
- „Schon wieder ein neues Major-Release. Jetzt müssen wir schon wieder testen, ob unsere Prozesse und Automations-/Konfigurations-Skripte noch funktionieren.“
- „Hoffentlich müssen wir das Betriebskonzept nicht anpassen.“
- „Endlich, wir warten schon lange auf neue Versionen wichtiger Bibliotheken, Laufzeitumgebungen und Datenbankmanagementsysteme.“
- „Wir würden ja gern auf Version B deployen, die IT gibt uns aber nur Version A.“
- „Mit jedem Major-Release ändert sich irgendwas und wir müssen uns schon wieder anpassen.“
- „Unsere Anwendung läuft gut auf Version A. Wir möchten skalieren, aber die IT gibt uns jetzt nur noch Version B. Wir wissen nicht, ob und wie unsere Anwendung darauf läuft.“
- „Wir testen gerade noch die letzte Patch-Version unserer Anwendung auf Version A. Der Test der folgenden Patch-Version drängt schon. Wir haben keine Zeit und keine Leute, um die Anwendung auch noch auf Version B zu testen.“
- „Kaum sind wir mit der Migration unserer Anwendung von Version A auf Version B fertig, drängt uns der IT-Betrieb schon wieder, wir müssten auf Version C migrieren.“
- „Vor lauter Betriebssystemwechseln kommen wir kaum dazu, unsere Anwendung weiterzuentwickeln.“
- „Es dauert so lange, bis alle Anwendungen von Version A auf Version B migriert wurden, dass Version B schon fast wieder End-of-Life ist.“
- „Es erzeugt enorme Aufwände mehrere Betriebssystemversionen parallel zu betreiben.“
Ihr habt hoffentlich erkannt, dass Version A und Version B hier stellvertretend für ein Release einer beliebigen Linux-Distribution stehen. Nimmt man die Aussagen zusammen, kann man den Eindruck gewinnen, dass ein neues Major-Release nicht bei allen Menschen in einer IT-Organisation Freude auslöst.
Und wenn wir nun ein Release auslassen?
- Das Betriebskonzept muss seltener überprüft und ggf. angepasst werden
- Die Anwendungsteams müssen ihre Anwendung seltener migrieren
- Automations-/Konfigurations-Skripte müssen seltener angepasst werden
- Die Anzahl von Migrations- und Veränderungs-Projekten kann reduziert werden
- Geringerer Aufwand senkt die Kosten
Lassen wir außer Acht, dass ich einen Punkt bewusst unterschlage, sind die Vorteile offenbar deutlich und überwiegen alle potenziellen Nachteile mit Leichtigkeit. Oder nicht? Also warum wollt ihr unbedingt jedes Major-Release mitnehmen? Bitte schreibt mir eure Gründe dafür gern in die Kommentare.
Aber Jörg, du weißt doch, wie das so ist…
Ja, natürlich ist mir bewusst, dass es sich bei großen Unternehmen um komplexe Systeme handelt, in denen aus verschiedenen Bereichen sehr unterschiedliche Anforderungen an Anwendungen und IT-Dienste gestellt werden.
So reicht das Spannungsfeld regelmäßig von „Never touch a running system (even when it’s 20 years old)“ bis hin zu „We need the latest and greatest to be successful in our business“.
Manche Anwendungen sind nur für den Betrieb auf ausgewählten Betriebssystemversionen zertifiziert, Abhängigkeiten zu Bibliotheken und Laufzeitumgebungen müssen eingehalten werden.
Doch habt ihr wirklich mal zusammen mit allen Beteiligten bewusst überlegt, ob es ohne einschneidende Nachteile möglich ist, ein Major-Release zu überspringen, um die oben skizzierten Vorteile zu nutzen? Oder nehmt ihr jedes Release mit, weil das schon immer so gemacht wurde?
Dies ist wirklich _____ großartige Idee
Also, was haltet ihr von dieser Idee? Machbar? Gut? Oder doch nur eine Schnapsidee? Was spricht dagegen?
Bitte nutzt die Kommentare unter diesem Text, um mich und alle Leserinnen und Leser wissen zu lassen, ob dieser Ansatz Vorteile hat oder welche zwingenden Gründe ihn unrealistisch erscheinen lassen.
Und wenn ihr euch nur mal den Frust von der Seele schreiben wollt, warum es überall klemmt und hakt und wie es besser sein könnte, ist das natürlich auch in Ordnung.
Anmelden
Das Kostenlos-Update für Windows 10 endet - gute Gelegenheit für den Absprung! Beim Umstieg auf Linux sollten Unternehmen aber einiges beachten. (
Zum 40. Geburtstag der Free Software Foundation werden zahlreiche Andenken versteigert - unter anderem die originale Gnu-Zeichnung. (
Docker und Kubernetes bieten für Spring-Boot-Anwendungen eine leistungsstarke Grundlage, um Anwendungen flexibel, skalierbar und effizient in verschiedenen Umgebungen auszuführen. Wie das geht, zeigt dieser Workshop. (
