O co właściwie chodzi w sporze Kubernetes vs serverless
Za wyborem między Kubernetes a serverless rzadko stoi czysto techniczne pytanie. Bardziej chodzi o to, co chcesz skalować: infrastrukturę, ludzi czy produkt. Oba podejścia potrafią obsłużyć ogromny ruch, ale wymagają innego stylu pracy, innych kompetencji i innego podejścia do kosztów.
Jeśli zastanawiasz się: „które podejście lepiej skalować w IT?”, tak naprawdę pytasz o kilka rzeczy naraz: jak tanio obsłużyć duży ruch, jak nie utonąć w złożoności operacyjnej i jak szybko dowozić nowe funkcje. Do tego dochodzi jeszcze kwestia ryzyka – vendor lock‑in w serverless kontra złożoność zarządzania klastrem Kubernetes.
Patrząc na skalowanie, zwykle ścierają się cztery główne problemy:
- Ruch – skoki obciążenia, sezony, kampanie marketingowe, nagłe piki.
- Złożoność – rosnąca liczba serwisów, integracji, środowisk i zależności.
- Koszty – rachunki chmurowe, ale też koszt pracy ludzi i ryzyko „przepalenia” budżetu.
- Prędkość dostarczania – jak szybko zespół jest w stanie zareagować na zmiany biznesowe.
Kluczowe pytanie, które dobrze zadać sobie na starcie, brzmi: jaki masz horyzont czasowy i budżetowy? Chcesz przetrwać pół roku do product‑market fit, czy budujesz platformę na 5–10 lat? Masz budżet na stały zespół DevOps/SRE, czy raczej liczysz na gotowe usługi?
Jeśli budujesz produkt, który może nie przetrwać pierwszych 6 miesięcy, agresywna inwestycja w rozbudowany klaster Kubernetes i skomplikowaną infrastrukturę może być zupełnie nieproporcjonalna. Z kolei jeśli rozwijasz system krytyczny, który musi przeżyć wiele lat, ścisłe związanie się z jednym dostawcą serverless może boleśnie się zemścić.
Warto doprecyzować: czego już próbowałeś? Masz za sobą pierwsze wdrożenia mikrousług na maszynach wirtualnych? A może zespół działa dotąd w architekturze monolitu na jednym serwerze? Odpowiedź zmienia sensownie dostępne ścieżki migracji i może przesunąć środek ciężkości w stronę Kubernetes albo serverless.
Podstawy – czym jest Kubernetes, a czym serverless (bez marketingu)
Kubernetes w praktyce zespołu developerskiego
Kubernetes to system orkiestracji kontenerów, który przypomina warstwę „systemu operacyjnego” dla klastrów. Z punktu widzenia zespołu developerskiego oznacza to, że aplikacje pakuje się w kontenery (np. Docker), a Kubernetes rozmieszcza je na dostępnych węzłach (maszynach), dba o ich replikację, restart, sieć, konfigurację i część bezpieczeństwa.
W praktyce na co dzień pracujesz głównie z takimi obiektami jak:
- Deployments – definicje jak uruchamiać daną aplikację (kontener) i ile mieć replik.
- Pods – najmniejsze jednostki pracy (zwykle 1 kontener z aplikacją + sidecary).
- Services – stabilne adresy/endpointy wewnątrz klastra dla innych usług.
- Ingress – zasady wystawiania usług na zewnątrz klastra (HTTP/HTTPS).
Zespół zyskuje dużą kontrolę: może decydować o zasobach (CPU/memory), politykach rolloutów, strategiach aktualizacji, rozkładzie ruchu. W zamian bierze na siebie istotną część złożoności: utrzymanie klastra, aktualizacje Kubernetes, monitoring, bezpieczeństwo, storage, backupy. Nawet jeśli używasz managed K8s (EKS, AKS, GKE), znika tylko część problemów – w praktyce trzeba mieć ludzi, którzy rozumieją działanie klastra.
Stąd pytanie kontrolne: czy masz już zespół z doświadczeniem kontenerowym i DevOps, czy dopiero zaczynasz? Jeśli dopiero uczysz się podstaw Docker i CI/CD, pełny Kubernetes może być zbyt dużym skokiem na start.
Serverless jako model wykonania, nie tylko „funkcje”
Serverless bywa utożsamiany z funkcjami FaaS (Function as a Service), jak AWS Lambda, Azure Functions czy Google Cloud Functions. W rzeczywistości chodzi o model wykonania, gdzie:
- nie zarządzasz serwerami ani klastrami (to robi dostawca chmury),
- płacisz głównie „pay per use” – za wywołania, czas CPU, pamięć, transfer,
- skalowanie w górę/w dół realizuje automatycznie platforma.
Do serverless zalicza się nie tylko FaaS, ale też szereg usług zarządzanych: bazy danych (RDS/Aurora Serverless, DynamoDB, Cosmos DB), kolejki (SQS, Pub/Sub), narzędzia orkiestracji (Step Functions, Logic Apps) czy serwery HTTP w stylu API Gateway. Całą infrastrukturę traktujesz jak klocki, które składasz, zamiast budować je samodzielnie na maszynach lub w Kubernetes.
Kluczowe jest to, że oddajesz kontrolę nad wieloma aspektami (m.in. nad sposobem skalowania, patchowaniem, topologią sieci), a w zamian otrzymujesz szybkość i prostotę. W wielu projektach oznacza to, że mniejszy zespół jest w stanie osiągnąć więcej, ale musi mocno grać w rytm wybranego dostawcy chmury.
Najczęstsze mity: „brak serwerów” i „Kubernetes zrobi wszystko za mnie”
Dwa utrwalone mity potrafią mocno wypaczyć decyzję:
- „Serverless to brak serwerów” – serwery są, tylko zajmuje się nimi dostawca. Nadal istnieją limity CPU, pamięci, równoległości i czasy zimnego startu. Różnica jest taka, że nie masz bezpośredniego wpływu na to, jak te serwery są zarządzane.
- „Kubernetes załatwi wszystko sam” – Kubernetes ułatwia automatyzację, ale nic nie dzieje się „magicznie”. Kiedy HPA ma skalować? Na podstawie jakich metryk? Jakie limity pamięci ustawić? Kto reaguje, gdy autoscaler klastra nie może już dodać nowych węzłów? To wszystko wymaga świadomych decyzji.
Jeśli aktualnie stoisz przed wyborem, dobrze zadać sobie pytanie: gdzie wolisz mieć złożoność – po swojej stronie czy u dostawcy? W Kubernetes większość szczegółów konfigurujesz sam. W serverless konfiguracji jest mniej, ale płacisz ograniczeniami platformy, specyficznymi limitami i ryzykiem vendor lock‑in.
Jak skalują się aplikacje na Kubernetesie – mechanika skalowania
HPA, VPA i inne mechanizmy automatycznego skalowania
W Kubernetes skalowanie w praktyce oznacza manipulowanie liczbą podów (replik kontenerów) i zasobami przypisanymi do tych podów. Główne narzędzia to:
- Horizontal Pod Autoscaler (HPA) – automatycznie zwiększa lub zmniejsza liczbę replik danego deploymentu, bazując na metrykach (zwykle CPU, czasem pamięć lub niestandardowe metryki).
- Vertical Pod Autoscaler (VPA) – dostosowuje przydział CPU/memory dla pojedynczego poda, tak by odpowiadał faktycznemu zużyciu.
- Cluster Autoscaler – zwiększa lub zmniejsza liczbę węzłów (maszyn) w klastrze w zależności od zapotrzebowania na zasoby.
Te narzędzia muszą ze sobą współgrać. Przykładowo: HPA może chcieć podnieść liczbę replik z 10 do 50. Jeśli klaster nie ma wystarczających zasobów, wchodzi do gry Cluster Autoscaler i próbuje dołożyć węzły. Jeżeli polityki chmurowe lub limity budżetowe na to nie pozwalają, skalowanie się zatrzyma, a aplikacja zacznie odpowiadać wolniej lub z błędami.
Dlatego konfiguracja HPA/VPA nie powinna być robiona „na czuja”. Trzeba przeanalizować realne zużycie, wymagania SLA oraz to, jak szybko chcesz reagować na skoki ruchu. Zbyt agresywne skalowanie może powodować fluktuacje, zbyt zachowawcze – przeciążenia.
Skalowanie w górę, w dół i w szerz w Kubernetes
W Kubernetes możesz skalować w trzech wymiarach:
- W szerz (scale out/in) – dodajesz lub odejmujesz repliki (pody). To jest główne zadanie HPA.
- W górę (scale up) – przydzielasz więcej CPU i pamięci pojedynczym podom lub zwiększasz rozmiar węzłów w klastrze.
- W dół (scale down) – ograniczasz zasoby lub liczbę replik, by nie przepalać budżetu.
Kluczową rolę odgrywają requests i limits dla zasobów. Request mówi schedulerowi, ile minimalnie zasobów potrzebuje pod, limit – ile może maksymalnie zużyć. Źle ustawione wartości skutkują sytuacjami, gdzie:
- pody są duszone throttlingiem CPU lub OOMKillami (brak pamięci),
- klaster jest niedowykorzystany, bo każdy pod „rezerwuje” za dużo zasobów.
Do tego dochodzą strategie deploymentu (RollingUpdate, Blue/Green, Canary), które decydują, jak szybko nowe wersje serwisu wchodzą do ruchu. Przy dużej skali źle dobrana strategia potrafi jednocześnie obciążyć mocno stary i nowy kod, doprowadzając do spirali autoskalowania.
Przykład: kampania marketingowa i 10x więcej ruchu
Wyobraź sobie aplikację webową działającą na Kubernetes, obsługującą średnio umiarkowany ruch. Marketing uruchamia dużą kampanię, ruch rośnie dziesięciokrotnie w ciągu godziny. Co się dzieje?
- Metryki (np. CPU na podach) zaczynają rosnąć. HPA widzi, że przekroczono ustalony próg (np. 70% CPU).
- HPA podnosi liczbę replik z np. 5 do 20 w kilku krokach, zgodnie z konfiguracją stabilizationWindow i tempa wzrostu.
- Scheduler próbuje ulokować nowe pody na istniejących węzłach. Jeśli brak miejsca – Cluster Autoscaler uruchamia dodatkowe węzły w chmurze.
- Nowe pody przechodzą proces startu, readiness/liveness probes, aż zaczną serwować ruch.
- Po zakończeniu kampanii ruch spada, HPA zaczyna stopniowo zmniejszać liczbę replik, a Cluster Autoscaler usuwa nieużywane węzły.
Na papierze brzmi to idealnie. W praktyce całość zależy od:
- jakości metryk (prometheus/metrics‑server),
- poprawnych requestów/limitów, by uniknąć thrashingu,
- opóźnień dostawcy chmury w dodawaniu nowych węzłów,
- sprawności samej aplikacji (np. rozgrzewania cache, połączeń do bazy).
Dlatego tak ważne jest wykonanie testów obciążeniowych i sprawdzenie, jak klaster Kubernetes reaguje na realistyczne skoki ruchu. Masz już takie testy dla swoich aplikacji?
Jak skalują się rozwiązania serverless – model zdarzeniowy w praktyce
Funkcje jako reakcje na zdarzenia
W modelu serverless centrum świata stanowią zdarzenia. Funkcje FaaS uruchamiają się w reakcji na:
- żądania HTTP (API Gateway → Lambda/Azure Function),
- wiadomości z kolejek (SQS, Pub/Sub),
- zmiany w storage (wgranie pliku do S3/Blob Storage),
- zdarzenia z innych usług (bazy, IoT, cron/scheduled events).
Platforma serverless automatycznie skaluje liczbę równolegle działających instancji funkcji w odpowiedzi na liczbę zdarzeń. Jeśli przychodzi tysiąc żądań na sekundę, dostawca powołuje tyle instancji, ile potrzeba (w granicach limitów), by je obsłużyć. Jeśli ruch spada do zera – instancje są ubijane.
Deweloper nie musi się zastanawiać, ile maszyn czy kontenerów uruchomić. Skupia się na logice biznesowej i kontraktach zdarzeń. W tym sensie skalowanie „dzieje się samo”, choć nadal trzeba rozumieć granice platformy.
Skalowanie do zera i problem cold start
Jedną z największych przewag serverless jest możliwość skalowania do zera. Gdy nie ma ruchu, nie płacisz za zasoby wykonawcze (płacisz ewentualnie za storage, logi, minimalne koszty usług towarzyszących). To czyni serverless bardzo atrakcyjnym przy nieregularnym ruchu, prototypach i usługach pomocniczych.
Ceną jest cold start – opóźnienie związane z pierwszym uruchomieniem instancji funkcji. Obejmuje:
- przydział zasobów przez dostawcę (kontenery/VM w tle),
- inicjalizację środowiska wykonawczego (runtime języka),
- ładowanie kodu i zależności,
- wstępne nawiązanie połączeń (np. do bazy, cache, API).
Czy zauważyłeś u siebie losowe skoki opóźnienia przy pierwszych requestach po dłuższej przerwie? To właśnie efekt cold startu. Da się go częściowo ograniczyć:
- trzymając funkcje małe, z minimalnym zestawem zależności,
- wybierając lżejszy runtime (np. Go zamiast ciężkiego Pythona z masą bibliotek),
- stosując mechanizmy „rozgrzewania” (periodic pingi, provisioned concurrency w AWS),
- masz lub planujesz stały zespół DevOps/SRE,
- zarządzasz wieloma usługami/mikroserwisami, integracjami, środowiskami,
- projekt ma żyć lata i chcesz ograniczyć vendor lock‑in.
Najczęściej zadawane pytania (FAQ)
Kubernetes czy serverless – co lepiej się skaluje przy dużym ruchu?
Oba podejścia świetnie radzą sobie z dużym ruchem, ale w inny sposób. Kubernetes daje pełną kontrolę nad tym, jak działa autoskalowanie (HPA, VPA, Cluster Autoscaler), za to wymaga ludzi, którzy rozumieją klaster i potrafią go dobrze skonfigurować. Serverless przerzuca większość mechaniki skalowania na dostawcę chmury – łatwiej zacząć, ale mocniej wchodzisz w konkretne limity i sposób działania platformy.
Zadaj sobie pytanie: jaki masz zespół i horyzont czasowy? Jeśli chcesz szybciej dowieźć MVP i przetrwać pierwsze miesiące bez rozbudowanego działu DevOps, serverless zwykle będzie prostszy. Jeśli budujesz długoterminową platformę i liczysz na duży, przewidywalny ruch, Kubernetes pozwoli ci precyzyjnie sterować kosztami i zachowaniem przy pikach obciążenia.
Kiedy wybrać Kubernetes, a kiedy serverless w nowym projekcie?
Dla krótkiego horyzontu (walka o product–market fit, niepewny model biznesowy) lepszy bywa serverless. Unikasz inwestycji w infrastrukturę i zespół SRE, płacisz głównie za faktyczne użycie, możesz szybko iterować. Pytanie: czy naprawdę potrzebujesz własnego klastra, jeśli produkt może nie przetrwać 6 miesięcy?
Kubernetes ma sens, gdy:
Jeżeli dziś działasz na monolicie na jednej maszynie, często dobrym krokiem pośrednim jest konteneryzacja i prosty klaster (np. managed K8s), zamiast od razu pełnego serverless wszystko‑as‑a‑service.
Co jest tańsze: Kubernetes czy serverless przy skalowaniu?
Na krótką metę serverless zwykle wygrywa kosztowo: nie płacisz za „puste” serwery, nie musisz zatrudniać osób do utrzymania klastra, a rachunek rośnie głównie wtedy, gdy rośnie ruch. To dobry wariant, jeśli jeszcze nie wiesz, czy produkt „zaskoczy” i chcesz ograniczyć ryzyko przepalenia budżetu.
Przy stabilnym, dużym ruchu sytuacja się odwraca. Stale działające funkcje serverless mogą być droższe niż dobrze dobrane węzły w Kubernetesie. Do tego dochodzi koszt ludzi: czy łatwiej będzie ci znaleźć developerów ogarniających chmurę i serverless, czy specjalistów od Kubernetes i SRE? Sprawdź: jakie rachunki chmurowe masz dziś i jak zmienią się przy 2–3x ruchu oraz jakie kompetencje masz już w zespole.
Jak serverless wpływa na vendor lock‑in w porównaniu z Kubernetes?
Serverless mocno wiąże cię z jednym dostawcą, bo używasz jego funkcji (Lambda, Azure Functions), kolejek, baz, API Gateway, orkiestracji. Migracja takiej architektury do innej chmury oznacza przepisywanie sporej części integracji i logiki. Zastanów się: czy akceptujesz to ryzyko na 5–10 lat do przodu?
Kubernetes jest bardziej przenośny – ten sam manifest deploymentu możesz uruchomić w różnych chmurach lub on‑premise. Vendor lock‑in nie znika, ale dotyczy głównie usług towarzyszących (bazy danych, storage, monitoring). To opcja dla produktów, które mają żyć długo, przechodzić audyty, a czasem zmieniać środowiska (np. wymogi prawne, zmiana dostawcy).
Jakie kompetencje w zespole są potrzebne przy Kubernetes, a jakie przy serverless?
Przy Kubernetesie potrzebujesz kompetencji kontenerowych i operacyjnych: Docker, sieć w klastrze, podstawy bezpieczeństwa, CI/CD, monitoring, autoskalowanie (HPA, VPA), rozumienie storage i backupów. Pytanie kontrolne: masz dziś choć jedną osobę, która realnie utrzymywała klaster produkcyjny?
Przy serverless kluczowe są dobre projektowanie event‑driven, znajomość usług chmurowych i ich ograniczeń (limity czasu, równoległości, zimne starty, wzorce retry). Zespół musi „myśleć chmurą”: jak złożyć gotowe klocki (kolejki, funkcje, bazy) zamiast budować wszystko samodzielnie. Dla małych ekip często łatwiej zbudować takie kompetencje niż pełny skillset DevOps/SRE.
Czy można łączyć Kubernetes i serverless w jednym systemie?
Tak, hybryda jest częstym i sensownym podejściem. Krytyczne, długo działające usługi możesz trzymać w Kubernetesie, a elementy o zmiennym lub sporadycznym ruchu (np. przetwarzanie plików, webhooki z zewnętrznych systemów, batchowe joby) realizować serverless. Zastanów się: które części twojego systemu naprawdę muszą być ultra‑elastyczne, a które stabilne i przewidywalne?
Taki miks pozwala wykorzystać mocne strony obu światów: kontrolę i przewidywalne koszty Kubernetes plus elastyczność i szybkość wdrożeń serverless. Minusem jest większa złożoność architektury i potrzeba ogarnięcia dwóch modeli operacyjnych naraz, więc sprawdź, czy zespół ma na to przepustowość.
