Serverless brzmi jak marzenie każdego CTO małej firmy: płacisz tylko za to, czego używasz, nie martwisz się serwerami, a skalowanie dzieje się samo. W 2025 roku to wciąż jeden z najgorętszych tematów w architekturze aplikacji. Problem w tym, że wiele firm wpada w pułapkę, myląc „bezserwerowość” z „bez kosztów”. W swojej praktyce widziałem przypadki, gdzie miesięczny rachunek za AWS Lambda czy Cloud Functions nagle wystrzeliwał z kilkudziesięciu do kilku tysięcy dolarów. Nie przez wzrost ruchu, ale przez złą strategię. Oto trzy błędy, które windują koszty serverlessa w małych firmach – i jak ich uniknąć.
Błąd #1: Ignorowanie zimnych startów i czasu wykonania
Serverless nie jest magiczny. Każda funkcja, gdy jest wywoływana po okresie bezczynności, przechodzi tzw. zimny start. To trwa od kilkudziesięciu milisekund do nawet kilku sekund, w zależności od środowiska. Problem w tym, że zimne starty nie tylko spowalniają aplikację, ale też generują koszty – płacisz za czas inicjalizacji, nawet jeśli funkcja nie robi nic produktywnego.
Widziałem firmę, która uruchamiała funkcję serverless co 5 minut tylko po to, by „trzymać ją ciepłą”. To paradoksalnie zwiększało koszty, bo zamiast płacić za pojedyncze wywołania, płacili za ciągłe utrzymywanie funkcji w stanie gotowości. Lepszym rozwiązaniem jest optymalizacja kodu: zmniejszenie rozmiaru paczki, użycie języków szybszych przy starcie (np. Python zamiast Node.js w niektórych przypadkach) oraz wykorzystanie Provisioned Concurrency tylko dla krytycznych ścieżek.
Kolejna pułapka: zbyt długi czas wykonania. Serverless jest tani dla krótkich zadań (ms), ale drożeje, gdy funkcja działa kilka sekund. Jeśli masz funkcję przetwarzającą obraz, która trwa 10 sekund – lepiej rozważyć usługę dedykowaną (np. AWS Batch) lub zmienić architekturę. W jednym z audytów spotkałem firmę, która używała Lamdy do generowania PDF-ów – każde wywołanie trwało średnio 15 sekund, co przy 10 tysiącach miesięcznie dawało rachunek wyższy niż tradycyjny serwer VPS.
Błąd #2: Złe zarządzanie wywołaniami i równoległością
Serverless kusi, by każdą małą czynność zamknąć w osobnej funkcji. Efekt? Lawinowe wywołania, które generują koszty. W architekturze mikroserwisów często widzę, że jedna operacja – np. złożenie zamówienia – wywołuje 5-6 funkcji łańcuchowo. Każda z nich płaci za czas i liczbę żądań.
Co gorsza, równoległe wywołania (concurrency) mogą błyskawicznie zwiększyć koszty, zwłaszcza jeśli funkcja korzysta z zewnętrznych API, które mają własne limity. Przykład: firma e-commerce używała serverlessa do wysyłki e-maili powitalnych. Każda rejestracja wywoływała funkcję, która łączyła się z SendGridiem. W Black Friday ruch wzrósł 10-krotnie, a koszty Lamdy poszły w górę 20-krotnie – bo funkcja czekała na odpowiedź z API, a czas oczekiwania też był liczony.
Rozwiązanie: projektuj funkcje tak, by były idempotentne i jak najkrócej działały. Używaj kolejek (np. SQS) do rozłożenia obciążenia. A przede wszystkim – mierz i monitoruj. Bez tego nie zobaczysz, gdzie wycieka budżet.
Błąd #3: Brak budżetów i alertów
Największym grzechem jest wdrożenie serverlessa bez ustawienia limitów kosztów. W tradycyjnym hostingu płacisz stałą miesięczną opłatę – w serverless koszt jest zmienny i zależny od skali. Bez barier ochroniarskich jedna pętla w kodzie może wygenerować miliony wywołań w kilka minut.
Znam historię startupu, który przez błąd w konfiguracji webhooka (zapętlenie) wygenerował 2 miliony wywołań funkcji w ciągu godziny. Rachunek: 4000 dolarów. Firma nie miała ustawionych alertów na AWS Budgets, więc dowiedziała się o tym dopiero po miesiącu na fakturze.
Dobre praktyki: zawsze konfiguruj budżet z alertami (próg 80% i 100%). Dodatkowo, ustaw limity concurrency na funkcjach i używaj API Gateway z throttlingiem. Monitoruj logi pod kątem anomalii – narzędzia jak CloudWatch czy Datadog mogą wykryć skoki kosztów w czasie rzeczywistym.
Podsumowanie
Serverless to świetne narzędzie, ale nie jest srebrną kulą. Dla małych firm może być zarówno oszczędnością, jak i finansową pułapką. Klucz to świadome projektowanie: krótkie funkcje, kontrola wywołań i monitoring. Zanim wrzucisz całą aplikację na Lamdę, przetestuj koszty na małej skali. A jeśli już popełniasz błędy – wyciągnij wnioski, zanim faktura zrobi to za Ciebie.
