Building Resilience: Widerstandsfähig in der IT-Strategie verankern

Resilience - also Widerstandsfähigkeit - ist eine der wichtigsten Eigenschaften erfolgreicher Unternehmen. Zwei Eckpfeiler die dabei helfen können:

• Sich unabhängig machen von externen Abhängigkeiten
• eine schnelle Reaktion auf unerwartete externe Ereignisse

Die folgende aktuelle Geschichte aus der Open Source Welt, möchte ich nutzen um eine entsprechende Strategie vorzuschlagen, um sich gegen die im folgenden geschilderten Ereignisse vorbereiten zu können.

Es war einmal ein Open Source Projekt...

In der Open Source Welt herrscht aktuell wieder einmal jede Menge Aufregung. Branchen Primus Red Hat (seit 2019 ein Unternehmen der IBM) hat eine einschneidene Änderung seiner Strategie zu seinem Kernprodukt Red Hat Enterprise Linux (RHEL) durchgeführt. Bisher war der gesamte Quellcode von allen RHEL Paketen (das sind alle Software Teile die Red Hat rund um den Linux Kernel gebaut hat) offen frei verfügbar. Das hat sich mit einem Blog Post von Mike McGrath vom 21 Juni 2023 mit dem Titel Furthering the evolution of CentOS Stream schlagartig geändert. Darin wird angekündigt, dass nur noch CentOS Stream die einzige Quelle ist, in dem die Sourcen frei verfügbar sind. Für das eigentliche Kernprodukt - RHEL - können diese nur noch mit einer entsprechenden Subscription erworben werden. Gleichzeitig hat Red Hat verboten, diese Sourcen als Grundlage für davon abgeleitete Software zu verwenden (oder man muss für jede verwendete abgeleitete Verwendung ebenfalls eine Subscription bezahlen).

Nun muss man etwa zwei Jahre in die Vergangenheit zurück reisen. Zu diesem Zeitpunkt hat Red Hat den Support für die freie Linux Distribution CentOS eingestellt. Dafür wurde CentOS Stream ins Leben gerufen. CentOS war eine freie, 100% zu RHEL kompatible Linux Distribution. 100% kompatibel, weil CentOS eine 1:1 Distribution war, die direkt aus RHEL erstellt worden war - salopp formuliert ein "gratis RHEL". Schon damals war der Aufschrei in der Open Source Community groß. Red Hat sah das naturgemäß anders und stellte seine Sichtweise auf einer Info Seite über CentOS online.Verwendeten vor allem viele kleinere Unternehmen oder andere Open Source Projekte CentOS um Ihre Produkte auf Kompatibilität mit RHEL hin zu überprüfen war diese Möglichkeit mit der Einstellung nicht mehr möglich. Auch wenn Red Hat den Support für CentOS einstellte, so spielte Red Hat den Quellcode von RHEL noch regelmäßig auf ein öffentlich zugängliches Git Repository ein. Aus diesen Quellen resultierten zwei neue Linux Distributionen AlmaLinux und Rocky Linux, die die Lücke durch den Wegfall von CentOS kompensierten. Mitte Juni stellte Red Hat nun also die weitere Veröffentlichung der RHEL Quelldaten auf dem Git Repository ein und nimmt damit den beiden Linux Distributionen die Grundlage.

Die heftige Kritik an dem Vorgehen veranlasste Mike McGrath zu einer weiteren Stellungnahme

Warum ist der Unterschied wichtig, denn es gibt ja noch CentOS Stream?

Warum nun überhaupt die Aufregung, wenn es doch CentOS Stream weiterhin gibt und dafür auch der Quellcode zur Verfügung steht? Auch wenn der Name CentOS noch im neuen Produkt enthalten ist, ist die Zielsetzung von CentOS Stream eine völlig andere. Dort werden nämlich neue Software Paketversionen ausprobiert um sie zu stabilisieren und danach in RHEL zu integrieren.

RHEL -> CentOS

CentOS Stream -> RHEL -/-> keine weitere Veröffentlichung mehr

Fedora -> RHEL -/-> keine weitere Veröffentlichung mehr

CentOS Stream ist also, ebenso wie die Linux Distribution Fedora eine Art Spielwiese und Testplattform für das Kernprodukt von Red Hat RHEL. Und genau da steckt der Teufel im Detail. Die fertigen Softwarepakete die letztlich in RHEL landen, werden nicht mehr in CentOS Stream zurückgespielt und sind damit nur noch durch eine Subscription erhältlich. CentOS Stream ist nicht mehr zu 100% kompatibel zu RHEL und damit auch nicht mehr als Testplattform für andere Software Hersteller oder Open Source Projekte geeignet. Diese wären gezwungen sich eine entsprechende Subscription bei Red Hat zu kaufen. Einer der deutlichsten Kritiker an diesem Vorgehen ist der Bekannte Open Source Pionier Jeff Gerling, der seinen Standpunkt in mehreren Blogposts darlegt.

https://www.jeffgeerling.com/blog/2023/dear-red-hat-are-you-dumb https://www.jeffgeerling.com/blog/2023/removing-official-support-red-hat-enterprise-linux https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux

Auch die beiden unmittelbar betroffenen Linux Distributionen haben mit entsprechenden Beiträgen auf die Änderungen von Red Hat reagiert.

https://almalinux.org/blog/impact-of-rhel-changes/ https://rockylinux.org/news/2023-06-22-press-release/

Was kann man daraus lernen, welche Strategie hilft dagegen?

Damit schließt sich der Kreis zur zuvor erwähnten Widerstandsfähigkeit. Auch wenn ich diesmal die aktuelle Geschichte aus der Open Source Welt als Beispiel gebracht habe, noch viel öfter passiert es im Bereich der kommerziellen Software, dass Produkte verschwinden oder zusammengeführt werden, sich in eine andere Richtung entwickeln als gewünscht oder der Hersteller die Preisstrategie ändert, sodass diese nicht mehr zum eigenen Unternehmen passt. Ich beschränke mich jetzt einmal auf den Bereich der Infrastruktur. Denn dort gibt es eine klare Strategie, die sich bei unseren Kunden und natürlich auch bei uns selbst bewährt hat:

• Infrastruktur in eine Cloud legen (public oder privat)
• Virtualisierung einführen
• Infrastructure als Code einführen
• Containerisierung einführen
• Abstraktion der IaC um die Zielplattform offen zu lassen
• Restore Strategie ausarbeiten (Backups mach ja jeder)
• Wiederanlaufpläne und Abstraktion testen
• Regelmäßiges Desaster Recovery durchführen

Unser DevOps Team: Erfahrene Unterstützung für Deine IT-Infrastruktur

Sind diese Schritte einfach umzusetzen? Natürlich, vorausgesetzt man hat das Know-How und die Erfahrung. Oder hat einen Partner der diese Expertise bereits hat und aushelfen kann. Bei all den einzelnen Schritten können wir mit unserem erfahrenen DevOps Team helfen! Dabei vermeiden wir natürlich auch, dass wir selbst nicht zum "Vendor Lockin" werden. Jede Software, Configuration, Ablaufbeschreibung die wir im Zuge der Arbeiten durchführen liegt natürlich auch im Quellcode vor und kann jederzeit eingesehen und weiter verwendet werden. Wir leben und lieben den Open Source Gedanken einfach!