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
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.
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.
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
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?
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
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.
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.