Serverless vs tradycyjne backendy: koszty, które ukrywa marketing
Gdy słyszysz „serverless”, pewnie myślisz: zero zarządzania serwerami, płacisz tylko za wykonanie, skalowanie automatyczne. Brzmi jak marzenie każdego CTO. Marketing dostawców chmury zrobił swoje – serverless stał się synonimem nowoczesności i oszczędności. Ale czy na pewno?
Pracując z kilkoma startupami, które z entuzjazmem rzuciły się na serverless, widziałem sytuacje, gdzie miesięczne rachunki za AWS Lambda czy Azure Functions były wyższe niż koszt stałego serwera VPS. I to nie był przypadek – to efekt ukrytych kosztów, które dostawcy chętnie pomijają w swoich kalkulacjach.
W tym artykule rozłożymy na części pierwsze realne koszty serverless w porównaniu do tradycyjnych backendów (np. serwer na Node.js na VPS lub kontenerach). Pokażę, kiedy serverless ma sens, a kiedy jest finansową pułapką.
1. Cena za wygodę: ukryte opłaty za zimne starty i czas wykonywania
Serverless reklamowany jest jako „płać tylko za to, czego używasz”. To prawda, ale diabeł tkwi w szczegółach. W AWS Lambda płacisz za liczbę zapytań oraz czas wykonywania w milisekundach. Problem polega na tym, że czas wykonywania obejmuje również tzw. zimne starty – inicjalizację środowiska, które może trwać od 100 ms do nawet kilku sekund przy większych funkcjach. Te milisekundy sumują się w skali tysięcy wywołań dziennie.
Przykład: Aplikacja e-commerce z 500 tysiącami zapytań dziennie, każde średnio 200 ms (w tym 100 ms zimnego startu). Przy stawce $0.0000166667 za GB-s, koszt Lambda może wynieść około $50 miesięcznie tylko za czas wykonania, plus opłaty za zapytania ($0.20 za milion) – dodatkowe $0.10. Do tego dochodzą koszty API Gateway ($3.50 za milion zapytań), CloudWatch Logs, i inne. Łącznie może to być $60-80 miesięcznie.
Tymczasem tradycyjny serwer VPS z 2 vCPU i 4 GB RAM kosztuje około $20-30 miesięcznie, a obsłuży ten sam ruch bez problemu, z tym że z góry płacisz stałą stawkę, niezależnie od obciążenia.
Kiedy serverless jest droższy? Przy stałym, przewidywalnym ruchu. Jeśli Twoja aplikacja ma równomierne obciążenie 24/7, stały serwer będzie tańszy.
2. Koszty przepustowości i transferu danych
W serverless często zapomina się o kosztach transferu między komponentami. Każde wywołanie Lambda, które odczytuje dane z DynamoDB (kolejna usługa serverless) lub S3, generuje ruch. AWS za transfer danych między usługami w tym samym regionie nie pobiera opłat, ale jeśli używasz VPC (np. dla bezpieczeństwa), musisz dodać NAT Gateway, który kosztuje $0.045 za godzinę + $0.045 za GB przetworzonych danych. Przy 100 GB danych miesięcznie to dodatkowe $4.50 za NAT + $32.40 za stałą opłatę (720h * $0.045 = $32.40) – łącznie prawie $37 miesięcznie tylko za komunikację w VPC!
W tradycyjnym backendzie wszystko działa w jednym procesie lub kontenerze, a komunikacja z bazą danych czy storage odbywa się bez dodatkowych pośredników. Nie ma NAT Gateway, nie ma oddzielnych opłat za transfer wewnętrzny.
Przykład porównawczy: Aplikacja SaaS z bazą danych PostgreSQL na oddzielnym serwerze. W serverless: Lambda + RDS Proxy (aby uniknąć problemów z połączeniami) + VPC + NAT. W tradycyjnym: jeden serwer z aplikacją i bazą danych (lub osobna baza w tej samej sieci). Różnica w kosztach infrastruktury może wynieść 30-50% na korzyść tradycyjnego rozwiązania.
3. Ukryte koszty zimnych startów dla użytkowników
Zimne starty to nie tylko koszt pieniężny, ale też utrata użytkowników. Jeśli Twoja aplikacja jest wrażliwa na opóźnienia (np. API dla frontendu), czas odpowiedzi 1-2 sekundy może zniechęcić odbiorców. Badania pokazują, że wzrost czasu ładowania o 1 sekundę przekłada się na spadek konwersji o 7%.
W tradycyjnym backendzie proces działa cały czas, gotowy na przyjęcie żądań. Czas odpowiedzi jest stabilny. W serverless, jeśli funkcja jest wywoływana rzadko, zimny start może trwać nawet 5 sekund (w przypadku Javy lub .NET). To zabija UX.
Realny przypadek: Startup oferujący narzędzie do analizy nastrojów w social media. Użyli serverless do przetwarzania danych. Każde zapytanie od użytkownika wywoływało Lambda, która musiała załadować model ML (50 MB). Zimny start trwał 4 sekundy. Użytkownicy narzekali na opóźnienia. Po przeniesieniu na stały serwer z procesem wsadowym czasy spadły do 200 ms, a koszty zmalały o 40%.
4. Kiedy serverless faktycznie się opłaca?
Serverless ma swoje miejsce – tam, gdzie ruch jest bardzo zmienny: aplikacje sezonowe, webhooki, funkcje wywoływane nieregularnie (np. cotygodniowe raporty), backupy. W takich przypadkach tradycyjny serwer stałby bezczynnie większość czasu, generując koszty bez korzyści.
Przykład: System do rezerwacji terminów w klinikach – szczyt w poniedziałek rano, potem martwo. Serverless płaci tylko za szczyt. VPS płaci cały miesiąc. Różnica: serverless $10 vs VPS $30.
5. Hybryda – złoty środek
Najlepsze rozwiązanie to często połączenie: stały backend dla podstawowej logiki (np. API REST) i serverless dla zadań asynchronicznych (wysyłka maili, przetwarzanie obrazów, generowanie PDF-ów). Dzięki temu unikasz zimnych startów w głównym API, a jednocześnie korzystasz z elastyczności serverless dla obciążeń zmiennych.
Wnioski:
- Nie daj się zwieść marketingowi – oblicz realne koszty dla swojego ruchu.
- Serverless jest świetny dla małych, nieregularnych zadań, ale nie dla stałego obciążenia.
- Uważaj na ukryte opłaty: NAT Gateway, transfer, zimne starty.
- Rozważ architekturę hybrydową jako kompromis.
JurskiTech pomaga firmom dobrać odpowiednią architekturę backendu – taką, która nie generuje niepotrzebnych kosztów i nie spowalnia rozwoju. Jeśli rozważasz serverless, zanim podejmiesz decyzję, przeanalizuj rzeczywiste przypadki użycia. Nie każdy błysk w chmurze to złoto.
