Serverless backend – brzmi jak marzenie każdego startupu. Zero martwienia się o serwery, skaluje się automatycznie, płacisz tylko za to, czego użyjesz. Nic dziwnego, że tyle młodych firm rzuca się na AWS Lambda, Cloud Functions czy podobne rozwiązania. Problem w tym, że po kilku miesiącach rachunki potrafią zaskoczyć, a aplikacja działa wolniej niż na tradycyjnym VPS-ie. Dlaczego? Bo serverless to nie srebrna kula, tylko jedno z narzędzi – a używane bez zrozumienia, potrafi zrobić więcej szkody niż pożytku.
Widziałem to wielokrotnie. Startup oszczędza na początku, bo nie płaci za bezczynne serwery, ale potem klienci skarżą się na czas odpowiedzi, developerzy tracą godziny na debugowanie cold startów, a finał jest taki, że przepisują wszystko na tradycyjny backend. Albo gorzej – toną w długach technicznych.
W tym artykule pokażę trzy największe błędy, jakie popełniają startupy przy wdrażaniu serverless. Nie będzie teorii – same konkretne historie z życia i rady, jak ich uniknąć.
Błąd #1: Traktowanie każdej funkcji jak mikroserwisu
Klasyka. Zespół pcha wszystko do osobnych funkcji Lambda, bo „serverless wymaga dekompozycji”. Efekt? Setki maleńkich funkcji, każda robi jedną prostą rzecz, ale sieć zależności i komunikacji między nimi staje się koszmarem do zarządzania. Debugowanie zamienia się w piekło, a opóźnienia związane z łańcuchem wywołań potrafią zabić UX.
Przykład z życia:
Pracowałem z startupem, który budował platformę do zarządzania kampaniami reklamowymi. Zdecydowali się na serverless i podzielili logikę biznesową na kilkadziesiąt funkcji. Każda zapisana kampania wymagała sekwencyjnego wywołania pięciu różnych lambd – jednej do walidacji, drugiej do zapisu w bazie, trzeciej do wysłania notyfikacji, czwartej do aktualizacji cache’a, piątej do logowania. Czas odpowiedzi przeciętnego requestu wynosił ponad 3 sekundy, bo każda funkcja startowała od zera (zimny start). Klienci odchodzili w ciągu pierwszego tygodnia.
Lekcja:
Serverless nie oznacza, że każda linijka kodu musi być osobną funkcją. Wręcz przeciwnie – dobrze jest łączyć powiązane operacje w jedną funkcję, szczególnie jeśli są wywoływane razem. Zamiast trzymać się święcie zasady jednej odpowiedzialności, pomyśl o granicach kontekstowych – co ma sens jako całość? Walidacja + zapis w bazie + notyfikacja? To może być jedna funkcja, która działa w jednym wywołaniu.
Błąd #2: Ignorowanie zimnych startów (cold start)
To najczęstsza przyczyna problemów z wydajnością w serverless. Każda funkcja, która nie była wywoływana przez jakiś czas, musi zostać załadowana od zera – stworzenie kontenera, załadowanie runtime’u, uruchomienie kodu. To trwa od kilkuset milisekund do kilku sekund, w zależności od języka i wielkości funkcji.
Startupy często zapominają o tym, gdy projektują API dla klienta końcowego. Wyobraź sobie, że użytkownik loguje się do aplikacji, a pierwsze zapytanie trwa 2 sekundy, bo Lambda jest zimna. Potem kolejne requesty są szybkie, ale pierwsze wrażenie – fatalne. Użytkownik myśli, że aplikacja jest wolna.
Przykład z życia:
Inny startup – aplikacja do rezerwacji wizyt. Używali Python na AWS Lambda. Każde wywołanie API, które nie było wywoływane przez 15 minut, dostawało cold start rzędu 1,5 sekundy. W efekcie średni czas odpowiedzi wynosił 800 ms, ale rozkład był ogromny – od 200 ms do 2 sekund. Klienci zgłaszali opóźnienia, a zespół nie wiedział, dlaczego, bo ich testy robili w pętli i wszystko działało szybko.
Rozwiązania:
- Używaj języków szybszych do cold startu – Node.js i Go są znacznie lepsze niż Python czy Java.
- Zmniejszaj rozmiar paczki – im mniej kodu do załadowania, tym szybciej.
- Rozważ użycie provisioned concurrency – utrzymujesz kilka „ciepłych” instancji cały czas. Kosztuje, ale jeśli masz ruch, może to być opłacalne.
- Jeśli cold start to problem krytyczny, zastanów się, czy serverless jest dla Ciebie odpowiedni. Może lepszy będzie kontener z auto-scalingiem?
Błąd #3: Pomijanie limitów i kosztów przy dużym ruchu
Serverless kusi modelem pay-per-use, ale wielu zapomina, że przy dużej liczbie wywołań ceny rosną liniowo, a czasem wykładniczo. Do tego dochodzą limity – np. AWS Lambda ma limit 1000 współbieżnych wywołań na region (można zwiększyć, ale to dodatkowy proces). Przekroczenie limitu skutkuje throttlingiem – requesty są odrzucane.
Przykład z życia:
Startup z aplikacją do przetwarzania obrazów – użytkownicy wysyłali zdjęcia, lambda je kompresowała i zapisywała. Początkowo ruch był niski, koszty śmieszne. Gdy aplikacja trafiła na pierwszy kanał social media, w ciągu godziny dostali 100 000 wywołań. Lambda zaczęła throttlować, a użytkownicy dostawali błędy 429. Próbowali zwiększyć limit, ale AWS potrzebował 24h na zatwierdzenie. Stracili szansę na viralowe rozprzestrzenienie się.
Koszty:
Przy okazji zorientowali się, że każda lambda działała średnio 2 sekundy, a koszt za milion wywołań to około 10 dolarów. Przy 100 000 wywołań na godzinę, rachunek za jeden dzień viralowego ruchu wyniósłby 240 dolarów – i to tylko za funkcje, do tego dochodziły koszty transferu danych i przechowywania. Nie mieli na to budżetu.
Lekcja:
- Zawsze oszacuj maksymalny ruch, jaki możesz obsłużyć, i związane z tym koszty. Zrób testy obciążeniowe.
- Ustal limity budżetowe i alerty, żeby nie obudzić się z gigantycznym rachunkiem.
- Rozważ mieszkankę – serverless dla małego ruchu, a dla skoków użyj tradycyjnego backendu lub CloudFront z cache’em.
- Pamiętaj, że serverless nie jest za darmo – płacisz za wygody, ale przy dużym wolumenie tradycyjne serwery są tańsze.
Podsumowanie
Serverless to potężne narzędzie, ale tylko jeśli rozumiesz jego ograniczenia. Startupy często dają się skusić obietnicą „zero zarządzania” i niskich kosztów początkowych, a potem płacą frycowe za błędy w projektowaniu architektury. Moja rada? Zanim zdecydujesz się na serverless, dokładnie przeanalizuj charakter swojego ruchu, wymagania dotyczące czasu odpowiedzi i budżet. I nigdy nie wrzucaj wszystkiego do jednego worka – serverless, kontenery, VPS – to wszystko narzędzia, które mają swoje miejsce.
Jeśli potrzebujesz pomocy w zaprojektowaniu architektury backendu dla Twojego startupu – serwerless czy nie – JurskiTech ma doświadczenie w realnych wdrożeniach. Doradzimy, która droga będzie dla Ciebie najlepsza.
