On-premises czy chmura? Prawdziwe koszty, o których nikt nie mówi

Firma produkcyjna z Łodzi - 120 pracowników, system ERP, 3 TB danych. Przenieśli wszystko do chmury, bo „tak teraz się robi". Po 18 miesiącach miesięczny rachunek za AWS wynosił 14 200 PLN. Wcześniej, na własnym serwerze, płacili 1 800 PLN miesięcznie za hosting w colocation.

Nie twierdzę, że chmura jest zła. Twierdzę, że decyzja „on-premises czy chmura" to decyzja finansowa i strategiczna, a nie modowa. I że w wielu przypadkach odpowiedź jest inna, niż sugeruje marketing dostawców chmurowych.

Co dokładnie porównujemy

Zanim przejdziemy do liczb, ustalmy definicje:

On-premises - serwery fizyczne lub wynajmowane (colocation/dedicated), nad którymi masz pełną kontrolę. Ty decydujesz o systemie operacyjnym, konfiguracji, aktualizacjach.

Chmura publiczna (AWS, Azure, GCP) - zasoby wynajmowane na żądanie. Płacisz za użycie: godziny obliczeniowe, gigabajty transferu, operacje na storage.

Chmura prywatna / hybrid - własna infrastruktura z narzędziami chmuropodobnymi (Kubernetes, OpenStack) lub połączenie własnych serwerów z chmurą publiczną.

Prawdziwe porównanie kosztów

Marketing chmurowy pokazuje koszty w wariancie: „mały startup, 1 serwer, płacisz tylko za to, co używasz". Ale firma z 50+ pracownikami i systemem produkcyjnym to inna historia.

Scenariusz: system ERP/CRM dla firmy średniej wielkości

Wymagania:

• 2 serwery aplikacyjne (8 vCPU, 32 GB RAM każdy)
• 1 serwer bazodanowy (16 vCPU, 64 GB RAM, 1 TB SSD)
• 500 GB storage na pliki/dokumenty
• Backup dzienny, retencja 30 dni
• Transfer sieciowy ~2 TB/miesiąc

Wariant A: chmura (AWS)

I to bez Reserved Instances (wymaga zobowiązania na 1-3 lata). Z RI oszczędzasz ~30%, ale tracisz elastyczność, która była argumentem za chmurą.

Wariant B: on-premises (colocation)

Różnica: 55 440 PLN rocznie. W ciągu 3 lat to 166 320 PLN - wystarczy na zatrudnienie administratora na pół etatu.

A co z kosztami ukrytymi?

Zwolennicy chmury słusznie pytają: „a kto tym zarządza?" Policzmy uczciwie:

Nawet doliczając 15-20h miesięcznie pracy administratora (3 000-4 000 PLN), on-premises wychodzi taniej o ~20 000 PLN rocznie w tym scenariuszu.

Kiedy on-premises ma sens

1. Przewidywalne, stałe obciążenie

Twój system ERP działa 8-17, poniedziałek-piątek, z podobnym obciążeniem. Nie potrzebujesz „elastycznego skalowania" - potrzebujesz niezawodnego serwera, który działa.

Chmura jest droga właśnie dlatego, że płacisz premię za elastyczność, której nie wykorzystujesz.

2. Duże wolumeny danych

Im więcej danych, tym większa przepaść kosztowa:

Przy 50 TB danych chmura kosztuje 20× więcej niż własny storage. Jeśli Twoja firma generuje dużo danych (produkcja, monitoring IoT, archiwum dokumentów), rachunek rośnie wykładniczo.

3. Wymogi regulacyjne i compliance

Niektóre branże mają twarde wymagania:

• Dane medyczne - muszą być przechowywane na terenie Polski
• Dane finansowe - audytory wymagają fizycznego dostępu do infrastruktury
• Sektor publiczny - obowiązek przechowywania w kraju, certyfikowane data center
• RODO - łatwiej udowodnić zgodność, gdy wiesz dokładnie, gdzie są dane

Chmura oferuje regiony EU, ale:

• Dane mogą być replikowane między regionami bez Twojej wiedzy
• Dostawca (US) podlega CLOUD Act - amerykańskie organy mogą żądać dostępu
• Audit trail jest ograniczony do tego, co dostawca udostępni

4. Wydajność bazy danych

PostgreSQL na dedykowanym serwerze z NVMe działa 2-5× szybciej niż na odpowiedniku chmurowym (RDS, Cloud SQL):

• Brak współdzielenia - dysk, CPU i RAM są tylko Twoje
• Brak wirtualizacji storage - bezpośredni dostęp do NVMe
• Tuning - pełna kontrola nad postgresql.conf, kernel parameters, filesystem
• Latencja - aplikacja i baza w tej samej sieci, < 0.1 ms

-- Porównanie wydajności tego samego zapytania
-- RDS db.r6g.2xlarge:     47 ms
-- Dedicated NVMe:          11 ms
-- Różnica: 4.3× szybciej

EXPLAIN ANALYZE
SELECT o.*, c.name, array_agg(oi.product_name)
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN order_items oi ON oi.order_id = o.id
WHERE o.created_at > NOW() - INTERVAL '30 days'
GROUP BY o.id, c.name;

Dla systemu obsługującego 100 zapytań/sekundę, ta różnica oznacza lepsze doświadczenie użytkownika i mniejsze wymagania sprzętowe.

Kiedy chmura ma sens

Chmura nie jest zła - jest narzędziem, które pasuje do konkretnych scenariuszy:

1. Startup na wczesnym etapie

Nie wiesz, ile użytkowników będziesz mieć za 3 miesiące. Nie chcesz inwestować w infrastrukturę, zanim zwaliduejesz produkt. Chmura pozwala zacząć od 200 PLN/miesiąc i skalować w miarę wzrostu.

2. Zmienne obciążenie

Sklep e-commerce z 10× większym ruchem w Black Friday. Platforma eventowa z pikami podczas rejestracji. System raportowy, który potrzebuje 64 CPU raz w miesiącu na 2 godziny.

W tych przypadkach płacisz za elastyczność i naprawdę ją wykorzystujesz.

3. Globalna obecność

Aplikacja musi działać szybko w Europie, USA i Azji. Chmura daje CDN, edge computing i regiony na całym świecie. Zbudowanie tego samodzielnie byłoby absurdalnie drogie.

4. Managed services o dużej złożoności

Machine learning (SageMaker, Vertex AI), przetwarzanie wideo na dużą skalę, globalny system kolejkowy - to usługi, których odtworzenie on-premises wymagałoby dedykowanego zespołu.

Pułapka vendor lock-in

Największe ryzyko chmury, o którym mówi się za mało:

Co to oznacza w praktyce

Zaczynasz od EC2 + RDS (łatwo przenieść). Potem dodajesz:

• SQS zamiast standardowego systemu kolejkowego → Twój kod jest powiązany z API AWS
• Lambda do event processing → logika biznesowa w formacie AWS
• DynamoDB jako cache → format danych specyficzny dla AWS
• S3 presigned URLs w API → klienci zależni od AWS

Po 2 latach 60-80% kodu jest powiązane z konkretnym dostawcą. Migracja oznacza przepisanie, nie przeniesienie.

Koszty wyjścia

AWS, Azure i GCP celowo nie pobierają opłat za wgrywanie danych (ingress), ale pobierają za pobieranie (egress):

To model „Hotel California" - łatwo wejść, drogo wyjść. Im dłużej jesteś, tym więcej danych zgromadzisz i tym droższe będzie przeniesienie.

Nasz sposób na unikanie lock-in

Projektujemy systemy, które nie zależą od konkretnego dostawcy:

• PostgreSQL zamiast DynamoDB/CosmosDB - działa identycznie na dowolnej infrastrukturze
• Oban (na PostgreSQL) zamiast SQS/Cloud Tasks - kolejki w bazie danych, zero zależności
• Phoenix PubSub zamiast SNS/Pub/Sub - wbudowany w BEAM, zero zewnętrznych usług
• S3-compatible API (MinIO) zamiast natywnego S3 - ten sam interfejs, własna infrastruktura
• Standard SMTP zamiast SES - wymienialny dostawca email

Efekt: cały system można przenieść między chmurą a on-premises w dni, nie miesiące.

Podejście hybrydowe - najczęściej najlepsze

W praktyce najlepsze rozwiązanie to zwykle połączenie obu podejść:

graph TD
    subgraph hybrid["ARCHITEKTURA HYBRYDOWA"]
        subgraph onprem["On-premises (stałe obciążenie)"]
            APP["Aplikacja
Phoenix/LiveView"]
            DB["PostgreSQL
dane biznesowe, compliance"]
        end
        subgraph cloud["Chmura (zmienne obciążenie)"]
            CDN["CDN
statyczne zasoby"]
            BACKUP["Backup off-site
disaster recovery"]
            CICD["CI/CD
GitHub Actions"]
            MON["Monitoring
Grafana Cloud, alerty"]
        end
    end

Co trzymamy on-premises:

• Aplikacja produkcyjna (stałe obciążenie, niska latencja)
• Baza danych PostgreSQL (wydajność, kontrola, compliance)
• Dane wrażliwe (RODO, dane klientów)

Co trzymamy w chmurze:

• CDN dla zasobów statycznych (globalny zasięg)
• Backup off-site (disaster recovery w innej lokalizacji)
• CI/CD pipeline (GitHub Actions - płacisz za minuty)
• Monitoring i alerty (Grafana Cloud - SaaS, nie infrastruktura)
• Środowiska testowe (uruchamiane na żądanie, gaszone po testach)

Dlaczego Elixir zmienia kalkulację

Jedna rzecz, o której rzadko się mówi: wybór technologii wpływa na koszty infrastruktury.

Typowa aplikacja w Node.js/Java obsługuje 1 000-5 000 requestów/sekundę na jednym serwerze. Aplikacja w Elixir/Phoenix obsługuje 50 000-100 000 requestów/sekundę na tym samym sprzęcie.

Co to oznacza w praktyce:

Jeśli Twoja aplikacja potrzebuje 1 serwer zamiast 5, decyzja „on-premises vs chmura" staje się jeszcze bardziej przechylona w stronę on-premises - bo nawet jeden serwer wystarczy.

# Phoenix obsługuje 100k+ połączeń na jednym serwerze
# dzięki lekkości procesów BEAM

# Ile procesów obsługuje jeden serwer?
:erlang.system_info(:process_limit)
# => 1_048_576 (domyślny limit: ponad milion)

# Pamięć jednego procesu BEAM:
:erlang.process_info(self(), :memory)
# => {:memory, 2688}  (2.6 KB na start)

# Dla porównania:
# - Wątek Java:        ~512 KB - 1 MB
# - Goroutine (Go):    ~8 KB
# - Proces BEAM:       ~2.6 KB

Macierz decyzyjna

Odpowiedz na 8 pytań, żeby wybrać właściwą infrastrukturę:

Więcej ✓ w lewej kolumnie → rozważ on-premises lub hybrid. Więcej ✓ w prawej kolumnie → zacznij od chmury.

Porównanie na jednej stronie

Typowe błędy przy wyborze

Błąd 1: „Chmura jest tańsza, bo nie kupujesz serwerów"

Nie kupujesz serwerów. Zamiast tego płacisz czynsz - bez przerwy, rosnący, z opłatami za transfer. To jak wynajem vs. zakup mieszkania: wynajem ma niższy próg wejścia, ale po 5 latach przepłacisz.

Błąd 2: „On-premises = serwerownia w piwnicy"

Nie. On-premises w 2026 to serwer dedykowany w profesjonalnym data center (Hetzner, OVH, polski operator) z:

• Redundantnym zasilaniem
• Klimatyzacją
• Fizycznym bezpieczeństwem
• SLA 99.95%+

Za 1 200-2 000 PLN/miesiąc masz serwer, który w AWS kosztowałby 4 000-6 000 PLN.

Błąd 3: „W chmurze nie musisz się martwić o infrastrukturę"

Musisz. „Managed" nie znaczy „bezobsługowy". RDS nadal wymaga:

• Planowania okien maintenance
• Monitorowania kosztów (alerty budżetowe!)
• Zarządzania security groups
• Aktualizacji wersji
• Optymalizacji kosztów (Reserved Instances, right-sizing)

Firma z rachunkiem AWS > 5 000 PLN/miesiąc powinna mieć dedykowaną osobę do zarządzania kosztami chmury (FinOps). To kolejny koszt ukryty.

Błąd 4: „Migracja do chmury to transformacja cyfrowa"

Przeniesienie starego systemu do EC2 nie jest transformacją - to ten sam problem w droższym opakowaniu. Prawdziwa transformacja to nowy system, nowa architektura, nowe procesy. Infrastruktura jest wtórna.

Jak podejmujemy tę decyzję z klientami

Nasz proces:

1. Audyt wymagań - obciążenie, dane, compliance, budżet, zespół IT
2. Kalkulacja TCO na 3 lata - oba warianty, uczciwie, z kosztami ukrytymi
3. Rekomendacja - najczęściej hybrid: aplikacja i baza on-premises, reszta w chmurze
4. Proof of concept - stawiamy środowisko w obu wariantach, mierzymy wydajność
5. Decyzja oparta na danych - nie na marketingu, nie na modzie, na liczbach

I najważniejsze: projektujemy system tak, żeby decyzję można było zmienić. PostgreSQL, Elixir, standardowe protokoły - zero vendor lock-in. Jeśli za 2 lata okaże się, że chmura jest lepsza (lub gorsza), migracja zajmie dni, nie miesiące.

Zastanawiasz się, która infrastruktura będzie optymalna dla Twojego systemu? Porozmawiajmy - przygotujemy kalkulację TCO dopasowaną do Twojej firmy.