Łukasz Kałużny: Więc takie projekty na zasadzie nadal istnieją i mogą mieć dwa powody.

Szymon Warda: I od razu mówię, stworzenie macierzy RACI to jest rzucenie granatu w organizacje.

Łukasz Kałużny: Zazwyczaj to są niestety bardzo nudne warsztaty, w których przepraszam za określenie, ale zaczyna się naprawdę duża napierdalanka.

Szymon Warda: Tagi są niewyobrażalnie ważne, są też absurdalnie nudne w realizacji. I tu się zaczyna prawdziwa napierdzielanka z zespołami, żeby wszyscy ustalili te tagi.

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

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka - góra, dół, prawo, lewo, Patoarchitekci.io, ogarniecie, wierzymy w Was.

Łukasz Kałużny: Dobra, to lecimy, bardzo szybkie ogłoszenia. Pierwsza rzecz, przypominamy o szkoleniach. Moje - Architektura, Agenci MCP. Szymon - cała seria, ma zaplanowaną do czerwca, Observability w różnych wydaniach od początku do bardziej dziwnych, zaawansowanych rzeczy.

Szymon Warda: Tak, przez alerting, jak tego użyć i jak zaoszczędzić grube dziesiątki, setki tysięcy dolków w skali roku i nieużywania wielkich dostawców, albo kiedy używać.

Łukasz Kałużny: Tak, miejsca się kończą, więc lepiej się zapisywać. Na stronie Patoarchitekci.io znajdziecie szkolenia.

Szymon Warda: Tym bardziej, że widzimy, że na koniec roku trochę sporo ludzi zakupiło. Więc tak, kończą się.

Łukasz Kałużny: Dobra. Druga rzecz, konferencja z okazji 200 odcinka. Też sprawdźcie na naszej stronie jak to będzie wyglądało. Widzimy się fizycznie w Warszawie 16 czerwca z bardzo fajnym widokiem na miasto.

Szymon Warda: Tak, więc jak już fizycznie, to pewnie obiecuję będziemy mieli spodnie założone. Nie to, co teraz.

Łukasz Kałużny: Nie, założyłem, dresowe bo dresowe, ale i nie od piżamy.

Szymon Warda: I tak nie wierzę.

Łukasz Kałużny: Dobra, to co, dzisiaj odcinek o chmura at Scale Greenfield. Pytanie z Discorda od Kuby - jak do tego podchodzić? I tam oryginalne pytanie było: jak wdrożyć chmurę w dużej skali, cały governance i security rozbite na kawałki, control policies C, Cloud Security Posture Management sieci, Identity, wspólne komponenty, moduły, koszty, od czego zacząć? Co może poczekać? I jeszcze Cię Szymon przegadam w tym momencie, bo Ziemek, pozdrawiam, który wrzucił, że: to w końcu Greenfield czy w dużej skali? I zabawa polega na tym, że nawet jakiś czas temu, już po zadaniu tego pytania, ofertowaliśmy jednego klienta, który jest duży i na przykład nie ma Azure’a i będzie trzeba taki Greenfield zbudować. Więc takie projekty na zasadzie nadal istnieją i mogą mieć dwa powody. Jedna to jest Greenfield, bo dana chmura nie jest, na przykład chcemy je wprowadzić do portfolio w firmie. A druga, niektórzy sprzątają też na rynku, już mamy projekty sprzątania Brownfieldu przez podstawienie Greenfieldu obok.

Szymon Warda: A ja się doczepię, bo to zależy od definicji. Bo ok, stawianie Azure’a, że tam jest green, może być. Ale wchodzisz i co? Nawet dotkniemy w tym odcinku, to jest to, że jak dotykasz integracji z on premem, który już tam istnieje, to już nagle zaczynasz bawić się trochę brown, bo musisz to wszystko ze sobą połączyć i tak dalej. Więc…

Łukasz Kałużny: Zawsze… Inaczej, w większości przypadków…

Szymon Warda: Jest greenish bym powiedział. Nie do końca (…).

Łukasz Kałużny: Inaczej, Szymon, zawsze będzie… Złośliwie możemy powiedzieć, że w takich scenariuszach zawsze będzie sieć i tożsamość.

Szymon Warda: Znaczy można powiedzieć, że w tej zielonej trawie czasami się w coś wdepnie. Bywa.

Łukasz Kałużny: I to jest najmniej spodziewana kupa.

Szymon Warda: Dokładnie tak.

Łukasz Kałużny: To co, zacznijmy od tego, ja bym rzucił taką moją główną tezę, że… Inaczej, zawsze to będzie. Jeżeli jesteśmy już kawałkiem większej organizacji, to zawsze to będą obszary ownership i podział obowiązków.

Szymon Warda: Tak, czyli ogólnie zrobienie, ustalenie racji i inwentaryzacji. Jeżeli mówimy o greenie to tam nie do końca to wchodzi, ale jak już będzie inwentaryzacja kto co chce, kto by co chciał i jak to ma wyglądać i tak dalej, czyli spotkania, spotkania, spotkania.

Łukasz Kałużny: Spotkania, tak. I tak, pierwsza rzecz co oznacza at scale, bo to w ogóle była rzecz, którą definiowałem, bo z jednej strony był ten odcinek też o platform engineeringu z perspektywy też pytania z Discorda, to był 166, gdzie że każdy robi po swojemu, wszystko leży. I u mnie taka pierwsza definicja, która była chamska, to było, że tu Pizza team, czyli ten sławetny team, którego nakarmisz dwoma pizzami jak u Bezosa w Amazonie, przestaje ogarniać całość.

Szymon Warda: Ja bym powiedział bardziej, że… Bo to zakłada tą opcję, że masz zespół, który ogarnia całość. A jeszcze masz tę sytuację, kiedy masz dużo zespołów i każdy ogarnia swój własny ogródek i rachunek rośnie.

Łukasz Kałużny: Tak i to się zaczyna, wiesz, i to jest właśnie teraz, zaczyna się, czyli właśnie to, co tam…

Szymon Warda: Skala jest taka, że boli Cię rachunek za dostawcę chmurowego.

Łukasz Kałużny: Raczej najczęściej jest to tak, czyli wiele zespołów, różne potrzeby razy standard i governance tak naprawdę można to sobie nazwać, który trzeba sprzątnąć.

Szymon Warda: Tak, to też z reguły często wynika z tego, że na przykład załóżmy zespoły się zmieniają, projekty się zmieniają i nagle ten taki bagaż rzeczy nie usuniętych, nie posprzątanych i tak dalej, nam rośnie i nagle stwierdzamy okej, kto za to płaci i z czego wynikają te rachunki?

Łukasz Kałużny: Tak. A wracając do perspektywy, bo to jest trochę brownfieldowa, a greenfieldowa oznacza przy takim at scale, że jesteśmy narażeni na ryzyko powstania bardzo szybko tego burdelu. Bardzo szybko w takim korpo powiedzmy, to jest w ciągu roku.

Szymon Warda: A jeżeli zakładamy, że będziemy mieli migrację z czegoś na coś, z reguły z on prema na coś, to może być nawet szybciej, w pół roku się może wydarzyć.

Łukasz Kałużny: Dobra, to co, kiedy Szymon zaczynamy z tym governancem? Kiedy warto to robić? Bo to było Twoje troszeczkę teza.

Szymon Warda: Kiedy zaczynać? Wszystkie wymagania prawne, czyli mamy rynek regulowany, jakiekolwiek mamy regulacje prawne, mamy dane, które dochodzą prywatnie, kiedy musimy się upewnić, że jeżeli wejdziemy do chmury, to sobie nie strzelimy w kolanko, albo jeszcze gorzej, sytuacjami, że nam dane wyciekną, wrzucimy dane produkcyjne, dane poufne i tak dalej, i tak dalej. To jest ta sytuacja, kiedy…

Łukasz Kałużny: Tego niestety jest kurde coraz więcej i to jest smutne.

Szymon Warda: Regulacje, regulacje.

Łukasz Kałużny: Tak, każdy, coraz bardziej dostajemy.

Szymon Warda: Kolejna opcja, kiedy robimy, planujemy przeniesienie większych systemów albo większej ilości małych systemów do dostawcy chmurowego. Czyli to o czym Ty mówiłeś, że bałagan, żeby nie powiedzieć pierdolnik, pojawi nam się bardzo szybko.

Łukasz Kałużny: Tak, to jest najgorsza rzecz. Ja bym jeszcze tak dorzucił z tym governancem, to to są te wszystkie sytuacje Merger and Acquisition, czyli wszystkie zakupy, przejmowania, konsolidacje, tym. I to jest kurde, ja to teraz u jednego klienta widzę, przygotowania pod to, kiedy będzie miał być wciągnięty. Jeżeli druga strona nie ma dobrego governance’u, a chce narzucić swoje podejście, to robi się pierdolnik, o tak, użyjmy tego słowa.

Szymon Warda: Kolejna sytuacja, kiedy mamy istniejącego rozbudowanego on prema i łączymy go z chmurą. Tu nie uciekniemy, bo będziemy musieli ogarnąć sieci, dostępy, firewalle i wszystko inne. Sorry, to będzie musiało istnieć.

Łukasz Kałużny: Więc to tak. I teraz powiedzmy sobie, że to jest też pewien moment, który… To są różne podejścia. Mieliśmy bardzo dużą dyskusję przed tym, o czym opowiadać, jakim rozmiarze. I to nie jest mała firma, która ogarnie wszystko na standupie z rana, co się dzieje.

Szymon Warda: To jest w ogóle ciekawe pytanie do słuchaczy - czy chcielibyście mieć odcinek o czymś, co jest mniejsze i takie sensowne podejście do chmury w skali odrobinę mniejszej? Jak chcecie - komentarze, maile, Discord zapraszamy.

Łukasz Kałużny: Dobra, przejdźmy sobie do bloku drugiego, który jest, czyli najgorszej części, to jest odpowiedzialność.

Szymon Warda: Czyli papierkologia. To co mówimy wielokrotnie: technologią nie rozwiążemy problemów organizacyjnych. Możemy je przykryć, ale to i tak wybuchnie, wybije.

Łukasz Kałużny: I trzeba sobie odpowiedzieć tak, jak teraz popatrzymy sobie, z tej oferty wyciągnięte, my podchodzimy do tego, to jest nasze podejście, że niestety trzeba stworzyć RACI i DACI. DACI jest na czas projektu, potem już idzie RACI, w zależności jak popatrzymy. I RACI to jest Responsible, czyli kto robi, Accountable, kto odpowiada, Consulted, to jest kto jest konsultowany i Informed, czyli osoby, którą… To też jest ważne, że nie wszyscy powinni być Consulted, to jest największa wada.

Szymon Warda: Oczywiście.

Łukasz Kałużny: Bardzo często Informed, czyli osobę, którą informujemy, ale nie ma wpływu na nasze decyzje. I to jest taka bardzo rzecz, którą trzeba bardzo świadomie nie używać Consulted.

Szymon Warda: I od razu mówię, stworzenie macierzy RACI to jest rzucenie granatu w organizacje, bo to jawnie mówi, kto za co odpowiada i kto ma do czego prawo. I przygotujcie tu się na napierdzielankę jak nie wiem co.

Łukasz Kałużny: Tak i potem jest jeszcze projektowo. Jest tak naprawdę ownership projektowy, czyli DACI, Driver - prowadzi, Approver - zatwierdza, Contributor - wspiera, Informed - jest informowany. I teraz tu jest największa rzecz, trzeba uważać z Approverem i Contributorem. To są dwie takie od razu uwagi. I jak popatrzymy na obszary, mi się rzucają 3 takie rzecz, 3 myśli: kto odpowiada za sieć, tożsamość, polityki, bezpieczeństwo, koszty.

Szymon Warda: I bym tu dorzucił jeszcze jedną rzecz: sekrety.

Łukasz Kałużny: Ty wiesz co, ja to trochę lecę w politykę. Tutaj lecę to jako tą część bezpieczeństwa.

Szymon Warda: Ja organizacyjnie w tym sensie pomyślałem bardziej, że kto uzupełnia Key Vaulty, żeby zespoły miały dostępy i tak dalej.

Łukasz Kałużny: Tak, jak se pójdziemy potem, to jest tak, kto tworzy właśnie subskrypcje, accounty, w zależności tam u jakiego jesteśmy dostawcy, jak to wygląda? I największy ból dupy proszę państwa, kto zatwierdza i w jaki sposób wyjątki od tego? Bo Szymon, te 20% przypadków generuje 80% problemów.

Szymon Warda: Ja się z Tobą w zupełności zgodzę i doskonale sobie zdaję sprawę, że to pokrycie będzie, tak, nawet jak pokryjesz te 20, to zawsze kawałek zostanie powiedzmy dalszy. Z wyjątkami to jeszcze zależy od środowisk i tak dalej, i tak dalej, bo to nie jest takie czarno-białe.

Łukasz Kałużny: Weźmy na przykład… Inaczej, wiesz co, ja wezmę, rzucę Ci przykład, żeby wszystkim uzmysłowić. Nałożyliśmy polityki bezpieczeństwa i je wymuszamy. I coś nam nie działa przez to wymuszenie. Wiesz, że stykamy się u klientów z tym, to jest chleb codzienny. I to jest powiedzenie sobie, kto i w jaki sposób będzie zrobione odstępstwo od polityki.

Szymon Warda: Znaczy,dorzucę jeszcze dwie rzeczy odnośnie samego RACI. W ogóle mieliśmy o tym odcinek, nie wiem, czy pamiętasz?

Łukasz Kałużny: Było coś kiedyś, poszukamy.

Szymon Warda: Było, był odcinek omawiający właśnie RACI. To tam jest jedna myśl, która była tam bardzo ważna, to był fakt: RACI ma być upublicznione gdzieś, żeby wszyscy dokładnie wiedzieli jak to wygląda, a nie ukryte na mailu. To jest taka mała pierdoła. Czemu o tym mówię? Bo wyjątki będą też wynikały z RACI.

Łukasz Kałużny: Tak i procesu, który mamy. Dobra, czyli co? Jak to mamy, i to jest w ogóle pierwsza rzecz, którą tak jak Kuba pytał, to jest w ogóle pierwsza rzecz, którą robimy, nie siadamy do planowania, tylko od odpowiedzialności. I ważne, że, jedna jeszcze jest taka moja z praktyki wrzucenia granatu, bo to są, zazwyczaj to są niestety bardzo nudne warsztaty, w których przepraszam za określenie, ale zaczyna się naprawdę duża napierdalanka.

Szymon Warda: Każdy walczy o swój obszar, dokładnie tak.

Łukasz Kałużny: Tak, więc warsztaty z interesariuszami i stamtąd nie powinny być ciągnięte całe zespoły, tylko w tym RACI powinny być wyznaczone, osoba główna i ją zastępująca i koniec. I nie wciągniemy więcej osób, bo im więcej osób na spotkaniach, tym jest gorzej. Po prostu, tym jest gorzej.

Szymon Warda: Tak, wchodzi jego i nie inaczej. Dobrze. Śmigamy do bloku trzeciego. Czyli jak wyglądałby taki scenariusz? Co właściwie robimy?

Łukasz Kałużny: Dobra, czyli pierwsza to jest w ogóle ta struktura organizacyjna, czyli to, co tak naprawdę nazywamy governancem. Czyli to jest tak naprawdę w zależności, jak podchodzimy, ja to sobie teraz połączę, to jest podejście, strategia, jak podchodzimy, w zależności od cloudu, bo te usługi nazywają się różnie, w jaki sposób podzielimy sobie strukturę organizacyjną kont, subskrypcji, czyli takie z lotu ptaka, w jaki sposób to pójdziemy. Bo mamy różne limity soft card, rzeczy kosztowe, więc trzeba patrzeć sobie, to z perspektywy swojej chmury, mówiąc agnostycznie teraz. Niestety w Azure to są na przykład management grupy, które na przykład dzielimy produkcyjnie, nieprodukcyjnie, a i bawimy się potem z podziałem, subskrypcjami.

Szymon Warda: I czemu to jest ważne? Będę uzupełniał, że fajnie, OK, robimy. Czemu? Wszystkie polityki będą do nas spływały, kosztowe rzeczy. Widoczność, to jest, zgodzę się z Tobą, jeden z najważniejszych kroków. Co więcej, on też jest dość łatwy inicjalnie, bo on będzie w miarę odpowiadał strukturze naszej organizacji. Potem będzie organizacja, działy, potem projekty i tak dalej. Ale to też wpływa na to generalnie jak dzielimy koszty, jak dzielimy widoczność, kto za co widzi i otagowanie ownerów i tak dalej. Super ważna rzecz i musi być.

Łukasz Kałużny: Następna rzecz, ból dupy w IT, zawsze to jest numer jeden problemów w każdym dowcipie, czyli konwencje nazewnicze.

Szymon Warda: To ja wyjaśnię czemu to jest ból dupy często. Bo, też tak możesz uważać, to jest to, że często konwencje robią zespoły, które potem tego nie używają i są zbyt długie. Pilnowanie długości, wyjątków, ustaleń, kto co widzi, jakie projekty czego potrzebują, kto czego używa. I to jest rzeźnia i to z reguły też się będzie zmieniało, jak już zacznie być używane, albo weryfikowane przez zespoły.

Łukasz Kałużny: Inaczej, i jest jedna rzecz taka, którą, to jest dobra i to jest rzecz z naszej praktyki, po prostu bierzemy, w przypadku Azure’a bierzemy domyślną azure’ową konwencję nazewniczą, delikatnie, naprawdę delikatnie ją tune’ujemy w niektórych miejscach, koniec.

Szymon Warda: Tak.

Łukasz Kałużny: Nie wymyślamy swojej, z daleka.

Szymon Warda: I część rzeczy może być też używane jako tagi. Nie wszystko musi być w nazwie. Moja taka mała uwaga.

Łukasz Kałużny: Dokładnie i świetnie, że przeszedłeś…

Szymon Warda: Płynne przejście.

Łukasz Kałużny: To następna rzecz, tak, płynne przejście. Lecimy! Strategia tagowania zasobów. I to jest kolejna rzecz, którą trzeba zrobić. Tagi pod cost, allocation, pod, być może potem, jak mówimy w skali, to prawdopodobnie pod podpięcie się pod jakiś serwis na UCMDB. Czyli to są wszystkie rzeczy, które chcieliście upchnąć w nazwie, a nie powinniście. Tak bym zdefiniował tagi.

Szymon Warda: Tagi są niewyobrażalnie ważne, są też absurdalnie nudne w realizacji. I tu się zaczyna prawdziwa napierdzielanka z zespołami, żeby wszyscy ustalili te tagi, żeby były, żeby nie były jednorazowe, żeby one nie zniknęły, żeby dodać je do CI/CD i do wszystkich innych rzeczy.

Łukasz Kałużny: Do polityk i innych rzeczy.

Szymon Warda: To jest rzeźnia organizacyjna, to się będzie ciągnęło jak smród, po czym, wiadomo.

Łukasz Kałużny: Dobra. I teraz rzecz, która…

Szymon Warda: Ale bez niej niewiele zrobimy dalej.

Łukasz Kałużny: Inaczej, i teraz granat, bo trzeba przełożyć model uprawnień na model uprawnień w danej chmurze. Czyli musimy przełożyć airbacka i odpowiedzialności na to, co zezwalamy, na to, jak zaimplementujemy tego airbaga, czyli fizycznie określamy sobie, kto co będzie mógł robić. Czyli nie wszyscy są ownerami, o tak. Jedna rzecz na przykład od strony Azure’a, ja uważam, że reader plus potem PIM do podbijania uprawnień i określenie sobie możliwości w jaki sposób podbijamy, eskalujemy uprawnienia poprzez PIM-a. I to jest dla mnie taka rzecz, której się będę trzymał.

Szymon Warda: Ja doprecyzuję. Mówisz o środowiskach produkcyjnych. Na developerskich jednak z całym szacunkiem… Znaczy na developerskim, Contributor do resource grupy się przydaje, przynajmniej na wczesnych obszarach.

Łukasz Kałużny: Raczej tak, tutaj z Tobą będę, jak popatrzę, konto serwisowe powinno mieć na przykład możliwość dodawania uprawnień, żeby Terraform… Bo będzie, ewentualnie możemy nadawać ownera, przyciętego na przykład w Azure, można dodać ownera, który może przyciąć mu uprawnienia, żeby nie mógł nadać innym ownerów. Przykładowo obciąć mu możliwość do jakichś ról, które dozwalamy.

Szymon Warda: Dla mnie, ja bym to jednak stopniował, powiedzmy sobie, tylko załóżmy możliwość korzystania przez portale, (…) na Bloba i tak dalej.

Łukasz Kałużny: Dobra, raczej w sensie mogę nadawać ownera, ale z ograniczonymi, że tak powiem, uprawnieniami, czyli obcinamy. Bo chodzi o to, że owner może powodować ciekawe wycieki danych.

Szymon Warda: Tak, dlatego mówię obcinane względem dojrzałości softu. Ale na produkcyjnych, jak tam będzie, z Tobą się zgodzę, airbag poucinany i PIM wszędzie, gdzie tylko możemy, a szczególnie już na częściach hubowych i wspólnych, tam to już w ogóle nie ma dyskusji.

Łukasz Kałużny: Tak, przy czym jedną rzecz, którą z praktyki, na części, jak jesteśmy przy części hubowej, dobrze jest, żeby jednak wszyscy mieli dostęp do logów na przykład z firewalla, żeby nie zawracali dupy czy coś ich nie przycina. I to jest taka rzecz, którą też praktykujemy. Tłumaczymy klientom, że warto by było, żeby na przykład developer wbrew pozorom, czy DevOps, który nie zajmuje się, jest w projekcie jakimś, a nie zajmuje się tym hubem, mógł wejść i w jakiś sposób zobaczyć logi, że coś go ubija. To jest bardzo przydatne.

Szymon Warda: Czyli nie chcesz żeby były, cała lista ticketów pod tytułem nie widzi, nie może się skomunikować i tak dalej? To jest taka fajna lista takich elementów.

Łukasz Kałużny: Zabieramy pracę.

Szymon Warda: Dokładnie. Nie, nabijamy się. Czemu to jest ważne? Bo w całej sieci hub and spoke’owej, to ten ruch puszczamy właśnie ze spoke’a, do spoke’a chcemy mieć, to puszczamy go przez huba. Co nam implikuje to, że faktycznie ten firewall będzie musiał być widoczny i będzie musiał być, będzie musiał tam istnieć, bo będziemy filtrowali ten ruch. Dobra, więc słuszna uwaga.

Łukasz Kałużny: Dobra, zazwyczaj zaczynamy od hub and spoke’a w jednym regionie i teraz jest tam problem, że potem architektura naturalnie może nam się rozrosnąć, że tych hub and spoke’ów będziemy mieli per region na przykład, bo znamy w zależności od skali, nie będzie jedna. Więc jedna rzecz, o której tutaj przy sieci, to jest: proszę, nie idźcie. Mamy klienta, który na przykład posiada współdzielone subskrypcje i w każdej dedykowanego firewalla. Jest masakra. I dowiadujemy się rzeczy, o których Microsoft na przykład nie śnił w ticketach i troubleshootingu i cieknącym ruchu w dziwnych miejscach, wyciekającym ruchu z usług na przykład takich setupach. Więc jedna ważna rzecz na początku, od razu robimy hub and spoke’a z centralnym firewallem do inspekcji. I tutaj powiem rzecz taką, polecamy zawsze zacząć z Azure Firewallem. A jeżeli mamy firmę silosową, no to przykro mi, wrzucamy sobie firewalla, którego lubi Wasz dział sieciowy i koniec. Albo ma, żeby mieć jedno portfolio. Wiem Szymon, nienawidzisz tego, ale taka jest. Jeżeli w zależności od tego jak wygląda nasze RACI. Mamy sukcesy automatyzacji takich firewalli przykładowo w naszych projektach, żeby to scentralizować. Raczej scentralizować konfigurację, na przykład pozwolić wrzucać pull requestami i innymi rzeczami. Ciekawostka, takie rzeczy też robimy w on premie z checkpointem. To też jest w ogóle, że możemy zautomatyzować terraformem on prema i checkpointa w on premie.

Szymon Warda: Ja bym to doprecyzował, bo okej, zgodzę się, faktycznie użycie istniejącego firewalla sporo upraszcza. Automatyzacja tak, robimy. Pytanie moje jest takie: czy faktycznie to co, żeby nie pójść, że korzystamy z tego, bo to mamy i tylko to jest jedyny powód, rewaluacja, czy faktycznie nie przesiąść się na firewalla azure’owego? To uprości dużo rzeczy jeśli chodzi o integracje, komunikację, automatyzację. Doskonale o tym wiesz.

Łukasz Kałużny: I szybkość. Tak. Szybkość, tak. Dlatego mówię, że dla mnie… Wiesz, w projektach mamy first choice, jest zawsze u nas Azure Firewall, a potem, jeżeli jest…

Szymon Warda: Tu się zgodzę.

Łukasz Kałużny: Tak. I w sumie teraz ja, tak jak myślę, żaden nie został przemigrowany na appliance. We wszystkich… Żaden.

Szymon Warda: Wiem. To jest prawda, dlatego właśnie zwróciłem na to uwagę.

Łukasz Kałużny: Dobra i teraz rzecz, która jest, zawsze będzie połączenie z on premem.

Szymon Warda: Bo mówimy o dużej organizacji. Ona z reguły ma coś na on premie. I to będzie istniało.

Łukasz Kałużny: Dobra, i teraz tak, pierwsza rzecz, zaczynamy od VPN-a, żeby było szybko. Jeżeli to jest duża migracja, prawdopodobnie od razu wchodzicie w ExpressRoute’a.

Szymon Warda: Którego trzeba dać wcześniej, bo to trochę zajmie.

Łukasz Kałużny: Tak. I słuchajcie, ten lead time, tak, to jest, da się to wdrożyć, odkąd jest kabel w serwerowni da się to zrobić w ciągu tygodnia. Kabel w serwerowni i subskrypcja gotowa.

Szymon Warda: Ale trzeba mieć kabelek.

Łukasz Kałużny: Tak i to jest chyba taka rzecz i wymaganie to są, będą, najczęściej to jest duży traffic SLA i ewentualnie opóźnienia jeżeli chodzi o integracje.

Szymon Warda: I jeszcze wymagania regulacyjne wszelkiej maści mogą być.

Łukasz Kałużny: Ale to już trochę mniejsze. Dobra. O kurde, teraz…

Szymon Warda: DNS-y, piękne, wspaniałe DNS-y.

Łukasz Kałużny: Właśnie chciałem powiedzieć, przypomina mi się Cloudflare’owe haiku. To nie był DNS, to był DNS.

Szymon Warda: Czemu się nabijamy z tego? Bo z reguły jak już mówimy, że mamy on prema, to na on premie z reguły mamy jakiegoś DNS-a, mamy rzeczy, które skoro będziemy pewnie mieli ExpressRoute’a, a będziemy mieli VPN-a, to w tym momencie będziemy mieli komunikację z Azure’a do on prema, z on prema do Azure’a, chcemy, żeby była bezpieczna. I zaczyna się cała zabawa w tym momencie na firewallu, fallbackach DNS-owych i tak dalej. I jest tu spora szansa na położenie wielu aplikacji, ponieważ co? Z reguły developerzy nie myślą, nie interesuje ich i…

Łukasz Kałużny: Ma działać.

Szymon Warda: (…) cały DNS.

Łukasz Kałużny: Tak, więc są 3 elementy, które trzeba zrobić. To jest centralizacja DNS-u po stronie chmury. To jest taka jedna rzecz i tych prywatnych stref. I potem druga sprawa, resolving pomiędzy on premem a chmurą, czyli żeby on prem potrafił na te wszystkie private niki inne rzeczy rozwiązać poprawnie, a z drugiej strony, żeby chmura potrafiła się zapytać On ma swoje strefy.

Szymon Warda: I przygotowanie tego, żeby wszystkie spółki ładnie mogły komunikować się reguły, uprawnienia i tak dalej, bo centralne będą musiały mieć dostępy już tożsamości nagle nie stają się takie proste, musiały mieć cross subskrypcyjne dostępy i tak dalej, i tak dalej.

Łukasz Kałużny: Kolejna rzecz mikro segmentacja, bo prawdopodobnie happenspo to będziemy mieli spółki. I tutaj powiedzenie sobie po całości ja bym to teraz zmniejsza sobie do dwóch takich elementów. Szymon z naszej wyliczanki. Pierwsza rzecz to jest trzeba jak podchodzimy do ruchu zespołów, do innych zespołów i do Prime u, czyli jak filtrujemy ruch do internetu i pomiędzy projektami. Oraz drugie pytanie jak filtrujemy ruch w projekcie w naszym subnecie, w necie w zależności od tego jak podchodzimy i nasze podejście jest takie ruch do internetu powinien iść centralnie przez centralnego firewalla. W środku subnetu powinno być to wymuszone, żeby nie dało się wyjść z internetu i do internetu poza przypadkami tam wystawienia aplikacji. I to pomińmy, bo to jest dostawca cloudowy. Się rozwiązuje ten problem i rzecz, która jest problematyczna. Czy robimy mikro segmentację w projekcie, czy nie. I to jest rzecz bardzo długa i dyskusyjna. Wiesz o czym mówię.

Szymon Warda: Wchodzi cała dyskusja odnośnie tego, jak robić wyjścia z on prema, czy na przykład, bo tam się pojawiał jakiś API i inne rzeczy i się komplikuje jeszcze bardziej. Jak ten ruch robić i gdzie jest punkt wyjścia.

Łukasz Kałużny: Tak więc inna rzecz mikro segmentacja już w samym tym samym projekcie, czyli na przykład network tej grupy na waszych subnetach. Nie zawsze to w zależności od podejścia. Jeżeli chodzi o centralny ruch to powinien być kontrolowany co do niego wchodzi i wychodzi i zero dostępu do internetu oprócz centralizacji.

Szymon Warda: Tak. No to śmigamy do kolejnych ciekawych rzeczy. Mianowicie to co polityk pierwszeństwo.

Łukasz Kałużny: O Boże hehehe. Dobra, słuchajcie i tak powiem jedną rzecz całościowo nie wymyślajcie niczego na nowo. Zaczynamy od tego, że bierzemy gotowca od dostawcy.

Szymon Warda: Czy w ogóle W wielu przypadkach można powiedzieć, że bierzemy gotowca od dostawcy, bo to musi wcześniej to też istnieją szablony, istnieją.

Łukasz Kałużny: Akceleratory, tylko tam trzeba zrobić cherry picking.

Szymon Warda: Właśnie. I tu wchodzimy do tego, że ten cherry picki może zamienić się dość wredny i możemy wyciąć co po pierwsze potrzebujemy, po drugie jak wytniemy, a nagle okazuje się, że wycinamy całe drzewo albo inne rzeczy tego potrzebują, więc Piknik nie jest wcale taki super łatwy.

Łukasz Kałużny: Znaczy inaczej to co mówimy nie jest łatwe, jest problematyczne. Cały ten temat jest projektem, który da się zrobić szybko. Jeżeli nie zachowujemy się jak płatek śniegu.

Szymon Warda: Nie jesteśmy unikalni. Dobrze polityki mamy cisowe security, benchmarki. Jak mamy ISO to też się trochę komplikuje, albo może nawet jest łatwiej, bo mamy procesy, więc to też jest fajne.

Łukasz Kałużny: Pierwsze bierzemy w tym raczej dwie myśli zaimplementujemy gotowe polityki do danego standardu i się tego trzymaj na starcie.

Szymon Warda: Tak pierw w trybie audytowym. Polecamy jednak mimo wszystko i dość szybko przejść na tryb design.

Łukasz Kałużny: Przy czym przy Greenfield ie można od razu wrzucić Dinah i po prostu odkręcać, jeżeli ten.

Szymon Warda: Racja.

Łukasz Kałużny: Odkręcać.

Szymon Warda: Jeżeli będzie mnie cały czas, cały czas ten brownfield z tyłu głowy straszy.

Łukasz Kałużny: Tak więc. Tak więc to jest w tym dobra. Druga sprawa odpalamy sobie poszczur management. Niestety w tym. I to jest cała taka rzecz zabawa z transferami logów do Sejmu, bo pewnie przy tej skali już będzie potrzebne centralizacji logów. Więc trzeba ogólnie z całej takiej zestawy Sękowej zobaczyć, czy my korzystamy na przykład z narzędzi, które już mamy, czy one się integrują z tym stosem i wykorzystujemy czy nasze security, czy z drugiej strony bierzemy natywne usługi, na przykład wywalamy te nogi na zewnątrz. Więc dwie rzeczy to jest tak na prawdę, żeby mieć logi audytowe, scentralizowane, do tego wrzucone to do siema albo gotowego od tego dostawcy cloudowego, albo do tego co już posiadamy do soku i village Identity management. Tutaj na samym końcu jak popatrzymy z takich najważniejszych myśli.

Szymon Warda: Tak odnośnie logów pytanie czy nie mamy wymagań odnośnie retencji tego i tak dalej, bo to też trzeba zadbać sobie miejscami.

Łukasz Kałużny: Tak? I rozdzielmy teraz bardzo ważne logi, logi bezpieczeństwa i audytowe, które potrzebujemy mieć wyrzucić na zewnątrz. I logi na co dzień. Nasze Operations dla zespołu, projektu, systemu, żeby żyć. To jest też ważne rozdzielenie. Zapraszamy do odcinków o logach, bo też się to przyda.

Szymon Warda: Było mówione tak To co, lecimy? Teraz będziemy korzystali z tej całej dobroci wszystkich tagów. Czyli mówimy o Winopsie, który jest elementem. Czemu on jest taki ważny? Bo on jest tym uzasadnieniem, czemu to zrobiliśmy w wielu obszarach, poza tym, że po prostu myśleliśmy, to też pokazujemy, że kontrolujemy koszty, wiemy jak to zrobić i zaczyna się cała zabawa. O tym, żeby nie popłynąć za bardzo.

Łukasz Kałużny: Tak, jest ona w ogóle odcinek, bo mówimy o fajna, o podejściu, standaryzacji, które fajna Foundation robi, więc też słuchajcie, idźcie po prostu do odcinków, zobaczcie, bo tam sporo powiedzieliśmy o dojrzałości. Chyba najważniejsze są budżety, alerty kosztowe i limity na całości.

Szymon Warda: Ja bym powiedział, że alerty, budżety na starcie to to jest kwestia dojrzałości. To nie będzie od razu. Najważniejsze jest podział, kto za co płaci i kto ile płaci.

Łukasz Kałużny: Widoczność, alert, jednak jakieś tam budżety i alerty. Szymon jak mówimy o Greenfield ie jednak bym zrobił, żeby widzieć co będzie, żeby nie było nagle, że kurde miałeś rozmowy z klientami, jak nagle przepraszam za ten wyjebało w górę płaczu, bo inaczej tego nie można było.

Szymon Warda: No i też doskonale też i Ty wiesz, jak bardzo chętnie ludzie podchodzą do tego, żeby. Żeby określić poziomy alertów i realne budżety ile system zajmie. Jest tam spora niechęć mimo wszystko.

Łukasz Kałużny: Tak powinno być.

Szymon Warda: Dla mnie takie budżety będą zmienne bardzo mocno. Pierw obserwacja, żeby się organizacja nauczyła ile co kosztuje, jak to wygląda. Potem wchodzimy z alertami.

Łukasz Kałużny: Dobra i teraz przejdźmy sobie do standaryzacji. Szymon. Bo to inaczej. I teraz będzie ta wojna, którą jak teraz popatrzymy sobie na całość elementów wojna pod tytułem i chęci. Mieliśmy też odcinek z pierwszym pytaniem z Discorda, platform engineeringu, bo od razu w tych projektach pojawiają się pomysły. Jak wiemy Custom Portal self serwisy, które nie są złe w pewnym momencie, ale to sobie ten. Jak sobie popatrzymy i pojawia się chęć pisania wystandaryzowanych modułów od początku.

Szymon Warda: Skrótowce, gotowce, gotowce, gotowce.

Łukasz Kałużny: Tak. Ja mam problem, że gotowce od dostawcy są. Kurde, mam problem z tymi modułami, że one są tak jak do bossa patrzę do tej reformy na przykład Azurowe. One są zwalone, wiesz o tym.

Szymon Warda: Łukasz Tak, ale założenie, że wiesz lepiej bez nauczenia się, bo to znowu to jest, to jest element nauki, organizacji, ludzi, zespołu. Można wziąć coś i zobaczyć, co mi tam nie pasuje, a nie wymyślamy od zera. Ja bym to zrobił tak.

Łukasz Kałużny: Raczej tak.

Szymon Warda: I tu gówno wiemy.

Łukasz Kałużny: Tak i w tym miejscu o tej standaryzacji ja bym popatrzył jak będziecie podchodzić, jak to w tym od strony Azura jest takie podejście, które kurde, ono nie jest złe, o którym mówimy policy driven. Standaryzacja, czyli polityki wymuszają nam dunajea i musisz się do nich dopasować, a potem ewentualnie do tego zaczynamy standaryzować. Bo to jest trochę pytanie, które zawsze czy dajemy wolność i każdy wybiera tulei? A co złego w projektach? Czy mówimy będziecie pisać tylko w bicepsie? Tylko w tej formie, tylko w Rumii, a może tylko operatorem?

Szymon Warda: Dobrze sobie zdajesz sprawę, że nawet jak powiemy, że tylko za chwilę pojawi się zespół, który jednak mimo wszystko użył czegoś innego i nie ma sensu, polityki muszą być, bo to daje nam tą ostatnią bramę oporu jeżeli chodzi o niezgodności i tak dalej. Nie wymusimy wszystkiego modułami, bo są wyjątki i ktoś coś musi wyklikać na szybko, bo był problem i tak dalej. Polityki muszą istnieć.

Łukasz Kałużny: Tak. I do całej tej dyskusji zapraszamy Was też do odcinka na temat platform engineering z Discordem i też poprzedni, bo tam dość sporo się dzieje. I zastanawiam się teraz słuchaj, jakby przejść w tym coś? Masz jeszcze na myśli, co byś chciał poruszyć.

Szymon Warda: Odnośnie tego, znaczy moja idea, żeby właśnie, żeby polityki wdrażać etapowo. Tak naprawdę nawet nawet jeżeli to jest ten totalnie greenfield, to jednak widzimy, jak to się zachowuje i rozmawiać z ludźmi, nie upierać się. Wierzę, że tak nie może być. Jak dalej słuchać argumentów? I to ma być też mimo wszystko rozmowa, żeby ludzie rozumieli te polityki, co mogą, co nie mogą i przewidzieć sytuacje na sytuacje wyjątkowe typu wywaliłem coś na produkcji, więc musimy coś zrobić dobrze. I teraz zupełnie scenariusze.

Łukasz Kałużny: I teraz malowanie trawy, tudzież malowanie trawy, czyli metryki sukcesu. I to jest problem, Tak? Bo mierzenie ma pokazać sukces, a nie pałować. To chyba Twoje było nawet to były chyba Twoje słowa, nawet sparafrazowane.

Szymon Warda: Ze 166 brzmi jak ja?

Łukasz Kałużny: Trochę tak I w sumie jeżeli popatrzymy, to całość bym patrzył chyba na adoption, czyli porównanie sobie ile tego wchodzi względem ten i jaką mamy adopcję tego. To jest pierwsza metryka. Druga, o której bym pomyślał, to trochę z Dory, że lead time, ale lead time. Od tego, że ktoś chce skorzystać do wejścia na produkcję. Pod tym względem określiłbym lead time story. To jest od tego commita na produkcję, a tutaj tak naprawdę to jest, jak szybko projekty są w stanie wejść na produkcję w takim setupie.

Szymon Warda: Tak, tym bardziej że zakładamy, że takie rzeczy typu na przykład subskrypcja Vinet w spokoju nie będzie tworzone przez zespół, więc musimy to rozdzielić. Tu wchodzi.

Łukasz Kałużny: To odpowiedzialności. Tak, całe to odpowiedzialności, o których powiedzieliśmy, bo trzeba sobie powiedzieć inaczej, to jest też rzecz, która może trochę nie padła wcześniej. Na przykład trzeba podejść, Jak mamy subskrypcję, to jak będziemy je wydawali, jak zrobimy, żeby to nie był korpo ticket jak na stwórz. Wiem Kevon premier, gdzie potrafił zaginąć na kilka tygodni. W niektórych przypadkach.

Szymon Warda: Tak to, co powtarzaliśmy. Procesy te ludzkie są tak samo ważne jak to, co wyklikamy czy wdrożymy w portalu. Jeżeli zrobimy tylko część techniczną, to się nie uda, bo będą marudzenia, że nie działa i nie jest to gotowe i tak dalej.

Łukasz Kałużny: No dobra, to co? Jakie są najważniejsze? Myśli Szymon.

Szymon Warda: Nie wymyślać koła na nowo. Procesy są bardzo ważne. Wrzuć racji i przygotuj się na prawdziwą walkę. Bym powiedział i polityki. Dla mnie to jest to.

Łukasz Kałużny: Dobra, to dla mnie to jest ten tę rolę przed technologią, czyli racji dać ci Proste z dużym. Niestety. Powiedziałeś, że tam nie są zespoły, tam są osoby. To jest taka rzecz, którą tych osoby. Bo mamy przypadki, gdzie są wciągnięte zespoły i nie ma żadnej decyzyjności, bo nikt nie chce się podpisać, to doszczegółowił.

Szymon Warda: To też mogą być role typu dyrektor czegoś, dyrektor czegoś, żeby się uodpornić na to, że ludzie zmieniają swoje stanowiska i potem, żeby to było też odporne.

Łukasz Kałużny: Tak, tylko chodzi o to, że to są rola osoby, a nie całe zespoły przynoszone do osoby. Są osoby są od wykonania. Tak, zespoły są od wykonania, a w racji są decyzyjności, potem muszą być w tym, to jest to druga sprawa, ta kolejność, czyli governance, sieć Identity Polityki, monitoring w OPS to jest taka rzecz, którą bym powiedział, kolejność po tym, jak mamy już zrobione, bo to zawsze zwykle jest tak, że jest subskrypcja, robimy hura sieć z tożsamością i jazda.

Szymon Warda: Tak? I jeszcze jedna rzecz to jest to, żeby polityki szczególnie, które zrobimy, opublikować, szczególnie jeżeli chodzi o nazewnictwo polityki, wymagań, co można, czego nie można robić, żeby to było widoczne i żeby się ludzie nie dowiadywali w momencie, jak coś mi się nie uda i żeby to nie było takie, żeby nie musieli robić reverse engineering na tym jak coś wdrożyć na zasadzie, że ok, próbuję. Wywala mnie, próbuję, wywala mnie to też nie działa.

Łukasz Kałużny: No dobra, to co to taki bardzo przelot? Tak, kończymy bardzo szybki przelot. Pewnie tak jak Kuba napisał dałoby się z tego zrobić tygodniowe szkolenie wchodząc we wszystkie detale i opowiadając o tym jak to wygląda. Ale rzeczywistość. Każdy jest unikalny, a tak naprawdę szary picking i dostosowywanie się trzeba niestety naszą. Nasze procesy dostosować do technologii, nie na odwrót.

Szymon Warda: Z gwiazdką, że jakiś tam obszar pewnie zostanie, ale mimo wszystko tak. Nie jesteśmy unikalni i przygotujmy się na to, że taniej i szybciej będzie jak będziemy lecieli od jakiegoś szablonu.

Łukasz Kałużny: Dobra, no to słuchajcie, Dzięki. Trzymajcie się.

Szymon Warda: Pa pa pa pa.