Rynek pracy upomina się o OpenShift – technologia znów na fali — co stoi za tym trendem?

Jeśli śledzisz ogłoszenia o pracę w DevOps w Polsce i Europie Środkowej, zauważyłeś prawdopodobnie ten sam trend: OpenShift pojawia się coraz częściej — w ogłoszeniach, gdzie rok temu królował „Kubernetes". Nie jest to zbieg okoliczności. Za tym wzrostem stoi kilka równoległych procesów rynkowych, które zbiegają się właśnie teraz.

Trzy czynniki napędzające popyt

1. Zakup Broadcom kupił VMware — i zmienił reguły gry

To prawdopodobnie największy pojedynczy czynnik napędzający popyt na OpenShift w ostatnich dwóch latach.

Gdy Broadcom sfinalizował przejęcie VMware w październiku 2023 roku za 61 miliardów dolarów, rynek spodziewał się zmian. Nikt jednak nie spodziewał się ich skali i tempa. W ciągu kilku miesięcy Broadcom wycofał wszystkie bezterminowe licencje VMware, zastępując je wyłącznie subskrypcjami. Popularne pakiety jak vSphere Essentials — dostępne wcześniej za ułamek obecnych kosztów — zniknęły z oferty. Ceny dla wielu organizacji wzrosły kilkukrotnie z dnia na dzień.

Efekt domina był natychmiastowy: działy IT na całym świecie dostały zadanie znalezienia alternatywy. Dla organizacji enterprise — szczególnie tych z setkami lub tysiącami maszyn wirtualnych, złożonymi środowiskami sieciowymi
i wymaganiami regulacyjnymi — przeprowadzka na vanilla Kubernetes bez supportu i bez enterprise governance była nie do przyjęcia. OpenShift trafił na te listy jako pierwsza odpowiedź.

Red Hat potwierdziło ten trend: w 2024 i 2025 roku odnotowało rekordową liczbę konwersji klientów VMware na OpenShift — szczególnie w sektorze finansowym
i publicznym.

2. IngressNightmare — architektoniczne zmiany pod presją

IngressNightmare dotknął 43% środowisk Kubernetes z ingress-nginx— podatność, która wstrząsnęła ekosystemem na początku 2026 roku i zmusiła organizacje do rewizji fundamentalnych wyborów architektonicznych.

Organizacje dotknięte IngressNightmare zadały sobie pytanie, którego wcześniej unikały: czy budujemy i utrzymujemy bezpieczną platformę Kubernetes samodzielnie, z własnym zestawem narzędzi, własnym procesem reagowania na podatności i własnym zespołem — czy korzystamy z platformy, gdzie ktoś inny bierze za to odpowiedzialność?

OpenShift używa własnego Ingress Operatora opartego na HAProxy — komponentu zarządzanego przez Red Hat, aktualizowanego przez Red Hat,
z gwarantowanymi oknami czasowymi na łatki bezpieczeństwa. Dla CISO
i dyrektorów IT, którzy w 2026 roku wyjaśniali zarządom dlaczego ich platforma była podatna — to argument trudny do odrzucenia.

3. Presja regulacyjna — DORA i NIS2

Dyrektywa DORA (Digital Operational Resilience Act) weszła w życie 17 stycznia 2025 roku i objęła wszystkie instytucje finansowe w UE — banki, ubezpieczycieli, domy maklerskie, dostawców usług płatniczych. NIS2 rozszerzyła wymagania cyberbezpieczeństwa na kolejne sektory.

Obie dyrektywy mają konkretne implikacje dla platform Kubernetes: wymagana jest dokumentacja łańcucha dostaw oprogramowania, audytowalna historia zmian konfiguracji, testowanie odporności operacyjnej i zarządzanie ryzykiem dostawców zewnętrznych.

OpenShift dostarcza te możliwości out of the box: wbudowane zarządzanie politykami bezpieczeństwa przez Security Context Constraints, operator Compliance Operator dla auditowania konfiguracji pod kątem CIS Benchmarks
i standardów regulacyjnych, pełny łańcuch dostaw z podpisanymi obrazami przez Red Hat Image Registry i SBOM dla wszystkich komponentów platformy.

Dla działu prawnego i compliance — Red Hat jest jednym dostawcą z kontraktem Enterprise Agreement, certyfikatami FIPS i Common Criteria oraz odpowiedzialnością kontraktową. Vanilla Kubernetes zbudowany z 15 projektów open source nie oferuje porównywalnego modelu odpowiedzialności.

OpenShift vs vanilla Kubernetes

Powiedzenie „OpenShift to Kubernetes" jest prawdziwe i jednocześnie mylące. OpenShift jest zbudowany na Kubernetes — ale dodaje do niego warstwę gotowych rozwiązań, narzędzi i governance, która fundamentalnie zmienia charakter platformy. Nie zawsze na plus.

Gdzie OpenShift ma przewagę

Sektory regulowane i korporacje. Banki, ubezpieczyciele, sektor publiczny, ochrona zdrowia — wszędzie gdzie istnieją wymagania dotyczące audytowalności, certyfikacji bezpieczeństwa
i odpowiedzialności dostawcy. OpenShift dostarcza Compliance Operator, Advanced Cluster Security (ACS/StackRox), wbudowane podpisywanie obrazów
i wielowarstwowy model RBAC z pełną integracją Active Directory/LDAP.

Mniejsze zespoły platformowe z dużymi klastrami. OpenShift operacjonalizuje wiele decyzji, które w vanilla Kubernetes trzeba podjąć samodzielnie: domyślna konfiguracja sieci (OVN-Kubernetes), domyślna polityka bezpieczeństwa (Security Context Constraints zamiast PodSecurityAdmission), wbudowane pipeline'y CI/CD (Tekton i OpenShift Pipelines), wbudowany GitOps (ArgoCD jako OpenShift GitOps). Dla pięcioosobowego zespołu zarządzającego 50 klastrami — gotowe rozwiązania są wartością, nie ograniczeniem.

Środowiska wielochmurowe i hybrydowe. Red Hat Advanced Cluster Management (RHACM) dostarcza zunifikowany plan zarządzania dla wielu klastrów OpenShift — on-premises, na AWS (ROSA), Azure (ARO) i Google Cloud (RHOIC). Zarządzanie politykami, obserwowalnością
i wdrożeniami przez jeden panel, niezależnie od lokalizacji klastra.

Migracja z VMware. OpenShift Virtualization (poprzednio KubeVirt) pozwala uruchamiać maszyny wirtualne bezpośrednio w klastrze OpenShift — ten sam klaster obsługuje kontenery i maszyny wirtualne. Dla organizacji migrujących
z vSphere: istniejące VM mogą działać w OpenShift przez OpenShift Virtualization podczas gdy aplikacje są stopniowo konteneryzowane. Nie trzeba migrować wszystkiego naraz.

Gdzie vanilla Kubernetes ma przewagę

Małe i średnie organizacje z dojrzałym zespołem DevOps. Jeśli masz doświadczony zespół, który zna Kubernetes w głąb i w poprzek — opinie OpenShifta mogą być ograniczeniem zamiast pomocą. Vanilla Kubernetes
z własnym stosem narzędzi (Cilium, ArgoCD, Falco, cert-manager) daje pełną kontrolę i brak „magii", którą trudno debugować.

Startupy i środowiska cloud-native od podstaw. Zarządzane Kubernetes (AKS, EKS, GKE) z dobrze dobranym stosem narzędzi jest prostszy operacyjnie
i tańszy licencyjnie niż OpenShift dla organizacji bez działu IT odziedziczonego po erze VMware.

Środowiska edge i IoT. MicroShift (minimalny OpenShift dla edge) istnieje, ale K3s, RKE2 i K0s są lepiej dostosowane do ograniczonych zasobów sprzętowych
i nierównej łączności.

Budżet. OpenShift z Red Hat Enterprise Linux jest znaczącym kosztem licencyjnym. Dla organizacji bez budżetu enterprise — vanilla Kubernetes
z AlmaLinux lub Rocky Linux jest funkcjonalnie równoważny przy ułamku kosztów.

Migracja z VMware na OpenShift — jak to wygląda w praktyce

Migracja z VMware na OpenShift to nie jest jeden projekt — to wieloetapowa transformacja, która w dużych organizacjach trwa 12–36 miesięcy. Oto jak wygląda realistyczna ścieżka.

Etap 1 — Inwentaryzacja i stratyfikacja workloadów

Zanim cokolwiek zmigruje, trzeba odpowiedzieć na pytanie: co właściwie mamy? Typowa organizacja z setkami VM ma mieszankę:

• Aplikacje konteneryzowalne — te przejdą na OpenShift natywnie
• Aplikacje legacy wymagające VM — te trafią do OpenShift Virtualization
• Aplikacje EOL — okazja do wyłączenia zamiast migracji
• Aplikacje zakupione od zewnętrznych dostawców — zależne od roadmapy dostawcy

Red Hat Migration Toolkit for Virtualization (MTV) automatyzuje import VM z VMware do OpenShift Virtualization — konwertuje formaty dysku, przenosi konfigurację sieci i mapuje polityki bezpieczeństwa. Dla prostych VM to proces w dużej mierze zautomatyzowany. Dla złożonych środowisk z sieciami VLAN, storage'em SAN i zależnościami między VM — wymaga manualnej interwencji.

Etap 2 — Infrastruktura platformy

OpenShift wymaga własnej infrastruktury obliczeniowej. Organizacje mają trzy ścieżki:

Bare metal — najwyższa wydajność, pełna kontrola, najwyższy nakład operacyjny. Rekomendowane dla środowisk z wymaganiami regulacyjnymi dotyczącymi suwerenności danych.

Istniejące VMware jako hypervisor (przejściowo) — OpenShift może działać jako VM na vSphere podczas gdy docelowa infrastruktura jest budowana równolegle. To najczęstsza ścieżka dla dużych organizacji — pozwala na stopniowe przenoszenie workloadów bez ryzyka „wielkiego wybuchu".

Chmura publiczna — ROSA (AWS), ARO (Azure), RHOIC (IBM Cloud) eliminują zarządzanie infrastrukturą platformy całkowicie. Dla organizacji, które chcą uciec od zarządzania infrastrukturą — nie tylko od VMware.

Etap 3 — Sieć i storage

To zwykle najtrudniejszy etap migracji z VMware.

Sieć: VMware NSX mapuje się na OVN-Kubernetes w OpenShift, ale mapowanie nie jest jeden-do-jednego. Logiczne przełączniki, rozproszone routery i polityki bezpieczeństwa NSX muszą być przetłumaczone na NetworkPolicies i EgressFirewall w OpenShift. Dla złożonych topologii — wymaga specjalisty od sieci.

Storage: VMware vSAN nie ma bezpośredniego odpowiednika w OpenShift. Ścieżki: Red Hat OpenShift Data Foundation (ODF, bazuje na Rook/Ceph), NetApp Trident dla istniejącej infrastruktury NetApp, lub dostawcy CSI dla konkretnych backendów. ODF jest rekomendowanym wyborem dla nowych wdrożeń, ale wymaga dedykowanych węzłów storage i jest znaczącym kosztem.

Etap 4 — Aplikacje i CI/CD

Konteneryzacja aplikacji to temat na osobny artykuł. Kluczowe narzędzia Red Hat w tym etapie to Migration Toolkit for Applications (MTA) do analizy i migracji aplikacji Java/JEE, oraz Source-to-Image (S2I) i Buildah dla budowania obrazów bez Dockerfile'ów.

Pipeline'y CI/CD migrują na OpenShift Pipelines (Tekton) lub zachowują istniejące narzędzia (Jenkins, GitLab CI) połączone z OpenShift przez standardowe API Kubernetes.

Co to oznacza dla rynku pracy

Rosnące zapotrzebowanie na OpenShift to nie trend chwilowy — to konsekwencja długoterminowych zmian strukturalnych: konsolidacji VMware, presji regulacyjnej i rosnącej złożoności środowisk. Organizacje, które migrują teraz, będą potrzebować specjalistów OpenShift przez co najmniej 5–7 lat.

Profil poszukiwany przez pracodawców jest bardzo konkretny: znajomość Kubernetes w głąb (nie tylko kubectl apply), doświadczenie z zarządzaniem klastrami w środowiskach produkcyjnych, znajomość sieci (CNI, NetworkPolicies, SDN), bezpieczeństwo (RBAC, PSA/SCC, image scanning) i — coraz częściej — doświadczenie z GitOps i IaC.

Różnica między inżynierem Kubernetes a inżynierem OpenShift jest mniejsza niż sugerują ogłoszenia. Większość konceptów przenosi się bezpośrednio — OpenShift dodaje warstwę narzędzi i rozwiązań na solidnym fundamencie Kubernetes. Dla kogoś z solidnym doświadczeniem Kubernetes, przestawienie się na OpenShift to tygodnie, nie miesiące.

Podsumowanie

Trzy siły napędzają popyt na OpenShift w 2026 roku: migracja post-VMware szukająca alternatywy klasy enterprise, presja regulacyjna DORA i NIS2 wymagająca audytowalnych platform z odpowiedzialnością dostawcy i IngressNightmare jako katalizator rewizji architektonicznych wyborów.

OpenShift nie jest odpowiedzią dla wszystkich — małe organizacje z dojrzałymi zespołami DevOps i cloud-native startupy lepiej obsługuje vanilla Kubernetes. Ale dla sektora finansowego, publicznego i każdej dużej organizacji dziedziczącej infrastrukturę VMware — OpenShift jest w 2026 roku poważną odpowiedzią na poważny problem.

Źródła: Red Hat OpenShift Documentation, CNCF Cloud Native Survey 2025, Wiz Research (IngressNightmare), European Banking Authority (DORA implementation), devnewsletter.com State of DevOps 2026