Po kablu do centrum danych, czyli zwiedzanie chmury z Rafałem Banaszkiewiczem

Słuchasz FlyTalks, podcastu, w którym łączymy świat biznesu i technologii. Dzisiaj okazja, by przyjrzeć się trochę bliżej rozwiązaniom i infrastrukturze Google Cloud Platform. A mam nadzieję, że będzie to możliwe dzięki naszemu dzisiejszemu gościowi. Rafał Banaszkiewicz jest z nami, Customer Engineer w Google Cloud. Dzień dobry, cześć!

Cześć, Konrad.

Świetnie, że jesteś z nami. To taki gwarant, że pojawią się konkrety i praktyka, bo to twoja perspektywa na co dzień. Zanim dowiemy się w ogóle, jak zbudowany jest świat GCP, zahaczając o obecne rozwiązania, też przykład nowego regionu w Polsce, postaramy się odpowiedzieć na to ważne pytanie "jak to wszystko działa?". A może to pytanie słyszysz czasem ze strony swoich klientów? Z czym spotykasz się na co dzień w pracy w Google?

Moją główną rolą jest tak naprawdę techniczne wspieranie naszego biznesu. W momencie, kiedy na przykład przychodzi do nas klient i chciałby rozpocząć swoją podróż właśnie z chmurą publiczną taką jak Google Cloud, moją rolą jest to, żeby takiego klienta troszeczkę przeprowadzić za rękę przez pierwsze dni pracy na naszej platformie, ale też wspomóc nasze lokalne siły sprzedażowe. Bo często jest tak, że ludzie, którzy u nas odpowiadają za rozwój tego biznesu lokalnie w Polsce rozmawiają właśnie dosyć wysokopoziomowo na różnych szczeblach po stronie klienta i naszą rolą jest takie techniczne wsparcie sprzedaży, ale też i wsparcie już samych ze sobą technicznych, później, przy jakiś takich testach, demo, trialach i tak dalej.

Czy jakiś scenariusz się szczególnie powtarza? To znaczy czy pewne przypadki są powtarzalne? Mówię tutaj o potrzebach naszego polskiego rynku obecnie. Albo co obserwujesz na przestrzeni ostatnich pięciu, dziesięciu lat? Bo rozumiem, że w branży jesteś już się od dłuższej chwili.

Wiesz co, na pewno scenariusze są w pewnym sensie powtarzalne, chociażby z tego względu, że wiele osób tak naprawdę rozpoczyna tą przygodę z chmurą publiczną nawet od zera. Mówię tutaj szczególnie o dużych firmach, dużych korporacjach, czasami firmach państwowych, dla których rzeczywistością do tej pory było data center, w którym trzymali swoje maszyny, swoje serwery. I teraz w pewnym sensie jest to troszeczkę rewolucja, ponieważ zespoły, ci ludzie, którzy do tej pory byli właśnie adminami czy deweloperami, muszą zacząć troszeczkę się przekonwertować powoli na to, żeby myśleć o takich zasobach w podobny sposób, ale jednak po stronie chmury. A tutaj pewne koncepty są podobne, ale jednak mimo wszystko różnią się

Dobrze, zatem czy w ogóle możemy narysować te rozwiązania albo jakkolwiek porównać je do tych, które znamy, tych starych, serwerowych, zlokalizowanych w jakimś centrum firmy? Zakładam, że w ogóle ekosystem Google jest bardzo rozległy, mówiąc o technicznych rozwiązaniach i założeniach chmury publicznej, ale, Rafale, jak działa chmura Google GCP? To też sprowadza się do konkretnego hardware tysięcy kilometrów przewodów, światłowodów, sposobu chłodzenia? Bo generalnie z zewnątrz powiem ci, że to miejsce brzmi bardzo tajemniczo. Pytanie, czy możesz po prostu nas tam wpuścić?

Oczywiście można to przyrównać, natomiast wiele z tych konceptów, które działają w chmurze Google Cloud, tak naprawdę zostało zaprojektowanych zupełnie od zera przez nas i to jest tak naprawdę poparte troszeczkę naszymi doświadczeniami z przeszłości, ponieważ biorąc chociażby usługi takie jak Google Set czy Gmail, Google Photos, YouTube i tak dalej, wyobraź sobie, że mamy tak naprawdę już w tym momencie nawet chyba i ponad 2 miliardy użytkowników aktywnych tego ekosystemu tej platformy. Musimy w jakiś sposób zapewnić skalowalność. Czyli załóżmy, że jednego dnia w Polsce ktoś może sobie obejrzeć jakiś koncert online na YouTubie i wejdzie sobie na ten koncert 100 tysięcy użytkowników, ale następnego dnia będzie tych osób troszeczkę mniej, 10 tysięcy czy 20 tysięcy. Musimy tak naprawdę automatycznie podążyć z zasobami, które są gdzieś tam z tyłu schowane w tak zwanym backendzie, żeby wyskalowały się właśnie do tego ruchu. Więc to jest coś, co tak naprawdę ciężko jest osiągnąć kiedy, załóżmy, mamy jakąś aplikację biznesową we własnym data center i mamy przewidziany określony ruch, załóżmy sklep internetowy, i nagle może się okazać, że jednak jest pięć razy tyle użytkowników niż się spodziewaliśmy, bo gdzieś tam jakaś kompania dotarła szerzej albo na przykład mamy takie sytuacje, czy taką rzeczywistość, w jakiej dzisiaj się obracamy w związku właśnie z pandemią, że tych użytkowników i usług online przybyło drastycznie. Google od wielu lat tak naprawdę budował własną sieć. Można powiedzieć, że Google też stworzył taki backbone trochę, który można przyrównać do największych operatorów telekomunikacyjnych, którzy budują właśnie taki backbone od lat. Firmy typu Orange, T-mobile, Deutsche, Telekom, NTT i tak dalej. I my zbudowaliśmy taki sam backbone jednak, że tylko i wyłącznie na nasze potrzeby. Czyli na potrzeby w ogóle całej platformy jako system Google jak i na potrzeby Google Cloud.

Czyli, jak rozumiem, to po prostu sprowadza się do infrastruktury technicznej, do przewodów, które przekraczają granicę? Czy raczej korzystacie tutaj jest operatorów? Jak wygląda kwestia techniczna, dajmy na to, przesyłu danych między różnymi regionami Google? Albo użytkownik jest w innym miejscu na świecie?

To tak naprawdę jest dosyć skomplikowany temat, ponieważ każdy z operatorów, który zbudował sobie taki (backbone w tym też uwzględniając Google, chociaż my nie jesteśmy operatorem telekomunikacyjnym), funduje właśnie taki szkielet w oparciu o własną infrastrukturę, ale też o infrastrukturę, która jest budowana wspólnie za pomocą tak zwanych konsorcjów. Jest taka ciekawa strona, którą można sobie właśnie w wyszukiwarce Google znaleźć – sea cable map i na tej stronie są pokazane aktualnie wszystkie działające systemy podmorskie kablowe uruchomione przez różnych operatorów telekomunikacyjnych, przez różne konsorcja. Jest informacja o tym, kto w danym konsorcjum uczestniczy, jaki jest jego procentowy udział w takim systemie kablowym. Ale są też systemy kablowe, które w pełni należą do danego operatora i mówię tutaj o Google. Mamy kilka systemów podmorskich kablowych, na przykład ostatnio wybudowany, który łączy Amerykę Północną z Europą, albo chociażby kabel podmorski o nazwie Marii Curie-Skłodowskiej, który łączy zachodnie wybrzeże Stanów Zjednoczonych z Ameryką Południową. Kabel to jest jedno, ale cały taki system transmisyjny składa się z wielu elementów. Oczywiście, wraz z tym kablem światłowodowym biegnie sobie też linia zasilająca, ponieważ co kilkadziesiąt, kilkaset kilometrów na dnie morza potrzeba, żeby istniał tak zwany wzmacniacz tego sygnału lub też regenerator, ponieważ światło jako fala elektromagnetyczna ulega właśnie takim zjawiskom jak tłumienie, jak dyspersja. Czyli dyspersja powoduje, że ten sygnał po prostu się zniekształca, tłumienie powoduje, że moc tego sygnału spada, w związku z czym co jakiś określony odcinek takiego systemu podmorskiego potrzebny jest właśnie taki "wzmacniacz" tego sygnału. Ale też są potrzebne urządzenia, które ten sygnał determinują na obu końcach. I mówimy tutaj o systemach właśnie, które noszą roboczą nazwę DWDM. Polega to na tym, że światło o różnych "kolorach", ponieważ jest to zazwyczaj pasmo podczerwieni czyli niewidoczne dla naszego oka, ale są różne długości tych fal, każdy z tych kawałków tego pasma stanowi tak zwany oddzielny kanał transmisyjny, w związku z czym takiej pojedynczej parze światłowodowej (para, mówię o dwóch włóknach, ale tych włókien w takim systemie kablowym biegnie wiele), jest w stanie zmieścić gigabity, terabajty na sekundę informacji, które są przesyłane z jednego punktu na drugi. Poza systemem transmisyjnym takim jak DWDM potrzebne są też urządzenia warstwy wyższej. Czyli mówię tutaj o switchach, o routerach, które już powiedzmy pakiety IP czy też dane w warstwie wyższej czy dane aplikacyjne są w stanie pokierować gdzieś dalej, od jednego data center Google do drugiego data center Google, czy też wypuścić ten ruch tak naprawdę w kierunku internetu, biorąc pod uwagę też różne zagrożenia, które się wiążą z internetem, który jest siecią publiczną i potrzeba też w jakiś sposób uruchomić infrastrukturę, która obroni nas, na przykład, przed atakami DDoS, przed atakami w aplikacyjnej warstwie siódmej. Mamy różne usługi chmurowe, typu właśnie Cloud Armor, które są w stanie naszych klientów obronić przed takimi atakami. Także cały obraz rysuje się w dosyć skomplikowany sposób i nie są tylko i wyłącznie kabelki, do tego dochodzi hardware sieciowy, ale też i oprogramowanie, które na tych urządzeniach działa, bo powiedzmy sobie szczerze, routery, switche to są w pewnym sensie też komputery, ale wyspecjalizowane w tym, żeby na przykład kierować odpowiednio pakietami z jednego miejsca do drugiego.

Z ciekawości, Rafale, wiesz o jakich latencjach, opóźnieniach, mówimy w przypadku przesyłu za pomocą światłowodu po dnie oceanu pakietu danych, dajmy na to, z Europy do Stanów?

Generalnie określa się, że jest to wszystko związane z prędkością światła, ale wiadomo, że to światło nie biegnie w próżni, to światło biegnie tak naprawdę w tym rdzeniu światłowodowym, do tego są urządzenia różne, które też dają odpowiednie opóźnienia, ale średnio przyjmuje się, że w wypadku takiego "gołego" kabla światłowodowego to jest około trzech, czterech mikrosekund na kilometr. Dla przykładu można podać, że pomiędzy wschodnim wybrzeżem Stanów Zjednoczonych a Europą, załózmy Londynem, Wielką Brytanią, jest to około 80 milisekund. Na samym kontynencie na poziomie kraju takiego jak Polska, to te czasy są poniżej 10 milisekund, Europa to jest 20, 30, 40 milisekund, w zależności od tego, gdzie takie połączenie jest zaterminowane, jak długi jest taki odcinek. Ale tak jak powiedziałem, światłowody to jest jedna rzecz, do tego są też urządzenia, które wprowadzają jakieś tam opóźnienia, ponieważ te dane i pakiety muszą być przeprocesowane w jakiś sposób, więc może być tego troszeczkę minimalnie więcej, ale powiedzmy, że można przyjąć, że to jest 3 mikrosekundy na kilometr, całość jakiegoś większego odcinka trzeba przemnożyć po prostu.

Szalenie ciekawe. Żeby to jakoś lepiej zobrazować może komuś, kto nie operuje na milisekunach w życiu codziennym – przesłanie maila, taka dwustronna komunikacja, jest to pewnie w jakiś sposób skończone. Natomiast gdy mówimy o przeprowadzeniu operacji z innego punktu świata, rozumiem, że opóźnienie jest szalenie kluczowe. Znajdujesz jakieś inne zastosowanie i obszary, w których walczymy właśnie o jak najmniejsze opóźnienie, tak żeby czas reakcji klienta względem regionu czy też w ogóle serwera był jak najkrótszy?

Bardzo wrażliwe, jeśli chodzi o opóźnienia są, chociażby wszelakiego rodzaju narzędzia do telekonferencji, chociażby Meet czy inne narzędzie typu Skype, Teams czy Zoom. Latency jest bardzo istotne z tego względu, że jeśli ta informacja dotrze zbyt późno to nie będziemy w stanie się zrozumieć albo czasami będzie to powodowało jakąś tam degradację jakości tego głosu. Kolejnym takim aspektem, gdzie to opóźnienie jest bardzo ważne, jest chociażby gaming online. Czyli wszędzie tam, gdzie mamy na przykład gry online, gdzie łączymy się z serwerami reakcja pomiędzy wciśnięciem jakiegoś przycisku czy joysticka na padzie a reakcją wybranej postaci, którą w danej grze kierujemy, to też są milisekundy. Jest też cała masa innych rzeczy związanych, chociażby, z branżą finansową. Wszelakie w czasie rzeczywistym transakcje czy jakieś giełdy papierów wartościowych, tutaj latency i opóźnienie, jakość, te straty pakietów są bardzo istotne. Ja ostatnio też widziałem taką ciekawą symulację jak jakiś lekarz, bodajże z Wielkiej Brytanii, przeprowadzał taką symulację zabiegu chirurgicznego na odległość. Lekarz był zlokalizowany w Wielkiej Brytanii, natomiast cała "operacja" – była to operacja na jakimś owocu, to był zdaje się banan, plus jakieś takie ramienia robota, które, powiedzmy, prowadziły rozcinanie tej...

Skórka z banana, na tym ćwiczy się szwy, tak lekarze często praktykują.

Dokładnie. To była taka symulowana właśnie operacja, która odbywała się na odległość i tutaj była wykorzystana właśnie do tego taka transmisja dalekiego zasięgu, ale wiem, że na obu końcach, zarówno od strony lekarza jak i od strony "operacji", były jakieś urządzenia, które były podpięte do sieci 5G, która też znacząco redukuje opóźnienia wykonywanych operacji.

Rozumiem, że banan-pacjent przeżył.

Pacjent przeżył, tak, udało się go zszyć do jednego kawałka.

Gaming to jedno, branża finansowa to drugie, pewnie takich klientów da się przekonać tym, że mamy już nowy region Google w Warszawie. Czy wiesz coś na temat infrastruktury, która zbudowana jest tutaj, u nas, w naszym pięknym kraju? To znaczy, jak taki region wygląda od środka? Już trochę zarysowałeś temat zakres transferu, natomiast jak to fizycznie wygląda? Czy to są podziemia zasilane jednym wielkim przewodem o niesamowitej prądożerności? Czy to są serwery chłodzone wodą? Czy panuje tam półmrok? Jak wygląda od takiej streony wizualno-technicznej?

W ogóle jak wygląda koncept regionów, czyli w tym wypadku regionu warszawskiego, nasze założenie jest takie, że budując region zakładamy, że ten region będzie się składał z co najmniej trzech tak zwanych inevibility zone. Inevibility zone można traktować jako oddzielne fizyczne data center i każda z tych zone jest od siebie niezależna jeśli idzie o zasilanie, jeśli idzie o infrastrukturę sieciową, kablową, nawet ścieżki czy też drogi kablowe zasilania jak i infrastruktury sieciowej, telekomunikacyjnej są wyznaczane w taki sposób, żeby nie spotykały się ze sobą w jednym miejscu. Czyli załóżmy, że mamy taką sytuację, że przyjeżdża sobie koparka obok data center buduje się jakaś tam droga, powstaje nowe osiedle i trzeba doprowadzić infrastrukturę i taka koparka przecina powiedzmy jeden z tych kabli. To jest najczęstszy scenariusz właśnie awarii tego typu. Struktura musi działać w taki sposób, że awaria takiej linii pojedynczej nie spowoduje odcięcia od świata takiej zony, a nawet jeżeli taka zona przestanie z jakiegoś powodu działać, będzie jakaś awaria to mamy dwie dodatkowe, które dalej są w stanie przejąć te wszystkie work cloud, te aplikacje działające na tej zonie, która uległa awarii tak, żeby po prostu system był w dalszym ciągu funkcjonalny. Można powiedzieć, że Google buduje takie data center troszeczkę na własną modłę. Czyli, oczywiście, w środku znajduje się sprzęt, znajdują się szafy rakowe, do których ten sprzęt też w pełni customowy, który my projektujemy, jest budowany według naszego ścisłego zamówienia, tam w tych szafach ten sprzęt jest instalowany. Zarówno sprzęty typu komputery jak i urządzenia sieciowe, ale także i całe zasilanie, zasilanie awaryjne, jakieś generatory, podtrzymanie tego zasilania, klimatyzacja też jak najbardziej. W wielu regionach, na przykład w Finlandii, w innych miejscach świata, jest tak, że taka ciepła woda czy też nadmiar ciepła, który jest usuwany z takiego data center, służy do ogrzewania na przykład budynków obok albo jakichś tam budynków mieszkalnych. Czasami też wykorzystujemy na przykład wodę ze źródeł typu rzeka górska do chłodzenia określonych elementów. Natomiast są to dosyć skomplikowane i różne wymieszane ze sobą systemy jeśli idzie o utrzymanie właśnie tej temperatury chłodzenia, ale też i reakcji na jakieś takie różne zdarzenia typu pożary, bo w zasadzie ryzyko ich powstania jest dosyć duże, zdarzają się praktycznie wszędzie, więc musimy szybko na to reagować, musimy mieć do tego odpowiednią infrastrukturę, musi być to odpowiednio zabezpieczone i tak jak wspomniałem, georedundancja w postaci właśnie niezależnych przebiegów w tych dróg kablowych, zasilania i też redundancja z punktu widzenia urządzeń. Czyli zawsze zduplikowane czy też zwielokrotnione po prostu urządzenia typu routery, switche, wszystko to, co stoi w takim regionie jest, można powiedzieć, w takim modelu. Czyli my projektujemy te urządzenia, działa na nich tylko i wyłącznie nasze oprogramowanie, nie korzystamy z zewnętrznych rozwiązań.

Hipotetycznie, czy istnieje moment, w którym zasoby mogą nie wystarczyć? To znaczy, czy one są uzupełniane hardwareowo co jakiś czas? Jak to po prostu się odbywa? Czy jest moment, czy to może kiedyś potencjalnie nastać?

To jest, że jak taki region jest planowany, angażowany jest do tego odpowiedni zespół, który bierze pewne dane z rynku, ale też i pewne trendy wykorzystania tych zasobów z już istniejących regionów spoza danego obszaru geograficznego, na przykład spoza Polski, i na tej podstawie szacujemy tak naprawdę potencjale zużycie tych zasobów, potencjalną ilość na przykład procesorów, która ma być zainstalowana w takiej lokalizacji, ilości pamięci RAM, CPU, który będzie nam potrzebny i wiadomo, że jeśli ktoś tak naprawdę wybierze region warszawski do uruchomienia swojej aplikacji możemy się spodziewać tego, że będzie tak zwany wzrost organiczny tej aplikacji. Szczególnie gdy tych użytkowników przybywa to z biegiem czasu oczywiście rośnie i u nas są odpowiednie zespoły, które dbają o to żeby takich zasobów dokładać w tych miejscach w tym regionie tak, żeby tych zasobów nigdy nie zabrakło. Oczywiście, mogą zdarzyć się na przykład sytuacje takie, że ktoś rozpoczyna przygodę z chmurą Google Cloud i nagle stwierdzi "o kurczę, nie mogę odpalić więcej niż 32 procesory, a dlaczego?" a no dlatego, chociażby, że są takie mechanizmy jak usage quota, które w pewnym sensie zabezpieczają też klienta przed tym, żeby nie odpalił zbyt dużo. Zdarzają się ludzkie błędy, ktoś na przykład uruchomi jakiś wielki klaster Kubernetesa czy uruchomi jakiś przeogromny klaster hadoop spark i nagle stwierdzi "kurczę, zrobiłem błąd, potrzebuje znacznie mniej", albo na przykład recommendation engine po naszej stronie pokaże klientowi “słuchaj, zredukuj te zasoby do połowy tej wielkości, bo reszta tak naprawdę się nudzi i nic nie robi”. Więc te quoty są po to, żeby zabezpieczyć klienta i jego rachunek przed potencjalnym bankructwem. Natomiast, tak jak mówiłem, my ciągle i stale monitorujemy wykorzystanie tych zasobów i jest odpowiedni zespół, który dba o to, żeby tych zasobów dokładać z biegiem czasu. Czasami też pojawiają się na przykład nowe rodziny procesorów i po prostu my dokładamy w ramach tego, co się dzieje na rynku, w zależności od tego, jakie są zapotrzebowania klienta, dokładamy nowsze regeneracje tych procesorów do tych regionów, robimy upgade, maintenance i tak dalej. Są zespoły po prostu, które są za to odpowiedzialne z punku widzenia hardware i utrzymania

Czy możemy sprowadzić Google Cloud do takich trzech najczęstszych obszarów zastosowań? To znaczy obciążanie GCP różną analizą, szyfrowaniem oraz te wszystkie operacje na kontenerach. Czyli tutaj pojawia się magia wspomnianego przez ciebie Kubernetesa.

Tak, generalnie wiadomo, że najczęstszym i najbardziej potrzebnym zasobem są zasoby obliczeniowe, zasoby typu compute. Tutaj po naszej stronie ta usługa się nazywa Google Compute Engine, która jest takim fundamentem w zasadzie wszystkiego, co działa nawet GCP jeśli nie usługi zarządzane tylko właśnie Google Kubrnetes Engine czy Google Cloud Dataproc, mówię tutaj o zarządzanych klastrach hadoop, czy usługę typu Google Cloud Dataflow, czyli taka zarządzalna wersja narzędzia Apache Beam, i tak naprawdę te usługi można skonfigurować w taki sposób, że będą skalowały się automatycznie w zależności od jakichś określonych parametrów. Czyli na przykład, załóżmy, nagle pojawia się jakiś ruch z zewnątrz – ktoś uruchomił sobie jakiś e-commerce w Google Cloud i zazwyczaj ma średnio po 10, 20 tysięcy userów i nagle jest taki skok, pik do 200, 300 tysięcy użytkowników albo nawet miliona użytkowników i trzeba ich obsłużyć. Mamy mechanizmy, które są w stanie reagować na te parametry, czyli zwiększony ruch, zwiększone obciążenie procesora na takim klastrze i odpowiednio wyskalować te zasady dla klienta. Oczywiście, klient też jest w stanie tą quote, o której wcześniej wspomniałem, podnieść na zasadzie wystawienia ticketu w supporcie i nasz zespół zazwyczaj po prostu podnosi to dosyć szybko i sprawnie. I sam Kubernetes. Kubernetes jest takim narzędziem, który trochę jest oparty o wewnętrzny mechanizm konteneryzacji Google, który jest praktycznie budowany w naszej firmie od roku 2003. Google bardzo się nim wspierał, w open-source’owym community udostępniliśmy wiele rozszerzeń do jądra systemu operacyjnego Linux, które tak naprawdę znacząco przyspieszyły powstanie Kubernetesa, ale też mocno wspomogły takie projekty właśnie jak Docker, ale to też zaraz jakby zaowocowało tym, że Kubernetes u nas w chmurze jest dostępny jako usługa zarządzana, ponieważ uruchomienie takiego klastra kubernetesowego spod palca to nie jest trywialna operacja, szczególnie nawet upgradeowanie tego klastra. Często to się sprowadza do tego, że zasadzie w wycinamy wszystko w pień i stawiamy od nowa nowszą wersję Kubernetesa i z powrotem deploy’ujemy na nim te wszystkie work cloudy, które stały na starszej wersji. Więc kontenery w rzeczywistości Google tak naprawdę napędzają wszystko, nawet jeśli korzystacie z Gmaila na co dzień, korzystasz z YouTuba, z wyszukiwarki, to wszystko pod spodem gdzieś tam jest zamknięte w jakichś malutkich kubełkach w postaci kontenerów, mikroserwisów, które kontaktują się między sobą, ale które też wystawiają do zewnątrz na internety jakieś interfejsy publiczne, chociażby w postaci ładnie wyglądającego interfejsu użytkownika.

Masz gdzieś z tyłu głowy jakieś praktyczne zastosowania Kubernetesa przez inne firmy? Mam tutaj na myśli jakieś case studies, które ostatnio przerabiałeś, albo które były wyjątkowe i ciekawe na tle innych?

Wiesz co, z naszych usług korzysta wiele firm, firmy z branży turystycznej, firmy z branży bankowej, chociażby wirtualne banki, które są uruchomiane w chmurze, czy też takie silniki do wyszukiwania lotów, wyszukiwania wycieczek, narzędzia, nawet takie typowe, webowe interfejsy czy jakieś tam proste wizytówki stron, ale też i różne platformy e-commerce, które są za tym schowane. Zazwyczaj to jest tak, że gdy podróż takiego klienta do chmury się rozpoczyna to jest to jakiś tam w pewnym sensie monolit. Czyli jest ta aplikacja, która jest jakby jednym, takim większym kawałkiem. Zarządzanie tym monolitem w perspektywie czasu nie jest łatwe, dewelopowanie nowych obszarów, dokładnie jakichś nowych funkcjonalności też jest dosyć skomplikowaną operacją, natomiast podzielenie tej aplikacji na jakieś mikrokawałki, na tak zwane mikroserwisy, umożliwia różnym zespołom niezależnie pracującym nad danymi obszarami, nad danymi kawałkami, unowocześnianie tej aplikacji i tak naprawdę przez to, że kontenery mają taką strukturę warstwową, można w bardzo szybki sposób cofnąć się do poprzedniej wersji w wypadku, na przykład, jeśli zdarzy się jakiś błąd typu wypuszczamy nowy release w piątek o 17:00. Kubernetes z czymś takim sobie spokojnie radzi, bo jeśli mamy dobrze zaprojektowany pipeline CI/CD, jesteśmy w stanie tak naprawdę za pomocą tych wszystkich narzędzi, a szczególnie tych narzędzi zautomatyzowanych, bardzo szybko wrócić do sprawnej, poprzednio działającej wersji i przywrócić coś, co działało i popracować tak naprawdę nad wyszukaniem tego buga. Także, podsumowując, klienci są różni, od branży turystycznej, gamingowej, finansowej, nawet operatorzy telco. Sama technologia Kubernetesa wymaga troszeczkę zmiany sposobu pisania tej aplikacji, zmiany sposobu trochę myślenia i zmiany też sposobu współpracy różnych zespołów. Mówię tutaj o zespołach deweloperów jak i operations, stąd wziął się też ten modny buzzword – DevOps. Czyli to jest ścisła współpraca tych dwóch zasobów, żeby zbudować taką aplikację.

Kubernetes posiada, też jak wspomniałeś, własną formę load balancingu, czyli technologii rozpraszania, takiego równoważenia może bardziej, obciążenia między wieloma maszynami. Rozumiem, że to może przynieść oprócz tego, że konkretne oszczędności klientowi, może też przełożyć się na jakieś mniejsze koszty środowiskowe, bo ekologia może równać się z ekonomią, przynajmniej na tym poziomie.

Tak, oczywiście tak i nawet chociażby wspominając tutaj wersję zarządzalną takiego Kubernetesa w postaci usługi Google Kuberetes Engine możemy wykreować klaster, który będzie miał dziesiątki nodes, setki, a nawet tysiące, ale mamy mechanizmy, które są w stanie zeskalować w dół tak naprawdę, zmniejszyć ilość tych worker node w klastrze kubernetesowym do minimalnej wymaganej do obsłużenia danego ruchu. W związku z czym, po pierwsze, jest mniejsza utylizacja tej chmury, czyli klient płaci w zasadzie tylko i wyłącznie tyle, ile w danym momencie zużył tej mocy obliczeniowej, i jest mniejsza konsumpcja mocy tak naprawdę, zasilania, mniejszy wpływ na środowisko. Mamy też różnego rodzaju mechanizmy, które dodatkowo są w stanie drastycznie zmniejszyć obciążenie portfela klienta. Mówię tutaj, chociażby, o maszynach wirtualnych typu Preemptible albo Spot VMs, gdzie koszt takiej maszyny to jest około 80% mniej niż standardowej maszyny, która działa w trybie 24/7 i taka maszyna typu Preemptible jest w stanie kosztować właśnie te 80% mniej. Różnica polega na tym, że ten hyperscyler pod spodem, który pilnuje, żeby te work cloudy działały raz na dobę, raz na 24 godziny jest w stanie zaterminować taką instancję. Ale Kubernetes ma mechanizmy, które te instancje podniosą znowu do góry, zaciągną obrazy tych wszystkich kontenerów dockerowych i aplikacja z punktu widzenia klienta dalej będzie działać. Więc można zarówno być eco-friendly (przez “eco” rozumiem tutaj economy jak i ecology friendly), ale też być optymalnym, jeśli idzie o wykorzystanie po prostu tych zasobów. Czyli zużywamy tylko ile potrzebujemy, a nie uruchamiamy nie wiadomo ile tych zasobów. Chociażby, gdyby taki klaster uruchomić data center, to mając tysiąc maszyn, uruchomienie ich ponownie, czy złożenie tych maszyn to jest skomplikowana operacja, tutaj robi to w pewnym sensie jakiś automat, którego zachowanie możemy kontrolować.

Czy możemy to wszystko sprowadzić do takiego trywialnego porównania i do takiej trochę przesiadki do chmury; czy podróżowanie komunikacją zbiera wątek, jak trochę ma to symbolizować chmura, jest lepsze ogólnie dla środowiska i dla planety podobnie jak podróż wspólna autobusem zamiast rozproszonymi maszynami, samochodami. Utrzymanie infrastruktury choćby nawet globalnej, ale jednak mocno scentralizowanej, jest mniejszym kosztem środowiskowym niż, dajmy na to, tysiące, miliony pojedynczych serwerów chłodzonych przecież tak samo, a jednak mniej wydajnie.

Oczywiście, że tak, ponieważ te zasoby to nie jest tak, że ja, czy ty, czy ktokolwiek inny korzysta z tej chmury na dedykowanej fizycznie maszynie i ma tą swoją maszynę i nikt więcej z niej nie korzysta. Te zasoby są współdzielone. Więc tak naprawdę może się okazać, że na danym node, gdzie taki klaster jest uruchomiony, czy na fizycznej maszynie, czy dzięki wirtualizacji, jesteśmy w stanie współdzielić te zasoby, więc, w cudzysłowie, jedzie sobie buspasem taki autobus, gdzie jest wielu pasażerów w jednym fizycznym dużym pojeździe zamiast jednego kierowcy tak naprawdę i trzy miejsca z czterech są po prostu wolne tak naprawdę, a powietrze emituje ileś tam spalin i dwutlenku węgla, tlenków azotu, jakiś tam substancji, pyłów i tak dalej. Więc na pewno będzie to bardziej efektywne z punktu widzenia środowiskowego, ale też i z punktu widzenia finansów takiego klienta. Więc jest w stanie te zasoby skalować automatycznie w zależności od potrzeb.

Czy nowy region Google w Warszawie jakoś różni się na tle innych, czy ma jakieś nowe specjalne funkcjonalności, czy raczej jest jakąś tam kopią systemu czy infrastruktury z innych części świata czy też Europy?

Wiesz co, staramy się, żeby regiony wyglądały w zasadzie bardzo podobnie do siebie. Mogą być jakieś tam poszczególne różnice na zasadzie dostępności usług. Mówię tutaj, chociażby, o jakiejś określonej rodzinie procesorów, które oczywiście też są dodawane, ale są jakieś minimalne różnice pomiędzy tymi regionami. Oczywiście, wszystko w szczegółach można sobie wyszukać też na stronie z naszą dokumentacją. Może być też czasem tak, że modele jakichś kart graficznych GPU, które podpinamy do takiej maszyny, może być ich dostępność w jednym regionie większa, a w innym regionie na przykład takiego GPU nie ma, czy TPU (Tensor Processing Unit, customowy cheat Googla, który służy do budowania modeli maszyn learningowych). Natomiast zasoby typu właśnie compute, storage, podstawowe rzeczy właśnie wokół tego jakiś serverless (mówię tutaj o App Engine, Cloud Run czy Cloud Functions), właśnie Google Cloud Storage obiektowy albo dyski persistent drive, które podłączamy do maszyn wirtualnych. Cała infrastruktura sieciowa wokół tego, czyli mówię o load balancerach, wirtualnej sieci prywatnej, firewallach, to wszystko jest zazwyczaj wszędzie takie samo i różnią się te regiony jakimś tam detalem mniejszym.

Jak słyszę to wszystko to myślę, że nowy region powinien bardzo cieszyć wszystkich deweloperów.

Zdecydowanie tak, chociażby mając na uwadze to latency. W ramach Polski to jest, spokojnie można powiedzieć, poniżej 10 milisekund jeśli ktoś ma dobre connectivity do internetu. Google jest tak szeroko rozproszony, jeśli wziąć restrukturę sieciową, jesteśmy połączeni z różnymi operatorami telekomunikacyjnymi, peerujemy się w różnych punktach wymiany ruchu, tak zwanych exchange’ach internetowych. Więc staramy się być maksymalnie blisko użytkownika końcowego, maksymalnie blisko operatorów. Czyli zarówno blisko tak zwanych eyeballs’ów, używając języka telco, jak i contentu, czyli miejsca, gdzie ta treść jest. Czyli content w sensie aplikacje, multimedia, systemy, różne bazy danych i tak dalej.

Czego wam życzyć w 2022, jeśli chodzi o twój zespół, Rafale?

Czego nam życzyć?

Bo wzrosty już są, region już jest. Co jeszcze? Spokój?

Spokój w tej branży nie jest zalecany, jeśli będzie spokój to będziemy się raczej nudzić. Myślę, że tego, żebyśmy się jak najmniej nudzili i żeby nasza praca była ciekawa, żeby przybywało nam klientów. Organizujemy różne warsztaty z klientami, różne webinary, więc życzyłbym sobie, żeby uczestników tych spotkań też było jak najwięcej; żeby ludzi, którzy chcą się tak naprawdę edukować i unowocześniać swój zakres wiedzy, też tego bym sobie życzył. Myślę, że chmury też nie należy się bać, bo często jest taka obawa, że "A, mam swoje data center on-premise, jak będzie chmura to ja stracę pracę”. Niekoniecznie. To nie jest do końca prawdą, ponieważ taki człowiek spokojnie może przenieść swoją aktualną wiedzę w dużej części, naprawdę w przeogromnej części, i tak naprawdę dokładając do tego jakieś elementy, które różnią ten on-premise od chmury, przenieść już istniejącą wiedzę w realia właśnie cloudowe. Dalej te zasoby, te kompetencje i ci ludzie są potrzebni, więc życzyłbym sobie i całemu swojemu zespołowi jak najmniej nudy.

Rafał Banaszkiewicz, Customer Engineer w Google. Życzę, by każdemu było dane współpracować z Rafałem przy swoich projektach. Bardzo dziękujemy, naprawdę to doceniamy. Dzięki za wpuszczenie nas do swojego cloudowego świata.

Dzięki za zaproszenie i mam nadzieję, że wkrótce usłyszymy się ponownie.