Co to jest Cloud Run i jak działa pod maską?

Wprowadzenie

W poprzednim wpisie mówiłem o tym, dlaczego warto zainteresować się połączeniem Kotlin + Cloud Run. Dziś czas przyjrzeć się bliżej samemu Cloud Run: czym właściwie jest, jak działa, i co dzieje się "pod spodem", gdy wdrażamy naszą aplikację.

Cloud Run to zarządzana platforma serverless, która pozwala na uruchamianie aplikacji kontenerowych na żądanie, bez potrzeby zarządzania serwerami lub infrastrukturą.

Czym jest Cloud Run?

Cloud Run to usługa od Google Cloud, która pozwala uruchamiać aplikacje HTTP opakowane w kontener Docker/OCI:

płacisz tylko za rzeczywiste zużycie CPU i pamięci (co do 0.1 s),
nie zarządzasz maszynami, klastrami, load balancerami,
możesz wystawiać endpointy publiczne lub chronione (np. JWT, IAM).

Pod względem użytkowania przypomina trochę Cloud Functions, ale daje większą kontrolę i elastyczność — zwłaszcza dla aplikacji zbudowanych na JVM.

Architektura pod spodem

Cloud Run opiera się na projekcie open source Knative, działającym na Kubernetesie, choć użytkownik nie musi znać ani jednego, ani drugiego.

Pod maską:

aplikacja trafia do środowiska Google-managed GKE,
infrastruktura dba o:
- autoskalowanie do zera i z powrotem,
- routing ruchu,
- TLS, logowanie, wersjonowanie (revisions).

Każde żądanie HTTP uruchamia odpowiednią wersję kontenera, która może być współdzielona (wielokrotne requesty) lub startowana od nowa (tzw. cold start).

Modele uruchomienia: request-driven vs always-on

Cloud Run w standardowym trybie działa jako platforma request-driven:

brak żądań = brak instancji = brak kosztów,
pojawia się żądanie = Cloud Run odpala nową instancję kontenera,
instancja może zostać "aktywna" przez chwilę (tzw. idle timeout).

Dla aplikacji, które potrzebują stałego działania (np. websocket, cron), można użyć trybu minimum instances, np.:

gcloud run services update my-service \
  --min-instances=1

Co mogę tam uruchomić?

Cloud Run przyjmuje dowolny kontener, który:

nasłuchuje na porcie wskazanym przez zmienną środowiskową $PORT,
potrafi przetwarzać żądania HTTP,
kończy się kodem wyjścia 0.

W praktyce uruchomisz tam:

aplikację ktor,
aplikację Spring Boot,
Express.js, Go, Rust, Python – cokolwiek potrafi przyjąć request HTTP.

Główne zalety Cloud Run

Auto-skalowanie do zera – nie masz ruchu, nie płacisz.
Brak lock-in – uruchamiasz standardowy kontener.
Wbudowane TLS, IAM, autoryzacja z JWT.
Preview zmian dzięki revisions i traffic splitting.
Integracja z Cloud Build, Artifact Registry, Monitoring, Logging.

Wady, o których warto wiedzieć

❄Cold start – przy pierwszym uruchomieniu instancji może być opóźnienie (0.5–2 s dla JVM).
Ograniczenia czasu wykonania – max 60 minut (dla requestu).
Brak trwałości – Cloud Run nie ma dysku – używaj GCS, Cloud SQL itp.

Co dalej?

W kolejnym wpisie:

zbudujemy minimalną aplikację w Kotlinie (ktor)
przygotujemy ją do wdrożenia.

Dowiesz się:

jak utworzyć projekt w GCP,
jak skonfigurować CLI,
jak przygotować build.gradle.kts.

Linki i dokumentacja

Inne artykuły z serii

Wprowadzenie

Dlaczego warto interesować się Cloud Run i językiem Kotlin?
Co to jest Cloud Run i jak działa pod maską?

Pierwsze wdrożenie