Kiedy zaczęliśmy budować projekt, instynktownie postawiliśmy na pełną chmurę: Google Kubernetes Engine, usługi zarządzane i architekturę gotową na przyszłą skalę. Na papierze wszystko miało sens — Kubernetes, wysoka dostępność, automatyzacja. Problem w tym, że aplikacja była wtedy po prostu MVP: miała niewielu użytkowników, mały zespół i wymagała szybkich iteracji.
Hostowaliśmy frontend, backend, bazy danych i środowiska testowe. Nic więcej. Mimo to płaciliśmy za infrastrukturę tak, jakbyśmy obsługiwali ruch dojrzałego produktu. Z czasem stało się jasne, że koszt i złożoność zupełnie nie odpowiadają rzeczywistym potrzebom projektu.
Zamiast „optymalizować chmurę”, zrobiliśmy krok wstecz. Przenieśliśmy infrastrukturę na VPS. Kubernetes pozostał. Porządek we wdrożeniach również, dzięki GitOps i Argo CD. Zniknęła natomiast cała warstwa usług zarządzanych, których faktycznie nie potrzebowaliśmy. Na jednym, zrozumiałym środowisku uruchomiliśmy frontend, backend, bazy danych i środowiska testowe.
Rezultat był jednoznaczny: koszty infrastruktury spadły około trzydziestokrotnie.
Poza argumentami biznesowymi i kosztowymi jest w tym też coś po prostu przyjemnego. Konfiguracja własnego VPS-a, uruchamianie na nim Kubernetesa oraz hostowanie frontendu, backendu czy baz danych dają realne poczucie kontroli nad systemem. Od czasu do czasu warto wrócić do tych podstaw, choćby po to, aby pamiętać, co naprawdę dzieje się pod maską. :)