Przemyślenie wydań z długoterminowym wsparciem

Tradycyjnie wydania systemów operacyjnych z długoterminowym wsparciem stanowiły ostoję wdrożeń korporacyjnych. To model stosowany przez IBM, Oracle, Microsoft, Suse i Red Hat i stanowiący konwencjonalne myślenie o systemach operacyjnych od początku ofert wsparcia wiele dekad temu.

W przeszłości zarówno serwery, jak i desktopowe wydania systemów operacyjnych powszechnie podążały za tym modelem, jednak w przestrzeni Linux w szczególności zaczęliśmy obserwować jego przełamywanie, gdy mniej formalne produkty mogły eksperymentować z szybszymi, nieobsługiwanymi lub po prostu nieustrukturyzowanymi wydaniami. W głównej przestrzeni produktowej openSuse, Fedora i Ubuntu wszystkie oferowały wydania krótkoterminowe lub szybkie. Zamiast cykli wydań mierzonych w latach i cykli wsparcia zbliżających się do dekady, skróciły cykle wydań do miesięcy, a wsparcie do zaledwie kilku miesięcy lub maksymalnie kilku lat.

W przestrzeni desktopowej szybsze uzyskiwanie nowych funkcji i aplikacji – zamiast skupiania się przede wszystkim na stabilności, jak było to powszechne na serwerach – często miało sens i przynosiło dodatkową korzyść w postaci możliwości testowania nowych technologii lub podejść na produktach z szybszym cyklem wydań przed ich integracją w produktach serwisowych z długoterminowym wsparciem. Fedora na przykład jest poligonem doświadczalnym dla technologii, które po udowodnieniu swojej wartości trafią do wydań Red Hat Enterprise Linux. Dzięki używaniu Fedory użytkownicy końcowi otrzymują funkcje szybciej, wcześniej dowiadują się o technologiach RHEL, a Red Hat może testować produkty na dużą skalę przed wdrożeniem na krytycznych serwerach.

Z biegiem czasu stabilność wydań krótkoterminowych poprawiła się dramatycznie i coraz częściej systemy te są postrzegane jako opcje przydatne dla systemów serwerowych. Systemy te otrzymują nowsze ulepszenia, funkcje i aktualizacje wcześniej, co jest często postrzegane jako korzystne.

Główną zaletą każdego systemu operacyjnego jest jego ekosystem wsparcia, w tym pakiety i biblioteki obsługiwane i dostarczane jako część bazowego systemu operacyjnego. W przypadku wydań długoterminowych często obserwujemy, jak krytyczne pakiety gwałtownie się starzeją przez cały czas trwania wydania, co może powodować problemy z wydajnością, kompatybilnością, a nawet bezpieczeństwem w ekstremalnych przypadkach. To oczywiście zmusza użytkowników długoterminowych wydań systemów operacyjnych do wyboru pomiędzy kontynuowaniem życia z ograniczeniami starszych komponentów a integracją nowych komponentów na własną rękę, co często podważa fundamentalną wartość produktu z długoterminowym wydaniem.

Ponieważ celem wydania długoterminowego jest stabilność i testowanie integracji, zastępowanie komponentów w produkcie w celu „obejścia" ograniczeń LTS oznacza, że te komponenty nie są traktowane w sposób właściwy dla LTS i że testowanie integracji przez dostawcę prawdopodobnie już nie zachodzi, lub jeśli tak, to nie w tym samym stopniu. W efekcie staje się to samodzielnie zbudowanym produktem z krótkoterminowym wydaniem, ale ze starszymi komponentami rdzennymi i mniejszym nadzorem.

W rzeczywistości pod wieloma względami jest to gorsze niż bezpośrednie przejście do produktu z krótkoterminowym wydaniem. Używanie produktu z krótkoterminowym lub szybkim wydaniem pozwala dostawcy zachować zakładane testowanie i integrację, tylko z szybszym cyklem wydań i wsparcia, tak że ogólna wartość koncepcji wydania długoterminowego jest zachowana i z wszystkimi komponentami systemu operacyjnego, a nie tylko kilkoma, będącymi aktualizowanymi. Pozwala to na większą standaryzację, testowanie branżowe, wspólną wiedzę i integrację niż w przypadku częściowego modelu LTS.

Być może nadszedł czas, aby przemyśleć wartość długoterminowego wsparcia dla systemów operacyjnych. Przez zbyt długi czas wydaje się, że wartość tego podejścia była po prostu zakładana i stosowana, i z pewnością miała i ma swoje zalety; jednak świat systemów operacyjnych zmienił się od czasu, gdy to podejście zostało po raz pierwszy wprowadzone. Potrzeba aktualizacji wzrosła, podczas gdy tempo zmian w takich elementach jak jądra i biblioteki dramatycznie spowolniło. Potężniejsze serwery przeniosły kompatybilność wyżej w stosie i zamiast oprogramowania pisanego pod system operacyjny, często jest ono pisane pod konkretną wersję języka lub środowiska uruchomieniowego albo innej warstwy abstrakcji.

Krótsze cykle wydań oznaczają, że systemy otrzymują funkcje, od góry do dołu, częściej. Aktualizacje pomiędzy „głównymi" wydaniami są mniejsze i mniej odczuwalne. Zmiany z aktualizacji są bardziej przyrostowe, zapewniając bardziej organiczną krzywą uczenia się i adaptacji. A co najważniejsze, potrzeba zastępowania komponentów systemowych starannie przetestowanych i zintegrowanych wersjami dostarczonymi przez strony trzecie staje się, praktycznie rzecz biorąc, niespotykana.

Stabilność dla dostawców oprogramowania pozostaje wartością dla wydań długoterminowych i spowoduje, że będą one potrzebne przez jeszcze długi czas. Jednak dla administratora systemu wartość tego podejścia wydaje się maleć i osobiście czuję, że w ostatnich latach osiągnęła punkt przegięcia. Kiedyś wydawało się oczekiwane i normalne czekanie dwa lub trzy lata na aktualizację pakietów, ale dziś to wydaje się niepotrzebnie uciążliwe. Coraz powszechniej wyżej poziomowe komponenty są budowane z wymogiem nowszych komponentów bazowych; oczekiwanie, że systemy operacyjne będą albo bardziej aktualne, albo że części systemu operacyjnego będą aktualizowane oddzielnie od reszty.

Silne poleganie na technologiach konteneryzacji może częściowo odwrócić ten trend, ale w sposób, który zawsze jednocześnie zmniejsza wartość wydań długoterminowych. Konteneryzacja redukuje potrzebę rozległych możliwości w bazowym systemie operacyjnym, czyniąc łatwiejszym i skuteczniejszym częstsze aktualizowanie go w celu poprawy wsparcia jądra, systemu plików, sterowników i kontenerów, pozostawiając biblioteki i inne zależności w kontenerach, co pozwala aplikacjom wymagającym długoterminowych zależności wsparcia być spełnionymi w ten sposób, a aplikacjom mogącym skorzystać z nowszych komponentów być obsługiwanym w ten sposób.

Oczywiście wirtualizacja odegrała rolę w zmniejszaniu wartości modeli długoterminowego wsparcia, czyniąc szybkie odtwarzanie i duplikowanie systemów prostą czynnością. Stabilność, której potrzebowaliśmy od wydań długoterminowych, jest częściowo zapewniana przez warstwę wirtualizacji; abstrakcja sprzętowa poprawia stabilność sterowników w bardzo ważny sposób. W tym samym duchu, modele wsparcia w stylu devops również redukują potrzebę długoterminowego wsparcia i sprawiają, że ekosystemy serwerowe są bardziej zwinne i elastyczne. Trendy w paradygmatach administracji systemami zmierzają ku bardziej nowoczesnym systemom operacyjnym.

Czas pokaże, czy trendy nadal zmierzają w kierunku, w którym zmierzają. Dla mnie osobiście miniony rok był otwierającym oczy doświadczeniem, które sprawiło, że przeniosłem swoje własne obciążenia po dekadzie zdecydowanego popierania produktów z bardzo długoterminowym wsparciem do produktów z szybkimi wydaniami i muszę powiedzieć, że jestem bardzo zadowolony ze zmiany.