Serverless czy VPS — gdzie hostować aplikację

Wybór modelu hostingu wpływa na miesięczny rachunek, na to, kto reaguje o trzeciej w nocy przy awarii, i na swobodę przeniesienia aplikacji do innego dostawcy. Różnice w koszcie między modelami bywają kilkukrotne — w obie strony, zależnie od charakteru ruchu.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Trzy modele, nie dwa

Zestawienie „serverless kontra VPS" pomija wariant pośredni, który w praktyce wybiera najwięcej firm: platformę zarządzaną, gdzie dostawca utrzymuje system operacyjny i środowisko uruchomieniowe, a Ty dostarczasz kod.

Serwer wirtualny — kontrola i przewidywalny rachunek

Dostajesz maszynę z określoną mocą obliczeniową i pamięcią, na której instalujesz to, co uznasz za potrzebne. Rachunek jest taki sam niezależnie od ruchu, co przy stabilnym obciążeniu bywa najtańszym rozwiązaniem na rynku.

Zaletą trudną do przecenienia jest przewidywalność diagnostyki. Gdy aplikacja zwalnia, można zalogować się na serwer, sprawdzić obciążenie, przejrzeć rejestry i zobaczyć, co się dzieje. W modelach zarządzanych część tych informacji jest niedostępna albo prezentowana w formie zagregowanej.

Kosztem jest odpowiedzialność. Aktualizacje systemu, konfiguracja zapory, certyfikaty, kopie zapasowe, monitoring i reakcja na awarię — wszystko to ktoś musi wykonać. Jeżeli firma nie ma administratora, ten obowiązek trzeba kupić jako usługę, co zmienia rachunek kosztów.

Model bezserwerowy — płacisz za to, czego używasz

Kod uruchamiany jest na żądanie, a rozliczenie następuje za liczbę wywołań i czas obliczeń. Przy braku ruchu koszt jest bliski zeru, przy nagłym wzroście środowisko skaluje się automatycznie, bez konfiguracji.

To rozwiązanie ma trzy właściwości, które bywają zaletą lub wadą w zależności od zastosowania. Skalowanie jest automatyczne, ale i rachunek rośnie automatycznie — błąd powodujący pętlę wywołań generuje realny koszt. Środowisko jest utrzymywane przez dostawcę, ale diagnostyka ogranicza się do tego, co udostępnia w rejestrach. Koszt przy niskim ruchu jest minimalny, ale przy wysokim i stałym potrafi wielokrotnie przekroczyć cenę serwera o równoważnej mocy.

Porównanie kosztów na przykładzie

Kwoty są orientacyjne i zależą od dostawcy, ale proporcje pozostają stabilne. Zasada jest prosta: im bardziej równomierny ruch, tym korzystniej wypada stała opłata za moc obliczeniową.

Czynniki pomijane w kalkulacjach

• Koszt administracji — kilka godzin miesięcznie przy serwerze wirtualnym, praktycznie zero przy modelu zarządzanym.
• Transfer wychodzący — u dostawców chmurowych bywa istotną pozycją rachunku, często pomijaną przy szacowaniu.
• Baza danych — model bezserwerowy wymaga bazy dostosowanej do dużej liczby krótkich połączeń, co bywa droższe.
• Przechowywanie plików — funkcje bezserwerowe nie mają trwałego dysku, więc pliki trafiają do osobnej usługi.
• Zadania długotrwałe — generowanie raportów czy przetwarzanie obrazów bywa ograniczone czasem wykonania funkcji.
• Monitoring i rejestry — w chmurze często rozliczane osobno, przy większym ruchu zauważalnie.
• Środowisko testowe — w modelu bezserwerowym praktycznie darmowe, przy serwerach to kolejna maszyna.

Uzależnienie od dostawcy

To ryzyko, o którym warto pomyśleć na starcie, choć rzadko bywa problemem natychmiastowym. Aplikacja korzystająca wyłącznie ze standardowych mechanizmów przenosi się między dostawcami w kilka dni. Aplikacja zbudowana wokół specyficznych usług jednego dostawcy — kolejek, baz, mechanizmów uwierzytelniania — bywa nieprzenośna bez istotnej przebudowy.

Nie oznacza to, że należy unikać usług dostawcy. Oznacza, że warto świadomie decydować, które z nich są na tyle wygodne, żeby zaakceptować związaną z nimi zależność, i trzymać logikę biznesową w warstwie od nich odseparowanej.

Jak wybrać — praktyczne kryteria

Kopie zapasowe i plan na awarię

Wybór modelu hostingu determinuje, kto odpowiada za odtworzenie serwisu po awarii — i to jest różnica ważniejsza niż comiesięczny rachunek. Warto ustalić ją świadomie, zanim awaria nastąpi.

Ostatni wiersz bywa źródłem nieporozumień. W modelu bezserwerowym dostawca utrzymuje środowisko uruchomieniowe, ale dane aplikacji — baza i pliki użytkowników — to osobne usługi z własną polityką kopii. Założenie, że „chmura sama to robi", kończy się utratą danych przy pierwszym błędzie w kodzie, który skasuje rekordy.

Minimum, które warto mieć niezależnie od modelu

• Kopia codzienna bazy danych i plików wgrywanych przez użytkowników.
• Kopia poza główną infrastrukturą — u innego dostawcy lub w innej lokalizacji.
• Przetestowane odtworzenie wykonane co najmniej raz przy wdrożeniu i powtarzane co pół roku.
• Kod w repozytorium z możliwością odtworzenia środowiska od zera.
• Opisana procedura — kto co robi i w jakiej kolejności przy awarii.
• Znany czas odtworzenia, żeby wiedzieć, ile potrwa przestój.

Trzeci punkt jest tym, który najczęściej wypada z listy. Kopia, której nigdy nie odtworzono, bywa niekompletna albo zapisana w formacie wymagającym narzędzi, których nie masz. Test wykonany raz, na spokojnie, kosztuje godzinę — a jego brak ujawnia się w najgorszym możliwym momencie.

Podsumowanie

Nie istnieje model lepszy w każdych warunkach. Serwer wirtualny wygrywa przy stałym ruchu i wtedy, gdy zależy Ci na pełnej kontroli oraz prostej diagnostyce. Model bezserwerowy wygrywa przy ruchu nierównomiernym i w projektach na wczesnym etapie, gdzie nie warto płacić za moc obliczeniową przez większość doby wykorzystywaną w niewielkim stopniu.

Przed decyzją warto oszacować dwie liczby: przewidywany rozkład ruchu w ciągu doby i miesiąca oraz realny koszt administracji. To one, a nie porównania cenników, przesądzają o tym, który wariant wyjdzie taniej w perspektywie roku.