POIT #165: Jak hostować aplikacje w GCP

Witam w sto sześćdziesiątym piątym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest hostowanie aplikacji w GCP.

Dziś moim gościem jest Piotr Gocłowskiw branży technologii od 10 lat, początkowo związany z automatyką przemysłową, a konkretnie sieciami, IoT i komunikacją szeregową. Cloud Architekt w GCP, posiadacz kilku certyfikatów GCP, na co dzień doradza i pomaga klientom rozwiązywać problemy związane z chmurą GCP. Fan Raspberry PI, Nintendo a prywatnie szczęśliwy mąż i ojciec 2 żywiołowych córek.

Sponsor odcinka

Sponsorem odcinka jest firma Farnell.

W tym odcinku o hostowaniu aplikacje w GCP rozmawiamy w następujących kontekstach:

  • czym jest GCP?
  • czy w dzisiejszych czasach hostowanie w chmurze stanowi już defaultowe podejście?
  • jakie są sposoby hostowania aplikacji w chmurze GCP?
  • czym się charakteryzuje Compute Engine?
  • jak GCP wspiera Kubernetes?
  • jak wygląda wsparcie serverless w przypadku GCP?
  • czym jest IAP (Identity-Aware Proxy)?
  • co sprawia, że klienci wybierają GCP do hostowania swoich aplikacji?

Farnell – podzespoły elektroniczne

Zapraszam do odwiedzenia strony sponsora odcinka, firmy Farnell, producenta podzespołów elektronicznych.

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 165. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o hostowaniu aplikacji Public Cloud Platform. Przypominam, że w poprzednim odcinku rozmawiałem o IT w branży FMCG. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/165 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję. 

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, pomagasz w realizacji tej misji. Dlatego już dziś wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Ja natomiast bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania!

 

Odpalamy!

 

Cześć, mój dzisiejszy gość w branży technologii jest już od 10 lat, początkowo związany z automatyką przemysłową, a konkretnie sieciami IoT i komunikacją szeregową, Cloud Architect w GCP, posiadacz kilku certyfikatów GCP. Na co dzień doradza i pomaga klientom w rozwiązywaniu problemów związanych właśnie z chmurą GCP. Fan Raspberry Pi Nintendo, a prywatnie szczęśliwy mąż i ojciec dwóch żywiołowych córek.

Moim i Waszym gościem jest Piotr Gocłowski.

Cześć, Piotr! Bardzo miło mi gościć Cię w podcaście.

 

Cześć, Krzysztof. Mnie również jest bardzo miło być tutaj. Dzięki wielkie za zaproszenie.

 

Przyjemność po mojej stronie. Dzisiaj będę z Tobą rozmawiał, jako że specjalizujesz się w chmurze GCP. Poruszymy temat hostowania aplikacji w GCP. Myślę, że nie tylko ja, ale i słuchacze wiele się dowiedzą.

Ale na początku chciałbym Cię zapytać, czy może coś pominąłem we wstępie w przedstawieniu Twojej osoby i tego, gdzie pracujesz.

 

W FOTC pracuję jako Cloud Architect, na co dzień zajmuję się wsparciem i konsultacjami dla naszych aktualnych i przyszłych klientów. FOTC jest partnerem Google Cloud i pełni rolę takiego przewodnika po chmurowej technologii. Dodatkowo oferujemy 500 dolarów na start, w formie vouchera, by móc swobodnie i bez stresu przetestować usługi GCP. Chmura może wydawać się na początku nieco skomplikowana na początku przygody, dlatego świadczymy też wsparcie techniczne. Więc zawsze można wysłać nam pytanie związane z GCP, korzystając z naszego dedykowanego adresu suportowego.

 

Fajnie, dzięki za to dopowiedzenie. Oczywiście wszystkie linki dodam później w notatce do odcinka, tak że jeśli ktoś jest zainteresowany, to śmiało można sobie odwiedzić stronę i dowiedzieć się więcej.

Fajnie, to skoro mamy już tę wprowadzającą część za sobą, to może przejdźmy do takiego standardowego pytania, które zawsze zadaję na początku, czyli: Czy słuchasz podcastów? Jeśli tak, to może masz jakieś swoje ulubione audycje, o których chciałbyś powiedzieć?

 

Tak, słucham. Co prawda nie bardzo regularnie, ale jeżeli mogę, mam czas i coś mnie bardzo zajmie, to słucham. Wiadomo, Porozmawiajmy o IT – zacznę od tego.

 

Dzięki.

 

Swojego czasu słuchałem Z pasją o mocnych stronach, Dominika Jurczyka; Na podsłuchu (Niebezpiecznik); Więcej niż oszczędzanie pieniędzy, Michała Szafrańskiego; nie tak dawno Podsiadło Kotarski Podcast (pod kątem, powiedzmy, humorystycznym); i DevTalk Aniserowicza, ale on już chyba nie jest niestety wydawany. Tak że taka krótka lista.

 

Nie taka krótka. Fajnie, dzięki za te rekomendacje. Dobrze, mówimy o GCP, ale oczywiście dla niektórych słuchaczy to może być niejasny skrót, więc na początku chciałbym Cię zapytać, czym właściwie jest GCP, ten obszar IT, w którym się specjalizujesz.

 

Generalnie jest to chmura obliczeniowa, czyli taki zestaw, grupa, zbiór usług przeznaczonych dla informatyków, programistów, ludzi z IT. Cechuje ją łatwość użycia, prosty interfejs użytkownika, TAR przez przeglądarkę. Jest też dostęp programistyczny poprzez właśnie RESTful API, mamy też biblioteki dla najpopularniejszych języków programowania. Możemy za pomocą kilku kliknięć lub wywołań API uruchamiać usługi, które normalnie wymagałyby sporej infrastruktury, sporo pracy i sporej liczby urządzeń w naszej serwerowni – jeśli byśmy taką mieli. Wynajmujemy u dostawcy chmurowego sprzęt. Sprzęt jest pod maską, a na zewnątrz mamy ładnie to opakowane w usługę.

 

Oczywiście dostawcą tej usługi jest w tym przypadku Google, bo mówimy o Google Cloud Platform. Dzisiaj oczywiście mówimy o GCP, ale wybieramy sobie taki fragment całego spektrum różnych tematów związanych z GCP pt. hostowanie aplikacji w chmurze. I dla osób, które wchodzą dopiero do branży IT może się wydawać, że standardowych podejściem jest hostowanie aplikacji w chmurze, ale nie tak dawno wcale nie było to takie oczywiste. Pamiętam jeszcze czasy, kiedy serwery pod biurkiem służyły właśnie do tego, później wchodziły kolokacje itd. Z tego punktu widzenia hostowanie aplikacji w chmurze wcale nie jest takie defaultowe, jakby się mogło wydawać.

I chciałbym Cię zapytać: czy z Twojego punktu widzenia w dzisiejszych czasach, jeśli mówimy o hostowaniu aplikacji, to w domyśle mówimy chmura, czy to już jest defaultowe, standardowe podejście wg Ciebie?

 

Wydaje mi się, że nie jest może defaultowe. W ogóle bardzo ciekawe pytanie. Na pewno widać, że rośnie zainteresowanie, ale to zależy też od klienta: czy mamy do czynienia z korporacją, czy mniejszą lub średnią firmą. Widać po prostu ten trend rosnący. Chmura jest idealna dla korporacji. Mają one trochę większe potrzeby niż standardowa mała/średnia firma i wymaga też odrobiny wiedzy do wystartowania. Poziom wymaganej wiedzy nie jest jakiś bardzo wysoki do takich podstawowych rzeczy, jak np. uruchomienie aplikacji na maszynie wirtualnej, ale wiadomo, coś tam trzeba poczytać. To dla, powiedzmy, takich prostych stron internetowych, typu mechanik czy strona zakładu fryzjerskiego, to wiadomo, że raczej te firmy hostingowe jeszcze są wybierane, ale nie jest to reguła. Wydaje mi się, że to powoli już przestaje dominować.

 

Chmura jest idealna dla korporacji. Mają one trochę większe potrzeby niż standardowa mała/średnia firma i wymaga też odrobiny wiedzy do wystartowania. Poziom wymaganej wiedzy nie jest jakiś bardzo wysoki do takich podstawowych rzeczy, jak np. uruchomienie aplikacji na maszynie wirtualnej, ale wiadomo, coś tam trzeba poczytać. 

 

Pewnie należy się spodziewać, że w przyszłości ten trend będzie się umacniał, będzie coraz więcej aplikacji, które na początku standardowo właśnie w chmurze są uruchamiane. I tutaj dostawcy tego typu usług, również Google daje szereg różnych możliwości hostowania aplikacji w chmurze, po to, żeby dobrać właśnie do danego rozwiązania, do wielkości, do skali, do planów rozwojowych aplikacji właściwą usługę.

Stąd moje pytanie do Ciebie, Piotrek, jak to wygląda właśnie w GCP. Jakie mamy sposoby hostowania aplikacji? Z czego możemy wybierać?

 

Mamy do wyboru kilka usług dosyć rozbudowanych. Część z nich jest trochę skomplikowana, część nieco prostsza i powiedzmy, można zacząć od Compute Engine. Jest to usługa typu IaaS, czyli Infrastructure as a Service. Uruchamiamy tam maszyny wirtualne, przez kilku innych dostawców nazywane też VPS-ami. I jest to taka usługa, która jest praktycznie u każdego dostawcy, zarówno chmurowego, jak i hostingowego. Wybieramy sobie typ maszyny, system operacyjny i potem po uruchomieniu takiej maszyny możemy tam łatwo wgrać naszą aplikację i po prostu ją już hostować. Pokazywać światu.

Drugą usługą może być np. Kubernetes Engine (wymowa zależy od osoby mówiącej), w skrócie K8s. I to jest Container as a Service. To jest taki, można powiedzieć, zarządzany przez Google Kubernetes i po prostu nie musimy go konfigurować na początku, tak samo, jakby to było on-premises, czyli u nas gdzieś tam w sieci. Na pewno jest znacznie szybszy do uruchomienia, do wystartowania z nim.

Mamy też App Engine. To jest taka usługa, a właściwie Platform as a Service. To jest taka typowa usługa, o której się mówi, gdy pada słowo serverless. W niej uruchamiamy nasz kod, napisany np. w takich popularnych językach, jak GS, Java, Rubi, C Sharp, Python. Generalnie jest to taka usługa, w której nie martwimy się o system operacyjny i o maszynę, która tam pod spodem napędza tę usługę. Tak że na głowie mamy tylko pisanie kodu. To na pewno dla programistów jest wygodniejsze.

Mamy jeszcze np. taką usługę, jak Cloud Run. Ona jest nieco podobna, z tym że tutaj nie dostarczamy gotowego kodu, a konkretnie już skonteneryzowaną aplikację. I musimy sobie ją wcześniej przygotować na naszej stacji roboczej, wgrać do repozytorium Google i potem możemy bardzo łatwo i szybko uruchomić ten kontener. Wiadomo, kontenery, podejście kontenerowe rozwiązują ten nasz słynny problem: U mnie działa. A u mnie nie. Możemy łatwo przenosić aplikację.

Kolejną taką usługą, która upraszcza mocno uruchamianie szczególnie bardzo prostych kodów, skryptów, to jest Cloud Function. To jest taka usługa, którą można opisać jako Function as a Service, czyli ona jeszcze bardziej szczegółowo umożliwia zdeployowanie tego kodu na poziomie pojedynczej funkcji. Tak samo tutaj mamy do dyspozycji najpopularniejsze języki, typu GS, Phyton, Java. Z tym że tutaj jest troszeczkę inaczej, bo ta usługa jest dla zdarzeń. Czyli mamy jakieś zdarzenie i wyzwalamy tę funkcję. Możemy je podzielić na dwa typy funkcji wyzwalanych za pomocą zapytania http albo za pomocą zdarzenia z innej usługi w ekosystemie Google. To może być np. zmiana w Cloud Storage, czyli takiej usłudze do przechowywania, może to być nowa wiadomość w Pub/Sub, albo z Firebase’a. Taki SDK do tworzenia aplikacji mobilnych. I moim zdaniem jest to najprostszy sposób, żeby pobawić się serwo losowymi usługami, w sensie w ogóle, żeby zobaczyć, jak to się robi, ponieważ wdrażanie takiego przykładowego kodu to jest dosłownie 3–5 minut. I możemy utrzymać publiczną funkcję wyzwalaną właśnie URL-em.

I ostatnia taka usługa, która nie wiem, czy powinna się tu znaleźć, ale wspomnę o niej, bo ona właściwie służy do przechowywania – właśnie Cloud Storage. To jest taka usługa podobna do S3 AWS-a. Taki storage obiektowy, gdzie możemy przechowywać duże ilości danych. Bardzo duże. Właściwie nigdzie nie ma opisanego limitu. Jest limit dla pojedynczego pliku, który wynosi 5 TB. I ta usługa jest dosyć tania. I dlaczego tutaj jest? Ponieważ można tam hostować strony statyczne, jeśli ktoś potrzebuje prostej strony, wizytówki, która jakoś bardzo się nie zmienia. Wtedy można użyć tego Cloud Storage. Polega to na tym, że umieszczamy tam pliki naszej strony, HTML-e i skrypty JS-owe i to działa praktycznie od razu. 

I dodałbym jeszcze ostatnią rzecz, już nawet nie usługę, ale rozróżnienie, czym się różnią te usługi w kontekście: odpowiedzialność użytkownika vs odpowiedzialność Google. W tych usługach typu Compute Engine Google odpowiada za maszynę pod spodem, ale użytkownik już wtedy zajmuje się od systemu operacyjnego w górę, czyli musi po prostu utrzymywać ten system i jeśli coś zrobi nie tak, to Google nie pomoże w tym. Bo to będzie wina tego usera. A w przypadku usługi typu serverless w App Engine jedyne za co odpowiadamy to kod. I wszystko, co poniżej, już nas nie interesuje.

 

Jasne, czyli po prostu dysponując rozwiązaniami typu Compute Engine, my odpowiadamy za to, żeby oprogramowanie działało poprawnie, mamy wówczas pewnie większą możliwość konfiguracji, dostosowania tego typu rozwiązania, ale musimy być świadomi tego, że to na nas będzie spoczywała odpowiedzialność za ewentualne upgrade’y, patchowanie i wszelkie tego typu rzeczy.

Rozpocząłeś przedstawianie tych różnych sposobów hostowania aplikacji od tego, że takie usługi typu Compute Engine to jest de facto core’owa rzecz dostępna u każdego providera. Myślę, że można śmiało powiedzieć, że takie maszyny wirtualne to najstarszy sposób. Co prawda nie dysponuję żadnymi konkretnymi statystykami, ale z tego, co obserwuję, myślę, że to jest jeszcze na tyle popularny sposób, że warto na pewno powiedzieć więcej na temat tego, czym się charakteryzuje Compute Engine, jak działa, w jaki sposób rozliczamy się za tego typu rozwiązaniami. Gdybyś mógł więcej na ten temat powiedzieć.

 

Jasne. To zaczniemy może od tego rozliczania, skoro poruszyłeś ten temat. Generalnie jeśli uruchamiamy maszynę wirtualną, to płacimy za typ maszyny. Te typy są predefiniowane. Właściwie są też customowe, ale uprośćmy: mamy predefiniowane typy maszyn z różną liczbą rdzeni CPU i różną ilością pamięci RAM. I to jest pierwszy składnik ceny. Wiadomo, im więcej rdzeni i więcej RAM-u, tym więcej płacimy za taką VMkę.

Kolejnym niezależnym składnikiem jest cena storage’u, w sensie tego dysku. I za ten dysk płacimy oddzielnie. Tam też mamy do wyboru, czy to będzie dysk SSD, czy dysk o zbliżonej wydajności do HDD.

I ostatnim, często zapominanym składnikiem, jest ruch wychodzący od naszej maszyny. Czyli jeśli użytkownicy dostają się do naszej usługi, do naszej aplikacji, to płacimy za ilość danych, która zostanie pobrana do nich. Ciekawostka: nie płacimy za ruch przychodzący do VMek.

A! Jeszcze jeden składnik to jest cena, to jest konkretnie, czy mamy publiczny adres IP na VMce, czy nie. I może być też publiczny adres IP stały lub zmienny. Wiadomo, stały jest najlepszy, możemy podpiąć domenę, możemy to jakoś fajnie upublicznić, ale jest też droższe.

Największym składnikiem, wiadomo, jest zawsze ten typ maszyny, czyli CPU i RAM. Jeszcze dodam, czym się charakteryzuje Compute Engine. Generalnie mamy predefiniowane typy maszyn, mamy też maszyny typu SPOT, tzn. to jest taki checkbox, który możemy zaznaczyć, i wtedy taka maszyna SPOT jest dużo tańsza. Pracuje 91% taniej, ale ma jedną wadę, dosyć poważną. Raz na jakiś czas zostanie wyłączona.

To jest taki, można powiedzieć, zapas dla Google, dla innych usług. I jeśli Google to wywłaszczy, to wtedy taka maszyna pada. Można ją potem włączyć, jeśli będą dostępne, ale jest to kiepski wybór np. na web server. Możemy też włączyć szyfrowanie w maszynach wirtualnych i takie dodatkowe zabezpieczenia integralności dysków. Generalnie Google bardzo wysoko stoi, jeżeli chodzi o bezpieczeństwo. I ciężko mi porównać z innymi operatorami, ale jest dosyć wysoko. Nie słyszałem ostatnio, żeby były jakieś wycieki, czy żeby ktoś znalazł jakąś dużą podatność w tym Compute Engine.

Są jeszcze automatyczne rekomendacje do maszyn. Czyli jeśli np. sobie wyklikamy maszynę, która jest dosyć droga, to po jakimś czasie Google przeanalizuje pracę tej maszyny i powie nam, że np. powinieneś zmienić tę maszynę na mniejszą, bo po prostu nie wykorzystujesz już jej w pełni. 

Mamy też grupy instancji w Compute Engine. Polega to na tym, że możemy sobie stworzyć taką grupę instancji, uruchomić taniej naszą aplikację i wtedy wykorzystać skalowanie. I to dotyczy zarządzalnych grup instancji. Możemy w ten sposób po prostu skalować naszą aplikację dla większej lub mniejszej liczby użytkowników. Jeśli chodzi o backupy, to Compute Engine jest moim zdaniem bardzo wygodny, ponieważ istnieje niezależność dysku od maszyny. Czyli możemy np. tę maszynę włączyć, odpiąć od niej ten dysk, podłączyć do innej maszyny, możemy zrobić kopię, możemy zrobić snapshot, możemy zrobić harmonogram robienia backupów bez naszego nadzoru, i to jest bardzo wygodne. 

I jeszcze jedną istotną cechą Compute Engine są sieci chmurowe VPC. Google to bardzo fajnie rozwiązał. To są takie prywatne sieci per projekt, podobne do sieci LAN, one są globalne i w każdym regionie możemy sobie utworzyć podsieci tych sieci. Adresacja tam jest taka jak w sieci lokalnej, czyli zgodna z RFC 1918, i automatycznie już są dodawane ścieżki routingu pomiędzy tymi podsieciami. Więc jeżeli uruchomimy sobie w USA jakąś maszynę i, powiedzmy, w Warszawie, to możemy bardzo łatwo skomunikować je za pomocą tego VPC z użyciem prywatnych adresów IP.

I jeszcze dosyć unikalna rzecz, bardzo fajna, jest taka, że podsieci GCP są regionalne, czyli możemy łatwo tworzyć np. grupę instancji, która będzie się rozciągała na cały region, w różnych zonach. I jeśli jedna zona by nam padła (to się zdarza bardzo, bardzo rzadko), to jest dodatkowa zona czy dwie zony, które zawsze będą działać.

 

I jeszcze jedną istotną cechą Compute Engine są sieci chmurowe VPC. Google to bardzo fajnie rozwiązał. To są takie prywatne sieci per projekt, podobne do sieci LAN, one są globalne i w każdym regionie możemy sobie utworzyć podsieci tych sieci. Adresacja tam jest taka jak w sieci lokalnej, czyli zgodna z RFC 1918, i automatycznie już są dodawane ścieżki routingu pomiędzy tymi podsieciami. Więc jeżeli uruchomimy sobie w USA jakąś maszynę i, powiedzmy, w Warszawie, to możemy bardzo łatwo skomunikować je za pomocą tego VPC z użyciem prywatnych adresów IP. 

 

To, co na pewno można powiedzieć, to faktycznie mnogość tych różnych możliwości konfiguracji. Myślę, że to swobodnie można sobie dostosować do swoich potrzeb, chociażby sterując tymi zasobami, które byśmy chcieli zużywać. Myślę, że te rekomendacje to też jest fajna i bardzo fair rzecz.

Ale teraz takim jakby przebojem jest i wkracza na salony Kubernetes. O ile Cloud Engine ma swoje stałe miejsce, o tyle coraz częściej słyszy się o klastrach kubernetesowych właśnie. I chciałbym Cię zapytać, jak GCP wspiera tym technologię, jakie możliwości daje klientom chcącym skorzystać z tego typu usług.

 

Kubernetes to jest generalnie technologia, którą opracował Google i wypuścili ją w 2014 roku jako open source. Zbudowali ją, bazując na swoich doświadczeniach sprzed X lat, budując swoje wewnętrzne systemy, właśnie swój wewnętrzny system Borg, podobny do K8s-a. I usługa, której możemy użyć w Google w GCP to jest Google Kubernetes Engine. I różni się ona głównie tym, że jest zarządzana przez Google i nie musimy w ogóle wieloma aspektami sobie zaprzątać głowy, bądź douczać się.

I można dosyć szybko uruchomić jakąś aplikację. Wystarczy, że przygotujemy sobie kontener z aplikacją, i generalnie wszystko wyklikujemy. Konfigurujemy klaster i możemy taką aplikację skonteneryzowaną dosyć szybko uruchomić. W GKE mamy dwa tryby pracy. Autopilot i standard. Standard to jest taki GKE, który istnieje w Google już jakiś czas i tam mamy sporą kontrolę nad klastrem, sporą kontrolę nad tym, na czym stoi ten klaster. Możemy też dosyć sporo zrobić, jeżeli chodzi o ruch sieciowy, kierowanie tego ruchu sieciowego, tego klastra. I tam generalnie płacimy głównie za maszyny pod spodem tworzące klaster. Ciekawostka: są to generalnie maszyny z Compute Engine, czyli jedna usługa wykorzystuje inną usługę. Dosyć łatwo się to rozlicza.

Tryb autopilot z kolei jest taki bardziej uproszczony. To jest taki kolejny krok w uproszczeniu tego K8s-a. On tam zarządza tym klastrem i tak naprawdę my już w ogóle nie musimy dotykać klastra, nie widzimy tych hostów, na których stoi klaster. I płacimy tak naprawdę już tak wirtualnie za godziny CPU, godziny RAM-u i godziny dysku. I w tym trybie autopilot jeszcze prościej te aplikacje się wdraża, ale niestety traci się kontrolę taką bardziej niskopoziomową. Tak że fajne na start, ale nie jestem pewny, czy w każdym przypadku może się to sprawdzić. Generalnie K8s to jest temat rzeka. Można by zrobić kilka odcinków na jego temat, ale Google moim zdaniem fajnie upraszcza jego zarządzanie i konfigurację.

 

No właśnie, zdejmuje jak gdyby ten ciężar przygotowania w ogóle całego tego klastra, czyli taką najcięższą rzecz. Później fajnie się tego używa, ale na początku trzeba faktycznie wykonać tę pracę inicjacyjną, jeśli ktoś może zdjąć ten balast z naszych barków, to zdecydowanie warto z tego skorzystać.

Chciałbym Cię zapytać teraz o kolejną, nazwijmy to, architekturę aplikacji, o której się sporo mówi, która coraz częściej jest wdrażana, czyli właśnie podejście serverlessowe. Tutaj, przedstawiając na początku, kiedy mówiłeś o tych różnych sposobach hostowania aplikacji dostępnych w ramach GCP, przynajmniej przy kilku wspominałeś, że dobrze nadają się do hostowania funkcji, czy czegoś, co dobrze nam się wpasowuje w to podejście serverlessowe.

Chciałbym Cię poprosić o porównanie tego sposobu do Compute Engine. I dwa takie tematy, które zawsze wypływają, kiedy się mówi o serwerlessowym podejściu, czyli finanse. I czy nadal problemem jest takie rozgrzewanie tych funkcji czy tych maszyn, czy to w dzisiejszych czasach jest już problem, o którym się właściwie nie mówi?

 

Oczywiście, pytanie bardzo na czasie. Jeśli chodzi o to rozgrzewanie, to jeśli mówimy o Cloud Runie czy o App Engine, to rzeczywiście, jeśli jesteśmy wyskalowani do zera, spoczynkowo, to wtedy pierwsze zapytanie może odrobinę dłużej trwać, ale to nie będzie jakiś taki szalenie długi czas, jak powiedzmy na komputerze lokalnym, gdy uruchamiamy kontener, tylko raczej Google ma to dosyć sprawnie zrobione, ruszanie z tego zimnego kontenera. Najważniejsze usługi serverlessowe to Cloud Run App Engine i Cloud Function.

Największa różnica jest taka, że płacimy tylko za wykorzystanie każdej z tych usług i możemy np. włączyć sobie skalowanie, czego nie można łatwo zrobić w Compute Engine. Możemy włączyć deskalowanie i wtedy, gdy będziemy mieli np. taki pik użytkowników, powiedzmy przed świętami, jakiś Black Friday, to wtedy ta nasza aplikacja się wyskaluje, ale przy standardowym ruchu ona będzie pochłaniała nieduże koszty. I to jest taka najważniejsza różnica. A kiedy ruch będzie minimalny, np. jesteśmy niedużą firmą, która dopiero się rozkręca lub start-upem, to ta nasza aplikacja na początku nie będzie miała dużego ruchu, więc będziemy za nią bardzo mało płacić. Na pewno mniej, niż gdybyśmy to postawili na maszynie wirtualnej. To jest taka główna różnica.

Generalnie Cloud Function nie nadaje się do tworzenia normalnych frontendowych aplikacji. Da się to zrobić, ale utworzona została bardziej jako taki klej do łączenia usług. Można za pomocą Cloud Function połączyć różne usługi albo coś tam wyzwolić w chmurze, nawet jak były bezpośrednio tym URL-em i coś tam się zacznie dziać. Podstawowa różnica to skalowanie. I w maszynach po prostu płacimy za czas pracy maszyny, a tutaj też jest czas pracy, ale można się wyskalować do zera przy podejściu serverless.

 

To jest fajne podejście, kiedy dajmy na to uploadujemy w naszej aplikacji obrazek, który potem wyzwala taki trigger i mamy taką Cloud Funkcję, która nam np. jakoś tam zmienia cokolwiek w tym obrazku, resize’uje itd., to się dzieje automatycznie, nie musimy już w kodzie tego umieszczać. To jest bardzo trywialny przykład, ale pokazuje, jakie możliwości za tym stoją.

Chciałbym Cię jeszcze dopytać, dlaczego właściwie wymieniłeś aż trzy usługi, jeżeli chodzi o serverless. Czy nie dałoby się tego zrobić jako jedną usługę? Mówiłeś, że Cloud Function to jest raczej coś, co ma być tym klejem. Czy to najbardziej odróżnia Cloud Function od App Engine Cloud Run?

 

Generalnie chodzi też o skalę tych aplikacji. Jeśli mamy App Engine, to jesteśmy w stanie dosyć łatwo uruchomić aplikacje frontendowe, tzn. musimy nieco dostosować ten kod, bo nie wszystko jest możliwe. Wrogiem skalowania jest trochę typowy Storage, bo ciężko jest go wyskalować i dlatego właśnie w App Engine domyślnie nasz system plików jest tymczasowy, czyli pomiędzy uruchomieniami, wywołaniami od nowa ten system plików jest czyszczony, jest tymczasowy. Da się to obejść na różne sposoby, np. używając Cloud Storage do takiego permanentnego przechowywania danych.

Dlaczego trzy? Wydaje mi się, że Google stara się wypełnić każdą niszę i Cloud Function jest idealny, gdy chcemy napisać skrypt, który będzie robił coś prostego. Będzie raczej krótki, to będzie zakres jednej, dwóch funkcji. I to się sprawdza. Zarządzamy wtedy małą bazą kodu. App Engine – możemy zrobić front do czegoś, jakąś aplikację frontendową. A Cloud Run – gdy mamy gotową aplikację albo gotowy kontener gdzieś tam pracujący z serwerem HTTP, to wtedy wdrożenie tego na Cloud Runie jest super szybkie i wygodne.

 

 

Wydaje mi się, że Google stara się wypełnić każdą niszę i Cloud Function jest idealny, gdy chcemy napisać skrypt, który będzie robił coś prostego. Będzie raczej krótki, to będzie zakres jednej, dwóch funkcji. I to się sprawdza. Zarządzamy wtedy małą bazą kodu. App Engine – możemy zrobić front do czegoś, jakąś aplikację frontendową. A Cloud Run – gdy mamy gotową aplikację albo gotowy kontener gdzieś tam pracujący z serwerem HTTP, to wtedy wdrożenie tego na Cloud Runie jest super szybkie i wygodne. 

 

Okej, to jeśli mamy już ten etap wyboru sposobu hostowania za sobą, udało nam się tę aplikację wdrożyć, to często pojawia się potrzeba kontrolowania dostępu do tak hostowanej aplikacji i wiem, że Google ma tu taką usługę o nazwie IAP (Identity-Aware Proxy). Gdybyś mógł nieco więcej powiedzieć, czym ona jest, w jaki sposób można ją użyć, do czego zastosować.

 

Jasne. Jestem fanem tej usługi. Jest bardzo wygodna. Służy do uwierzytelniania i autoryzacji użytkowników. Można tam łatwo dodać użytkowników do puli tych z dostępem. Wyobraźmy sobie, że mamy taką aplikację, która nie ma żadnej autoryzacji, ale chcielibyśmy jakoś łatwo, szybko i przyjemnie dodać możliwość uwierzytelniania i autoryzacji, ale nie chcemy za bardzo pisać kodu, to wtedy właśnie IAP przyjeżdża na białym koniu i robi całą robotę za nas. 

Wystarczy, że uruchomimy to dla naszych aplikacji, czy to w App Engine, czy w Cloud Runie, czy w GKE albo nawet w Compute Engine, tylko że tam akurat są wymagane grupy instancji przy Compute Engine, nawet na on-premisesie. Włączymy to, dodajemy użytkowników do puli użytkowników, którzy mogą korzystać z tego IAP-a, i wtedy automatycznie pojawia nam się pop-up przy wejściu na daną aplikację, na jej adres, i prosi nas o zalogowanie kontem Google. Logujemy się. Jeśli nasze konto zostało tam dodane w konfiguracji, to możemy tam się dostać. Aplikacja widzi też w nagłówkach, kto się tam loguje, i może to wykorzystać, np. wyświetlać nazwy użytkowników czy tę ikonkę taką. I to jest bardzo fajne, znacznie upraszcza to uwierzytelnianie. I jeśli użytkownik nie jest dodany, to po prostu zobaczy ekran, że niestety nie ma dostępu i żeby się skontaktować z administratorem.

 

I zdecydowanie lepiej skorzystać z tego typu usług dostarczonych przez sprawdzonych providerów, niż próbować tworzyć autoryzację czy uwierzytelnianie samemu, bo to na pewno będzie znacznie bardziej podatne na wszelkiego typu luki.

 

Tak, jeszcze tylko bym dodał, że wspiera ona HTTP, czyli standardowo, ale także PFP. Jeśli chcemy dostać się do naszej maszyny na przykład, która nie ma publicznego adresu IP ze względów bezpieczeństwa, to możemy np. utworzyć taki tunel SSH albo RTP i po prostu za pośrednictwem tego IAP-a bezpiecznie się dostać do takiej maszyny.

 

Bardzo fajna opcja. Wspominałeś wcześniej, że Google goni innych wiodących providerów, dzięki temu może być czasem bardziej konkurencyjny cenowo. Chciałbym Cię zapytać, jakie jeszcze inne przymioty, cechy stojące za GCP sprawiają, że Wasi klienci, firmy, z którymi współpracujesz, decydują się właśnie na hostowanie aplikacji w tej chmurze?

 

Bazując na swoich dotychczasowych doświadczeniach, mogę powiedzieć, że region w Polsce bardzo dużo zmienił, dla wielu klientów jest to bardzo istotny argument. Ponadto duża wydajność maszyn, np. jeśli wymieniliśmy stronę, która pracuje na jakimś VPS-ie albo współdzielonym hostingu, to generalnie czasami może ta wydajność nie być najwyższa. I jeśli przesiądziemy się na taką maszynę wirtualną w GCP, to taka strona może dostać niezłego kopa. Czyli przyspieszenie. 

Co jeszcze… Skalowalność. Czyli jeśli ktoś chce wdrożyć stronę czy aplikację, która będzie rosła razem z pulą użytkowników, to właśnie serverless jest tutaj odpowiedzią. Elastyczność, ponieważ możemy łatwo robić backupy danych, zarządzać tą kopią zapasową, pobierać ją itd. Duża przepustowość sieci Google jest też takim, niezbyt powszechnie znanym argumentem, ale Google ma bardzo dobrą sieć globalną, zbudowaną przez siebie, więc możemy tak skonfigurować sobie nawet dostęp do naszych VMek czy usług, że większość ruchu może przechodzić zamiast przez publiczny internet, to przez infrastrukturę Google, dzięki czemu te opóźnienia są znacznie mniejsze.

I jeszcze jeden taki argument, już taki według mnie, to prostota obsługi i dobry interfejs graficzny. Bo moim zdaniem Google robi dobrą robotę, jest to dość czytelne

 

Myślę, że to są istotne zalety zwłaszcza dla tych większych graczy, którzy np. mają potrzebę skalowania, którzy muszą zapewnić określony poziom działania tych aplikacji. Wtedy to jest na pewno znaczące, żeby opierać się pod względem infrastruktury na sprawdzonym dostawcy.

Ale wyobraźmy sobie właśnie tych mniejszych graczy, firmy, które mają mniej lub bardziej prostą stronę, osoby, które zajmują się tworzeninem tego typu mniejszych aplikacji czy stron. Zastanawiam się, czy wtedy GCP to jest dobry wybór pod względem tego progu wejścia. Czy trzeba ieć już jakieś rozeznanie w chmurze publicznej? Trzeba wiedzieć, jak ona działa, żeby poprawnie skonfigurować sobie takie środowisko pod nawet taką prostą stronę? Czy też może ten próg jest dużo niższy? Jestem bardzo ciekawy Twojej opinii na ten temat.

 

Moim zdaniem nie trzeba być specjalistą, aczkolwiek mogę mieć tutaj trochę skrzywione spojrzenie, ponieważ trochę przeczytałem tej dokumentacji. Ja zawsze rekomenduję, żeby się z nią zapoznać, nawet z tymi podstawowymi przykładami, bo to dużo daje. Najlepiej jest zacząć od quick startów. To są takie gotowe przykłady przygotowane w dokumentacji Google. Krok po kroku, jak wdrożyć jakiś kod, jak uruchomić aplikację, od początku do końca. 

Po przejściu czegoś takiego można dosyć dobrze zrozumieć daną usługę i warto też zawsze z przejściem do sekcji price’ingu zobaczyć, w jaki sposób naliczane są koszta za daną usługę, po to, żeby to sobie dokładnie oszacować, ile potencjalnie ta nasza aplikacja może kosztować. Po prostu pozwoli to uniknąć nieprzyjemnych konsekwencji, bo nie chcę straszyć, ale np. niektóre usługi, jeśli źle ustawimy skalowanie albo źle napiszemy jakąś funkcję czy pętlę, to mogą się w nieskończoność wywoływać i nabić rachunek. 

Tak że wiedza jest tutaj istotna. Bardzo polecam, jest taki kalkulator Google, na którym można wybrać usługę, wpisać jej parametry, i od razu dostajemy bezpośrednio koszty, jakie może generować miesięcznie. Bardzo wygodna narzędzie, pewnie podlinkujemy. I polecamy też skontaktować się z partnerem, czyli z nami, w razie problemów. Mamy po prostu dedykowane wsparcie dla Google.

 

Myślę sobie, że ten obszar chmury publicznej zmienia się bardzo szybko. Liczba usług, które się pojawiają, rośnie. Zmiany, które są wprowadzane również. Trzeba naprawdę za tym nadążać. Dlatego chciałbym się Ciebie zapytać, w którym kierunku wg Ciebie chmura GCP zmierza, jakich zmian, planowanych nowości na najbliższy czas możemy się spodziewać. Na co możemy liczyć w tym temacie hostowania aplikacji, jeśli chodzi i GCP w niedalekiej przyszłości?

 

To, co nasuwa mi się na początek, to takie bardziej ogólne rzeczy, czyli wydaje mi się, że jeszcze bardziej będzie upraszczana obsługa tych usług. Czyli będziemy też mieli coraz mniejszą liczbę zadań konfiguracyjnych, utrzymaniowych. Pewnie większy nacisk na Multicloud, Google mocno teraz na to stawia przy Anthosie. Czyli generalnie uruchamianie obciążeń w różnych chmurach, w ramach HA. Obstawiam też duży rozwój usług do analityki danych, takich jak Big Query. Jest ona już tak rozbudowana, że dobrze jest się w nią wgryźć niezależnie od reszty usług Google, żeby dobrze poznać. Myślę też, że do wizualizacji danych te usługi będą coraz lepsze. I jeszcze oczywiście AI i ML. I ogólnie wydaje mi się, że u każdego operatora chmury będziemy widzieć coraz więcej usług automatyzujących, upraszczających pracę ludzi. To jest trend od przemysłu, rzutujący na wszystkie dziedziny.

 

To jest naprawdę sporo kierunków, w których chmura publiczna, nie tylko GCP, ale ogólnie będzie się rozwijać. Myślę, że jeśli ktoś ma jakąś zajawkę, jeśli ktoś jest zainteresowany tego typu tematami, to lepiej do tego pociągu wskoczyć wcześniej niż później. 

 

Świetnie! Piotr Gocłowski był moim gościem. Rozmawialiśmy o tym, jak hostować aplikacje w GCP. Piotr, bardzo Ci dziękuję za mocno rzeczową rozmowę. Dzięki za ten poświęcony czas.

 

Ja również dziękuję, Krzysztof za zaproszenie. Bardzo miło było mi tu być. Mam nadzieję, że nie ostatni raz. Czas pokaże.

 

Cieszę się, że to było dla Ciebie miłe doświadczenie. Zanim się jeszcze rozłączymy, to zapytam Cię, gdzie Cię można znaleźć w internecie. Może jakieś miejsca, do których chciałbyś odesłać słuchaczy?

 

Na razie jeszcze nie zdążyłem tego bloga postawić, więc na razie zapraszam na LinkedIna. Standardowo: Piotr Gocłowski. Nie ma tam chyba zbyt wiele wyników, więc znalezienie mnie nie powinno być trudne.

 

Jasne. Właściwy link oczywiście będzie w notatce do odcinka. Piotr, jeszcze raz bardzo Ci dziękuję. Udanego dnia. Do usłyszenia!

 

Ja również życzę udanego dnia, wszystkiego dobrego!

Cześć!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków.

A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz, lub w social mediach. Zawsze możesz też się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o hostowaniu aplikacji w GCP. Zapraszam do kolejnego odcinka już wkrótce. 

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
Tags:
,
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.