Czego nauczyłem się o Cloud Run podczas migracji z Kubernetes

Czemu DevOps kochają Kubernetesa? To proste, bo dzięki niemu mają co robić! A co jak nie jesteś wykwalifikowanym DevOpsem i musisz uruchomić MVP swojej aplikacji? Cloud Run jest dobrą opcją w Google Cloud. Kiedyś dołączyłem do zespołu, który miał workloads wdrożone na Kubernetesie, natomiast zespół nie miał DevOpsa, ani nikogo kto by znał się na tyle na K8S aby nim zarządzać i wprowadzać zmiany. Dodatkowo eksperymentowaliśmy z mikroserwisami i potrzebowaliśmy czegoś co pozwoli nam na szybkie wdrażanie nowych serwisów bez zaangażowania zespołu odpowiedzialnego za infrastrukturę. W tym artykule podzielę się historią, jak przeprowadziliśmy migrację z Kubernetesa do Cloud Run, jakie wyzwania napotkaliśmy i co najważniejsze - czego się nauczyliśmy. Poza tym dowiesz się tutaj dużo o samym Cloud Run - jak działa i jakie ma zastosowania


Kubernetes: skuteczny motywator do sprawdzenia czym jest Cloud Run

Backend Services

HTTPS

JSON/HTTPS

JSON/HTTPS

JSON/HTTPS

User

Web Application

Vue.js

API Gateway

Node.js

Microservice 1

Node.js

Microservice 2

Node.js

Dołączyłem kiedyś do zespołu, który pracował nad aplikacją w architekturze rozproszonej. Była tam aplikacja frontendowa, backendowa(z czasem mikroserwisy) i API Gateway. Appki były wdrożone na Kubernetesie i działały sprawnie. Pomimo tego był z tym Kubernetesem jeden kłopot. W sumie nie było to problem samego narzędzia, tylko chodziło o to, że w zespole byli głównie frontendowcy z zamiłowaniem do backendu, a nie było nikogo, kto znałby się na infrastrukturze. Brakowało DevOpsa.

De facto, było to zorganizowane tak, że zespół rozwijający aplikację, miał rozwijać aplikację, a zespół od infrastruktury miał zarządzać infrastrukturą. W praktyce wyglądało to tak, że gdy zespół aplikacyjny potrzebował pomajstrować coś przy Kubernetesie to musiał czekać wiele dni lub nawet tygodni.

Zastanawiałem się, dlaczego ten zespół wdrożył ten software na Kubernetesie skoro nie było tam nikogo, kto znałby zaawansowane koncepty tego narzędzia. Odpowiedzi nie uzyskałem, natomiast był to dla mnie ciekawy przykład tego jak wybór odpowiednich narzędzi do pracy jest ważny.

Na szczęście pojawiła się opcja eksperymentowania z Google Cloud Run tak, aby zespół aplikacyjny mógł się uniezależnić od ludzi od infry. Postanowiliśmy, że wdrożymy jeden serwis na Cloud Run zamiast na Kubernetesie.

Zrozumienie Cloud Run

Google Cloud Run to w pełni zarządzana platforma serverless, która oferuje takiefunkcje:

  • Umożliwia łatwe uruchamianie bezstanowych kontenerów sterowanych żądaniami.
  • Zgodność z szeroką gamą języków programowania i integracja z innymi serwisami Google Cloud
  • Możliwość automatycznego skalowania w celu obsługi zmiennego obciążenia ruchem
  • Model cenowy pay-per-use dla efektywnego kosztowo wykorzystania zasobów

Czym jest Cloud Run?

Cloud Run eliminuje złożoność uruchamiania bezstanowych kontenerów HTTP, zapewniając w pełni zarządzane środowisko serverless z automatycznym skalowaniem i cennikiem płatności za użycie. Kompatybilny z wieloma językami programowania, Cloud Run pozwala skupić się na tworzeniu aplikacji bez kłopotów związanych z zarządzaniem infrastrukturą.

Łatwo wdrażaj konteneryzowane aplikacje i obserwuj, jak Cloud Run zajmuje się resztą, od skalowania po sieć.

Gdy pilotażowo wdrażałem pierwszy mikroserwis na Cloud Run to mając gotowy obraz Docker za pomocą kilku lini terraforma byłem w stanie wystawić ten serwis i eksperymentować. Trochę więcej zabawy było gdy wdrażałem inny serwis, który wymagał połączenia z Cloud SQL, natomiast dałem radę co jest dobrą wiadomością. Nie jestem przecież DevOpsem. Nie zrobiłbym tego w tak szybkim czasie w Kubernetes.


Google Cloud Run

Uruchom kontenery bezstanowe

Szerokie wsparcie językowe

Autoskalowanie

Pay-Per-Use

Wdrażaj kontenery bez martwienia się o infrastrukturę bazową

Obsługuje wiele języków programowania, zapewniając kompatybilność

Automatycznie dostosowuje się do skoków ruchu

Optymalizuj koszty dzięki modelowi cenowemu

Uproszczone tworzenie aplikacji bez zarządzania infrastrukturą


Zbuduj obraz, a resztą zajmie się Cloud Run

Korzyści z korzystania z Cloud Run

Dzięki Cloud Run możesz korzystać z zalet elastycznej, skalowalnej i ekonomicznej platformy do wdrażania aplikacji kontenerowych.

Po twojej stronie jest utworzenie i zbudowanie obrazu, a Cloud Run zajmie się resztą. Obraz możesz budować na wiele różnych sposobó np. używając Cloud Builda. Gdy ja tworzyłem swój pierwszy workload Cloud Run to stworzyłem w GCP własne Docker repository i w GitHub Actions skonfigurowałem pipeline, który budował mi obraz. Ni jest to konieczne, ale moja specyfika projektu tego wymagała. Najprostsza opcją jest wspomniany przeze mnie wcześniej Cloud Build, dzięki któremu można łatwo zbudować obraz np. po pushu do brancha main.

Kolejną zaletą Cloud Run jest jego kompatybilność z różnymi językami programowani, co pozwala wykorzystać dojrzały stos technologii do swoich projektów. Ja akurat wdrażałem aplikację w NodeJS, ale by default Cloud Run wspiera też inne jeżyki programowania jak Go, Java, Python, Ruby, .Net Core czy PHP

Model cenowy pay-per-use zapewnia, że płacisz tylko za wykorzystane zasoby, co czyni go atrakcyjnym wyborem dla firm każdej wielkości. Mój projekt nie miał dużego ruchu co sprowadzało się do tego, że nic nie płąciliśmy za Cloud Runa, ponieważ mieściliśmy się w darmowym przedziale zużycia. Miej jednak na uwadze to, że w internecie można znaleźć wiele historii o tym jak serverless kosztował o wiele za dużo. Dlatego, trzeba sobie dobrze obliczyć, czy taki model będzie OK dla Twojego zastosowania i skali.


Przypadki użycia dla Cloud Run

Cloud Run to doskonały wybór dla szerokiej gamy przypadków użycia takich jak:

  • Aplikacje internetowe
  • Interfejsy API
  • Mikrousługi
  • usługi sterowane zdarzeniami

Niezależnie od tego, czy pracujesz nad prostą aplikacją internetową, czy złożoną architekturą mikrousług, bezstanowe możliwości wdrażania kontenerów Cloud Run zapewniają skalowalność i wydajność aplikacji.


Wybieraj technologie dopasowane do problemu nie trendów

Moja wycieczka od Kubernetesa do Cloud Run

Byłem tech leaderem i na moje barki spadł proces wdrożenia pierwszego serwisu za pomocą Cloud Run. Oprócz tego dostałem wymaganie techniczne, że nowy serwis jak i stary monolit musiałby być ukryte za nowym API Gateway.

Wyzwania na drodze do wspaniałej przyszłości

Książkowo migracja jest prosta, natomiast w rzeczywistości zazwyczaj są dodatkowe okoliczności, które wpływają na to, że to co jest teoretycznie proste, w rzeczywistości staje się ogromnym wyzwaniem.

Architekci często wpadają w pułapkę stosowania znanych im narzędzi, zamiast dobierać najlepsze rozwiązanie do konkretnego problemu. Takie zjawisko nazywane jest “złotym młotkiem”. To takie faworyzowanie jednej technologii do rozwiązywania wszystkich problemów, nawet gdy istnieją lepsze alternatywy. Ja spotkałem się z czymś takim w kontekście managed serwisów. Migrowaliśmy wszystko i to w jednym czasie do managed serwisów.

Musieliśmy w tym samym czasie migrować backend z Kubernetesa na Cloud Run i Api Gateway z naszego serwisu napisanego w NodeJS na managed Google API Gateway. Ogólnie w tym projekcie nauczyłem się, że robienie wielu rzeczy na raz to droga do katastrofy.


Lekcje z tej podróży

Zacznij Małymi Krokami

Zbuduj Wiedzę

Eksperymentuj

Skaluj Rozwiązanie

1. Cloud Run nie jest tak prosty, jak się wydaje

Mimo że Cloud Run jest reklamowany jako proste rozwiązanie serverless, szybko przekonałem się, że bez fundamentalnej wiedzy o cloud i DevOps, wejście w ten temat może być trudne. Musieliśmy się sporo douczyć - od podstaw konteneryzacji, przez networking w chmurze, po zarządzanie sekretami. To nie było rocket science, ale też nie była to przysłowiowa bułka z masłem.

2. Ekonomia ma znaczenie

W naszym przypadku, przy małej skali, Cloud Run okazał się praktycznie darmowy. Mieściliśmy się w free tier i nie musieliśmy martwić się o koszty. Ale uwaga - przy większym ruchu trzeba dobrze przemyśleć ekonomię tego rozwiązania. Widziałem projekty, gdzie koszty serverless wystrzeliły w kosmos szybciej niż Falcon Heavy.

3. Integracja z ekosystemem Google Cloud

Cloud Run świetnie integruje się z innymi serwisami Google Cloud. Czy to Pub/Sub do obsługi eventów, Cloud SQL dla baz danych, czy Secret Manager do zarządzania wrażliwymi danymi - wszystko działa ze sobą jak w szwajcarskim zegarku.

4. Opór materii… ludzkiej

Zauważyłem ciekawą rzecz - DevOpsi i specjaliści od Kubernetesa patrzyli na Cloud Run jak na młodszego brata, który chce się bawić z dorosłymi. Było w tym sporo sceptycyzmu i pewnie część z tego wynikała z obawy o własną pozycję. W końcu po co zespołowi DevOps, jeśli programiści mogą sami zarządzać deploymentami?

5. Na wagę złota

Programiści, którzy są zainteresowani DevOpsem, Cloud Run i Terraformem to prawdziwe perełki. W moim zespole mieliśmy dwóch takich - byli bezcenni. Dzięki nim udało nam się sprawnie przeprowadzić migrację i zbudować wiedzę w zespole.


Kiedy Cloud Run jest dobrym wyborem?

Scenariusze

Cloud Run to dobry wybór

Zespół bez doświadczenia z K8s

Potrzebujesz szybkiego MVP

Prosta bezstanowa aplikacja

Optymalizacja kosztów

1. Gdy Twój zespół ma ograniczone kompetencje Kubernetes

Wiesz jak to jest - Kubernetes to potężne narzędzie, ale czy zawsze potrzebujecie czołgu, żeby pojechać po bułki? Jeśli w Twoim zespole są głównie programiści aplikacyjni, którzy znają się na frontendzie i backendzie, ale niekoniecznie na Kubernetes i infrastructure as code, to Cloud Run może być świetną alternatywą.

Przykład z mojego podwórka: pracowałem z zespołem świetnych frontendowców i backendowców, którzy potrafili napisać zajebistą aplikację, ale gdy przychodziło do zmieniania czegoś na Kubernetesa, to zaczynało się “czy ktoś może nam pomóc z konfiguracją ingressów?”. Z Cloud Run można większość takich rzeczy ogarnąć sami.

2. Gdy zależność od zespołu DevOps staje się wąskim gardłem

To jest taki scenariusz, który widziałem w wielu firmach - masz świetny zespół DevOps, ale jest ich trzech na całą firmę i obsługują 10 zespołów produktowych. Efekt? Czekasz tydzień na zmianę w konfiguracji Kubernetesa.

W takiej sytuacji Cloud Run może być wybawieniem. Twój zespół może sam deployować i zarządzać swoimi serwisami, bez czekania w kolejce do DevOpsów. To trochę jak przeprowadzka z hotelu (gdzie na wszystko musisz czekać) do własnego mieszkania (gdzie sam decydujesz co i kiedy).

3. Gdy chcesz szybko zwalidować pomysł przez MVP

Pamiętam jak kiedyś chciałem szybko przetestować pewien pomysł na aplikację. W Cloud Run wystartowałem z pierwszą wersją w jedno popołudnie.

Cloud Run jest idealny do szybkiego testowania pomysłów - nie musisz od razu projektować całej infrastruktury, martwić się o skalowalność czy wysoką dostępność. Wdróż aplikację i zobacz, czy w ogóle jest na nią zapotrzebowanie. Jak pomysł wypali, zawsze możesz później przenieść się na bardziej zaawansowane rozwiązanie.

4. Gdy Twoja aplikacja jest relatywnie prosta i bezstanowa

To jest bardzo ważne - Cloud Run najlepiej sprawdza się dla aplikacji bezstanowych, które mogą być łatwo skalowane horyzontalnie. Jeśli Twoja aplikacja to prosty backend API, serwis do przetwarzania obrazów czy jakaś aplikacja CRUD - Cloud Run będzie idealny.

Natomiast jeśli budujesz coś, co wymaga skomplikowanego stanu, długotrwałych połączeń (jak WebSocket) czy zaawansowanego routingu - może warto rozważyć inne opcje.

Bonus: Gdy liczysz każdy grosz

Cloud Run ma super model cenowy dla małych i średnich aplikacji - płacisz tylko za faktyczne wykorzystanie zasobów. W praktyce oznacza to, że jeśli Twoja aplikacja nie ma dużego ruchu, możesz płacić grosze albo w ogóle nic (free tier). To idealne dla startupów i małych zespołów, które muszą kontrolować koszty.

Pamiętaj tylko, że “serverless” nie zawsze znaczy “tańszy” - przy dużej skali tradycyjny hosting może wyjść ekonomiczniej. Ale do tego momentu Cloud Run może Ci zaoszczędzić sporo kasy na infrastrukturze.


Potencjalne pułapki

Pułapki Cloud Run

Złożone Setupy

Koszty

Monitoring

Multi-region & Load Balancing

Nieoczekiwane rachunki

Ograniczone możliwości debugowania

Nie wszystko jednak jest takie kolorowe jak w reklamach Google Cloud. Podczas mojej przygody z Cloud Run napotkałem kilka pułapek, o których warto wiedzieć zanim zdecydujesz się na migrację:

Złożone setupy to nie jest rocket science, ale…

Gdy przychodzi do bardziej zaawansowanych konfiguracji, Cloud Run potrafi pokazać swoje ostrzejsze zęby. Multi-region? Load balancing? To już nie jest “kliknij deploy i zapomnij”.

Musiałem skonfigurować aplikację w dwóch regionach z load balancerem. Co prawda dokumentacja Google jest całkiem niezła, ale i tak spędziłem dobre kilka dni na walce z konfiguracją tego wszystkiego i zrobieniu to w IaaC. Poza tym, każdy region to osobna instancja Cloud Run, więc zarządzanie deploymentami staje się bardziej złożone.

Koszty - diabeł tkwi w szczegółach

Z kosztami w Cloud Run jest trochę jak tankowaniem starego BMW z dużym silnikiem. Jest radość z jazdy, ale pod koniec miesiąca możesz się zdziwić. Szczególnie jeśli Twoja aplikacja zacznie dostawać więcej ruchu.

Internet jest pełen historii o złamanych sercach i portfelach na serverless. Dlatego zawsze zanim zaczniesz się bawić z jakimkolwiek serverless to:

  • Ustaw budżety i alerty
  • Monitoruj zużycie zasobów
  • Zrozum model kosztowy zanim przejdziesz na produkcję

Monitoring i debugowanie

To nie jest dokładnie pułapka, ale na pewno coś, co trzeba przemyśleć. Monitoring i debugowanie w środowisku serverless jest trochę inne niż w tradycyjnych aplikacjach. Nie możesz po prostu zalogować się na “serwer” i sprawdzić co tam się dzieje - musisz korzystać z narzędzi Google Cloud, co wymaga trochę innego podejścia i wiedzy.

Dobrą praktyką jest:

  • Konfiguracja poprawnego logowania od samego początku
  • Wykorzystanie Cloud Monitoring
  • Ustawienie odpowiednich alertów
  • Przygotowanie dashboardów monitorujących najważniejsze metryki

Dla mnie osobiście największym wyzwaniem była zmiana myślenia - z “serverowego” na “serverless”. Ale jak już się przestawiłem, monitoring w Cloud Run okazał się całkiem przyjazny.


Cloud Run to świetne narzędzie, ale pamiętaj nie ma idealnych rozwiązań w IT

Podsumowanie

Cloud Run to świetne narzędzie, ale jak wszystko w IT - nie jest silver bullet. Jest idealny dla zespołów, które chcą się uniezależnić od Kubernetesa i DevOpsów, szczególnie przy prostszych aplikacjach i MVP. Kubernetes nadal ma się świetnie i pewnie jeszcze długo będzie królem w świecie container orchestration, szczególnie w większych organizacjach.

Wiele zależy od strategii organizacji - czy stawiamy na szybkość rozwoju i prostotę zarządzania, czy na pełną kontrolę i zaawansowane możliwości orkiestracji. Nie ma złych wyborów, są tylko różne konteksty i potrzeby.


Jeśli chcesz być na bieżąco z moimi doświadczeniami w świecie cloud i architekturą aplikacji, zapisz się na mój newsletter. Dzielę się tam praktyczną wiedzą i przemyśleniami, które mogą pomóc Ci w podejmowaniu lepszych decyzji technologicznych.