Dwa modele uruchamiania aplikacji

W tradycyjnym modelu hostingu aplikacja działa na serwerze (fizycznym lub wirtualnym) przez cały czas. Serwer jest uruchomiony, nasłuchuje na żądania i odpowiada na nie. Płacisz za serwer niezależnie od tego, czy obsługuje 1000 żądań na sekundę, czy stoi bezczynnie o trzeciej w nocy.

Model serverless odwraca tę logikę. Nie zarządzasz serwerem — dostawca chmury uruchamia Twój kod w odpowiedzi na zdarzenie (żądanie HTTP, wiadomość w kolejce, zmiana w bazie danych), wykonuje go i zamyka. Płacisz wyłącznie za czas wykonania kodu i liczbę wywołań.

Najpopularniejsze platformy serverless to AWS Lambda, Google Cloud Functions, Azure Functions i Cloudflare Workers. Każda oferuje nieco inny model, ale fundamentalna idea jest wspólna — kod bez serwera.

Zalety serverless

Zerowe zarządzanie infrastrukturą to prawdopodobnie największa korzyść. Nie musisz konfigurować systemu operacyjnego, instalować aktualizacji bezpieczeństwa, monitorować użycia dysku ani planować pojemności. Dostawca chmury zajmuje się wszystkim, od sprzętu po balansowanie obciążenia.

Automatyczne skalowanie jest wbudowane. Jeśli Twoja funkcja otrzymuje 10 żądań na minutę, działa w jednej instancji. Gdy nagle dostaniesz 10 000 żądań na minutę — platforma automatycznie uruchomi setki instancji równolegle. Skalowanie w dół jest równie automatyczne — gdy ruch spada, niepotrzebne instancje są zamykane.

Model płatności za użycie może być bardzo ekonomiczny. AWS Lambda oferuje 1 milion wywołań miesięcznie w warstwie bezpłatnej. Dla małych projektów, wewnętrznych narzędzi czy API o niskim ruchu koszty mogą być bliskie zeru. W tradycyjnym modelu nawet najmniejszy VPS kosztuje kilkadziesiąt złotych miesięcznie, niezależnie od wykorzystania.

Szybki deployment — wgrywasz kod (zwykle spakowany plik ZIP lub kontener) i jest gotowy. Nie musisz konfigurować procesu CI/CD z budowaniem obrazów Docker, wypychaniem do rejestru i restartowaniem kontenerów.

Wady serverless

Cold start to najczęściej wymieniana wada. Gdy funkcja nie była wywoływana przez pewien czas, platforma wyłącza jej instancję. Następne żądanie musi poczekać na uruchomienie nowego środowiska wykonawczego — to tak zwany cold start. Czas cold startu zależy od języka programowania i rozmiaru funkcji:

  • Python, Node.js — zwykle 100-300 ms
  • Java, .NET — może sięgać 1-5 sekund
  • Go — dzięki małym binarkom i szybkiemu startowi, cold starty rzadko przekraczają 200 ms

Dla API, które musi odpowiadać w milisekundach, cold starty mogą być problemem. Istnieją obejścia — provisioned concurrency (utrzymywanie ciepłych instancji) — ale to podnosi koszty i komplikuje model.

Ograniczenia czasu wykonania różnią się między platformami. AWS Lambda pozwala na maksymalnie 15 minut, Cloud Functions na 9 minut. Długotrwałe operacje — generowanie raportów, przetwarzanie wideo, złożone migracje danych — nie nadają się do serverless.

Vendor lock-in to realne ryzyko. Funkcja Lambda korzystająca z DynamoDB, SQS, S3 i API Gateway jest głęboko osadzona w ekosystemie AWS. Migracja do innego dostawcy wymaga przepisania integracji. W tradycyjnym modelu kontener Docker działa wszędzie — na AWS, GCP, własnym serwerze czy laptopie.

Trudniejsze debugowanie i testowanie lokalne — odtworzenie środowiska serverless na maszynie deweloperskiej jest skomplikowane. Narzędzia takie jak AWS SAM czy Serverless Framework pomagają, ale nie odtwarzają w pełni zachowania produkcyjnego.

Koszty przy dużym ruchu mogą być zaskakująco wysokie. Model pay-per-invocation jest tani przy niskim ruchu, ale przy milionach żądań dziennie tradycyjny serwer okazuje się znacznie tańszy. Stały VPS za 100 zł miesięcznie obsłuży ruch, który w modelu serverless kosztowałby wielokrotnie więcej.

Kiedy serverless to dobry wybór

Webhooks i integracje — funkcja, która reaguje na zdarzenia z zewnętrznych systemów (płatności, formularze, powiadomienia). Ruch jest sporadyczny i nieprzewidywalny — idealny scenariusz dla serverless.

Przetwarzanie asynchroniczne — generowanie miniaturek po uploadzie obrazka, wysyłanie maili, indeksowanie dokumentów. Zadania uruchamiane zdarzeniami, gdzie kilkaset milisekund opóźnienia nie ma znaczenia.

MVP i prototypy — gdy chcesz szybko zweryfikować pomysł bez inwestowania czasu w infrastrukturę. Serverless pozwala uruchomić API w kilka godzin.

API o niskim i zmiennym ruchu — wewnętrzne narzędzia firmowe, sezonowe kampanie marketingowe, projekty hobbystyczne. Koszty skalują się proporcjonalnie do użycia.

Kiedy tradycyjny hosting wygrywa

Stały, przewidywalny ruch — strona firmowa z regularnymi odwiedzinami, sklep internetowy, portal informacyjny. Stały koszt serwera jest niższy niż pay-per-invocation przy dużym wolumenie.

Aplikacje stanowe — sesje użytkowników, połączenia WebSocket, długotrwałe procesy. Serverless jest z natury bezstanowy — każde wywołanie to niezależna instancja.

Pełna kontrola nad środowiskiem — własny serwer pozwala zainstalować dowolne oprogramowanie, skonfigurować system operacyjny, zarządzać certyfikatami SSL i logami dokładnie tak, jak potrzebujesz.

Niska latencja — tradycyjny serwer odpowiada w milisekundach, bez ryzyka cold startu. Dla aplikacji real-time, gier online czy systemów transakcyjnych to kluczowa różnica.

Nasze podejście

W LinWork stawiamy na tradycyjny hosting z kontenerami Docker za Nginx reverse proxy. Nasze serwisy Go startują w milisekundach, zajmują kilkanaście MB RAM i obsługują tysiące równoczesnych połączeń. Koszty są przewidywalne, debugging prosty, a vendor lock-in zerowy — kontenery można przenieść na dowolny serwer.

To nie znaczy, że serverless jest zły — po prostu nie jest optymalny dla naszego profilu zastosowań. Dla klientów z innymi potrzebami chętnie zaprojektujemy architekturę serverless. Skontaktuj się z nami, żeby omówić najlepsze rozwiązanie dla Twojego projektu.