Wstęp
Serverless brzmi jak marzenie każdego CTO: płacisz tylko za wykonanie, nie martwisz się o serwery, skaluje się automatycznie. Brzmi idealnie, prawda? Dopóki nie dostaniesz pierwszego rachunku z AWS Lambda, który przekracza budżet o 300%. Znam to z autopsji – jako praktyk widziałem startupy i średnie firmy, które wpadły w pułapkę serverless. W tym artykule pokażę, dlaczego architektura bezserwerowa może być najdroższym rozwiązaniem, jakie wybierzesz, i jak tego uniknąć.
Sekcja 1: Ukryte koszty zimnych startów i przepustowości
Serverless nie oznacza braku kosztów – oznacza jedynie przeniesienie ich z utrzymania serwerów na opłaty za każde wywołanie i czas wykonania. Zimne starty, czyli opóźnienia przy pierwszym uruchomieniu funkcji, to nie tylko problem wydajności, ale też finansów. Aby zminimalizować zimne starty, często konfiguruje się tzw. „provisioned concurrency”, czyli utrzymywanie gotowych instancji. To z kolei generuje stałe opłaty, nawet gdy nikt nie korzysta z aplikacji.
Przykład: klient uruchomił sklep e-commerce na AWS Lambda. Przy niskim ruchu koszty były znośne – około 500 zł miesięcznie. W Black Friday ruch wzrósł 10-krotnie, a rachunek skoczył do 45 000 zł. Powód? Każde wywołanie Lambda generowało koszt, a do tego doszły opłaty za API Gateway, DynamoDB i CloudWatch Logs. Klient nie zaimplementował limitów ani optymalizacji.
Sekcja 2: Złożoność debugowania i monitoringu
W serverless nie ma jednego loga, do którego możesz się podłączyć. Debugowanie rozproszonych funkcji wymaga narzędzi takich jak AWS X-Ray, OpenTelemetry czy specjalnych rozwiązań zewnętrznych. To generuje dodatkowe koszty i czas zespołu. Zespoły często lekceważą monitoring, dopóki nie pojawi się awaria. Wtedy okazuje się, że nie wiadomo, która funkcja generuje opóźnienia.
W tradycyjnej architekturze możesz postawić jeden serwer z monitoringiem za 100 zł/miesiąc. W serverless – potrzebujesz kilku narzędzi, każde płatne osobno. Widziałem firmy, które wydały 10 000 zł na samo skonfigurowanie monitoringu, a potem okazało się, że nie używają nawet 20% jego funkcji.
Sekcja 3: Vendor lock-in i migracja
Serverless to często silne uzależnienie od dostawcy (AWS, Azure, GCP). Przeniesienie funkcji z AWS Lambda do Cloud Functions jest kosztowne i czasochłonne, bo każda platforma ma inny model wywoływania, biblioteki i limity. Jeśli w przyszłości zechcesz zmienić dostawcę lub wrócić do tradycyjnych serwerów, zapłacisz za to wysoką cenę.
Przykład: firma SaaS zbudowała cały backend na AWS Lambda + DynamoDB. Po dwóch latach okazało się, że koszty są nieproporcjonalne do przychodów. Migracja do Kubernetes na własnych serwerach zajęła 3 miesiące i kosztowała 200 000 zł. Często tańsze jest zostanie z dostawcą i negocjacja rabatów, niż próba ucieczki.
Sekcja 4: Kiedy serverless ma sens?
Serverless sprawdza się przy:
- Niskiej i zmiennej przepustowości (np. okresowe zadania, webhooki)
- Szybkim prototypowaniu, gdy nie chcesz inwestować w infrastrukturę
- Funkcjach, które działają krótko (poniżej 1 sekundy)
Nie sprawdza się przy:
- Aplikacjach o stałym, wysokim ruchu
- Długo działających procesach (np. generowanie raportów)
- Złożonych interakcjach między funkcjami (np. współdzielenie stanu)
Podsumowanie
Serverless to potężne narzędzie, ale nie uniwersalne. Zanim zdecydujesz się na tę architekturę, przeprowadź dokładną analizę kosztów, uwzględniając monitoring, zimne starty i potencjalną migrację. Jeśli już jesteś w serverless, regularnie audytuj swoje funkcje – usuń nieużywane, optymalizuj czas wykonania. Pamiętaj: najdroższy jest brak wiedzy o rzeczywistych kosztach.
JurskiTech pomaga firmom projektować architekturę, która nie rujnuje budżetu. Jeśli chcesz uniknąć tych błędów – porozmawiajmy.
