Landing zone – bezpieczne lądowanie biznesu w chmurze

Witajcie w świecie FlyTalks. Subskrybuj, by być na bieżąco z kolejnymi odcinkami, treściami obszaru technologii oraz biznesu, a dzisiaj właśnie połączenie tych dwóch sfer. Jeśli chcesz dobrze wystartować ze swoim chmurowym środowiskiem, zarządzać organizacją w zgodzie z najlepszymi praktykami Google i to od samego początku, a do tego dowiedzieć się, co daje to bezpośrednio biznesowi, to słuchaj kolejnego odcinka FlyTalks z Podcastu o chmurze w biznesie, który będzie dotyczyć dzisiaj właśnie usługi landing zone.

Zanim w ogóle będziemy dotykać jeszcze w naszym podcaście treści sztucznej inteligencji i szeroko rozumianemu pojęciu AI, dzisiaj żywa inteligencja, bo są z nami ludzie świata IT, ale właśnie dwóch różnych perspektyw, Piotr Gocłowski Cloud Architect oraz Karol Mucha Customer Success Specialist. Witajcie, dzień dobry, cześć.

Cześć, Konradzie.

Cześć, Konrad, hej.

Pierwsze takie pytanie rozgrzewkowe trochę, które określi też, z kim i z czym mamy do czynienia. Czy macie gdzieś książeczki wojskowe? Było wam dane odbyć służbę wojskową?

Konradzie, szczęśliwie, nie odbyłem służby wojskowej, natomiast książeczka wojskowa zawsze jest u mnie w całej teczce z wszystkimi dokumentami. Jak byłem młodszy, usłyszałem bardzo mądrą anegdotę: "zbieraj wszystkie dokumenty sam i twórz swoją teczkę sam, bo inaczej ktoś może utworzyć to za ciebie", także jeżeli potrzebujesz, mogę ją wyciągnąć w dowolnej chwili.

Nie, spoko, ufam, ale to też takie fajne, chmurowe podejście, by być wszystko w jednej teczce i to dobrze zabezpieczonej, do tego będziemy też zmierzać. Piotrze, wiesz, że ciąży na te obowiązek, że musisz wiedzieć, gdzie ona jest, tak jak Karol?

No tego nie wiedziałem, aczkolwiek mam tu książeczkę, rzeczywiście, gdzieś zakopaną głęboko w dokumentach, mam nadzieję, że się nie przyda, także jest dostępna.

Landing zone to takie wojskowe pojęcie. Nieczęsto zdarza się, żeby świat wojskowy i terminologii wojskowej przechodził do IT, tak jest w tym przypadku, bo landing zone oznacza po prostu obszar lądowania, w którym mogą lądować samoloty. I dzisiaj tym samolotem będą wszystkie chmurowe projekty, o których będziemy gadać. Dowiemy się, na czym polega usługa landing zone w FOTC dokładnie, czym to się, ile to potencjalnie może zająć czasu, jakie są wymogi od strony technicznej, od strony klienta i finalnie, co daje to biznesowi. Tutaj, Karol, bardzo liczę na twoje biznesowe spojrzenie. Piotr będzie reprezentował spojrzenie techniczne, więc zacznę najpierw od Piotra i trochę wrócimy do tego w ogóle, czym zajmujesz się w FOTC i dlaczego dzisiaj będziesz mówił o usłudze landing zone.

Ok. No to w FOTC zajmuje się wdrażaniem klientów m.in., wsparciem. Pracuję jako architekt chmury. No i tudzież po prostu wspieram klientów, czy to istniejących, czy nowych we wchodzeniu właśnie do chmury. Projekty są różne. Najbardziej gdzieś tam bliskie memu sercu są sprawy związane z IoT, czyli gdzieś tam komunikacja machine to machine, w tym przypadku maszyna do chmury. No i dość często mamy klientów, którzy wchodzą do Clouda, no i po prostu potrzebują poznać dobre praktyki, od czego zacząć, jak skonfigurować, bo nie ma co ukrywać, to akurat sam rynek chmur to nie jest coś, co jest z nami od dawna bardzo, a chmura Google jest w ogóle bardzo młoda.

To od sfery technicznej, a od sfery biznesowej, Karolu, jaka jest twoja taka codzienna styczność z klientem i w czym tak naprawdę, w jakich obszarach im pomagasz?

Jasne. Jeżeli chodzi o moją taką typową rolę w FOTC, ona zaczyna się w momencie, kiedy klient rozpoczyna z nami współpracę, tak, więc ja operuję w obszarze dwóch typów klienta, tak, pierwszym typem to jest oczywiście klient, który dopiero rozpoczyna tą swoją przygodę w chmurze, zaczyna, że tak powiem, tworzyć swoje pierwsze workloady, używać pierwszych produktów. Ja jestem od tego, żeby właśnie skoordynować pewne kwestie związane właśnie z tym, żeby chociażby dobrać Piotra lub innych członków naszego zespołu technicznego, żeby wspomógł klienta właśnie w tych pierwszych krokach lub też, jeżeli mam do czynienia z klientami, którzy już w tej chmurze pierwsze kroki poczynili, w tej chmurze czują się dobrze, no to moim zadaniem jest to, żeby ich rozwijać, żeby dbać o nich, pokazywać nowe produkty, no i też na bieżąco po prostu odpowiadać na ich potrzeby. Więc na samym początku użyłeś takiego sformułowania, że landing zone to jest właśnie takie miejsce lądowania, tak, że jakby firma jest tym samolotem, ląduje w chmurze i landing zone ma zapewnić mu bezpieczne lądowanie. Natomiast moja definicja, kiedy rozmawiam z klientami i proszą mnie o to, żebym wytłumaczył, czym to landing zone jest, to zawsze używam pewnej analogii, tak, dlatego że wyobraźmy sobie, że nasza firma, tak, jest po prostu budynkiem, a ze względu na to, że otoczenie biznesowe jest jakie jest, jest pełne ryzyk, jest pełne zagrożeń, to możemy porównać, że nasza firma nie dość, że jest budynkiem, to jest budynkiem, który jest postawiony, czy ma zostać, być postawiony w obszarze, gdzie występują jakieś zagrożenia, np. trzęsienia ziemi, prawda. I tutaj mała ciekawostka, parę lat temu przeczytałem informację a propos fundamentów, jak sobie właśnie radzą firmy budowlane, tworząc wysokie budynki w tego typu miejscach, i te fundamenty muszą mieć możliwość reagowania na jakieś zmiany sejsmiczne, w taki sposób, żeby ten budynek był trwały, przetrwał lata, żeby można było go bezpiecznie budować. Uważam, że najlepszym porównaniem, czy najlepszą wizualizacją, czym jest landing zone, to są właśnie fundamenty, tak, czyli landing zone to jest fundament pod to, żebyśmy mogli budować naszą infrastrukturę w sposób bezpieczny, w sposób taki, który będzie umożliwiał jego dalszy rozwój, czyli budowanie tych dalszych ścian, prawda, więc to jest taka z mojej strony definicja, która może być najbardziej biznesowa.

Jak rozumiem, można zbudować bez fundamentów. Mamy przykłady takich różnych pomysłowych rozwiązań w częściach świata, powiedzmy, bardziej zwinnych i tam, gdzie zwłaszcza nie ma zimy i to wszystko stoi, ale czasem się wali i giną ludzie, prawda? I rozumiem, że chodzi o to, by dobrze zacząć i zwłaszcza uniknąć tej klęski urodzaju w momencie, kiedy organizacja się rozrasta i trudno będzie cofnąć niektóre procesy i wyprostować, nie wiem, kwestie dostępów, konfiguracji, security czy kontroli bilingu na późniejszym etapie. Czy trochę o to chodzi?

Myślę, że tutaj porównanie jest bardzo mocne. Na szczęście operujemy w branży, gdzie co najwyżej może po prostu dojść do tego, że użytkownicy będą mieli utrudniony dostęp, chociażby do aplikacji, czy gdzieś ta aplikacja na jakiś moment zostanie wstrzymana. Natomiast tak, generalnie początek przy szczególnie przenoszeniu, tak, infrastruktury z serwerów on-premisowych do chmury jest bardzo istotny ze względu na to, że wtedy klient już ma pewne wymagania, jeżeli chodzi o jego infrastrukturę, o jej możliwości, dlatego im lepiej zaczniemy, im lepiej przygotujemy te fundamenty, tym będzie po prostu dla nas lepiej i bezpieczniej w przyszłości. Odpowiadając na twoje pytanie, czy tutaj można cofnąć pewne rzeczy, podejrzewam, że można zrobić wszystko, tak, natomiast tworząc i patrząc długofalowo na rozwój naszej firmy, rozwój naszej aplikacji, rozwój infrastruktury, czegokolwiek, do czego będziemy wykorzystywać chmurę, zależy nam na tym, żeby popełniać jak najmniej błędów, żeby rozwój był stały, bezpieczny, obarczony ryzykiem związanym właśnie z tym, co powiedziałeś.

A Piotrze, zmierzając już w stronę szczegółów, ale jednak poruszając się jeszcze na gruncie ogółów. Pod kątem technicznym, to jak opowiesz o landing zone w FOTC.

Najprościej jest to ująć w takich słowach, że jest to taka początkowa konfiguracja chmury, takie przygotowanie. Może to trochę porównać do konfiguracji jakiegoś urządzenia sieciowego, prawda, kupujemy jakieś urządzanie do domu, jakiś router czy coś, no i żeby w ogóle zaczął działać, to musimy gdzieś tam to konfigurować. Tutaj jest podobnie, tylko że na nieco większej skali, tak, jest trochę więcej tych detali do skonfigurowania, żeby w przyszłości łatwo było zarządzać tym wszystkim, żeby łatwo było nadawać dostępy, żeby te zasoby mogły łatwo się ze sobą komunikować. Generalnie mamy dwie landing zony, jest to wersja ręczna albo automatyczna, gdzie używam Terraforma, czyli takiego narzędzia infrastructure-as-code, definiujemy po prostu naszą infrastrukturę, opisując ją w skrypcie, podobną trochę do JSONa.

Teraz skupmy się jeszcze na tym, wróćmy do tego wątku, do kogo kierowana jest ta usługa, Karolu, tak ogólnie, kto może być odbiorcą landing zony?

Tutaj również nie ma jednoznacznej definicji, i jak to często słyszę od kolegów z działu technicznego: "to zależy". Natomiast ja z mojego doświadczenia mogę powiedzieć, że przede wszystkim landing zone jest skierowany do firm, które rozpoczynają swoją przygodę z chmurą. Nie oznacza to, że musi to być firma, która dopiero zupełnie będzie tworzyła jakiekolwiek środowiska, może to być zarówno startup, może to być zarówno duża korporacja, więc na pewno tutaj jako pewnego rodzaju czynnik, do kogo to jest skierowane, nie możemy wziąć pod uwagę ani wielkości firmy, ani jej obecnych rozmiarów, czy ilości obecnych work loudów, więc to jest gdzieś tam wyciągnięte z tej definicji, natomiast z mojej perspektywy warto jest, żeby była to firma, która już posiada jakieś kompetencje techniczne w swoim zespole, ze względu na to, że wtedy i cały proces związany z landing zoną i samo korzystanie z chmury jest ułatwione, prawda, więc jeżeli miałbyś mnie zapytać, kto może skorzystać z landing zony, odpowiem: praktycznie każdy. Przede wszystkim landing zona kierowana jest do firm, które jeszcze z chmury nie korzystają. Oczywiście, z doświadczenia wiem, i były takie przypadki, że klient już posiadał jakieś swoje pierwsze środowiska, bardzo często odbywało się to w gwoli testów, tak, dlatego, że wykorzystywali jeden produkt, prawda, z tutaj gamy produktów Google Cloud. Natomiast w momencie, kiedy już stwierdzają, że ok, dobra, do tej pory mieliśmy jeden produkt, np. nie wiem, translation API, prawda, natomiast cała reszta naszego środowiska była na rozwiązaniach on-premowych. Decydujemy się na to, żeby przenieść wszystko, tak, jak najbardziej takie przypadki są, takie przypadki gdzieś w historii występują, tak wygląda to w praktyce.

Piotrze, jesteś w stanie narysować taką sytuację, czym to potencjalnie może się różnić? Tak pokrótce bardzo, zarządzanie on-premowym środowiskiem, względem zarządzania chmurą. Czy w ogóle, żeby wiesz, zaadresować, co ktoś musi wiedzieć i co to landing zona mu po prostu da?

Jasne. Powiem ci, że przede wszystkim jest znacznie przy Google Cloudzie, przy każdej chmurze, jest znacznie, znacznie mniej rzeczy, które trzeba wiedzieć, bo wyobraźmy sobie np. sytuację, że musimy wdrożyć coś na Kubernetesie. Jeśli tworzymy nawet klaster gdzieś u siebie na on-premie, to sam proces tej samej konfiguracji, postawienia tylko fundamentów, żeby wdrożyć jakąkolwiek aplikację, potrafi potrwać dzień albo więcej, a przy Google Cloudzie po prostu wyklikujemy konfigurację naszego klastra, no i w przeciągu, nie wiem, 5 minut, 10 minut jesteśmy w stanie już wdrażać aplikację, czyli oszczędność czasu jest znaczna, ilość wiedzy też jest znacznie mniejsza, którą trzeba wiedzieć. Dodatkowo wszystko mamy w jednej konsoli. Przy on-premie zwykle jest tak, że zarządzamy, musimy pamiętać, żeby zarządzać routerami, urządzeniami sieciowymi, musimy zarządzać maszynami wirtualnymi. Są tam często jakieś wirtualizery typu, powiedzmy, VMware, tak np., no ale na pewno nie da się tego wszystkiego zrobić w jednym okienku, w jednej konsoli prawda, jak to mamy w chmurze. No ilość pracy jest, różnica w ilości pracy jest duża.

Co oprócz tego, że ten próg wejścia technologiczny jest niższy daje organizacji przeprowadzenie landing zony? To znaczy, czy podążamy tutaj z jakimiś best-practise'ami?

M.in. tak. Może tutaj pozwolisz, Konradzie, że ja odpowiem na to pytanie, Piotr pewnie troszeczkę bardziej rozwinie od kwestii technicznej, natomiast weźmy pod uwagę, co jest bardzo warte zaznaczenia, tak, i chcę to bardzo mocno zaznaczyć, kiedy my zaczynamy korzystać z landing zony? Z landing zony zaczynamy korzystać, kiedy w firmie pada decyzja: ok, wchodzimy do chmury. Dlaczego warto wejść do chmury? Tutaj myślę, że pewnie i tej godziny by nam zabrakło, żeby odpowiedzieć na te wszystkie pytania i spokojnie, jakby można byłoby na ten temat stworzyć zupełnie osobny podcast. Natomiast w momencie, kiedy pada taka decyzja firmie, pada ona z jakiegoś konkretnego powodu, tak. Natomiast, jeżeli rozmawiamy o samej landing zonie i co ona daje od strony biznesowej, ponieważ nie ukrywajmy, zazwyczaj tego typu decyzje są właśnie na tym biznesowym levelu podejmowane, to przede wszystkim chcemy, żeby ta nasza adaptacja do chmury była jak najszybsza, tak, żeby była jak najszybsza, żeby nasze osoby techniczne mogły zacząć pracować na tej chmurze jak najszybciej, żeby mogły wprowadzać te workloady jak najszybciej. Natomiast, oczywiście, poza szybkością liczy się również bezpieczeństwo, tak, czyli właśnie odpowiadając na twoje pytanie, również podczas przeprowadzania landing zony spełniane są wszystkie best-parctisy, które dają nam gwarancję tego, że nasza organizacja, którą utworzymy w chmurze, będzie jak najbardziej bezpieczna. No i koniec końców już wdrożyliśmy ten pierwszy word cloud, mamy organizację, która jest zabezpieczona, odpowiada wszelkim best-practise'om wyznaczonym przez Google i również dochodzi wtedy trzeci, z mojej perspektywy najważniejszy argument biznesowy, czyli zwiększona wydajność operacyjna, tak, czyli tutaj wszystkie zmiany, które chcemy dokonać, mogą one być dokonane szybciej. Jeżeli chcemy dokonać zmian związanych z dostępami, również one mogą być dokonane szybciej, tak więc najważniejsze 3 argumenty: szybka adaptacja, bezpieczna adaptacja i późniejsze większe możliwości operacyjne.

Pierwszym punktem, który jest taki dosyć istotny, to jest szybsze dostarczanie użytkowników do chmury, tych użytkowników, którzy będą korzystać z tych zasobów, w tej chwili nie mam na myśli klientów aplikacji, tylko tych użytkowników w ramach naszej organizacji, lepsze i prostsze może zarządzanie też dostępem, tak, bo jeśli możemy łatwo dostarczać użytkowników, zarządzać nimi, to możemy też nadawać im dostępy. Łatwiej jest też prowadzić atrybucję kosztów, po prostu łatwiej jest nam przypisać określone koszty do określonych osób lub działów, np. dzięki levelowaniu zasobów, wygodniejsza komunikacja między naszymi zasobami, ponieważ jednym z punktów jest np. utworzenie takich sieci współdzielonych, że możemy z nich korzystać w każdym projekcie, w naszej organizacji, które oczywiście zdecydujemy, że chcemy, żeby były, co ułatwia komunikację np. między oddziałami. Też bezpieczeństwo to jest dosyć ważny punkt. Możemy kilka rzeczy ustawić, które znacząco podnoszą nam bezpieczeństwo projektów, tak globalnie, w całej organizacji. No i w przypadku wybrania tej automatycznej, tej terraformowej landing zony, no to mamy automatyczne zarządzanie zasobami, czyli wszystko, co definiujemy w kodzie ma odzwierciedlenie w rzeczywistości, w infrastrukturze, co niesie za sobą szereg korzyści, takich właśnie jak niesie ogólnie zarządzanie kodem, tak, czyli kontrola wersji, możemy wrócić do poprzedniej wersji, tak samo jak tutaj w Gitcie, prawda, możemy cofnąć zmiany, jest to bardzo wygodne.

A czy może coś więcej o Terraformie powiedzieć? Bo to rozumiem, że wymaga trochę innego zaplecza też po stronie klienta i odbiorcy chmury.

Dokładnie, dokładnie. Przede wszystkim powinna być osoba, przynajmniej jedna osoba albo więcej osób, które umieją już Terraforma, albo chcą się go nauczyć, są gotowe nauczyć się. To nie jest rocket science, od razu z góry uprzedzam, trzeba po prostu mniej więcej poznać koncepcję, jak to działa, no i wiadomo, nie uczymy się na pamięć nazw tych wszystkich zasobów, czy tych tych obiektów, no pracując, z Terraformem po prostu korzystamy mocno z dokumentacji.

Rozumiem, że jest to język i tworzymy infrastrukturę jako...

Kod. Jako kod, jako kod. Po prostu piszemy sobie skrypty, podobne do właśnie Jasona, który definiujemy po kolei, np. maszynę wirtualną możemy zdefiniować, wybrać dany typ, wybrać jakiej sieci ma używać, jakiego dysku itd.

To wszystko rozumiem. Panowie, co daje użycie teraformowego podejścia? To użycie wymaga więcej pracy, więcej nakładów ludzkich, finansowych, ale finalnie co to daje organizacji, że napiszemy sobie kod, który będzie mógł odzwierciedlić naszą infrastrukturę? Jakie są korzyści biznesowe i technologiczne?

Przede wszystkim, jeżeli chodzi o korzyści biznesowe. W momencie, kiedy tworzymy jakiś projekt, ja generalnie przed FOTC byłem bardzo mocno związany ze środowiskiem startupowym, więc też jakby moje myślenie, nawet jeżeli rozmawiam z większymi firmami, zawsze jest troszeczkę startupowe, tak, i zawsze musimy pamiętać o tym, że ten świat biznesowy, to otoczenie biznesowe, które nam teraz przyszło w nim funkcjonować, może wymusić dla nas pewne zmiany, tak, czy wdrażanie pewnych zmian często nawet to definiuje, czy nasza firma przetrwa, czy ona będzie się rozrastała, tak, więc przede wszystkim, główna korzyść biznesowa, jeżeli chodzi o użycie Terraforma jest taka, że wszystkie zmiany, których chcemy dokonywać, dokonujemy ich, Piotrze, tutaj wybacz, jeżeli przejdę źle z nomenklaturą, natomiast niemalże za pomocą jednego kliknięcia.

Mniej więcej tak. Chodzi o to, że jak mamy jakąś, mamy już nasze repozytorium, w którym przetrzymujemy, można powiedzieć, obraz, tak, obraz tej infrastruktury w kodzie, łatwo jest tam coś zmienić, łatwo jest tam cofnąć jakąś zmianę, jest to dużo wygodniejsze, bo mamy tak naprawdę w tym repozytorium mamy historię, widzimy historię naszej infrastruktury, bardzo wygodną, którą możemy zarządzać właśnie narzędziami ITA, bez Terraforma tego nie ma.

Dobra. Czy możemy w takim razie zabawić się trochę na przykładach? Bo to kręci nas najbardziej, gdy możemy odnieść coś do siebie, albo lepiej sobie to zwizualizować na czyimś błędzie, albo sukcesie, to trafia oczywiście głębiej i dociera dalej, więc pytanie, czy możemy przeprowadzić, nie wiem, czy w ogóle to z waszej strony jest możliwe, by wyobrazić sobie jakąś firmę, prześledzić wszystkie kroki, tak naprawdę od pierwszego kontaktu, dajmy na to z FOTC, z prośbą o przygotowanie oferty, no i potem przeprowadzenie landing zony, byśmy w ogóle poznali całą usługę i cały proces?

Tak, jest to jak najbardziej ogarnialne i po prostu stworzymy może z Piotrem ci, powiedzmy. Firmę na bazie naszego doświadczenia, tak, która będzie wypośrodkowanym...

Ekstra, tylko bogatą, tylko bogatą, dobra?

Słuchaj, chcę umieścić cię jako jej prezesa, więc mam nadzieję, że tutaj...

Dobrze, zaczynamy.

Będzie ona bogata, dużo od ciebie będzie zależało. Natomiast tak, umówmy się, że nasz przykład od dużej korporacji do startupu, od bardzo dużych kwalifikacji technicznych pośród zespołu, do małych kwalifikacji technicznych pośród zespołu. Więc wyobraźmy sobie, Konradzie, że zostałeś prezesem firmy, która sprzedaje oprogramowanie do zarządzania logistyką, prawda, czyli generalnie waszym targetem są firmy właśnie logistyczne, tak. Wasze oprogramowanie do tej pory było umieszczone w środowisku on-premisowym i nagle pojawia się sytuacja, kiedy już to środowisko on-premisowe przestaje być wystarczające, jeżeli chodzi o tutaj wyzwania techniczne waszej firmy. I teraz ty, Konradzie, musisz podjąć decyzję, czy dokupujemy większą liczbę serwerów...

Typowy case.

Może upgrade'ujemy te serwery.

Chcemy rosnąć.

W takim razie idziemy w stronę chmury. Widzę, że jesteś prezesem, który jest tutaj świadomy, obliczył sobie total cost of ownership dla całego przedsięwzięcia i wyszło ci ok, dobra, chmura będzie dla mnie lepszym rozwiązaniem. Dodatkowo chcesz skalować się międzynarodowo, tak, chcesz wyjść na rynki pozaeuropejskie, więc też jest to dla ciebie bardzo ważna, żeby to...

Ja już tam jestem, panie Karolu. Logistyka, ja już tam jestem.

W takim razie, panie Konradzie, rozpoczynamy od z tego. I tutaj rzeczywiście bardzo często tak się zdarza, że rzeczywiście na samym początku klienci nawet nie mają zdefiniowanych potrzeb, jeżeli chodzi o kwestię landing zony i zazwyczaj ten cykl życia klienta rozpoczyna się od momentu skontaktowania z naszą firmą, tak, czyli przychodzi do nas firma i mówi: "panie Karolu, chcemy przenieść się na chmurę, jak to zrobić?". No i wtedy jakby następuje pierwszy proces, który niezależnie, czy rozmawiamy z korporacją, czy rozmawiamy ze startupem, czy rozmawiamy właśnie z firmą Konradex, tak, zaczynamy od tego zbadania potrzeb, tak, czyli co wy chcecie osiągnąć, jak obecnie wygląda wasze środowisko, z czego obecnie korzystacie, czy macie wykupione jakieś licencje, tak, czyli robimy jakby taki pełny wywiad zarówno biznesowy, jak i techniczny, dotyczący waszego obecnego rozwiązania, jak i rozwiązania, które docelowo chcecie umieścić w chmurze. No i okazuje się, rzeczywiście, wasz przypadek kwalifikuje się do tego, żeby rozpocząć waszą przygodę chmurą od landing zony, tak, czyli oczywiście tutaj sukcesem kończymy cały proces sprzedażowy, tak, ty stwierdzasz, że rzeczywiście landing zone odpowiada na wasze potrzeby, więc my ustalamy sobie pewnego rodzaju założenia czasowe, podpisujemy sobie umowę w praktyce, która określa, jakich informacji od was potrzebujemy, jaka powinna być dostępność waszego zespołu i przechodzimy do realizacji technicznej, o której więcej opowie Piotr.

Super, jak szybko. Teraz pewnie nie będzie tak łatwo, obstawiam.

Łatwo i niełatwo. Jesteśmy przygotowani, mamy gotowe gdzieś tam ścieżki przetarte, więc idzie to zwykle dość sprawnie, dość płynnie i zwykle zaczynamy od tego, żeby spotkać się z klientem, zrobić tak naprawdę wywiad, jak wygląda firma, jakie ma gdzieś tam hierarchie i dlaczego, no bo to jest trochę, to jest potrzebne np. do tego, żeby zaplanować hierarchię zasobów w Google Cloudzie, coś, z czego korzystamy, tworząc nasze zasoby, zasoby tworzymy w ramach projektów, tak, to jest jakby taki zakres sum projektowych w ramach projektu. Projekty mogą być podpięte pod foldery lub pod organizację, a foldery wiadomo, że mogą być podpięte albo pod inne foldery, albo pod organizację. Warto to dobrze przemyśleć, ponieważ będzie to miało wpływ, spory wpływ na późniejsze przydzielanie uprawnień i gdzieś tam na polityki np. bezpieczeństwa, które wdrożymy z czasem. No i tutaj pytanie, czy chcemy, żeby to było wszystko skoncentrowane wokół środowiska, czyli np. folder Prod , inny folder Dev, czy na zespole, czyli zespoły w stylu zespół, powiedzmy, księgowy, może zły przykład, ale jakiś marketing, jakiś development, tak, czy np. możemy też na jednostce biznesowej to też oprzeć. Generalnie to jest pierwszy krok, tak, ta hierarchia zasobów. Dalej musimy się zastanowić nad konwencją nazewnictwa, czyli w jaki sposób będziemy nazywać nasze zasoby? Najistotniejsze jest nazwanie odpowiednio projektów. Generalnie dobrze, żeby to było zbieżne z naszymi istniejącymi systemami, jeśli jakieś mamy do zarządzania właśnie zasobami. I druga rzecz ważna, żeby być konsekwentnym w tym.

Taki porządek od początku pozwoli na łatwiejszą organizację zespołem, nadawanie uprawnień, no i też logiczniejszą hierarchię, bo rozumiem, że często trzeba w pracy z chmurą odwoływać się, dajmy na to, do nazwy projektu.

Bardzo, bardzo często. Prawie każdy zasób ma jakiś tam w swoim takim unikalnym URL-u nazwę projektu sobie. To potem, jak się np. patrzy w blogi, w monitoring, widzimy te ścieżki, patrzymy, aha, no to to jest projekt tego i tego zespołu, czy tego i tego projektu, i po prostu od razu mam te informacje. Najgorsze, co można zrobić, to np. wrzucić do jednego projektu X rzeczy, tak, aplikację A, aplikację B, generalnie im drobniej to rozbijemy, tym... Znaczy, drobniej, odpowiednio drobno, tym lepiej.

A, Karolu, czy coś z perspektywy biznesowej daje rozgraniczenie na projekty?

Tak, przede wszystkim zacznijmy od tego, że często jest tak, że w danej firmie kilka zespołów pracuje nad osobnymi projektami, tak, więc jakby to jest pierwsza korzyść, tak, że możemy sobie, po pierwsze, rozgraniczyć kwestie odpowiedzialności, możemy też ograniczyć dostępy, że tylko dana grupa osób ma dostęp do danego projektu i może wokół niego pracować, więc to na pewno ma swój plus, jeżeli chodzi o zarządzanie zasobami ludzkimi, tak, dlatego, że tutaj dużo prościej jest wtedy wiedzieć, co zespół poczynił, jak to zrobił, jeżeli tutaj jeszcze mamy Terraforma, to już w ogóle mamy jeszcze dodatkowy plus. Natomiast z takiej strony bardziej może nie tyle biznesowej, co finansowej, też duża liczba projektów pozwala nam mieć lepszy wgląd w koszta, tak, bo możemy wtedy sobie sprawdzić, czy dany projekt zużył kwotę X, czy to zużycie wzrasta w skali roku, czy np. okazuje się, że ten wzrost jest zbyt duży, jeżeli chodzi o stosunek i porównanie go do wzrostu organicznego liczby użytkowników, więc to na pewno polecam właśnie wszystkim firmom, które gdzieś zaczynają swoją przygodę w chmurze, żeby tworzyć jak największą liczbę projektów, oczywiście, z rozsądkiem, tak, natomiast przede wszystkim na to, żeby również w późniejszym czasie móc pewne rzeczy od strony organizacyjnej łatwiej sprawdzić.

Idziemy dalej. Rozumiem, że moja firma Konradex, jak dobrze pamiętam, realizuje sobie landing zone, chyba bez Terraforma, bo to by przewyższało moje potrzeby, tak może, załóżmy, jakieś benefity generalnie są już dla mnie jasne. Czy na polu security możemy coś tutaj narysować? Jakie są korzyści wynikające z lepszej hierarchii, no i też takie późniejsze konsekwencje?

Tak, jeszcze ustalmy sobie proces, czyli na początku mamy rozpoznanie firmy, kwestię związaną ze sprzedażą, formalnościami i decyzją na tak, wprowadzamy Landing zone, wtedy dla danej firmy zostaje przydzielony delivery manager, który od strony, powiedzmy, z tego świata technicznego i biznesowego, będzie całym tym procesem później zarządzał i przechodzimy właśnie do tej kwestii, o której wspomniał Piotr, tak, czyli już takiego technicznego rozpoznania potrzeb firmy, więc tutaj tak tylko chciałem mniej więcej zaznaczyć na timelinie, w którym miejscu jesteśmy.

Jesteśmy już też po wymyśleniu, ustaleniu tej konwencji nazewnictwa, więc musimy się zastanowić, w jaki sposób będziemy dostarczać naszych użytkowników do chmury. Google wspiera takie narzędzia jak Cloud Identity, Google Workspace. Do czego one służą? Generalnie to są narzędzia, w których zarządzamy tożsamością, tak, możemy tam dodawać użytkowników, możemy ich usuwać, możemy tworzyć grupy itd. Czyli to jest takie miejsce, gdzie zarządzamy tym całym identity, ale nie jest to jedyne miejsce, z którego możemy korzystać. Możemy dostarczyć istniejące tożsamości, np. z naszego istniejącego systemu do zarządzania nimi, np. Active Directory, tak, możemy użyć takiego narzędzia, toola, specjalnie stworzonego do tego, to się nazywa GDCS, który potrafi synchronizować konta, z Active Directory do Google Workspace, znacząco już nam ułatwiając pracę i życie. Możemy też ustalić, żeby w ogóle źródło tożsamości było zewnętrzne, czyli żeby Google zawsze odwoływał się do zgłoszonego dostawcy tych użytkowników, więc to jest bardzo wygodne. Jak już mamy ustalone, jak ci użytkownicy będą dostarczani, musimy po prostu ich potworzyć. Jeszcze jest jedna opcja, możemy uploadować użytkowników po prostu z pliku CSV, gdyby po prostu była taka potrzeba, gdybyśmy dotychczas nie mieli istniejącego systemu zarządzania tożsamości. Tak, no i w dalszej kolejności musimy odpowiednio skonfigurować konta administratorskie, a konkretnie to jest best-practise, ale to generalnie jest taki must-have obecnie, włączenie 2FA, autoryzacji 2FA dla administratorów, to moim zdaniem jest obowiązek, bo ktoś takie konto przechwyci, no to zyskuje ogromne możliwości.

Czyli dwustopniowe uwierzytelnienie?

Dokładnie tak, uwierzytelnianie czy to SMS-em, czy to kodem w aplikacji, a w ogóle idealnie i najlepiej to za pomocą takich fajnych kluczy U2F, ponieważ są aktualnie, niephishingowalne. Jeśli jest możliwość wdrożenia takiej polityki w firmie, żeby używać 2FA to zdecydowanie warto to wdrożyć. Kolejnym etapem jest konfiguracja bilingu. Warto utworzyć budżety, żebyśmy wiedzieli, dostali notyfikację. Wymyślamy kwotę, jak taki budżet, powiedzmy, na pewien oddolny okres czasu, np. na miesiąc, wybieramy sobie z listy zasoby, jakieś projekty, jeden lub kilka, czy np. cała organizacja, czy określone usługi tylko. Wybieramy sobie jakiś scoup, no i po prostu, kiedy zostanie przekroczony zdefiniowany przez nas próg tego budżetu, np. 25%, 50, 75, to wtedy przychodzi nam powiadomienie, przy każdym tym progu.

A w jakiej formie? To jest mail, czy to jest jakieś powiadomienie, nie wiem, przez aplikację?

Tak, to jest w formie maila domyślnie, czyli mail do administratorów konta bilingowego.

Dobra, a czy mój dyrektor finansowy, który zatwierdził mi ten biling, jego wysokości, też dostanie takie powiadomienie, czy lepiej nie?

Wszyscy dostaną, którzy mają rolę biling administratora na koncie bilingowym, są dwie role, które uprawniają, które po prostu dostają te maile.

Czyli sfera bilingu może być pod kontrolą, wystarczy ustawić biling alerty, odpowiednie poziomy i będziemy informowani na czas, gdy nasz zespół będzie pracować i testować możliwości chmury. Ok, to pozwala trzymać w ryzach. Co jeszcze pozwala trzymać bezpieczeństwo na możliwie wysokim poziomie? Czy jeszcze jest jakaś praktyka, która tutaj na tym polu uzupełni temat?

Jasne. Jeśli chodzi o bezpieczeństwo, to ogólnie w landing zone jest zalecane, żeby włączyć security command center, to jest takie narzędzie od Googla, które potrafi nam śledzić nasze zasoby i pokazywać alerty, prawda, jeśli coś zostanie źle skonfigurowane, czy coś jest...Ma dwie wersje, prawda, i w tej wersji standard, takiej tej darmowej może już sporo pokazać, ale jest też wersja premium. Kolejną rzeczą i chyba najważniejszą, jeśli chodzi o bezpieczeństwo, to to są tzw. zasady bezpieczeństwa na poziomie organizacji, z angielskiego to jest constraints. Co to właściwie jest? To są takie gotowe polityki, takie już zdefiniowane, które można wymusić na całej organizacji, np. możemy zablokować, żeby tworzone maszyny wirtualne w naszym projekcie czy folderze, albo w całej organizacji, nie mogły dostać publicznego adresu IT. Dlaczego, po co to komu? Chodzi o to, że jeśli coś publicznie stoi, prawda, np. serwer z Windowsem, nie zadbamy wystarczająco o firewalle, firewall przed takim serwerem, no to dosyć dużo osób może tam próbować, botów, nie botów, dosyć dużo różnych rzeczy może się tam złych zadziać, nawet może taki serwer zostać przejęty w najgorszym przypadku, jeśli gdzieś tam będzie jakaś podatność, coś niezałatane. Może te polityki tworzyć na różnym poziomie, no i po prostu gwarantują nam bezpieczeństwo. To jest właśnie jedna z głównych zalet, moim zdaniem, w ogóle dla posiadania w Google Cloudzie organizacji, tego organization node, ponieważ tylko właśnie w tym przypadku możemy korzystać z tych constraintów. Mogę powiedzieć jeszcze o jednym fajnym przykładzie tego constraintu, to jest blokada w nadawaniu uprawnień kontom spoza jest Google Workspace, domyślnie w Google Cloudzie możemy nadać uprawnienia nawet kontom gmailowym, tak, co jest takie trochę niebezpieczne, bo wystarczy, że ktoś o złych, ktoś, np., nie wiem, na wypowiedzeniu albo po prostu o złych zamiarach, mając dostęp do IAM-a w Google Cloudzie, będzie chciał po prostu udostępnić jakieś dane czy dostęp do jakiejś usługi, no to wystarczy, że po prostu poda właśnie, tworzy politykę IAM dającą dostęp dla konta gmailowego, jakiegoś zewnętrznego, ktoś może zostawić backdoor dla naszego systemu.

I rozumiem, że można tego łatwo uniknąć?

Tak, po prostu włączając dla całej organizacji tą zasadę bezpieczeństwa, czyli blokada w nadawaniu uprawnień kontom spoza GWS, czyli Google Workspace.

Ja jeszcze tylko może dodałbym, jak to rzeczywiście wygląda, ponieważ tak jak tutaj troszeczkę długo rozmawialiśmy o aspektach technicznych, tak, natomiast landing zone nie jest produktem, który jest skomplikowanym dla klienta, dlatego że z definicji wykonanie jest po naszej stronie, tak, więc jest warto o tym pamiętać. Oczywiście, zalecane jest to, żeby klient z nami cały czas współpracował z różnych względów, natomiast z mojej perspektywy przede wszystkim ważne jest, żeby klient również miał świadomość dotyczącą tego, jak to wszystko wygląda od strony wykonawczej, ponieważ późniejsze procesy, późniejsze wdrożenia kolejnych produktów będą przebiegały dużo sprawniej, tak, więc tak jak wspomniałem, zaczynamy od kwestii sprzedażowych, kwestii formalnych, przydzielenia odpowiedniej osoby, która będzie całym procesem zarządzała i też będzie punktem kontaktowym dla takiego klienta, i potem przechodzimy te wszystkie kroki, których chyba, jak dobrze, Piotrze, pamiętam, jest około 10, tak, pracując z klientem i mamy właśnie wynik związany z tym, że mamy gotową infrastrukturę.

A dokładnie po ilu godzinach? Ile to potencjalnie może zająć? I kiedy mówicie: "słuchajcie, wszystko jest gotowe do bezpiecznego operowania w Google Cloud"?

To zależy w dużej mierze też od klienta. Generalnie według takiej podstawowej definicji jest to około 30 dni pracy, tak, natomiast to zależy oczywiście od tego, jakie są potrzeby danej firmy, jakie są wymagania, ile tych poszczególnych ustawień musi być zrealizowanych, natomiast również jakby czas realizacji landing zony w dużej mierze często zależy właśnie od klienta, tak, no bo jak to w praktyce wygląda przy tworzeniu różnych projektów, musimy dostać pewną informację, przygotować to dobrze. Z jednej strony landing zone jest produktem skalowalnym, natomiast są pewne elementy, które muszą być dopasowane do konkretnych potrzeb.

Ok. A gdy będę jeszcze chciał coś zrobić z moją chmurą i z moją konsolą, czy są jeszcze jakieś inne usługi w ofercie FOTC, po które można sięgnąć, tak tylko pokrótce, oprócz landing zone? Bo to jest taka podstawa i fundament, jak powiedziałeś. Co jeszcze na późniejszym etapie pozwoli, nie wiem, czy to zwiększyć bezpieczeństwo, czy kontrole nad bilingiem, czy są jakieś rozwiązania dostępne?

Tak, jasne. Generalnie, jeżeli chodzi o naszą ofertę, to może przybliżę 3 takie podstawowe produkty, jeżeli mówimy tutaj o kontekście produktów. Pierwszym to jest rozwiązanie kill-switch, czyli to jest jakby poszerzenie tego, co Piotr opowiadał wcześniej, czyli właśnie tych powiadomień, jeżeli chodzi o kwestię przekroczenia bilingu. Kill-switch działa troszeczkę bardziej może ostrzej, tak, bo po prostu w pewnym momencie, jeżeli przykładowo, chcemy sobie przetestować jakiś produkt, którego wcześniej nie testowaliśmy, no to w momencie, kiedy użyjemy produktu kill-switch po prostu jakby całkowicie odcinamy sobie tutaj dany projekt, tak, więc te koszty nie tyle dostajemy informację o tym, że budżet został przekroczony, ale po prostu już dany projekt przestaje nam dawać jakieś obciążenie. Oczywiście, mamy tutaj możliwości również audytów czy w zakresie security, czy w zakresie optymalizacji kosztów, a raczej informacji o tym, czy nasza infrastruktura koszty dobrze, że tak powiem, wykorzystuje, czy wszystkie produkty działają tak, jak trzeba. Natomiast coś, co jest też bardzo ważne i co chciałbym powiedzieć na sam koniec, bo wydaje mi się, że w kontekście rozmowy o samej chmurze to jest bardzo ważna informacja, Google Cloud posiada w swojej ofercie, nie wiem, chyba około 200, pewnie już ponad nawet 200 produktów i warto pamiętać o tym, że każda firma ma swoje indywidualne potrzeby, dlatego przede wszystkim my w FOTC skupiamy się na tym, żeby rozmawiać z klientem, dotrzeć do tego, czego on potrzebuje i wspierać go w późniejszej realizacji tych projektów. W praktyce zazwyczaj wygląda to tak, że to my doradzamy klientowi, pomagamy ustalić mu jakieś kroki, jeżeli chodzi o wdrożenie danego produktu, natomiast również my możemy część pracy wziąć na siebie. Natomiast naszym takim głównym celem jest to, żeby klient również podnosił kompetencje związane z Google Cloud, ponieważ będzie to lepsze i dla nas, jak i dla zespołu klienta.

Ja po prostu życzę, żeby każdy klient miał styczność, było mu dane spotkać duet biznesowo- technologiczny, Karol Mucha Customer Success Specialist był dzisiejszym gościem FlyTalks, podobnie jak Piotr Gocłowski, który w FOTC pełni rolę Cloud Architecta. Panowie, bardzo dziękuję. Pamiętajcie o książeczkach wojskowych, no i widzimy się w strefie lądowania.

Dzięki.

Landing zone.

Do zobaczenia w takim razie.

Dzięki za rozmowę. Wszystkiego dobrego.

Do zobaczenia, cześć.