Cloud Run
Uruchamiaj kontenery i agentów AI w sekundach, płać tylko za realne zużycie
Cloud Run to serverless runtime Google Cloud, w którym Twoje aplikacje, API i agenci AI uruchamiają się na żądanie, skalują do zera i są rozliczane co do sekundy. Klasyczne mikroserwisy w Pythonie, Node.js czy Javie, batch jobs uruchamiane w Cloud Scheduler, modele AI na GPU NVIDIA, a od Cloud Next '26 także środowisko uruchomieniowe dla agentów z Gemini Enterprise Agent Platform.
0 → instancja
w 5 sekund (GPU + drivery)
per-second
rozliczenie co do setnej
B+
parametrów modelu na GPU
Agent Platform
integracja w preview
Uruchamiasz API, model albo agenta, a połowa kosztu to puste serwery
Większość firm uruchamiających aplikacje w chmurze ma ten sam problem. Środowisko musi być gotowe na szczyt obciążenia, więc przez resztę czasu nadmiarowe zasoby stoją bezczynnie. Przy klasycznych maszynach wirtualnych płacisz za to 24 godziny na dobę. Przy klastrach Kubernetes płacisz za nody, których nie używasz. To akceptowalne, dopóki ktoś nie pokaże Ci, ile można zaoszczędzić.
Pewnie znasz przynajmniej jedną z tych sytuacji:
-
Aplikacja działa, ale 80% czasu nie obsługuje ruchu
API dla aplikacji wewnętrznej, integracja z partnerem, sklep B2B z ruchem w godzinach pracy. Zasoby stoją w nocy, weekendy, święta. Płacisz za nie tak samo. -
Model AI na własnym GPU kosztuje krocie
Wdrożyłeś model do klasyfikacji dokumentów, analizy zdjęć produktów albo czatu z klientami. GPU pracuje przez kilka minut na godzinę, a kosztuje pełne 24 godziny. Skala kosztu zaskakuje przy pierwszej fakturze. -
Agent AI w prototypie działa, ale jak go wdrożyć?
Pierwszy agent z Agent Platform działa lokalnie. Production-grade deployment wymaga osobnej decyzji architektonicznej: GKE, własne VM, Cloud Run. Każda opcja ma swoje konsekwencje.
Cloud Run jako runtime pierwszego wyboru dla nowoczesnych aplikacji
Cloud Run to fully managed serverless runtime, w którym Twój kontener uruchamia się na żądanie, skaluje się automatycznie od zera do tysięcy instancji i jest rozliczany za realne zużycie z dokładnością do sekundy. Wszystko, co potrafi działać w kontenerze Linuxowym, działa tu bez konfiguracji infrastruktury.
Prowadzimy wdrożenie Cloud Run w czterech etapach:
Architektura i wybór scenariusza
Sprawdzamy, czy Cloud Run jest właściwym wyborem dla Twojego obciążenia, czy lepszą drogą jest GKE (długie procesy stanowe, custom controllers) lub Compute Engine (bardzo specyficzne wymagania). Definiujemy scenariusz: serwis online, batch job, model AI na GPU, agent.
Konfiguracja i deployment
Konfigurujemy serwisy Cloud Run pod realne wymagania: limity CPU i pamięci, concurrency, autoscaling, polityki uruchamiania. Wdrażamy z poziomu kodu źródłowego (source-based deployment, bez ręcznego Dockerfile) lub z gotowych obrazów kontenerów. Konfigurujemy IAM, sieć, prywatne endpointy.
Utrzymanie i optymalizacja
Po wdrożeniu przejmujemy bieżącą opiekę w modelu Managed Services GCP: monitoring (Cloud Observability), optymalizacja kosztów (zmiana concurrency, scale-to-zero policies, GPU rightsizing), aktualizacje runtime, bezpieczeństwo.
Płacisz za serwery, których używasz przez kilka godzin w tygodniu?
Policzymy, ile odzyskasz, przenosząc obciążenie na Cloud Run. Konkretne liczby na Twoim środowisku, nie ogólne kalkulacje.
Co realnie robimy na Cloud Run
Cloud Run jest na tyle elastyczny, że obsługuje bardzo różne typy obciążeń. W naszej praktyce powtarza się sześć głównych scenariuszy.
01
API i mikroserwisy backend.
Klasyczny przypadek. Serwis Pythonowy, Node.js, Java, Go, .NET albo Ruby uruchamiany na żądanie HTTP, skalujący się automatycznie. Pasuje do API dla aplikacji webowych i mobilnych, integracji między systemami, webhooków od dostawców zewnętrznych.
02
Frontend i aplikacje webowe
Cloud Run serwuje również aplikacje webowe (Next.js, Nuxt, statyczne SPA z backendem). Razem z Firebase tworzy kompletny stack do nowoczesnych aplikacji web i mobile.
03
Modele AI na GPU
Cloud Run ma GA dla GPU NVIDIA L4 i obsługuje już NVIDIA RTX PRO 6000 Blackwell, na której można serwować modele do 70B+ parametrów. Scale-to-zero dla GPU eliminuje koszt bezczynnego sprzętu. Pasuje do inferencji własnych modeli, custom embeddings, klasyfikacji obrazów, OCR-a, scoringów.
04
Batch jobs i przetwarzanie wsadowe
Cloud Run Jobs uruchamiają zadania bez ograniczeń HTTP, do 24 godzin czasu wykonania. Klasyczne use case: nocne przetwarzanie danych, generowanie raportów, masowe importy, ETL, dystrybucja powiadomień.
05
Event-driven processing
Cloud Run reaguje na zdarzenia z Pub/Sub, Eventarc, Cloud Storage. Każde dodane zdjęcie do bucketu uruchamia agenta klasyfikującego. Każda wiadomość w kolejce wywołuje proces. Cron jobs przez Cloud Scheduler dla powtarzalnych zadań.
06
Runtime dla agentów AI
Najnowszy scenariusz, ogłoszony na Cloud Next '26. Agent Platform integruje się z Cloud Run, dzięki czemu agenci zbudowani w ADK przechodzą z eksperymentów do production-grade systemów bez przebudowy. Cloud Run staje się compute environment dla agentów. Plus fully managed remote MCP server pozwala na łatwe deploymenty MCP-zgodnych serwerów.
Płacisz wtedy, kiedy faktycznie używasz
To, co odróżnia Cloud Run od klasycznej infrastruktury, to model rozliczeniowy. Warto rozumieć go dobrze przed wdrożeniem, bo na nim opiera się największa wartość biznesowa.
Per-second billing
Rozliczasz vCPU-seconds i GB-seconds, z dokładnością do 100 milisekund. Płacisz tylko za czas, kiedy kontener obsługuje request. Idle time nie jest naliczany.
Scale-to-zero
Kiedy nie ma ruchu, liczba instancji spada do zera. Zero instancji = zero kosztu. To największa różnica wobec klasycznych maszyn wirtualnych i Kubernetesa.
Rapid startup
Kontener startuje w sekundach. Nawet GPU z driverami uruchamia się w mniej niż 5 sekund. Cold start istnieje, ale nie jest blokerem dla większości scenariuszy.
Free tier
2 miliony requestów i 360,000 GB-seconds miesięcznie bez opłat. Dla małych aplikacji i prototypów może oznaczać zerowy koszt.
Pricing
Cena vCPU-second to około 0,0000240 USD, GB-second około 0,0000025 USD. GPU rozliczane podobnie per-second. Dla większości scenariuszy oznacza to koszt znacząco niższy niż utrzymanie odpowiedniego klastra Kubernetes.
Pricing
Cena vCPU-second to około 0,0000240 USD, GB-second około 0,0000025 USD. GPU rozliczane podobnie per-second. Dla większości scenariuszy oznacza to koszt znacząco niższy niż utrzymanie odpowiedniego klastra Kubernetes.
Dla obciążeń stałych (API z ciągłym, dużym ruchem 24/7) klasyczny GKE może okazać się tańszy. Pomagamy zrobić rzetelną analizę porównawczą przed migracją.
Cloud Run, Google Kubernetes Engine czy Compute Engine? Pomagamy wybrać.
Trzy główne sposoby uruchamiania kodu na Google Cloud. Każdy ma swoje miejsce, my mamy kompetencje we wszystkich trzech.
Cloud Run
Najprostszy, serverless, zero ops. Pasuje do request-driven i event-driven obciążeń, mikroserwisów, frontendów, modeli AI z inferencją on-demand. Limit timeoutu (do 60 minut dla services, 24 godziny dla Jobs) oraz ograniczenia dla stanowych aplikacji wymagających persistent disk.
Google Kubernetes Engine (GKE)
Pełna platforma Kubernetes. Pasuje do długich procesów, custom controllerów, złożonych architektur mikroserwisów wymagających service mesh, aplikacji stanowych z persistent volumes. Wymaga zarządzania (chociaż GKE Autopilot redukuje ten narzut). Google wymyślił Kubernetes, więc GKE to natywny silnik.
Compute Engine
Klasyczne maszyny wirtualne. Pasuje do bardzo specyficznych scenariuszy: SAP, dedykowane bazy danych, aplikacje wymagające pełnej kontroli nad systemem operacyjnym. To podstawa migracji typu lift & shift z własnej serwerowni.
W praktyce nowoczesna architektura na GCP używa wszystkich trzech: Cloud Run dla nowych usług i mikroserwisów, GKE dla złożonych systemów wymagających Kubernetesa, Compute Engine dla obciążeń legacy i specyficznych. Projektujemy hybrydę, która ma sens kosztowo i operacyjnie.
Dlaczego warto wdrożyć Cloud Run z 7Technology
Google Cloud Sell & Service Partner
Wyższy poziom partnerstwa Google Cloud z potwierdzonymi kompetencjami wdrożeniowymi. Mamy dostęp do najnowszych funkcji (Cloud Run GPU dla Blackwell, integracja z Agent Platform w preview) i negocjujemy warunki dla Twojej organizacji.
Łączymy Cloud Run z resztą Twojego IT
Cloud Run jako serwis nie istnieje w izolacji. Łączymy go z BigQuery (dane), Pub/Sub (eventy), Cloud SQL i Firestore (bazy), Agent Platform (agenci), Firebase (frontend). Mamy te kompetencje w jednym zespole.
Wybieramy runtime do problemu, nie do sprzedaży
Cloud Run, GKE, Compute Engine. Każdy ma swoje miejsce. Jeśli Twoje obciążenie lepiej pasuje do Kubernetesa, tak powiemy. Nie sprzedajemy Cloud Run tam, gdzie się nie sprawdzi.
Doświadczenie w migracjach klasycznych aplikacji do serverless
Lift & shift to nie wszystko. Często modernizacja aplikacji do kontenera na Cloud Run wymaga refaktoryzacji: stateless design, externalizacja sesji, retry policy. Wiemy, jak to zrobić bez przepisywania od zera.
Zostajemy po wdrożeniu
Po starcie przejmujemy bieżące zarządzanie środowiskiem: monitoring, optymalizacja kosztów (rightsizing concurrency, instances), aktualizacje, bezpieczeństwo. Cloud Run jako serwis rozwija się szybko, więc utrzymanie wymaga bieżącej uwagi.
Co mówią o nas klienci
"Migracja produkcyjnego SAP była dla nas projektem o najwyższym ryzyku. 7Technology przeprowadziło nas przez nią bez ani jednego nieplanowanego przestoju."
Lucyna Michniewicz
CIO @ VOX
"Szukaliśmy partnera, który weźmie odpowiedzialność za całość, a nie odeśle nas do kolejnego podwykonawcy. Po kilku latach współpracy wiem, że trafiliśmy dobrze."
Edyta Sapijaszko
CIO @ Herbapol
"Automatyzacja procesów na WEBCON BPS zdjęła z naszych zespołów dziesiątki godzin pracy ręcznej miesięcznie. Wdrożenie poszło sprawnie i zgodnie z planem."
Magdalena Obidowska
Project Manager @ Oceanic
Projekty, za które wzięliśmy odpowiedzialność
Środowisko IT dealera Mercedes-Benz w Google Cloud
Migracja kluczowych systemów biznesowych do chmury, a następnie przejęcie i integracja środowiska IT nowego salonu w Sosnowcu - bez przerwy w pracy sprzedaży i serwisu.
System:
Środowisko IT - ok. 55 systemów (m.in. ERP, DMS, systemy kadrowo-płacowe i księgowe, SAP)
Technologia:
Google Cloud Platform, Terraform, SAP
Kluczowe osiągnięcia:
Jedno środowisko dla 5 lokalizacji; przejęcie salonu bez przestoju
Automatyzacja sortowania półtusz w chłodni
Decyzję o przydziale półtuszy do zamówienia zamiast operatora podejmuje algorytm, a rozjazdy na torach przestawiają się same - na podstawie sześciu parametrów każdej sztuki.
System:
System MES 7Technology + dedykowany moduł automatyzacji chłodni
Technologia:
RFID w hakach, sterowniki PLC, integracja z wagami i klasyfikacją mięsności
Kluczowe osiągnięcia:
Kilku pracowników na zmianę → 1 operator; reakcja na zmianę zamówienia w kilka sekund
Od papierowych kart do pełnej identyfikowalności z 7MES
Wdrożenie objęło cały zakład - od rampy przyjęć, przez rozbiór i produkcję, po kontrolę załadunku pod dokiem - z pełną genealogią każdej partii.
System:
7MES (autorski system klasy MES 7Technology)
Technologia:
Comarch ERP XL, wagi hakowe / najazdowe / stanowiskowe / laboratoryjne, skanery i terminale dotykowe
Kluczowe osiągnięcia:
Kompletacja krótsza o 4–5 godzin; genealogia partii od ręki zamiast w dni
Cztery lata cyfryzacji na WEBCON BPS, SAP i AI
Kilkanaście procesów w WEBCON zintegrowanych z SAP, a najnowszy etap zamienił ponad 40 000 dokumentów surowcowych w przeszukiwalną bazę wiedzy dla działu badań.
System:
WEBCON BPS + SAP (moduły FI i MM)
Technologia:
WEBCON BPS, SAP Gateway (OData, REST API), Google Cloud (Gemini, BigQuery, Looker Studio), OCR, KSeF, Autenti
Kluczowe osiągnięcia:
Wyszukiwanie surowca z 2–4 godzin do poniżej 30 sekund
Powiązane technologie i usługi
Technologie:
Usługi
Konsultacje:
Często zadawane pytania o Cloud Run
Cloud Run to fully managed serverless platforma do uruchamiania kontenerów Linux na Google Cloud. Twój kontener uruchamia się na żądanie (HTTP lub event), skaluje się automatycznie od zera do tysięcy instancji i jest rozliczany za realne zużycie. Wszystko, co działa w kontenerze Linuxowym (każdy język programowania, niemal każda aplikacja), działa na Cloud Run.
Cloud Run jest prostszy: zero ops, automatyczne skalowanie, payment per-second, scale-to-zero. GKE daje pełną platformę Kubernetes z większą kontrolą i obsługą złożonych scenariuszy (service mesh, custom controllers, aplikacje stanowe, długie procesy). Cloud Run pasuje do większości nowoczesnych aplikacji request-driven i event-driven. GKE pasuje do złożonych architektur Kubernetes-native. Często projektujemy architekturę, która używa obu.
Tak. Cloud Run ma GA dla NVIDIA L4 i wspiera już NVIDIA RTX PRO 6000 Blackwell, na której można serwować modele do 70B+ parametrów. GPU mają scale-to-zero, więc nie płacisz, kiedy nie ma ruchu. Cold start dla GPU z driverami trwa poniżej 5 sekund.
Cloud Next '26 zapowiedział integrację Cloud Run z Gemini Enterprise Agent Platform. Agenci zbudowani w ADK mogą być deployowane bezpośrednio na Cloud Run jako fully managed production-grade systemy. Dodatkowo Cloud Run wspiera fully managed remote MCP server, więc agenty zgodne z protokołem MCP mogą być uruchamiane na nim łatwo.
Tak. Cloud Run Jobs to osobny tryb dla zadań bez ograniczeń HTTP, do 24 godzin czasu wykonania. Pasuje do nocnych przetwarzań danych, generowania raportów, masowych operacji ETL. Możesz wyzwalać je z Cloud Scheduler (cron) lub Pub/Sub (event-driven).
Cloud Run nie pasuje do bardzo długich procesów (timeout services do 60 minut, Jobs do 24 godzin), aplikacji stanowych wymagających persistent disk, oraz workloadów wymagających kontenerów Windows. Dla tych przypadków lepiej używać GKE lub Compute Engine.
Rozliczanie per-second, zaokrąglane do 100 milisekund. vCPU-second około 0,0000240 USD, GB-second około 0,0000025 USD. Free tier: 2 miliony requestów i 360,000 GB-seconds miesięcznie. Dla większości aplikacji z ruchem nierównomiernym Cloud Run wychodzi znacznie taniej niż klasyczne maszyny lub klastry Kubernetes.
W modelu Managed Services GCP przejmujemy bieżącą opiekę: monitoring w Cloud Observability, optymalizacja kosztów (rightsizing concurrency, max instances, GPU policies), aktualizacje runtime, bezpieczeństwo, rozwój o nowe serwisy. Optymalizacja Cloud Run to realne pieniądze, bo platforma jest rozliczana per-use.
