Serverless w 2025: 3 błędy, które windują koszty małej firmy
Model serverless od lat kusi obietnicą: „płać tylko za to, czego używasz”. Brzmi idealnie dla małej firmy, która nie chce przepłacać za bezczynne serwery. W praktyce jednak coraz częściej widzę zespoły, które po migracji do serverless dostają rachunek 3–5 razy wyższy niż wcześniej w tradycyjnym modelu. Dlaczego? Bo serverless ma swoją ciemną stronę, którą operatorzy chmury chętnie pomijają w marketingowych materiałach.
W JurskiTech.pl codziennie pomagamy firmom optymalizować koszty chmury. Poniżej opisuję trzy najczęstsze błędy, które widzę w projektach serverless u małych klientów – i co zrobić, żeby nie wylądować z kosztami na minusie.
Błąd nr 1: Zbyt drobne funkcje i efekt „kaskady wywołań”
Serverless zachęca do rozbijania logiki na mikro-funkcje. W teorii to fajne – każda funkcja robi jedną rzecz. W praktyce często prowadzi to do sytuacji, gdzie jedna operacja biznesowa wywołuje 10–15 oddzielnych funkcji, a każda z nich generuje koszt.
Przykład z życia: Klient – sklep e-commerce – zbudował proces realizacji zamówienia jako łańcuch 12 funkcji Lambda. Każda sprawdzała stan magazynowy, aktualizowała bazę, wysyłała e-mail, logowała zdarzenie. W przypadku standardowej wysyłki – ok. 1000 zamówień dziennie – koszt Lambda wyniósł 0,30 USD dziennie. Niby niewiele. Ale przy promocji Black Friday ruch wzrósł 10-krotnie, a koszt poszybował do 300 USD dziennie, bo funkcje były wywoływane wielokrotnie, a każda z nich miała długi czas wykonania (ponad 500 ms).
Jak tego uniknąć? Zamiast tworzyć kaskadę funkcji, połącz kilka kroków w jedną funkcję. Zmniejsz liczbę wywołań i czas wykonania. W tym przypadku wystarczyłyby 3 funkcje zamiast 12. Koszt spadł o 70%.
Błąd nr 2: Ignorowanie kosztów zimnego startu (cold start)
Cold start to moment, gdy funkcja nie była używana przez jakiś czas i musi zostać załadowana od nowa. W małych firmach często nie ma stałego ruchu – bywa, że funkcja jest wywoływana co kilka minut, a potem przez godzinę nic. Każdy cold start to opóźnienie i dodatkowy koszt, bo chmura musi uruchomić kontener.
Klient – startup SaaS z aplikacją do zarządzania projektami – używał funkcji serverless do obsługi logowania. Użytkowników było ok. 500 dziennie, ale ruch był nierównomierny. Średni czas odpowiedzi wynosił 2 sekundy, z czego 1,5 sekundy to cold start. Koszty były niskie (ok. 50 USD/miesiąc), ale UX ucierpiał. Zdecydowali się na utrzymanie jednej „rozgrzanej” funkcji – koszt wzrósł do 80 USD, ale czas odpowiedzi spadł poniżej 300 ms. Klient był zadowolony, bo retencja wzrosła o 15%.
Rekomendacja: Jeśli masz nierównomierny ruch, rozważ użycie „keep-warm” (np. CloudWatch Events wywołujący funkcję co 5 minut). Koszt to kilka dolarów miesięcznie, a oszczędność na UX i potencjalnych stratach klientów – nieporównywalna.
Błąd nr 3: Zapominanie o kosztach transferu danych
Serverless to nie tylko czas wykonania. Często największym składnikiem rachunku jest transfer danych między funkcjami a innymi usługami (bazy danych, kolejki, API zewnętrzne). W architekturze serverless każda funkcja często komunikuje się z innymi serwisami, a każdy gigabajt transferu kosztuje.
Przykład: Firma analityczna przetwarzała dane z IoT – miliony rekordów dziennie. Użyli AWS Lambda do czyszczenia danych, a następnie zapisywali do S3. Funkcja była mała (128 MB, 100 ms wykonania), ale każde wywołanie czytało plik z S3 i zapisywało nowy plik – transfer między S3 a Lambda wynosił średnio 500 MB dziennie. Koszt Lambda: 5 USD/miesiąc. Koszt transferu: 45 USD/miesiąc. Nikt tego nie przewidział.
Rozwiązanie: Zamiast czytać i zapisywać całe pliki, mogą przetwarzać dane strumieniowo. Lepiej: użyj funkcji, która działa na strumieniu danych (np. Kinesis) zamiast odczytywać pliki z S3. Transfer wewnętrzny w VPC jest tańszy, ale też nie darmowy. Zawsze szacuj koszt transferu przed wdrożeniem.
Podsumowanie
Serverless to świetne narzędzie, ale nie jest srebrną kulą. Dla małych firm może być pułapką, jeśli nie kontrolują liczby wywołań, zimnych startów i transferów. Zanim wrzucisz wszystko do Lambda czy Cloud Functions, przeanalizuj rzeczywisty przepływ Twojej aplikacji. Często dobrze zaprojektowana monolityczna aplikacja na małym serwerze (np. VPS za 5 USD/miesiąc) będzie tańsza i prostsza w utrzymaniu niż skomplikowana sieć funkcji serverless.
Jeśli masz wątpliwości – zaproś kogoś z doświadczeniem (np. nas z JurskiTech.pl) do audytu. Lepiej wydać 1000 zł na konsultację, niż później płacić 3000 zł miesięcznie za przetwarzanie, które można zoptymalizować.
