Red Hat chce, żeby programista mógł odetchnąć [WYWIAD]

Kamil Dudek, dobreprogramy: RHEL7 wprowadził bardzo duże zmiany - większe niż poprzednicy i następcy. Migracja na niego mogła być wymagająca - a teraz po dziesięciu latach zakończyło się dla niego wsparcie. Jak w przypadku każdego systemu, któremu kończy się support, powstaje pytanie o użytkowników, którzy pozostali w tyle. Na ile jest to zjawisko powszechne w przypadku produktów Red Hat i RHEL-a?

Wojciech Furmankiewicz, dyrektor Red Hat ds. technologii i rozwiązań w regionie Europy Środkowo-Wschodniej: Zmiana głównego numeru wersji jest obecnie dużo łatwiejsza. Istotnie, między odsłonami 6 i 7 różnice były większe, ale teraz jest inaczej. Udostępniamy odpowiednie narzędzia, które pozwalają wykryć potencjalne problemy przy upgradzie, w tym te z kompatybilnością. Nie zarejestrowaliśmy istotnych problemów, które wskazywałyby na trudności w jej przeprowadzeniu. Nasza baza wiedzy oraz dostępne narzędzia pozwalają gładko przejść przez tę operację. Wobec tego pozostawanie przy starych wersjach systemu należy rozważać w kategorii długu technologicznego.

KD: Jeżeli różnice między kolejnymi wydaniami systemów zacierają się, to jest to efekt ogólnych zmian w rozwoju technologii, czy może konkretnych decyzji? Na przykład, na ile CentOS Stream był tu przyczyną, a na ile skutkiem? I jak wygląda przyszłość "point releases", gdy wszystko wydaje się być produkowane w trybie ciągłym?

Dalsza część artykułu pod materiałem wideo

WF: Byłbym ostrożny z zakładaniem, że zmiany będą coraz mniejsze. Co jakiś czas pojawiają się innowacyjne pomysły, które wymuszają zupełnie nowe podejście, następnie obserwujemy proces stabilizacji. Przykładem jest Kubernetes: OpenShift, niegdyś pracujący w oparciu o inne rozwiązania, zaadoptował tę technologię, co wprowadziło rewolucję w całej architekturze rozwiązania. To była ogromna zmiana. Podobnie było też z systemd. Z dużą pewnością możemy założyć, że za jakiś czas nastąpi kolejna, rewolucyjna zmiana w tym lub innym obszarze. W tym kontekście wersje RHEL 8 i 9 są bardziej do siebie podobne niż ich poprzednicy, sam proces aktualizacji jest też bardziej przyjazny.

Co do odejścia od point releases, nie sądzę, żebyśmy z nich rezygnowali. Jest to aktywna odpowiedź na oczekiwania klientów, którzy potrzebują stabilności. Długi czas wsparcia pozwala im spokojniej planować modernizację i wewnętrzną certyfikację swoich aplikacji, skupiając się na funkcjach biznesowych zamiast nieustannie ścigać się z nowymi wersjami platformy. Taka certyfikacja jest kosztowna i musi być przewidywalna. Mamy też rozwiązania EUS i ELS, które pozwalają utrzymać się na danym wydaniu dłużej, jeżeli jest taka potrzeba.

Oczywiście utrzymywanie starszych wersji wiąże się z dodatkowym nakładem pracy, a ich użycie wynika z konkretnych priorytetów. Główna linia zawsze będzie rozwijała nowe funkcje, a przedłużone wsparcie jest dodatkową wartością, którą oferujemy naszym klientom.

KD: A jak wygląda sprawa ze wzrostem złożoności? Dotychczas było to ogólne pytanie (z hipotezą większe = gorsze), teraz pojawia się ono w kontekście dołączania np. narzędzi do obserwowalności i detekcji, jak pechowy niedawno Crowdstrike. Jak rozwiązania Red Hat radzą sobie w świecie, w którym złożoność rośnie?

WF: To kwestia jasnego podziału odpowiedzialności, a nie samej złożoności. Aplikacje w Red Hat OpenShift pracują pod rygorem silnych reguł bezpieczeństwa, które pomagają zwiększyć poziom bezpieczeństwa platformy. OpenShift dostarcza zaawansowane polityki obejmujące pełen cykl życia aplikacji. Jeżeli aplikacja jest z nimi niezgodna, domyślnie nie będzie możliwości jej uruchomienia.

KD: Tak, ale dzieje się to tylko w kwestii aplikacji. Co z samym systemem, orkiestratorem podów, zarządcą Kubernetesa? To przecież też jest jakiś OS.

WF: Cały łańcuch dostaw produktów Red Hat jest pod ścisłą kontrolą, przechodzi szereg rygorystycznych testów, zanim trafi do klienta. Zwykle nie ma potrzeby dodawania niczego z zewnątrz. Prostota jest jednym z naszych priorytetów. Owszem, samą wewnętrzną platformę charakteryzuje duży poziom złożoności, ale OpenShift ma się nią zajmować za nas. To samo dotyczy systemu RHEL CoreOS, który jest podstawą platformy. Obsługa tego systemu została ograniczona do minimum, aby w efekcie ułatwić jej używanie.

Jeżeli chodzi o obserwowalność samego klastra, to OpenShift dostarcza własne API, z którego wyjście możemy "przepuścić" przez systemy graficzne takie jak Grafana. Dodatkowo istnieje Service Mesh, gdzie wiele funkcji i mechanizmów nadzoru zachodzi w sposób, którego aplikacje nie muszą być świadome. Paradoksalnie dodatkowe funkcjonalności sprawiają, że programista może odetchnąć i zająć się rozwijaniem kodu.

Bezpieczeństwo to dla nas kolejny istotny priorytet, łatwość zdobycia informacji na temat stanu zabezpieczeń oraz aplikowania aktualizacji jest tu kluczowa. Dodatkowo cały cykl życia oprogramowania, od developmentu kodu po runtime jest ściśle monitorowany pod kątem spełniania rygorystycznych założeń. Jest to duża wartość i silna strona tego, co dostarczamy naszym klientom.

KD: Dziękuję za rozmowę.

Z udzielonych odpowiedzi wyłania się obraz wzrostu złożoności zachodzącego ze świadomością i pod kontrolą. Platforma nie rośnie poprzez inercję lub zaniedbania, a dostarczając rzeczywistą wartość. Otrzymujemy także zapewnienia o kontroli jakości - i istotnie nie słychać o redhatowych wpadkach z platformą. Czy oznacza odporność na ataki na łańcuch dostaw?

Operacja przejęcia projektu XZ prawie się powiodła. Odkryto ją przez przypadek. Złośliwy XZ nigdy nie pojawił się w Red Hacie... ale przez chwilę był w Fedorze. Tylko, że był to problem wszystkich dystrybucji, także tych bez kontroli jakości. Można postulować, że tworzenie całego kodu in-house rozwiązałoby problem… ale czy naprawdę taki Microsoft, stosujący właśnie ten model, jest tu znacząco bardziej godny zaufania?