Serverless bardzo łatwo polubić.
Zwłaszcza na początku.
Nie trzeba zarządzać serwerami.
Nie trzeba od razu projektować całej warstwy operacyjnej.
Da się szybko wdrożyć API, kilka flow, integracje, kolejkę, bazę, autoryzację i domknąć to w modelu, który z punktu widzenia MVP wygląda bardzo rozsądnie.
I właśnie dlatego serverless jest tak atrakcyjny.
AWS od lat buduje tę obietnicę wokół mniejszego narzutu operacyjnego, szybszego dostarczania i automatycznego skalowania. W dokumentacji i materiałach Well-Architected dla serverless widać też bardzo wyraźnie, że ten model ma upraszczać uruchamianie aplikacji i ograniczać ciężar zarządzania infrastrukturą.
To wszystko jest prawdą.
Problem zaczyna się dopiero wtedy, gdy ktoś zaczyna traktować serverless nie jako świadomy wybór dla konkretnego etapu, tylko jako domyślną odpowiedź na wszystko.
Bo serverless potrafi być świetnym sposobem na zbudowanie MVP.
Ale potrafi też bardzo skutecznie ukryć koszt, który pojawia się trochę później:
koszt poznawczy systemu.
I to właśnie ten moment jest najciekawszy.
Nie pytanie, czy serverless jest dobry.
Tylko: w jakim rodzaju problemu daje realną przewagę, a w jakim zaczyna komplikować życie bardziej, niż je upraszcza.
Dlaczego serverless tak dobrze pasuje do MVP
Na etapie MVP najważniejsza nie jest zwykle idealna architektura.
Najważniejsze jest coś prostszego:
dowieźć działające flow,
szybko iterować,
nie utopić czasu w operacjach,
nie budować infrastruktury cięższej niż sam produkt.
I tu serverless ma bardzo mocny argument.
Lambda, API Gateway, Step Functions, SQS, EventBridge, DynamoDB czy Cognito pozwalają bardzo szybko zestawić system, który:
działa,
skaluje się bez ręcznego pilnowania hostów,
nie wymaga rozbudowanego zaplecza operacyjnego,
pozwala zespołowi skupić się bardziej na przepływach niż na maszynach.
To jest duża przewaga.
Zwłaszcza gdy nie chcesz jeszcze inwestować energii w:
utrzymywanie klastra,
tuning autoscalingu,
rollout infrastruktury pod kontenery,
patchowanie hostów,
cały koszt bycia „operacyjnie gotowym”, zanim produkt udowodni, że w ogóle zasługuje na taki ciężar.
W tym sensie serverless jest bardzo zdrową decyzją dla MVP.
Nie dlatego, że jest nowoczesny.
Tylko dlatego, że potrafi utrzymać system blisko realnej potrzeby.
Tam, gdzie ja testowałem to serverless sprawdza się, gdzie najważniejsza jest iteracja
Jeśli produkt jest jeszcze w fazie szukania kształtu, to przewagę daje nie najbardziej wyrafinowana architektura, tylko taka, która pozwala szybko:
sprawdzić hipotezę,
zmienić flow,
dodać integrację,
wyrzucić nietrafiony fragment bez przepisywania połowy systemu.
Serverless bardzo dobrze wspiera właśnie ten etap.
Nie musisz od razu budować pełnego modelu operacyjnego wokół usług.
Możesz dużo szybciej skupić się na pytaniu:
czy to flow ma sens dla użytkownika?
I to jest bardzo ważne rozróżnienie.
Bo wiele zespołów nie przepala czasu na zły kod.
Przepala go na zbyt wczesne budowanie dojrzałości infrastrukturalnej.
Serverless potrafi ten błąd ograniczyć.
Jeśli masz produkt, który:
ma nieregularny ruch,
potrzebuje kilku prostych integracji,
nie ma jeszcze bardzo skomplikowanej logiki domenowej,
wymaga szybkiego time-to-market,
ma mały albo średni zespół,
to bardzo często sensowniej jest zacząć od prostego modelu serverless niż od budowania pełniejszego środowiska kontenerowego tylko dlatego, że „tak będzie bardziej przyszłościowo”.
Tyle że przewaga serverless nie jest darmowa
To jest moment, w którym warto przestać mówić marketingiem.
Serverless nie usuwa złożoności.
On bardzo często przesuwa ją w inne miejsce.
Na początku ta zamiana jest opłacalna.
Płacisz mniej za infrastrukturę operacyjną, a więcej dostajesz szybkości.
Ale później zaczyna się ujawniać druga strona tego modelu.
Złożoność trafia wtedy do:
rozproszonego flow,
debugowania zdarzeń,
zależności między funkcjami,
retry logic,
idempotency,
obsługi błędów między komponentami,
obserwowalności,
nietrywialnych zależności między usługami managed.
I nagle okazuje się, że system nie jest trudny dlatego, że ma serwery.
Jest trudny dlatego, że ma za dużo punktów pośrednich.
To nie znaczy, że to zły model.
To znaczy tylko, że jego koszt nie leży tam, gdzie leży w bardziej klasycznej architekturze.
W klasycznym modelu częściej płacisz za runtime i operacje.
W serverless częściej zaczynasz płacić za mentalny model przepływu.
Czy serverless dla MVP to sprytny skrót czy po prostu elegancki dług techniczny?
To jest moment, w którym warto zadać niewygodne pytanie.
Bo bardzo łatwo zachwycić się serverless na poziomie hasła:
szybciej wystartujesz, mniej operacji, łatwiejszy deployment, automatyczne skalowanie.
I to wszystko może być prawdą.
Ale równie prawdziwe jest coś innego:
źle użyty serverless potrafi być po prostu elegancko opakowanym długiem technicznym.
Nie dlatego, że Lambda jest zła.
Nie dlatego, że AWS źle rozwiązuje ten model.
Tylko dlatego, że MVP bardzo łatwo staje się wymówką, żeby nie odróżniać tego, co jest tymczasowe, od tego, co powinno być trwałe.
To jest dla mnie kluczowe rozróżnienie.
Jeśli budujesz MVP, masz pełne prawo upraszczać:
runtime,
deployment,
operacyjny model środowiska,
część integracji,
część decyzji wydajnościowych.
To jest normalne.
Właśnie po to między innymi istnieje sensowny model serverless.
Ale są rzeczy, których nie warto traktować jako tymczasowe nawet na etapie MVP:
granice odpowiedzialności,
główne flow biznesowe,
model domeny,
zignorowane luki bezpieczeństwa,
kontrakty wejścia i wyjścia,
sposób obsługi błędów i stanu.
Jeśli te elementy od początku są przypadkowe, rozsmarowane po triggerach, eventach i handlerach, to problemem nie jest już „lekka architektura na start”.
Problemem jest to, że produkt testujesz na technicznym układzie, który sam w sobie nie nadaje się do spokojnej ewolucji.
I wtedy bardzo łatwo wpaść w złą narrację:
„teraz zrobimy to szybko, a później i tak przepiszemy porządnie.”
To zwykle nie jest zdrowa strategia.
To zwykle jest sygnał, że prawdziwa decyzja architektoniczna została tylko odłożona.
AWS samo pokazuje, że nawet wewnątrz serverless nie istnieje jeden docelowy wzorzec. Zespoły potrafią zaczynać od drobnych funkcji, później scalać logikę w bardziej zwarty model, a czasem iść w rozwiązania pośrednie, bo przesadne rozdrobnienie też generuje koszt poznawczy i operacyjny. To ważny sygnał: ewolucja nie musi oznaczać pełnego rewrite’u, jeśli od początku sensownie ułożysz granice i logikę systemu.
I właśnie tutaj leży cała różnica.
Dobrze użyty serverless nie oznacza:
„zróbmy byle jak, a potem zaczniemy od nowa”.
Dobrze użyty serverless oznacza:
„na tym etapie upraszczamy sposób uruchamiania i operowania systemem, ale nie psujemy jego przyszłej czytelności”.
To naprawdę nie jest to samo.
Bo późniejsza zmiana nie zawsze musi być pełnym przepisaniem wszystkiego.
Czasem to tylko:
zmiana runtime’u,
scalenie zbyt rozdrobnionych elementów,
przeniesienie części flow do bardziej zwartego modelu,
uporządkowanie warstwy wykonawczej.
To są normalne etapy dojrzewania systemu.
Pełny dług techniczny zaczyna się wtedy, gdy MVP jest tak mocno splecione z chwilowym sposobem budowy, że nie da się oddzielić:
logiki produktu od mechaniki platformy,
domeny od triggerów,
sensownego kontraktu od przypadkowego zachowania infrastruktury.
Wtedy później nie rozwijasz systemu.
Wtedy go wyciągasz z własnej prowizorki.
Dlatego dla mnie najzdrowsza zasada brzmi tak:
tymczasowy może być runtime.
Tymczasowy nie powinien być model myślenia o systemie.
Jeżeli serverless pozwala Ci szybciej sprawdzić wartość produktu, a jednocześnie utrzymujesz porządek w domenie, flow i odpowiedzialnościach, to nie budujesz katastrofalnego długu.
Budujesz kontrolowany kompromis.
Jeśli natomiast MVP działa tylko dlatego, że cała logika jest rozlana po eventach, integracjach i usługach provider-specific, to bardzo możliwe, że nie skracasz sobie drogi.
Tylko przesuwasz koszt na później i to zwykle z odsetkami.
Pierwszy moment, w którym serverless zaczyna uwierać: kiedy flow jest prosty biznesowo, ale rozproszony technicznie
To chyba najczęstszy sygnał ostrzegawczy.
Biznesowo masz prosty proces:
użytkownik wysyła żądanie, system coś waliduje, zapisuje stan, uruchamia jedną czy dwie operacje uboczne, odsyła wynik.
Logicznie nie ma tu nic skomplikowanego.
Ale technicznie ten sam proces zaczyna żyć w kilku miejscach:
wejście przez API Gateway,
jedna funkcja waliduje,
druga publikuje event,
trzecia reaguje asynchronicznie,
czwarta robi jeszcze jakiś side effect,
do tego retry, DLQ, timeouty, jakaś logika kompensacyjna.
Na papierze wszystko jest poprawne.
Architektura wygląda czysto i nowocześnie.
Tylko że po pewnym momencie prosty proces biznesowy zaczyna wymagać zbyt rozproszonego modelu technicznego.
I wtedy zespół nie zyskuje już prostoty.
Zyskuje architekturę, którą trzeba śledzić krok po kroku, żeby zrozumieć coś, co biznesowo jest banalne.
To jest moment, w którym trzeba się zatrzymać i zadać jedno pytanie:
czy ten poziom rozproszenia naprawdę rozwiązuje obecny problem, czy tylko sprawia, że system wygląda bardziej „serverlessowo”?
Drugi moment: kiedy observability zaczyna nadrabiać architekturę
Serverless bardzo mocno korzysta z dobrej obserwowalności.
I słusznie.
AWS rozwija Step Functions między innymi właśnie po to, żeby dawać wykonanie workflow z historią i wizualnym debugowaniem, szczególnie dla dłuższych lub audytowalnych procesów. To nie przypadek — im bardziej rozproszony workflow, tym bardziej potrzebujesz narzędzi, które pozwalają zrozumieć jego rzeczywisty przebieg.
To jest cenna wskazówka sama w sobie.
Bo jeśli architektura wymaga coraz większej ilości telemetryki tylko po to, żeby zrekonstruować podstawowe flow, to być może problem nie leży już tylko w braku lepszych narzędzi obserwowalności.
Być może problem leży w tym, że techniczny model przepływu stał się bardziej rozbudowany, niż wymaga tego sama logika produktu.
To nie jest argument przeciwko telemetryce.
To jest argument przeciwko sytuacji, w której observability zaczyna kompensować nadmierne rozproszenie.
Dobra obserwowalność ma pomagać szybciej rozumieć system.
Nie powinna być protezą dla modelu, który zrobił się trudny do ogarnięcia bez dochodzenia.
Trzeci moment: kiedy zaczynasz dopłacać za cechy, które miały być „za darmo”
Serverless kusi obietnicą:
skalujesz się automatycznie, płacisz za użycie, nie zarządzasz serwerami.
I znowu — to prawda.
Tylko że przy bardziej wymagających workloadach zaczynasz odkrywać, że niektóre cechy nie są już tak darmowe, jak wyglądały na początku.
Dobry przykład to wrażliwość na latency.
AWS w Serverless Lens wprost wskazuje provisioned concurrency jako mechanizm dla funkcji, które muszą skalować się bez wahań opóźnień — i jednocześnie zaznacza, że to jest trade-off kosztowy. Czyli: jeśli naprawdę potrzebujesz przewidywalnego czasu startu i stabilnej responsywności, zaczynasz płacić za dodatkowy poziom gotowości.
To nie jest wada AWS Lambda.
To jest po prostu przypomnienie, że każdy model ma swój rachunek.
Na początku serverless daje prostotę operacyjną.
Później może zacząć odbierać prostotę kosztową, wydajnościową albo poznawczą, jeśli workload wchodzi w mniej naturalny dla niego profil.
I właśnie wtedy kończy się myślenie „serverless jest prostszy”, a zaczyna się dojrzalsze myślenie:
dla jakiego typu problemu ten model nadal jest prostszy całościowo?
Publiczny sygnał z samego AWS: nie ma jednego wzorca nawet w obrębie Lambda
To ciekawy i ważny trop.
W 2024 roku AWS opublikował materiał porównujący różne podejścia do budowania serverless microservices i wprost zaznaczył, że zespoły często ewoluują od bardzo drobnych funkcji do tzw. „Lambda-lith”, a oba podejścia mają własne trade-offy. AWS pokazuje tam nawet wariant pośredni, bo nie istnieje jeden uniwersalny wzorzec, który zawsze wygrywa.
To jest bardzo zdrowe.
Bo pokazuje rzecz, o której mało mówi się w uproszczonych narracjach o serverless:
nawet wewnątrz serverless nie chodzi o maksymalne rozdrobnienie dla zasady.
Czasem zbyt drobny podział daje:
za dużo punktów wejścia,
za dużo zależności,
za dużo miejsc do debugowania,
za dużo kontekstu potrzebnego do zmiany jednej rzeczy.
I wtedy bardziej zwarte podejście może być po prostu lepsze.
Nie dlatego, że jest „mniej cloud-native”.
Tylko dlatego, że jest bardziej adekwatne do problemu.
Kiedy serverless jest naprawdę dobrym wyborem dla MVP
Dla mnie serverless jest bardzo dobrym wyborem wtedy, gdy spełnionych jest kilka warunków naraz.
- Produkt jest jeszcze w fazie intensywnego uczenia się
Zmiany są częste, wiele rzeczy może zostać wyrzuconych, a najważniejsze jest szybkie domykanie kolejnych iteracji.
- Ruch jest nieregularny albo trudny do przewidzenia
Nie chcesz utrzymywać środowiska zaprojektowanego pod szczyt, którego jeszcze nie rozumiesz.
- Logika domenowa nie jest jeszcze bardzo głęboka
System ma flow i integracje, ale nie ma jeszcze ciężaru, który uzasadnia bardziej złożony runtime lub bardzo rozbudowany model orkiestracji.
- Zespół chce ograniczyć narzut operacyjny
Nie dlatego, że operacje są nieważne, tylko dlatego, że na tym etapie ważniejsze jest dowożenie zmian niż budowanie rozbudowanej warstwy platformowej.
- Da się zachować czytelność przepływów
To jest najważniejsze.
Dopóki architektura nadal daje się opowiedzieć spokojnie i bez mapy wojennej, serverless zwykle robi dobrą robotę.
Kiedy serverless zaczyna przeszkadzać
Nie wtedy, gdy „jest duży traffic”. To zbyt uproszczone.
Przeszkadzać zaczyna wtedy, gdy:
prosty biznesowo proces jest rozproszony na zbyt wiele elementów,
coraz trudniej debugować pełny przepływ,
observability zaczyna być obowiązkową archeologią,
system wymaga coraz więcej dopłat za przewidywalność,
zmiana jednej rzeczy wymaga odtworzenia za dużej części modelu zdarzeń,
zespół bardziej zarządza konsekwencjami wzorca niż realnym problemem produktu.
To jest ten moment, w którym trzeba przestać pytać:
czy to dalej działa?
I zacząć pytać:
czy to dalej jest najprostszy sensowny model dla tego systemu?
Bo architektura może działać poprawnie i jednocześnie być już niewłaściwa dla swojego etapu.
Co z tego wynika praktycznie
Najrozsądniejsza rzecz, jaką można zrobić z serverless, to nie traktować go ani jak religii, ani jak tymczasowej protezy.
To nie jest „architektura gorsza, bo niekontenerowa”.
To nie jest też „architektura lepsza, bo nowoczesna”.
To jest po prostu model, który bardzo dobrze działa wtedy, gdy:
redukuje ciężar operacyjny,
przyspiesza iterację,
nie psuje czytelności systemu.
I przestaje być dobrym modelem wtedy, gdy:
rozprasza prostą logikę,
podnosi koszt zrozumienia,
wymaga coraz większej ilości mechanizmów pobocznych, żeby zachować przewidywalność.
Wtedy nie chodzi już o to, żeby uciekać od serverless za wszelką cenę.
Chodzi o to, żeby uczciwie zobaczyć trade-off.
Może wystarczy uprościć podział funkcji.
Może warto przenieść część logiki do bardziej zwartego modelu.
Może dopiero wtedy opłaca się myśleć o innym runtime.
Najgorsze, co można zrobić, to bronić wzorca tylko dlatego, że kiedyś był dobrą decyzją.
Serverless nie jest strategią. Jest decyzją na etap
Najgorsze, co można zrobić z serverless, to potraktować go jak odpowiedź uniwersalną.
Bo wtedy bardzo łatwo pomylić dwie rzeczy:
świadome uproszczenie,
i zwykłe odsunięcie problemu w czasie.
Serverless nie jest dobry dlatego, że jest nowoczesny.
Nie jest też zły dlatego, że kiedyś być może trzeba będzie coś zmienić.
Jest dobry wtedy, gdy na obecnym etapie naprawdę zmniejsza ciężar systemu:
operacyjny, wdrożeniowy i poznawczy.
Jeśli to robi — świetnie.
Jeśli zaczyna tylko ukrywać złożoność pod wygodnym modelem wykonania, to przestaje być przewagą.
I właśnie tu leży sedno.
Nie chodzi o to, czy system działa na Lambda, kontenerach czy czymkolwiek innym.
Chodzi o to, czy architektura nadal pomaga zespołowi myśleć jasno, zmieniać spokojnie i debugować bez archeologii.
Bo jeśli prosty biznesowo flow wymaga coraz bardziej skomplikowanego technicznie dochodzenia, to problemem nie jest już wybór narzędzia.
Problemem jest to, że etap systemu się zmienił, a architektura udaje, że nie zauważyła.
Zakończenie
Lubię serverless właśnie za to, że nie zmusza do przedwczesnej infrastrukturalnej powagi.
Dobrze użyty potrafi bardzo skutecznie skrócić drogę od pomysłu do działającego produktu.
Potrafi ograniczyć narzut operacyjny.
Potrafi dać zespołowi więcej miejsca na iterację.
Ale jak każda dobra technologia, wymaga dyscypliny.
Bo jego siłą nie jest to, że rozwiązuje wszystko.
Jego siłą jest to, że w odpowiednim momencie rozwiązuje dokładnie tyle, ile trzeba.
A to w architekturze zwykle znaczy więcej, niż wygląda na pierwszy rzut oka.
