Łukasz Kałużny: Bo dużo osób się nie będzie chciało przyznać. W szczególności jak zmieniło rolę, odpowiedzialność, albo jak nagle się okaże, że billing się nie zgadzał i będzie miał za coś zacząć płacić.

Szymon Warda: Ten mail będzie ignorowany bardzo często i konkretnie, że tak powiem.

Łukasz Kałużny: To nigdy nie będzie migracja ani stopniowe sprzątnięcie tego, co już mamy. Zazwyczaj te wszystkie projekty in-place kończą się porażką.

Szymon Warda: Projekt takiej zmiany to jest projekt techniczny i biznes z tym zawsze wygra.

Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzi Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka góra, dół, lewo, prawo. Zobaczcie sobie jak Łukasz się pięknie śmieje. Widać, że pogoda dopisuje. Linki ogarniecie, wierzymy w Was. No to co, parafialki teraz.

Łukasz Kałużny: Tak. Czyli 16 czerwca konferencja z okazji 200 Pato. Mamy potwierdzonego Mariusza Gila i Oskara Dudycza, których mogliście spotkać w odcinkach, bądź sławetne linki do bloga Oskara, które często omawiamy.

Szymon Warda: Chyba obecni goście potwierdzeni nikogo absolutnie nie dziwią.

Łukasz Kałużny: Dobra i szybkie przypomnienie. Dwa najbliższe szkolenia, po pierwsze, Observability z Szymonem na stosie Grafana.

Szymon Warda: Ja dorzucę jedną rzecz, że już po przebudowie, więc będzie przy okazji pokazywanie różnych innych bajerów, feature’ów i ładnie zintegrowanej Grafany z dużą ilością rzeczy. Między innymi z LLM-ami, które wyjaśniają ładnie co się dzieje, jak się dzieje i co poprawić w kodzie.

Łukasz Kałużny: Aż tak?

Szymon Warda: Tak. Podpięty został OpenAI. Jak klikasz na stack trace Pyroscope to Ci mówi w której klasie co masz zmienić, z czego to wynika i wszystko ładnie, nawet co zoptymalizować.

Łukasz Kałużny: Nieźle. A ze mną za to też AI, ale Agentic AI the Hard Way, czyli poznęcamy się nad API, tutaj OpenAI-a, żeby zrozumieć, co tak naprawdę wszystkie frameworki AI-owe robią pod spodem. I sammy from scratch, korzystając tylko z samego czystego SDK do wywołań API, zbudujemy sobie kawałek loopa agentowego. Tak, można piękną, wspaniałą pętlę, tak to można nazwać.

Szymon Warda: Łukasz wraca do podstaw programowania, prawda?

Łukasz Kałużny: Ale zobacz i tak tam trafimy, żeby to zrozumieć. Więc te fundamenty będziemy zawsze. Przypomniałeś. Dobra, koniec dygresji. Idźmy do tematu odcinka, czyli…

Szymon Warda: Brownfield.

Łukasz Kałużny: Mówiliśmy, robiliśmy sobie intro do governance, do chmury at scale, bardziej w okolicach greenfieldowych. Zachęcamy do przesłuchania. A teraz scenariusz, który jest częściej, nawet w zeszłym roku się zdarzały, bo przynajmniej jestem w stanie, tak, na pewno jeden projekt taki robiliśmy w zeszłym roku sprzątający. Inaczej…

Szymon Warda: (…) sprzątanie.

Łukasz Kałużny: Tak. I teraz słuchajcie, sytuacja jest zawsze taka, są postanowienia, postanowienia noworoczne, bo w sumie my nagrywamy zaraz po Nowym Roku. Są też założenia, że będziemy trzymać się tym razem tego governance’u i tego pilnować. I nasz ekosystem, w tym wypadku chmura, po czterech, pięciu latach wygląda zupełnie jak zawsze.

Szymon Warda: Łukasz, ja bym powiedział, że scenariusz jest inny, bo Ty właśnie mówisz o motywacji. To nie jest postanowienie, tylko coś się gdzieś poważnie wywaliło, nazywając to politycznie poprawnie, gdzieś koszty poleciały, ktoś zaczął pytać co się dzieje, jak to się dzieje, gdzieś coś wyciekło. Więc nagle jest wielka motywacja, nazwijmy to ponownie politycznie poprawnie, żeby coś z tym zmienić, ruszyć i tym razem, żeby było dobrze.

Łukasz Kałużny: Słuchaj, to nazwijmy to, chyba najczęściej to jest koszty albo wiedza plemienna zmienia komórkę organizacyjną. Albo będzie kontynuować karierę, albo będą kontynuować karierę poza strukturami organizacji.

Szymon Warda: Jeszcze czasami jest certyfikacja ISO, która motywuje bardzo mocno, żeby jednak to ogarnąć.

Łukasz Kałużny: No tak, miałeś taki też fajny case sprzątania pod to.

Szymon Warda: Piękna rzecz, tak.

Łukasz Kałużny: Dobra, słuchajcie teraz tak, jeżeli teraz popatrzymy sobie na adopcję chmury, bo mamy właśnie greenfieldy, które są przyjemne i są zmianą, bardzo ciężką zmianą organizacyjną. To brownfieldy mają ten problem… W ogóle wiecie co? Dostałem dobre wytłumaczenie kiedyś czemu Brownfield? Bo jak kupa wpada w wentylator to wszystko jest ubrudzone.

Szymon Warda: A tu będzie i to też będzie dokładnie mocno widać przy tym co będziemy omawiali, to Brownfield trwa dużo dłużej. Jak mówiliśmy, że Greenfield w 3 miesiące można zamknąć, to Brownfield to jest dużo dłuższa opcja.

Łukasz Kałużny: Mieliśmy też ten odcinek, w którym się poprzednio odnosiliśmy na temat pytania właśnie z Discorda, że mamy ileś kont AWS, różne standardy, nikt z nikim nie rozmawia. To jest jedno. A druga rzecz, że zaczyna nasza landing zone’a, cokolwiek zaczęło przypominać Frankensteina przez swój rozwój totalnie ewolucyjny, jak w tych algorytmach genetycznych.

Szymon Warda: Łukasz, zakładasz, że Jest landing zone’a i jej tam może nie być.

Łukasz Kałużny: Tak. Przy skali zazwyczaj coś przypominającego landing zone, przy większej skali. Dobra i co, chyba pierwsza rzecz to trzeba sobie powiedzieć jak do tego podchodzimy. Czyli trzeba wiedzieć w ogóle co my mamy.

Szymon Warda: Tak, inwentaryzacja jest super ważna. To samo trochę co było przy greenfieldzie, dowiedzenie się, otagowanie, mówiąc bardzo prosto, dowiedzenie się co, gdzie jest, ustalenie właściciela, ustawienie cost center tak zwanego, czyli kto za to płaci. Dla kogo to jest, ustawienie czy to jest developerskie, produkcyjne i tego typu różne rzeczy. Tagi. Tagi. Tagi.

Łukasz Kałużny: Tagi. Znaczy nie, to teraz tak, popatrzmy sobie, bo mówimy sprzątanie brownfielda. Może powiedzmy też główną rzecz, żeby już od razu nie było gdzieś to na końcu, Brownfield to nigdy nie będzie migracja ani sprzątnięcie, stopniowe sprzątnięcie tego, co już mamy. Nie zrobimy. Zazwyczaj te wszystkie projekty in-place kończą się porażką.

Szymon Warda: Tak, czyli nie bierzemy obecnego kodu Terraforma, Bicepa albo czegokolwiek innego i nie ulepszamy go, bo to się nie uda.

Łukasz Kałużny: Czyli stawiamy sobie z boku i zmuszamy ludzi do migracji. I z tą inwentaryzacją, chyba najważniejsze to jest powiedzenie, kto jest za co odpowiedzialny. I to jest w ogóle najdłuższa mordęga.

Szymon Warda: Polityczna głównie.

Łukasz Kałużny: Bo dużo osób się nie będzie chciało przyznać, w szczególności jak zmieniło rolę, odpowiedzialność, albo jak nagle się okaże, że billing się nie zgadzał i będzie miał za coś zacząć płacić.

Szymon Warda: Ten mail będzie ignorowany bardzo często i konkretnie, że tak powiem. Kilka sposobów jak to zrobić. Oczywiście jest powiedzenie, że wyłączamy jak nie ma i tak dalej. Dość takie rzeczy oczywiste. No i popędzanie, popędzanie, popędzanie. Trzeba, przy brownfieldach bardzo mocno trzeba mieć kilka rzeczy. Trzeba mieć kogoś, kto nie tylko technicznie popiera, ale też to popiera politycznie. To jest rzecz pierwsza. I druga rzecz, to jest szybko udowodnić wartość tego, co robimy.

Łukasz Kałużny: Tak, ale wróćmy do…

Szymon Warda: Dlatego (…) center, alerty, co wspomniałeś, budżety.

Łukasz Kałużny: Raczej musimy się dowiedzieć… To jest inaczej, jak będziecie patrzyli na Brownfield, po pierwsze, kto jest odpowiedzialny, kto płaci? To są dwie, dwa pytania, na które trzeba sobie odpowiedzieć. Od tego potem idzie pytanie - co możemy wykasować?

Szymon Warda: Najprostszy sposób na optymalizację - co wywalić? I to nam podnosi nie tylko koszty, znaczy obniża koszty, ale też podnosi nam bezpieczeństwo, całe dane, łatwe do zarządzania i tak dalej. Wywalanie jest bardzo ważne. I ja bym powiedział kolejny element to jest sprawdzenie, kto do czego w ogóle ma dostęp i na jakim poziomie. Bo zobaczymy tam, że całe zespoły, developerzy, ludzie, którzy już nie pracują i tak dalej, tam będzie cała piękna litania. Dobrze, to zinwentaryzowaliśmy. Tą inwentaryzację w ogóle możemy zautomatyzować w pewien sposób, przynajmniej tworzenie tego Excela.

Łukasz Kałużny: Inaczej, tak, mamy wbudowane te wszystkie narzędzia. Szymon teraz może powiedzieć, Szymon właśnie ten jest na moim etapie z maja, więc też powie tak samo jak ja: użyj do tego Cloude’a częściowo.

Szymon Warda: Jakie częściowo? Jakie częściowo w ogóle?

Łukasz Kałużny: Tak, będzie trzeba przebrnąć potem przez te bagno, które wypluje, ale odwali dużo brudnej roboty. Jak popatrzymy sobie, to tak, z jednej strony to będzie cost managementy, cost explorery, billingi, raportsy, w zależności gdzie jesteście. Potem wszystkiego rodzaju jeszcze od strony bezpieczeństwa cała zabawa z defenderami, security hubami, security command center, czyli to będzie w tym. I z notatek Szymon, ja się z tą siecią nie zgodzę, bo żadna z tych usług nie działa dobrze, żeby dało się zrobić jakąś większą analizę. Więc od strony ruchu sieciowego to może logi na centralnym firewallu, jeżeli go mamy.

Szymon Warda: Łukasz, to nie jest to, że nie zgadzasz się ze mną. Dobrze wiem z kim się nie zgadzasz. Dobra.

Łukasz Kałużny: Dobra.

Szymon Warda: Kawałek dalej idziemy. Czyli udowodniliśmy, zrobiliśmy, zinwentaryzowaliśmy, pokazaliśmy co możemy zaoszczędzić. Mamy ogarnięte tak i mamy pierwsze bezpieczeństwo ogarnięte. Co robimy dalej?

Łukasz Kałużny: No dobra, to teraz jak podchodzimy? Wiemy co mamy, to możemy zaplanować jak chcemy to sprzątnąć. Więc pierwsza rzecz to strategia nowej wyspy, czyli cofamy się do odcinku wstecz i budujemy nową wyspę obok. I mówię teraz zupełnie i mówię zupełnie poważnie w wielu przypadkach. Przy czym czasami może się okazać, że na przykład centralny hub zostanie, bo jest ok, bo te centralne elementy często da się uporządkować. Bo teraz powiedzmy, problem jest z częścią aplikacyjną. Niektóre elementy centralne będą po prostu ok.

Szymon Warda: Będą ok albo będą miały tyle naleciałości, żeby rzeczy działały i połączeń z on premem i tak dalej, że ruszanie tego może nie być wartościowe.

Łukasz Kałużny: Prościej będzie je posprzątać, te centralne rzeczy, być może.

Szymon Warda: Tak, tudzież cała seria, jak to doskonale teraz się dowiadujesz, reguł firewallowych i tak dalej, które po prostu są tam i lepiej ich nie ruszać, bo za chwilę coś wywalimy. A co jest ważne? Wywalenie czegoś przy takim brownfieldzie nie jest dobrym pomysłem, bo to jest duże ryzyko, że projekt zostanie ubity.

Łukasz Kałużny: Bo skrzywdziliście.

Szymon Warda: Tak.

Łukasz Kałużny: Dobra, ale jak popatrzymy i to jest jedna rzecz. I teraz taka, zasada taka chyba pierwsza: nie migruj starego Terraforma, jak to spisałeś Szymonie. Zawsze jest takie przeświadczenie, że przemigrujemy, będzie dobrze. Takiej, że Terraform czy inne te skrypty są multi cloudowe. To jest taka rzecz. Będzie w tym, jeżeli coś nie żyło… Może inaczej, jeżeli coś nie żyło, regularnie nie było update’owane, nie miało żadnego rozsądnego standardu, to nie mielibyście Brownfielda, gdyby to żyło.

Szymon Warda: Jeszcze jest inna bajka. Nawet gdyby żyło, nawet gdyby było utrzymywane, to to był Terraform napisany pod konkretny projekt zakładam, przez konkretny zespół. Inaczej nie mielibyście tego pierdolnika, który macie. Więc branie tego czegoś, co zostało dostosowane do innego projektu, potem powoduje problemy w innych projektach, bo to nie będzie w miarę uniwersalne. Nie będziemy przenosili takich dobrych praktyk rynkowych, bo też o to nam chodzi, na całość. Dobrze jest mieć start, jako dobre praktyki rynkowe i potem dostosowywać to, a nie odwrotnie, mieć dostosowane i potem na to nakładać praktyki rynkowe. Tak z reguły nie działa, sorry. Mamy kawałek Terraforma nowego. Co robimy Łukaszu?

Łukasz Kałużny: Dobra, i teraz trzeba powiedzieć, że drodzy wszyscy przyjaciele przenosimy się.

Szymon Warda: Tak, przynajmniej wziąć jeden pierwszy projekt i z nimi tak trochę bardziej w kooperację przenieść, żeby nie było wielkiego wybuchu.

Łukasz Kałużny: Czyli teraz tak i teraz w tym… I słuchajcie, i teraz tak, jak sobie na to popatrzymy, o Bożesz, słuchaj, jedno, co się łapie i tutaj jest podejście, że mamy datę amnestii. Ona będzie przesuwana dziesiątki razy i będą w tym. I trzeba to po prostu zaakceptować fakt, że to jest jak teatr, musi trwać. To chyba będzie taka przewodnia z tego myśl, bo możecie, jeżeli popatrzycie się, jak robimy komunikację, każemy się gdzieś przemigrować, zawsze będzie tysiąc powodów za. Nawet inaczej, mamy taki projekt, w którym ze względu na releasy, ważność biznesową i potem inne rzeczy w takim sprzątaniu, coś, co powinno dać się zrobić w trzy miesiące, dzieje się dziewięć miesięcy.

Szymon Warda: I będzie odwlekane, terminy będą się zmieniały i ktoś będzie nam mówił w twarz, że wyrobi się, a wie, że się nie wyrobi. I co jest ważne, nie należy z tym walczyć. To jest… Projekt takiej zmiany to jest projekt techniczny i biznes z tym zawsze wygra, więc stawanie tutaj oporem i tak dalej nie ma sensu. To jest piękny scenariusz, żeby ubić ten cały projekt i z tym trzeba się liczyć. Dobrze, co tam dalej, jak to w ogóle, jak do tego podejść? Mamy co? Zrobiliśmy sobie blok pierwszy, zrobiliśmy sobie blok drugi, super, fajnie. Co dalej w ogóle odpalamy?

Łukasz Kałużny: Dobra i teraz jak popatrzymy sobie jak robicie, to wracając trochę do tego greenfieldu, tutaj jeżeli będziemy się migrować, tak naprawdę ten target, do którego będzie musiał być migrowany, to tu będzie to problematyczne, bo tak, musicie już to zabezpieczyć, o tak. Bo przykładowo, jedno ze sprzątań jest takie, że mieliśmy standardy i poszły się walić zgodnie z teorią wybitych szyb. Albo dochodziły nowe usługi przykładowo Azure’owe, ale już nikt polityki bezpieczeństwa dla nich nie zrobił.

Szymon Warda: Tak, zakładamy to, że jak już coś przemigrowaliśmy na nową wersję, to już tam pilnujemy porządku. Nie ma tak, że znowu samowolka.

Łukasz Kałużny: Więc inaczej, jeżeli teraz popatrzymy, to co Wam wyjdzie z inwentaryzacji będzie trzeba przenieść. To będzie lista rzeczy, które będziecie musieli wspierać, usług, bo tak to sobie można popatrzeć. I przy całości, jak będziecie to projektować, to jest to… Inaczej, znowu to będzie komunikacja: co do diabła powinno być, będzie włączone i wymuszone na nowych, w nowym miejscu, do którego się przenosimy z tym całym bajzlem, który mieliśmy. I tutaj może być pomocne, żeby polityki, rzeczy, które macie, w ramach inwentaryzacji też właśnie to, co dostaniecie z defenderów for cloud czy innych rzeczy, odpalonych polityk np. Azure’owych odpalonych w (…) modach, czyli tego co chcecie zhardeningować, żeby wykryć co będzie hardeningowane. I można powiedzieć, że właścicieli ostrzec, co zostanie przycięte, bo taki feedback będzie można bardzo tanio i łatwo przekazać.

Szymon Warda: I też to jest jeden bardzo ważny element, że jak się przemigrują, to nie będą mieli całej listy po migracji rzeczy, które nie działają. Że to będzie musiało wyglądać tak, oni lokalnie sobie zmieniają, przygotowują się, weryfikują i potem po zmianie, po dostosowaniu starego przechodzą na nowy, żeby nie mieć debugowania czemu nie działa przez jedno albo drugie.

Łukasz Kałużny: Jedna taka rzecz, którą można zrobić, te polityki, które wymusisz na nowym, możesz włączyć w trybie audytowym na starym.

Szymon Warda: Przydaje się, ale to też musi być per zespół, żeby oni tego byli świadomi, bo jak włączysz, to będziesz miał całą listę rzeczy do ogarnięcia, na które nikt nie zobaczy i utoniesz w nadmiarze informacji.

Łukasz Kałużny: No nie, to trzeba paluszkiem, o tak, ten resource, ta rzecz włączona.

Szymon Warda: Dobra, czyli zrobiliśmy bezpieczeństwo, zrobiliśmy polityki i mamy nowe tagowanie, mamy ładnie ogarnięte komunikacje i tak dalej. To w takim razie jak podejść w ogóle do porządków tak naprawdę? Czyli mamy blok 4, czyli jak to w ogóle będzie wyglądało czasowo, żeby sobie uświadomić. Bo mówiliśmy, że greenfelda możemy zrobić w 3 miesiące. A teraz dochodzimy do realiów brownfielda, czyli to się ciągnie miesiącami. Czyli realnie ile, tak z naszego doświadczenia, jak to wygląda?

Łukasz Kałużny: Nie chcę rzucać teraz dokładnie liczb ze skali, ale powiedzmy sobie, że inwentaryzacja, to jest około 1 faza inwentaryzacyjna, to będzie od miesiąca do dwóch prawdopodobnie.

Szymon Warda: I nie róbcie tego w wakacje. Czemu? Nie wiem czy pamiętasz, kiedyś była taka sytuacja, że ktoś wypuścił maila inwentaryzującego w wakacje i okazało się z opcją, że jak nie, to usuwamy za 2 tygodnie i owner był na wakacjach. No i maszyna poszła produkcyjna, poszła do kosza delikatnie nazywając to.

Łukasz Kałużny: Zdarza się. Ale słuchajcie, jak teraz popatrzymy, więc ta inwentaryzacja tego wszystkiego… Szymon, w zeszłym roku akurat to był projekt Kubernetesowy a nie cloudowy, ale zobacz ile tygodni zajęło dowiedzenie się, kto jest właścicielem którego name space’a i aplikacji w dużej organizacji.

Szymon Warda: Nie wiem czy pamiętasz inną inwentaryzację w pewnym banku też, która też się ciągnęła prawie dwa miesiące i to było tylko kilka systemów.

Łukasz Kałużny: A tak, dokładnie, więc to słuchajcie taki właśnie powiedzenie sobie kto jest w ogóle za co odpowiedzialny, kto za co płaci. Jeżeli były, na przykład nie było to zrobione, to jest problem. I teraz jest ciekawa rzecz, która z tego też jest taki wniosek, że bardzo często słyszymy, że wiemy, kto jest właścicielem i nagle się okazuje, że ten właściciel, on za ten system, za to rozwiązanie już od dawna, manager już dawno nie ma u siebie tego w portfelu.

Szymon Warda: Albo osoba, która za to odpowiadała, już dawno nie pracuje i nie ma to właściciela.

Łukasz Kałużny: Tak, tylko że ludzie obsługują tickety na zasadzie mam uprawnienia to naprawiałem na przykład.

Szymon Warda: Zgadzam się, jak najbardziej. Jeszcze jedna rzecz, przy inwentaryzacji przydaje się spisanie czy to jest deploy’owane z CI/CD jakiegokolwiek. To jest fajna wiedza, którą warto pamiętać.

Łukasz Kałużny: Ja o tym już zapomniałem, ale w tym… Słuchajcie i teraz jest dowcip. Gdzieś w firmie, na przykład w ramach czegoś mamy, powiedzmy, że szkolimy z Gita na przykład przy okazji projektu. Więc ten dowcip na temat od strony, że coś zostało wyklikane w portalu, on jest ciągle, ciągle żywy. Tak, mina Szymona przerażona.

Szymon Warda: Więc idziemy. Pierwsze to jest inwentaryzacja - miesiąc, dwa. Zgadzamy się jak najbardziej. Potem mamy tą pierwszą fazę kiedy przechodzimy, usuwamy, patrzymy co się dzieje i tak dalej, i tak dalej. Miesiąc lekką ręką.

Łukasz Kałużny: Tak, czyli patrząc się, czyli to jest jedna rzecz, sprzątanie osieroconych, do tego co się nikt nie przyznał i ustalenie właścicieli kosztów inwentaryzacji dostępów w tym. I potem tak naprawdę przygotowujemy greenfielda, to cofacie się do tego odcinku, i tu pojawia się tak naprawdę migracja pilotażowa.

Szymon Warda: Ja bym podzielił, że pierw robimy fundamenty, tak zwany Greenfield, a potem robimy ładną, pilotażową, czyli wybieramy jakieś przychylne, aktywnie rozwijany system, nie krytyczny, z kumatym zespołem i tak dalej. Ten wybór jest ważny, bo ten system będzie miał jakieś problemy, tam będzie się działo, to będzie taka robota trochę przód-tył, przód-tył.

Łukasz Kałużny: I oczywiście i to jest też taka rzecz, która występuje przy greenfieldzie od razu, wszystkie nowe projekty na to onboardujemy.

Szymon Warda: Od razu, tak.

Łukasz Kałużny: To jest taka rzecz, która musi być moment, że bałagan nie wpuszcza, jeżeli nowe powstaje, to nie wpuszczamy.

Szymon Warda: Dokładnie. Więc teraz idziemy dalej. Potem, jak już te pierwsze 2, 3 systemy przemigrowaliśmy, czyli mamy taki proof concept, udowodniliśmy, że to działa, zmieniliśmy parę rzeczy, dostosowaliśmy do wewnętrznych wymagań i tak dalej. Potem mamy skalowanie, czyli tworzenie planu migracji wszystkiego pozostałego i patrzenie… Tutaj w ogóle by się kav przydał tak naprawdę, patrzenie czy przy tej migracji my tam coś jeszcze musimy pozmieniać, uporządkować coś, czy robimy sobie… Łukasz przecież wiesz, że tam będą migracje też z on prema, no przecież to jest oczywiste w ogóle. To się przyda jak najbardziej. Czy robimy po prostu taki lift and shift, czy przenosimy to w trochę ładniejszy sposób, czy przenosimy na nowsze usługi, też może być, na przyklad z Kubernetesa na jakiegoś zarządzanego Kubernetesa. Te wszystkie inne zabawki, to by się też przydało w tym momencie ruszyć. I na koniec co? Governance i optymalizacja tak naprawdę. Czyli taki długi ogon sprzątania i zapewnienia, żeby to działało ładnie.

Łukasz Kałużny: Inaczej, i obiecujemy sobie, że nie dopuścimy znowu do tej sytuacji.

Szymon Warda: Tak. I robimy też takie wisienki na torcie typu fin opsy różne, jakąś rekomendację skalowania w dół, w górę i tak dalej.

Szymon Warda: Ale tutaj już wchodzi Greenfield. Tak naprawdę te same praktyki, które omówiliśmy przy greenfieldzie i tutaj w tym. I chyba trzeba sobie ten powiedzieć, co nie zadziałała w ogóle w tym brownfieldzie, w takim, że… Inaczej, Big Bang Migration.

Szymon Warda: Big Bang nigdy nie działa w niczym, nie oszukujmy się.

Łukasz Kałużny: Tak. To co, drugi. Naprawianie starego Terraforma.

Szymon Warda: Nie zadziała. Denaye na policies od dnia pierwszego, to po prostu wywalimy cały system i wylecimy z roboty. Tak to będzie wyglądało. I ten pilot jest bardzo ważny.

Łukasz Kałużny: Tak, migracja bez pilota, bez systemu, ja bym powiedział tak, bez właściciela, z którym mamy dobrą relację i który na przykład odczuł problemy tego burdelu, w którym żyje, to też jest idealny, który chce się z niego wynieść na przykład.

Szymon Warda: Albo taki, który po prostu chce się wykazać bardzo ładnie. I to też jest bardzo ważne - cierpliwość, komunikacja i poprawne umocowanie polityczne w organizacji. Bo taki Brownfield to jest projekt, który może się łatwo wywalić na twarz.

Łukasz Kałużny: Nie do polityka, do polityki.

Szymon Warda: Dokładnie. Spotkania regularne i całe plany co z tym robić. Spotkacie się z takimi rzeczami typu: u mnie działa. Po co my to robimy? Nie mam czasu. My to ogarniamy wszystko po swojemu i tak dalej. I tu Wam wchodzi cała kwestia motywacji ludzi, jak to by jednak ich nakłonić do współpracy? Siłą, znaczy kijkiem i marchewką mimo wszystko.

Łukasz Kałużny: Miałem ostatnio przemyślenie po co w ogóle jest change management? Ale niestety firma to takie duże liceum, duże przedszkole.

Szymon Warda: Bardziej przedszkole często. Dobrze.

Łukasz Kałużny: Dobra, raczej inaczej, jeżeli popatrzymy, to jest budowanie sobie też, chyba warto powiedzieć tutaj, tak naprawdę to jest budowanie koalicji. Czyli w zależności jak wygląda ta układanka w firmie, której może zależeć na chęci posprzątania. Często będzie gdzieś to bezpieczeństwo, ktoś odpowiedzialny za licencje, koszty, gdzieś management, w szczególności jeżeli były fuck upy, to łatwo dostać od strony managementu, tudzież jakieś ryzyko zacznie się materializować albo zbliżać.

Łukasz Kałużny: Regulacje prawne, chęć sprzedaży firmy, czyli tak zwanego exitu, to zawsze też jest dobra motywacja, bo to od samego zarządu wynika. Jest tego ogólnie rzecz biorąc dużo, będzie chodziło.

Łukasz Kałużny: Zgodnie z zasadą Pareto - 20% roboty, to w tym… Raczej przepraszam, te 80% sukcesu, czy tam jak to ten, odrzucić, to będzie największa rzecz, w której będziecie się babrać, to ludzie, polityka i komunikacja.

Szymon Warda: No i czasami jakieś raporciki. Dobrze, jak to w ogóle mierzyć? Mierzyć, ustawiać sobie cele. Ustawienia zasobów, ustalenia, otagowania, pilnowania kosztów, pilnowania zasobów, które są osierocone, nieużywane i tego typu rzeczy.

Łukasz Kałużny: Znaczy to jest faza tej inwentaryzacji, stabilizacji, tego początku, jak wchodzimy, czyli chcemy mieć 100% przypisanych właścicieli.

Szymon Warda: Tak.

Łukasz Kałużny: W 100% zinwentaryzowanych, pokrytych subskrypcji kont, w zależności gdzie tam jesteśmy. Potem w tym, liczba zasobów bez wymaganych tagów na brownfieldzie malejąca.

Szymon Warda: Jednak z założeniem, że dojdzie do zera.

Łukasz Kałużny: Tak, powinna. No i osierocone zasoby to jest zawsze problem z nimi. To powiedzmy, że realnie 95% powinna nie być osierocona, o tak.

Szymon Warda: Tym bardziej, że to jest też ryzyko bezpieczeństwa. Popatrzcie sobie na jakieś wycieki, to tak często była jakaś tam VM-ka, ktoś postawił i okazało się, że nagle coś wyciekło, bo miało otwartego RDP-a. Smuteczek. Dobrze, metryki fazy migracji. Przede wszystkim patrzymy na to, ile workloadów jest na nowej platformie. Cel? Do oszacowania organizacyjnie, ale to musi się wydarzyć ponad połowa w ciągu roku, bo inaczej projekt umrze po prostu, znaczy, że się nie dzieje.

Łukasz Kałużny: Nawet więcej niż. Teraz ważne, od momentu, teraz tak, ten rok, czas liczymy od momentu rozpoczęcia pierwszego pilota. To też trzeba taką rzecz sobie powiedzieć, że to nie jest w tym, bo jak sobie dodamy całego projektu nie, to dopiero od startu pierwszego pilota.

Szymon Warda: Tu nie wolno być zbyt takim pushy, ale też nie wolno dać sobie wejść na głowę, bo to po prostu umrze i się rozciągnie zbyt bardzo. Patrzymy ile zajmuje migracja poszczególnych aplikacji. To powinny być malejące, nie rosnące, bo znaczy, że coś tam mamy nie halo. I można jeszcze rzucić okiem na liczbę incydentów. Czyli patrzymy nie tylko ile trwa, ale też jak płynna jest ta migracja, jak dużo (…) problemów spełnia. Fajna metryka, żeby się pochwalić, żeby przekonać kolejne zespoły, które się opierają, że to nie jest taki ból.

Łukasz Kałużny: Tak. A potem zapraszamy do greenfieldu i posłuchania, co możemy mierzyć, bo to będzie dobry odnośnik w tym miejscu. I teraz tak, czego nie mierzyć?

Szymon Warda: Tu wchodzimy w całe metryki DevOpsowe, można powiedzieć, DevOps raportu tak naprawdę. Nie liczba, tylko po prostu idziemy jakościowo tak naprawdę, żeby to się wydarzyło. Problem jest z dojrzałością. Czy mierzyć dojrzałość? No to będzie, jak znajdziemy jakąś skalę, no to może nam się uda, ale raczej pewnie się nie uda.

Łukasz Kałużny: Czy wiesz co, to tak jak… Inaczej, to tak jak wspaniałe próby zrobienia algorytmu kiedyś tam lata temu: czy aplikacja jest gotowa na cloud?

Szymon Warda: A było takie coś, pamiętam, tak.

Łukasz Kałużny: To wszystko to jest takie, ale ludzie… Inaczej, to też trzeba powiedzieć, co do dojrzałości tych rzeczy trzeba, bo ktoś lubi oglądać siebie na tym, lubi oglądać te abstrakcje na PowerPoint i to trzeba też, będziecie zmuszeni do dostarczenia czegoś takiego. To jest taki element. I znajdziecie takie skale jako wzorce i można nią pokazywać i upchnąć pod spodem swoje cele.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Tak to nazwijmy.

Szymon Warda: Można spokojnie pokusić się o porównanie przed i po, jak ktoś chce, ale to się pewnie razem w czasie rozmyje, więc fajny pomysł, ale często się nie udaje, bo się świat i system zmieniły. Dobrze Łukaszu, to co? Podsumowanie, take awaye?

Łukasz Kałużny: Wiesz co, dla mnie najważniejsze take away, że trzeba zaakceptować jeden fakt. To tak jak, że każdy kod, który trafił do repo, jest legacy. Tak, każda taka chmura, każdy taki setup będzie w pewnym momencie bez inwestycji i bez dostosowywania, będzie zawsze i bez pilnowania przyjętych zasad, będzie zawsze brownfieldem.

Szymon Warda: Nawet jak zasady będziesz miał, to za chwilę będą wyjątki, o których mówiliśmy swoją drogą w poprzednim odcinku. To trzeba raz na jakiś czas robić. Ważne są polityki, ważna jest automatyzacja. I też chyba najważniejsze tu jest umocowanie odpowiednie i długotrwały plan na zrobienie tego, bo to nie jest krótka piłka.

Łukasz Kałużny: Tak, więc jedna rzecz w tym. Więc jak sobie popatrzymy, takie take away, to jest inwentaryzacja…

Szymon Warda: Która i tak się przyda.

Łukasz Kałużny: Tak, żeby mieć. Jeżeli tylko się da, to nie rób in place, nie naprawiaj starego, tylko wrzuć na nowe. Dwa lata temu mieliśmy ciekawą, to jest akurat przy małym przypadku, bo tam dało to się zamknąć w dwa miesiące. Ale posprzątanie było w tym, przeniesienie tam systemów na nowe środowisko było cztery razy prostsze niż posprzątanie, dosłownie.

Szymon Warda: Wiem o którym mówisz. Dobra. I co tak naprawdę?

Łukasz Kałużny: No i 80% to są…

Szymon Warda: Ludzie, jak zwykle i przygotowanie się na to, że to się będzie ciągnęło. Dobra, nie przedłużając, chyba tyle na dzisiaj.

Łukasz Kałużny: Trzymajcie się, na razie.

Szymon Warda: Pa pa.