Chmura czy własny serwer? Jak wybrać infrastrukturę dla systemu firmowego

Każdy system, który dla kogoś budujemy, musi gdzieś działać. I prawie przy każdym projekcie pada to samo pytanie: „Chmura czy własny serwer?". Część klientów słyszała, że chmura jest droga. Inni — że własny serwer to przeżytek. Jeszcze inni mają w szafie w biurze komputer, który „od lat działa i nikt go nie dotyka" (i właśnie to powinno ich niepokoić najbardziej).

Prawda jest mniej emocjonalna: każda opcja ma swoje miejsce. W tym artykule rozkładamy je na czynniki pierwsze — tak, jak robimy to z klientami przy projektowaniu architektury.

Trzy modele, o których warto wiedzieć

Zanim porównamy koszty, ustalmy słownictwo:

• Chmura publiczna (hyperscalery) — AWS, Microsoft Azure, Google Cloud. Setki usług zarządzanych: bazy danych, kolejki, funkcje serverless, AI, magazyny plików. Płacisz za zużycie, skalujesz w minutę. Wszystkie trzy mają regiony w Polsce lub tuż obok.
• Serwery VPS i dedykowane u dostawcy — np. Hetzner, OVHcloud, Scaleway czy polscy dostawcy hostingu. Dostajesz maszynę wirtualną lub fizyczny serwer za stałą miesięczną opłatę. Mniej usług „z pudełka", znacznie niższa cena za moc obliczeniową.
• On-premise — serwer stoi w Twojej firmie lub w wynajętej szafie w centrum danych (kolokacja). Kupujesz sprzęt, odpowiadasz za wszystko: od zasilania po aktualizacje.

Do tego dochodzi warstwa usług: IaaS (dostajesz maszynę), PaaS (dostajesz platformę — np. zarządzaną bazę danych, na której nie musisz sam instalować PostgreSQL) i SaaS (dostajesz gotową aplikację, np. Microsoft 365). Im wyżej, tym mniej pracy administracyjnej, ale też mniej kontroli i wyższa cena jednostkowa.

Mit nr 1: „Chmura zawsze jest tańsza"

Chmura jest tańsza na starcie — nie kupujesz sprzętu, płacisz od pierwszego dnia za to, czego używasz. Ale przy stałym obciążeniu 24/7 rachunek potrafi być kilkukrotnie wyższy niż za porównywalny serwer dedykowany.

Najczęstsze źródła niespodzianek na fakturze:

• Transfer danych wychodzących (egress). Przesyłanie danych z chmury do internetu jest płatne za każdy gigabajt. Przy aplikacjach z dużą ilością plików, wideo czy kopii zapasowych trzymanych poza chmurą — to potrafi być największa pozycja.
• Usługi zarządzane. Zarządzana baza danych kosztuje zwykle wielokrotnie więcej niż maszyna wirtualna o tych samych parametrach. Płacisz za wygodę: automatyczne kopie, aktualizacje, replikację.
• „Drobne" usługi sieciowe. Load balancery, bramy NAT, publiczne adresy IP, logi i monitoring — każda z tych rzeczy osobno kosztuje niewiele, razem potrafią podwoić rachunek.
• Zapomniane zasoby. Środowisko testowe postawione „na chwilę" pół roku temu, snapshoty dysków, nieużywane wolumeny.

Mit nr 2: „Własny serwer to brak kosztów po zakupie"

Serwer w szafie wygląda na darmowy, bo nie przychodzi za niego faktura co miesiąc. Ale koszty są — tylko ukryte:

• prąd i chłodzenie — serwer pracujący całą dobę to od kilkuset do kilku tysięcy kWh rocznie,
• czas administratora — aktualizacje systemu, łatki bezpieczeństwa, monitoring, reakcja na awarie,
• kopie zapasowe poza lokalizacją — backup trzymany na dysku obok serwera nie chroni przed pożarem, zalaniem ani ransomware,
• wymiana sprzętu — dyski i zasilacze się psują, a cały serwer po 5–7 latach wymaga wymiany,
• ryzyko przestoju — awaria zasilania, łącza internetowego albo jedynego dysku bez RAID potrafi zatrzymać firmę na kilka dni.

Porównanie na przykładzie: typowy system firmowy

Weźmy system, jaki często budujemy dla firm: aplikacja webowa dla 20–50 użytkowników, baza danych PostgreSQL, kilka automatyzacji w tle (np. n8n), pliki (skany, zdjęcia) — łącznie kilkaset gigabajtów. Kwoty są orientacyjne i zależą od dostawcy oraz kursu walut:

Wniosek z tabeli: dla większości małych i średnich firm najlepszy stosunek ceny do możliwości daje dobrze skonfigurowany VPS lub serwer dedykowany u europejskiego dostawcy, z automatycznymi kopiami zapasowymi w innej lokalizacji. Chmura publiczna wygrywa, gdy potrzebujesz wysokiej dostępności, szybkiego skalowania lub konkretnych usług zarządzanych. On-premise wygrywa, gdy dane nie mogą opuścić firmy albo system musi działać bez internetu.

Kiedy wybrać chmurę publiczną

• Obciążenie jest zmienne. Sklep internetowy z pikami w Black Friday, system rozliczeń uruchamiany raz w miesiącu, przetwarzanie wsadowe. Płacisz za szczyt tylko wtedy, gdy jest szczyt.
• Potrzebujesz usług, których nie chcesz budować sam. Kolejki, funkcje serverless, globalny CDN, zarządzane bazy z replikacją, usługi AI.
• Dostępność jest krytyczna. Kilka stref dostępności w regionie, automatyczne przełączanie, SLA na poziomie 99,9% i więcej.
• Startup lub nowy produkt. Nie wiesz, czy będziesz mieć 10 czy 10 000 użytkowników. Kredyty startowe od dostawców chmury pozwalają przetrwać pierwszy rok niemal za darmo.

Przy projekcie QR-CARS — platformie SaaS dla warsztatów i dealerów — postawiliśmy właśnie na chmurę: frontend w Next.js na Vercelu, bezserwerowa baza PostgreSQL w Neon, uwierzytelnianie i funkcje w Firebase. Zero serwerów do utrzymania, wdrożenie po każdym commicie przez CI/CD i koszty rosnące razem z liczbą klientów.

Kiedy wybrać VPS lub serwer dedykowany

• Obciążenie jest stałe i przewidywalne. System wewnętrzny firmy, CRM, automatyzacje działające 24/7.
• Budżet ma znaczenie. Za cenę jednej zarządzanej bazy danych w hyperscalerze dostaniesz serwer dedykowany z wielordzeniowym procesorem i dużą ilością pamięci RAM.
• Chcesz uniknąć uzależnienia od jednego dostawcy. Standardowy Linux, Docker i PostgreSQL przeniesiesz do innego dostawcy w jeden dzień. Aplikację zbudowaną na własnościowych usługach chmurowych — w kilka miesięcy.

Kiedy wybrać on-premise

• Dane nie mogą opuścić firmy — ze względów prawnych, umownych albo polityki bezpieczeństwa.
• System współpracuje z lokalnym sprzętem — kamery, sterowniki przemysłowe, urządzenia IoT, lokalne bazy danych starszych programów.
• Potrzebujesz dużej mocy GPU przez cały czas — np. do lokalnego modelu językowego. Wynajem GPU w chmurze przez całą dobę szybko przekracza koszt zakupu karty.
• Masz kompetencje do utrzymania. Własny administrator albo firma zewnętrzna z umową serwisową.

Architektura hybrydowa — najczęstszy wybór w praktyce

W rzeczywistości rzadko wybieramy jedną opcję. Typowa architektura, którą proponujemy, wygląda tak:

• aplikacja i baza danych na serwerze dedykowanym lub VPS w europejskim centrum danych,
• kopie zapasowe w innym centrum danych, u innego dostawcy (object storage zgodny z S3),
• elementy lokalne (np. obsługa kamer, integracja z programem księgowym zainstalowanym w biurze) na małym serwerze w firmie, połączonym bezpiecznym tunelem VPN,
• usługi specjalistyczne (wysyłka maili, SMS, modele AI) przez API wyspecjalizowanych dostawców.

Każdy element stoi tam, gdzie jest najtańszy i najbezpieczniejszy dla swojej roli.

Czy potrzebujesz Kubernetesa?

Kubernetes to standard orkiestracji kontenerów. Automatycznie restartuje aplikacje, rozkłada ruch, skaluje liczbę instancji i pozwala wdrażać nowe wersje bez przestojów. Na co dzień utrzymujemy klastry Kubernetes — w tym produkcyjne wdrożenia n8n skalowane od 2 do 10 workerów, z monitoringiem w Prometheusie i Grafanie oraz własnym operatorem do kopii zapasowych PostgreSQL, MinIO i Qdranta.

Właśnie dlatego możemy powiedzieć uczciwie: dla większości małych firm Kubernetes to przesada. Wprowadza dużą złożoność, wymaga wiedzy do utrzymania i rozwiązuje problemy, których mała firma zwykle nie ma.

Kubernetes ma sens, gdy:

• masz wiele usług (mikroserwisów) i kilka zespołów je rozwijających,
• potrzebujesz automatycznego skalowania i wdrożeń bez przestojów,
• utrzymujesz wiele środowisk (produkcja, testy, klienci),
• masz zespół lub partnera, który zna Kubernetesa na poziomie produkcyjnym.

Dla jednej aplikacji z bazą danych w zupełności wystarczy Docker Compose na dobrze skonfigurowanym serwerze, z automatycznymi aktualizacjami i monitoringiem. Prościej, taniej i z mniejszą liczbą rzeczy, które mogą się zepsuć.

Kopie zapasowe: reguła 3-2-1 (i dlaczego backup to nie wszystko)

Niezależnie od wyboru infrastruktury, obowiązuje jedna zasada: 3 kopie danych, na 2 różnych nośnikach, z czego 1 poza główną lokalizacją. Coraz częściej rozszerza się ją do 3-2-1-1-0: dodatkowa kopia niemodyfikowalna (immutable), której nie zaszyfruje ransomware, i zero błędów przy weryfikacji odtworzenia.

To ostatnie jest kluczowe. Kopia zapasowa, której nikt nigdy nie próbował odtworzyć, jest tylko nadzieją. W naszych wdrożeniach testujemy odtwarzanie cyklicznie i automatycznie — w ramach procedury disaster recovery, a nie dopiero wtedy, gdy coś się stanie.

Dwa parametry warto ustalić z góry:

• RPO (Recovery Point Objective) — ile danych możesz stracić? Jeśli kopia robi się raz na dobę, w najgorszym wypadku tracisz dzień pracy.
• RTO (Recovery Time Objective) — jak długo system może nie działać? Godzina, dzień, tydzień?

Od odpowiedzi na te pytania zależy architektura — i koszt.

RODO, NIS2 i suwerenność danych

Kilka kwestii prawnych, o które pytają klienci:

• Lokalizacja danych. RODO nie zakazuje korzystania z amerykańskich dostawców, ale wymaga odpowiednich podstaw transferu i umów powierzenia. Najprostsza droga to wybór regionu w UE i dostawcy, który podpisuje umowę powierzenia przetwarzania danych.
• Dostawcy spoza UE. Część firm — zwłaszcza w sektorze publicznym, medycznym i finansowym — preferuje dostawców z siedzibą w Europie, żeby ograniczyć ryzyko dostępu do danych na podstawie prawa państw trzecich.
• NIS2. Unijna dyrektywa o cyberbezpieczeństwie rozszerzyła listę firm, które muszą spełniać wymogi zarządzania ryzykiem, zgłaszania incydentów i bezpieczeństwa łańcucha dostaw. Jeśli Twoja firma działa w sektorze objętym dyrektywą (lub jest dostawcą takiej firmy), wybór i dokumentacja infrastruktury przestają być wyłącznie decyzją techniczną.
• Data Act. Unijny akt w sprawie danych stosowany od września 2025 roku ułatwia zmianę dostawcy chmury i stopniowo ogranicza opłaty za przeniesienie danych przy migracji. To dobra wiadomość dla wszystkich, którzy obawiają się uzależnienia od jednego dostawcy.

Jak podjąć decyzję — lista kontrolna

Zanim wybierzesz infrastrukturę, odpowiedz na te pytania:

1. Czy obciążenie jest stałe, czy zmienne?
2. Jakie dane przetwarzasz i czy mogą opuścić firmę lub UE?
3. Jak długo system może nie działać (RTO) i ile danych możesz stracić (RPO)?
4. Kto będzie odpowiadał za aktualizacje, monitoring i reagowanie na awarie?
5. Czy system musi współpracować z lokalnym sprzętem lub oprogramowaniem?
6. Jak łatwo będzie przenieść system do innego dostawcy za 3 lata?
7. Jaki jest całkowity koszt w horyzoncie 3 lat — łącznie z pracą ludzi, a nie tylko fakturami?

Podsumowanie

• Chmura publiczna — dla zmiennego obciążenia, wysokiej dostępności i gotowych usług zarządzanych. Uważaj na egress i koszty usług zarządzanych.
• VPS / serwer dedykowany — najlepszy stosunek ceny do możliwości dla stałych, przewidywalnych systemów firmowych.
• On-premise — gdy dane nie mogą wyjść z firmy, system współpracuje z lokalnym sprzętem albo potrzebujesz stałej mocy GPU.
• Hybryda — najczęściej najlepsze rozwiązanie w praktyce.
• Kubernetes — potężne narzędzie, ale dla jednej aplikacji zwykle przesada.
• Backup — reguła 3-2-1, kopia niemodyfikowalna i regularne testy odtwarzania.

W Nightcode projektujemy i utrzymujemy infrastrukturę dla systemów, które budujemy — od prostego serwera z Docker Compose po produkcyjne klastry Kubernetes z monitoringiem i disaster recovery. Jeśli zastanawiasz się, gdzie powinien działać Twój system, albo chcesz sprawdzić, czy nie przepłacasz za obecną infrastrukturę — porozmawiajmy.