Den Status (Distro)Quo disruptieren

Dies ist der erste in einer dreiteiligen Serie, die sich mit der Bereitstellung von Open-Source-Software befasst — der jüngsten Vergangenheit, dem Wendepunkt der Gegenwart und der Zukunft. Wir werden in die Grundlagen eintauchen, die Unix- und Linux-Betriebssystemdistributionen erstellt und definiert haben, die Herausforderungen, die diese traditionellen Distributionen darstellen, den Moment der Veränderung und Chainguards Ansatz zur Definition unserer Open-Source-Zukunft.

Der erste Teil konzentriert sich darauf, wie der heutige Status (Distro)Quo entstanden ist und einige seiner Auswirkungen.

Geschichte der Linux-Welt

In ihrer über 30-jährigen Geschichte haben Linux-Distributionen (Distributionen) eine bemerkenswerte Allgegenwart erreicht und alles von persönlichen Laptops und Servern bis hin zu komplexen Cloud-Umgebungen und eingebetteten Systemen angetrieben. Die verschiedenen Geschmacksrichtungen und Varianten von Linux-Distributionen sind ein Beweis für die überwältigende Popularität von Open Source und die breiten Anwendungsfälle, für die sie entwickelt wurden, wobei prominente Akteure jeweils Distributionen mit ihren eigenen einzigartigen Eigenschaften und Philosophien veröffentlichen.

Auf den Spuren von UNIX-Systemen haben Linux-Distributionen die etablierte Praxis übernommen, regelmäßig Snapshots des Kernels und des Benutzerbereichs zu erstellen, jede Version rigoros zu testen, zu härten, zu dokumentieren, freizugeben, zu unterstützen und schließlich zurückzuziehen. Seit Jahrzehnten folgen Stalwarts wie SUSE, Debian, Red Hat und Ubuntu einem Muster der Produktion von benannten und nummerierten Distributionen.

Über drei Jahrzehnte lang wurden Unix- und Linux-Versionen geliefert, "wenn sie bereit waren". Canonical erkannte die asynchronen und unvorhersehbaren Veröffentlichungszyklen seiner übergeordneten Distribution Debian und führte ein zeitgesteuertes Veröffentlichungsmodell für Ubuntu ein. Ubuntu wird seit 2004 jedes Jahr im April und Oktober zuverlässig auf Debians Zweig "devel" veröffentlicht. Dies steht im Gegensatz zum "wenn es fertig ist" -Ansatz von Red Hat und Debian und gibt den Benutzern und Organisationen, die sich auf Ubuntu verlassen, ein gewisses Gefühl der Voraussicht. Dieser konsistente Release-Zyklus half den Benutzern, ihre Technologieeinführung und Infrastrukturbereitstellungen besser zu planen. Der Lebenszyklus und die Wartung traditioneller Distributionen führten jedoch zu längerfristigen Bedenken.

Software, eingefroren in der Zeit

Jedes Release kapselt den Zustand des Open-Source-Software-Ökosystems zu diesem bestimmten Zeitpunkt mit Tausenden von Softwarepaketen, die in einer bestimmten Allzweckverteilung gebündelt sind. Stellen Sie sich jede dieser Versionen als einen Eiskern vor, der eine historische Aufzeichnung der atmosphärischen Bedingungen bewahrt. In diesem Fall handelt es sich jedoch um Software, die in der Zeit weitgehend "eingefroren" ist.

Die Herstellung einer robusten Linux-Distribution wie RHEL, Ubuntu oder Debian erfordert monumentale Anstrengungen, an denen Hunderte, wenn nicht Tausende von Ingenieuren beteiligt sind (viele sind bei der Distribution beschäftigt und viele weitere engagieren sich freiwillig in ihren eigenen Open-Source-Communities). Während die Benutzer die erste Version zu schätzen wissen, sind die laufende Wartung und Updates ebenso entscheidend. Die Betreuer, ob Community-Freiwillige oder kommerzielle Einheiten, stellen für einen definierten Zeitraum laufende Updates und Korrekturen für diese Pakete bereit, was letztendlich zum Ende des Lebenszyklus (End of Life, EOL) der Veröffentlichung führt. Diese Updates beheben Fehler, verbessern die Leistung, verbessern die Stabilität und, was vielleicht am wichtigsten ist, beheben Sicherheitslücken. Diese kritische Wartung und Unterstützung erreicht schließlich ihr Ende, unabhängig von der Bereitschaft des Benutzers oder der Organisation, so dass sie nicht unterstützte Software ausführen und selbst mit Schwachstellen oder Inkompatibilität umgehen können.

Die Realität einer eventuellen Obsoleszenz führt dazu, dass Benutzer ihre Aufmerksamkeit über laufende Patches und geringfügige Leistungsverbesserungen hinaus auf "Big Bang" -Upgrades richten. Diese wichtigen Versions-Upgrades sind notwendig für den Zugriff auf neue Funktionen, Hardware-Kompatibilität, Cloud-Verbesserungen, Leistungsverbesserungen und umfassendere Sicherheitsupdates, aber es entstehen erhebliche Kosten. Größere Upgrades sind immer zeitaufwändig und herausfordernd, bedrohen die Stabilität und Leistung und verlangsamen gleichzeitig die allgemeine Geschäftsgeschwindigkeit. Auch wenn Unternehmen und Hobbyisten die Notwendigkeit von Upgrades erkennen, fällt es Ihnen schwer, jemanden zu finden, der sich für die Aussicht begeistert, insbesondere für eine riesige Infrastrukturflotte.

Wenn es um traditionelle Linux-Distributionen geht, befinden sich viele Benutzer, die Open Source verwenden, zwischen diesem Felsen und einem harten Ort:

• Sie können sich auf inkrementelle Patches verlassen, solange eine bestimmte Distribution beibehalten wird. Das bedeutet, dass sie ihre veraltete Infrastruktur patchen müssen, um potenzielle Sicherheits- und Leistungsrisiken zu begrenzen, während sie nicht in der Lage sind, jeden Fix auf ihre stabile Umgebung zu übertragen;

• Oder sie können ein groß angelegtes "Urknall" -Upgrade versuchen, das neue Funktionen in aufstrebenden Bereichen wie KI liefern und einige ansonsten nicht gepatchte Sicherheitsprobleme lösen kann, aber auf Kosten enormer Anstrengungen, die Instabilität einführen. Darüber hinaus ist dies nur eine vorübergehende Lösung, da sie dies alle paar Jahre immer wieder tun müssen.

Distrokompromisse und goldene Imageanstrengungen

Dieser ständige Kompromiss führt zu einer Vielzahl von organisatorischen Problemen. Sicherheitsteams weisen ständig auf hohe CVE-Zahlen und Schwachstellen in der Software hin, die einer Vielzahl von Anwendungen und Prozessen zugrunde liegen, ohne dass ein klarer Weg zur Behebung besteht. Engineering-Teams verbringen unzählige Stunden und Entwicklerressourcen damit, Schwachstellen zu beheben, ohne die Leistung und Verfügbarkeit zu beeinträchtigen, während neue Funktionen und Innovationen entweder ausrangiert oder verzögert werden. Das Jonglieren widersprüchlicher Engineering- und Sicherheitsprioritäten führt letztendlich zu einer Art Kompromiss auf Vorstandsebene, unabhängig davon, ob dies ein höheres Risiko oder eine Verlangsamung der Innovation und möglicherweise der Umsatzsteigerung bedeutet.

Einige Organisationen haben versucht, diese Probleme intern zu lösen, mit Teams, die sich der DIY-Kuration von Softwarepaketen und maßgeschneiderten Distributionen durch Golden Image-Programme widmen. Diese gut gemeinten Bemühungen, die Sicherheits- und Standardisierungserwartungen und die Entwicklergeschwindigkeit zu überbrücken, fallen oft den Herausforderungen der heutigen Distributionsmodelle zum Opfer, die weniger ein Standardisierungsgremium als vielmehr einen Engpass darstellen, der von der Schatten-IT umgangen wird. Selbst mit diesen Programmen haben Unternehmen Schwierigkeiten, Lieferfristen einzuhalten oder neue Compliance-orientierte Märkte zu erschließen, da Open-Source-Kernsoftware entweder altern, anfällig oder beides ist.

Die Zeit für einen neuen Ansatz

All dies macht deutlich, dass das traditionelle Distributionsmodell trotz seiner Geschichte als grundlegende Komponente der Bereitstellung von Open-Source-Software zunehmend durch die Anforderungen an die Sicherheit und die ständig zunehmende Geschwindigkeit des modernen Computing herausgefordert wird. Um das Potenzial Cloud-nativer Technologien wirklich zu nutzen, müssen wir über die Grenzen der konventionellen Distribution hinausschauen und neue Paradigmen erforschen.

Im nächsten Beitrag dieser Serie schauen wir uns an, welche Kräfte einen Wendepunkt antreiben und was das für die moderne Softwareentwicklung bedeutet.

Wenn Sie dies nützlich fanden, lesen Sie unbedingt unser Whitepaper und den breiteren Ansatz, den wir zur Lösung dieses Problems für Unternehmen gewählt haben.