podcast TechChatter
Odcinek 5

BARTEK: Cześć Daniel, cześć Damian. Dawno się nie mieliśmy okazji zdzwonić, dawno nie mieliśmy się okazji widzieć. Co u Was dobrego? 
DANIEL: Wiesz co, z tego co pamiętam, to chyba każdy z nas po wcześniejszych przygodach i wspólnych projektach wylądował na swoim własnym projekcie z klientem. No ja powiem Ci, aktualnie pracuję dla klienta, który jest takim dość sporych rozmiarów holenderskim bankiem, głównie w roli czegoś, co nazywają lead cloud architektem, tudzież lead devops architektem, jakkolwiek by to dziwnie nie brzmiało. Damian, co u Ciebie?
DAMIAN: Siema chłopaki, dobrze Was widzieć i słyszeć. Ja też po wielu wspólnych bojach wylądowałem sam, podobnie jak Ty Daniel, na projekcie gdzie budujemy platformę związaną z kontenerami. Tym razem jest to AWS a nie Azur, więc ciekawe doświadczenie, ale z tego co Ty Daniel mówisz to, to co Ty robisz, jest bardzo ciekawe i chętnie bym o tym usłyszał więcej.
DANIEL: No pewnie, do tego możemy zaraz. AWS to jakaś księgarnia, jakiś sklep z tego co kojarzę? To chyba w Stanach Zjednoczonych. 
DAMIAN: Tak. 
BARTEK: Tak, w stanach Zjednoczonych, dokładnie. 
DANIEL: No doskonale wiesz, że ja preferuję chmurę Azure. 
DAMIAN: To może panowie tak po dwa słowa od każdego z nas, jakie są nasze doświadczenia, żeby tutaj słuchacze wiedzieli.
BARTEK: Jasne, to właśnie, to może też tak rzeczywiście przedstawmy się bardziej formalnie. Ja się nazywam Bartłomiej Czudek, pracuję jako architekt. Moimi specjalnościami to jest Azure i Kubernetes, a także część architektury software’owej.
DANIEL: Ja jestem Daniel, w zasadzie robię bardzo podobne rzeczy jak Bartek. Zresztą od lat pracujemy razem bliżej bądź dalej na różnego rodzaju projektach. Też głównie zajmuję się chmurą publiczną, głównie oczywiście jak wspomniałem wcześniej chmurą Microsoft Azure, ale też miałem swoje epizody z AWS czy też GCP. Od kilku lat można powiedzieć, że inwestuję bardzo dużo czasu w rozwój swoich kompetencji kontenerowych, czy to Docker, Enterprise, czy to Kubernetes, nie ma to dla mnie większego znaczenia. Damian? 
DAMIAN: Okej, to teraz moja pora. Ja tutaj w Capgemini pracuję w tej chwili jako doradca do spraw Kubernetesa, można tak to nazwać. Mój główny fokus to w tej chwili świat Cloud Native i kontenery, ale też po drodze przy tym pojawiają się chmury, pojawia się on-prem. Czasami różnie to bywa. Natomiast tak jak powiedziałem, mój główny punkt zainteresowania to wszystko co kręci się wokół świata Cloud Native. Tutaj mieliśmy okazję współpracować nieraz z Danielem i Bartkiem na różnych ciekawych projektach. No i dzisiaj poniekąd tym doświadczeniem będziemy się chcieli też podzielić tutaj z Wami. 
DANIEL: I też fajnie się składa, że akurat w tym gronie się spotykamy, bo szczerze mówiąc w niedawnej przeszłości przyszedł do mnie klient właśnie z pytaniem odnośnie Kubernetesa i miałem nadzieję zasięgnąć troszkę Waszej rady jako doświadczonych, mówiąc kolokwialnie, wymiataczy od technologii kontenerowych. Może zacznę od tego, na pewno nie jest to aż tak duża transformacja jak ta, którą mieliśmy okazję razem przeprowadzać. I dotyczy ona tak naprawdę jednego konkretnego produktu, który ten klient rozwija, to jest ichniejsza platforma bankowa, którą chcą zmigrować właśnie do Kubernetesa. 
DAMIAN: Dlaczego? 
DANIEL: Trzymajcie się krzeseł, no właśnie, trzymajcie się krzeseł, bo powód, który usłyszałem od biznesu w zasadzie można by streścić w kilku zdaniach. Biznes po prostu chce zminimalizować czas downtime’ów podczas releasów nowych wersji ichniejszej platformy i chcą też dostać coś, co w tym momencie bardzo ich boli i chcą to naprawić, a mianowicie nie mają możliwości przetestowania biznesowego, to znaczy przeklikania, mówiąc kolokwialnie transakcji biznesowych już na zrelease’owanym produkcyjnie systemie, ale w taki sposób, żeby jeszcze klienci tejże wersji nie widzieli. Więc mówiąc w naszym żargonie, starają się zrobić coś pomiędzy kanary deploymentami tudzież kanary release’ami, bądź blue-green deploymentami. 
DAMIAN: Czyli strategię release’ową próbują jakby.
DANIEL: Dokładnie, próbują poprawić co nieco swoją strategię release’ową, celem właśnie zminimalizowania ryzyka i ograniczenia ilości problemów, które po tych release’ach mogą występować. Głównym motorem napędowym tej decyzji jest to, że często zdarza się, że release’y, jak sami wiecie, są skomplikowane i potrafią wybuchnąć w najmniej oczekiwanym momencie i kilkukrotnie ostatnio takie coś się właśnie temu klientowi przytrafiło, co oczywiście kosztowało dość grube nadgodziny kilku naprawdę solidnych, technicznych ludzi. Pomijając oczywiście koszta i stres związany z tego typu incydentami, klient nie chce po prostu być postrzegany jako instytucja niestabilna technicznie. Zaufanie w tej branży jest absolutnie krytyczne zwłaszcza, że ten klient działa w zasadzie głównie w obszarze bankowości internetowej, więc ta wysoka dostępność jest dla nich absolutnie kluczowa. Więc taką intencją klienta jest, żeby przy użyciu technologii kontenerowej i migracji do Kubernetesa otworzyć poniekąd możliwości poprawy tych strategii release’owych, które nawiasem mówiąc już teraz wcale nie są takie złe. Mogę Wam od razu zdradzić, że klient właściwie w całości działa w chmurze publicznej, co jest dość powiedziałbym nietypowe nawet jak na bankowość internetową, a tym bardziej bankowość ogólnie. I w tejże chmurze publicznej, którą jest Microsoft Azure, naprawdę używają jej w sposób taki, w jaki vendor to przewidział. Tudzież wykorzystują zarządzane serwisy i starają się wykorzystać potencjał, który dostarcza Microsoft w maksymalnym możliwym stopniu. Stara się też ograniczać wdrażanie swoich komponentów platformy na tak zwany IaaS, czyli na Infrastructure as a Service, mówiąc potocznie na wirtualne maszyny. 
BARTEK: Co w naszym rozumieniu powinno być zabronione. 
DANIEL: Co w naszym rozumieniu powinno być zabronione, dokładnie. W IaaS w cloudzie to jak po prostu data center, tylko gdzieś indziej i to drożej. Ale to jest temat chyba na inną rozmowę. 
BARTEK: Wspomniałeś o tej strategii deweloperskiej, przepraszam o tym CICD tutaj i takim użyciu chmury przez klienta, że ono jest jakby dojrzałe. Jak to wygląda w kwestii architektury aplikacji? Czy mówimy o jakimś dobrym, srogim monolicie, czy jednak jest to podzielone? 
DANIEL: Wszyscy kochają dobre, srogie monolity, dopóki nie przeczytają w Internecie, że one są złe. Później chcą coś z tym zrobić, robią z tego mikroserwisy. Okazuje się, że jest jeszcze trudniej. W przypadku tego klienta akurat ta aplikacja złożona jest z około 50 serwisów działających mniej lub bardziej niezależnie. Czy nazwałbym to architekturą mikroserwisową? Niekoniecznie, może nie w 100%.
DAMIAN: Pewnie w zależności jak zdefiniujemy co to jest mikroserwis. 
DANIEL: Zdecydowanie.
DAMIAN: Ale to i tak brzmi całkiem dobrze, że mają chmurę, że mają CICD, a mają jakiś infrastructure as a code? 
DANIEL: Tak, w zasadzie to chyba z czystym sumieniem mogę powiedzieć, że wszystkie około 50 serwisów, właściwie to cykl życia wszystkich 50 serwisów, może tak to ujmę, jest zarządzany w pełni automatycznie używając, jeżeli chodzi o infrastrukturę właśnie infra as code, czyli mamy pełną automatyzację wdrażania infrastruktury, oczywiście opakowaną w pipeline CICD przy użyciu Azure DevOps. Poza tym proces release’owy, który tak naprawdę został już zbudowany na około tych kilkudziesięciu serwisów, już w tym momencie jest całkiem dojrzały, tak bym go określił. To znaczy pozwala on w zasadzie na przejście między wszystkimi środowiskami tejże platformy, czyli devem, UAT-em, produkcją, właściwie przy pomocy kilku kliknięć myszy i uruchomieniu pipeline’u. Więc od tej strony jest to dość zaawansowany i powiedziałbym stabilnie działający, dojrzały proces SDLC, Sutter Development Lifecycle, który oczywiście rządzi się swoimi prawami, jeżeli chodzi o prędkość działania i wpływanie na stabilność samego systemu, ale można spokojnie rzec, że jest ten proces release’owy i deploymentowy w pełni zautomatyzowany w tym momencie. 
BARTEK: To brzmi jak wymarzony klient. Gdyby jeszcze tylko uzasadnienie biznesowe pójścia w te kontenery miało trochę więcej, przynajmniej tak to by miało więcej sensu.
DANIEL: To jest powód, dla którego chciałem z Wami porozmawiać, bo o ile ja sam jestem pod dużym wrażeniem tego, co do tej pory klient był w stanie osiągnąć ze swoją platformą, o tyle sam, jak to mówią potocznie, driver czy też motor tej decyzji o przejściu na Kubernetesa wydaje mi się dość prozaiczny i miałem nadzieję, że wymienimy się troszkę naszymi doświadczeniami i porozmawiamy na temat tego, czy w ogóle jest sens takie przejście robić oraz na temat tego czy ewentualne przejście wiąże się też z jakimiś zagrożeniami. Na ten moment oczywiście ja mam jakieś swoje obawy, mam jakieś swoje problemy z tego typu wymaganiem, ale nie chciałbym od razu o tym mówić. Miałbym nadzieję, że trochę podzielicie się ze swojej perspektywy tym, co myślicie o takim przejściu, czy w ogóle ono ma sens i czy w ogóle ten cel biznesowy, który został postawiony, czyli cel obniżenia ryzyka wdrożeń i może obniżenia czasu tych wdrożeń, może w ogóle być osiągnięty używając Kubernetesa?
BARTEK: Mówiłeś Daniel o tych uzasadnieniach biznesowych, że to jest rzecz, którą warto przedyskutować, rzeczywiście ten driver taki decyzyjny. Jak najbardziej tak, czyli żeby podsumować to, czego klient szuka, to w technologii kontenerowej szuka ułatwień związanych z release’owaniem aplikacji w sposób taki, aby on był lepszy niż to, co ma dotychczas. To bym też chciał zrozumieć, co ma dotychczas, ale też na pewno, aby mógł zaimplementować tych większość praktyk takich szeroko znanych i rozumianych, jeśli chodzi o sposób release-owania. Czy moglibyśmy wymienić może te praktyki, które znamy, które Kubernetes nam daje, jeśli chodzi o sposób release’owania, z których ten klient mógłby skorzystać? 
DAMIAN: Zanim jeszcze wymienimy, ja bym chciał tak jeszcze podsumować ten temat i jak ja go rozumiem. Czyli z tego, co ja rozumiem, klient chce uniknąć sytuacji, w której release’ują aplikację w weekendy na przykład o 4 rano po to, żeby zmniejszyć ryzyko, że ktoś z tej aplikacji korzysta i chcieliby mieć sposób, żeby release’ować nie o 4 rano w weekend, ale chcieliby release’ować na przykład o 9 rano w poniedziałek bez żadnych problemów i bez odczucia, że ta aplikacja na przykład przestaje działać na godzinę w momencie szczytowym powiedzmy, tylko cały czas jest dostępna. Do tego klient może na przykład o 9 rano w poniedziałek testować tę aplikację gdzieś obok produkcyjnie. Część ruchu użytkowników może być przekierowana już na nową wersję, a część ruchu użytkowników nadal może korzystać z tej starej wersji powiedzmy przed wydaniem.
BARTEK: Tak, myślę, że ująłeś to perfekcyjnie z małą tylko i wyłącznie różnicą, już teraz release’y odbywają się w tygodniu tylko po godzinach pracy, po godzinach operowania ichniejszego biznesu, ale nie zmieniam tego kontekstu Twojego podsumowania, reszta jest jak najbardziej zgodna z tym, czego oczekuje klient.
DAMIAN: Bartek, Ty zacząłeś, jakbyś mógł dokończyć, gdzie ja Ci wszedłem troszkę w słowo. 
BARTEK: Jasne, nie ma problemu. To co myślałem, że skoro tak wspominaliśmy, że Ty tak ładnie podsumowałeś to wymaganie biznesowe, to może warto, udałoby się zastanowić, jakie te strategie release’owe, które Kubernetes nam daje, mogłyby spełnić te wymagania, z czego mógłby ten klient skorzystać. Zanim jeszcze w ogóle będziemy rozmawiać o tym fascynującym procesie przestawienia zwrotnicy z tego, co jest obecnie na Kubernetes, to chciałbym, żebyśmy mieli pewność, że rzeczywiście klient może dostać przy pomocy Kubernetesa to, na czym mu zależy. Czyli wiemy, że mamy różnego rodzaju metody, strategie release’owe, takie jak Canary, Blue Green Deployment, czy widzimy którąś z nich, która by ewentualnie aplikowała się dla tego klienta, dla tego wymagania, któraś konkretna. 
DANIEL: Ja myślę, że wstępnie można byłoby się kierować nieco bardziej w kierunku Blue Green Deploymentów mając na uwadze fakt, że klient chce przeprowadzać release’y, ale jeszcze nie udostępniać ludziom end userom, klientom nowej wersji platformy. Wykonywanie Canary release’ów związane z na przykład podziałem części ruchu do nowej wersji i starej wersji platformy wydaje się nie być możliwe. Co więcej, warto też może w tym momencie zaznaczyć, że powodem, dla którego nie chciałem nazywać tej aplikacji mikroserwisową, jest fakt, że klient nie zaimplementował odpowiedniego wersjonowania swoich API-ów swoich serwisów. Problem, który to powoduje jest taki, że właściwie ta platforma nie może działać w dwóch różnych wersjach w jednym czasie, czy jej komponenty nie mogą działać w różnych wersjach w międzyczasie, ponieważ najnormalniej w świecie ichniejsze serwisy nie potrafiłyby ze sobą rozmawiać. Dlatego też klient w aktualnym setupie, podczas release’ów, release’uje wszystko naraz do środowiska produkcyjnego, tudzież każdego innego tak naprawdę. Zawiera w tym release’ie wszystkie komponenty, które były w jakiś sposób modyfikowane w danym cyklu developerskim. Dlatego tak, wydaje mi się, że na ten moment chyba bardziej przemawiałaby do mnie strategia Blue Green Deploymentów chyba, że macie inne na ten temat zdanie. 
BARTEK: Jeszcze mamy tą strategię związaną z, nie wiem jak to na polski przetłumaczyć, okręgami, Ring-Based Deployment, prawda, że mamy części aplikacji dla dedykowanych użytkowników, którzy są jakby zapisani do tej konkretnej nowej wersji, prawda? To jest jeszcze taka rzecz, ale z tego co mówisz to wersjonowanie może być tutaj dosyć problematyczne. Czy jest to coś, co uważasz, że należałoby naprawić jako prerequisite do całej tej zmiany w stronę Kubernetesa, zanim w ogóle będziemy dyskutować, czy też jest to coś, czego nie da się teraz zrobić i mimo to damy radę osiągnąć te założenia biznesowe, które klient przedstawił. 
DANIEL: Wiesz co Bartek, to jest dobre pytanie. Czy da się to zrobić? Pewnie, że się da. Da się to zaimplementować, da się poprawić kwestie wersjonowania serwisów. Pytanie tylko czy klient nie przerazi się ilością pracy i kosztów, które by to wymagało. Boję się, że byłby to killer, jeżeli chodzi o istniejszy biznes case przejścia na Kubernetesa i być może nie skierowałoby ich to w te tory. Już abstrahując od tego, że fajnie byłoby już samą taką transformację do Kubernetesa zrobić też z innych powodów, o których pewnie później porozmawiamy, o tyle zaimplementowanie w tych 50 serwisach wersjonowania myślę, że mogłoby być raczej show stoperem dla klienta. Także myślę, że to raczej nie wchodzi w grę. 
DAMIAN: Ja też myślę, że z perspektywy systemu bankowego to też jest tak, że chcemy wydawać całość, że to pewnie jest, tak zakładam, że to jest jedna logiczna całość, która ma być wydana o danym czasie i trudno by było to zrefaktorować. 
DANIEL: Tak, to jest też dobry punkt, który podniosłeś. Bankowość niesie za sobą kilka konsekwencji, jeżeli chodzi o projektowanie i wdrażanie systemów IT. Jedną z nich jest to, że bardzo często zależymy od zewnętrznych systemów, centralnych systemów bankowych, gdzie nie mamy możliwości i nie mamy luksusu pełnej kontroli nad tym, w jaki sposób nasz własny software wypuszczamy. Dlatego tak, jak mówiłem, może się to okazać show stoperem dla klienta.
BARTEK: To co słyszę, to chyba daje nam, przynajmniej mi, mam nadzieję Damian, że Tobie również.
DAMIAN: Tak.
BARTEK: Całkiem dobry pogląd i obraz tego, jak wygląda sytuacja u tego klienta. On jest dosyć dojrzały, cały software, który jest pisany, release’owany, chmura jest używana w stopniu bardzo zaawansowanym. Więc od strony takiej technicznej myślę, że przejście na Kubernetes byłoby takim często chyba naturalnym krokiem dla niektórych inicjatyw. Trochę jest dla nas to wymaganie biznesowe takie, powiedzmy, nie do końca uzasadnione, bo jak przynajmniej z mojego doświadczenia wynika, ta podróż w stronę Kubernetesa jest dosyć skomplikowana, dosyć kosztowna i wprowadza dużo zmian. Ale myślę, że możemy jakby tak spróbować zaplanować taką ścieżkę dla tego klienta wspólnie, że mielibyśmy kilka takich po drodze checkpointów, takich punktów, w których moglibyśmy zweryfikować, dobra, czy to dalej jest dla nas, idziemy, nie, zatrzymujemy się i może udałoby nam się to nawet jakoś poukładać w taki sposób, w który ryzyko związane z wydatkami i zaangażowaniem sił roboczych w przejście na ten Kubernetes będzie stopniowo narastać. Nie od razu tak po prostu wszystko rzucać się na głęboką wodę, tylko po prostu powoli ten temat rozwijać. 
DAMIAN: Ja bym jeszcze dodał, że rezultatem takiej analizy można by było później porównać koszty migracji do Kubernetesa versus na przykład koszty stworzenia dodatkowej instancji jakiegoś PAS-a, czyli Platforma as a Service, który pełniłby rolę takiego właśnie Blue Green Deployment, jeżeli dobrze rozumiem, to to też mogłoby poniekąd rozwiązać ten najważniejszy problem, czyli wydawanie nowych wersji na niezależne środowisko, ale wydaje mi się, że jeszcze jedna rzecz jest taka ważna, że te środowisko powinno być dokładnie takie same. To jakby środowisko, na którym wydajemy nową wersję po to, żeby ją zweryfikować, powinno być dokładnie identyczne jak to, na którym działa już ta stara wersja. I pytanie, czy SAS-y rozwiążą ten problem, czy też na przykład Kubernetes go rozwiąże. 
DANIEL: To jest ciekawy punkt, Damian, bo masz rację, jeżeli mielibyśmy osiągnąć cel biznesowy, który postawił klient bez używania Kubernetesa, to oczywiście byłoby to pewnie możliwe. Trzeba byłoby, tak jak mówisz, stworzyć pełną replikę produkcyjnego środowiska, które teraz klient posiada. To nie jest oczywiście jeden PAS, czy jedna instancja Platform as a service, któreś z usług Azure. To są dziesiątki, bądź nawet setki takich usług, więc wydaje mi się, na taki mój rozum, że koszty związane z osiągnięciem tego byłyby bardzo wysokie, dlatego że już aktualnie klient posiada kilkadziesiąt application serwisów w Azure, które hostują poszczególne komponenty tejże platformy. Wydaje mi się, że byłoby to dość skomplikowane przedsięwzięcie, żeby taką replikę do celu Blue Green Deploymentu zrobić, a na pewno trwałoby to trochę czasu. 
BARTEK: Jasne i to jest też jeden z często takich driverów, który słyszymy, kiedy mówimy o przejściu na Kubernetes, to jest to, żeby zagęścić ilość aplikacji biznesowych na infrastrukturze, bo to jest jedną z fantastycznych rzeczy, które daje nam technologia kontenerowa. Ty Damian wspomniałeś ciekawą rzecz, która mi przypomina również jedną z wielu dyskusji, którą prowadziliśmy z Docker Professional Services, kiedy powiedzieli nam, że wielu klientów traktuje środowisko deweloperskie na równi lub nawet prawie na równi z środowiskiem produkcyjnym, jeśli chodzi o moc obliczeniową i dostępność. Albowiem jakikolwiek outage środowiska deweloperskiego powoduje często gigantyczne koszty i straty finansowe i straty po prostu w czasie całych zespołów ludzi, którzy są nauczeni do continuous integration, continuous deployment, więc to rzeczywiście tu jest tak jak mówisz, takie nawet środowisko Blue Green musiałoby mieć taki sam, powiedziałbym, mir o produkcji praktycznie rzecz biorąc. 
DAMIAN: Dobrze, czyli możemy założyć, że ta migracja ma sens. Znaczy, jednoznacznie jeszcze nie jesteśmy w stanie tego stwierdzić, ale poniekąd możemy zbadać, jakie kroki klient powinien podjąć.
DANIEL: Pytanie, czy możemy jakimś niskim kosztem może rozpocząć pracę nad taką migracją, ale w taki sposób, żeby przynajmniej ocenić to rozwiązanie, które aktualnie ma klient, tudzież środowisko, które ma przygotowane, pod kątem tego przejścia w taki sposób, żeby nie wydawać na to zbyt dużo pieniędzy, tudzież nie angażować w to zbyt dużo środków. Nie wiem, macie jakieś pomysły, jak można byłoby w ogóle taką migrację zacząć? Mamy rzeczoną platformę z wieloma serwisami, potrzebujemy ją zmigrować do Kubernetesa. Ja powiem może tylko tyle, że na razie te aplikacje hostowane są w sposób klasyczny. To znaczy kod jest kompilowany i binaria są wdrażane na środowiska hostingowe. Jakieś pomysły macie, coś Wam do głowy przychodzi? 
BARTEK: Pierwsza rzecz, która gdzieś mi tam rezonuje w głowie, to jest to coś, co może nie jest związanego z technologią, ale wspominają, że to jest branża bankowa. To mi tutaj zawsze gdzieś pachnie jakimiś regulacjami, jakimiś wymogami związanymi ze standardami bankowości, standardami zabezpieczeń. Czy my mamy pewność, czy było przeprowadzone, jak to się tłumaczy bardzo dobrze na polski, studium wykonalności projektu, tudzież feasibility study, jeśli chodzi o to, czy w ogóle technologia Kubernetes i okoliczne technologie, które Kubernetes nam przyniesie, są w zgodzie z tymi regulacjami, z tymi obecnie używanymi procesorami u klienta.
DANIEL: Wiesz co, powiem Ci, że takiego studium przynajmniej na stan mojej wiedzy nie było. Zdecydowanie zakrywa na szeroką skalę analizy dotyczące chmury publicznej były robione przez tego klienta, które zakończyły się pozytywnie. Nie znaleziono przypadków regulacji, których nie dałoby się w jakiś sposób osiągnąć w chmurze publicznej, której używa klient. Wydaje mi się, że znaczyłoby to, że prawie na pewno podobne wyniki osiągnęlibyśmy w przypadku migracji na Kubernetesa i takiego asesmentu w środku Kubernetesa. Oczywiście nie mam pewności, więc ja od razu sobie notuję, że jest to być może jeden z punktów, który powinienem z klientem poruszyć, żeby takie feasibility study przeprowadzić, ale na ten moment wydaje mi się, że nie powinno być to problemem. Damian, masz jakieś doświadczenie z tym związane? Znasz jakieś dobre praktyki, jeżeli chodzi o właśnie compliance, czy właśnie wymuszanie zgodności z regulacjami na platformach kontenerowych?
DAMIAN: Zanim jeszcze odpowiem na pytanie, to też bym się zgodził z tym, co powiedziałeś, że wydaje mi się, że skoro klient zmigrował się do chmury, to już te największe problemy z compliance są za nami. Bo jeżeli przyjmiemy, że ten Kubernetes też będzie w tej samej chmurze, no to tak z mojego doświadczenia wydaje mi się, że nie będzie tutaj żadnych problemów. Oczywiście to jest temat jeszcze do weryfikacji, no bo to nie możemy sobie przyjmować. Trzeba mieć konkretne decyzje, konkretne powody. Natomiast wracając do pytania, jak najbardziej jesteśmy w stanie wymuszać pewne regulacje co do bezpieczeństwa. Jak wiemy bankowość to niemal jest równoznaczne z wymogiem bezpieczeństwa słowo. Także w Kubernetes jest coś takiego możliwe, aby wymuszać pewne najlepsze praktyki jeżeli chodzi o bezpieczeństwo i myślę, że bez problemu możemy je osiągnąć. Zestaw narzędzi, które są w tej chwili dostępne na rynku, pozwalają na takie elastyczne dopasowanie tych reguł, które chcemy wymuszać. Możliwości są ogromne i jestem prawie pewny, że jesteśmy w stanie osiągnąć prawie wszystko, co zażyczy sobie klient, jeżeli chodzi o jakieś wymuszanie best practice.
BARTEK: Czyli to by mogła być jedna z tych rzeczy, które byśmy mieli jako akcję do tego klienta, żeby to zweryfikować. Myślę, że taka weryfikacja byłaby chyba dwuetapowa dla mnie. Najpierw weryfikacja generalnie podejścia do technologii kontenerowej, a potem weryfikacja designu, bo wiemy, że już na etapie designu wprowadzimy kilka narzędzi. Podejrzewam, że jeden z nich to jest to, o którym opowiadał przed chwilą Damian, do zarządzania politykami na Kubernetes, które wprowadzają pewne reguły, ale myślę, że to takie narzędzia też będą musiały zostać zweryfikowane. Więc to będzie taki drugi etap post design, żeby sprawdzić, czy jesteśmy na dobrej ścieżce. No dobrze, no to nudy za nami. Czy jeszcze coś mamy poza takimi rzeczami? 
DANIEL: Myślę, że chyba z takich wstępnych tematów to tyle. Mnie ciekawi właśnie najbardziej, jak Wy byście widzieli taką migrację, bo nie ukrywajmy, tematy, jak to wcześniej określiłeś, dobrze nudne, trzeba będzie przewałkować z klientem, zawsze tak jest, zawsze tak będzie i pewnie będą się one ciągnąć dość długi czas, ale to co tak naprawdę jest istotne dla mnie na tym etapie, to jest jakieś takie ułożenie planu takiej potencjalnej migracji, bo wydaje mi się, że dopiero wtedy zobaczyłbym i też klient zobaczyłby tak naprawdę, ile z tym wiąże się pracy i ile potencjalnych problemów można sobie stworzyć nowych oprócz tych, które się miało teraz. Także co byście doradzili w tym temacie? 
BARTEK: Jeszcze może warto tutaj nadmienić, że do tych nudnych aczkolwiek ja trochę boję się akurat w tym przypadku, tak jak to określił, bo to jest trochę fascynujący temat związany z kulturą organizacji, która już u tego klienta jest, nazwałbym to, właściwa i prawidłowa, no bo definiujemy sobie infrastrukturę przy pomocy kodu na pipeline, więc to wszystko, co dla mnie jest takim kluczowym komponentem wymaganym, aby był na miejscu, dobrze działającym, zanim w ogóle będziemy mówić o Kubernetes i kontenerach, no to jest już u tego klienta zaimplementowane. Więc to bym też chyba z tego, co opowiadasz, oczywiście, to bym też gdzieś tam odhaczył i to powoduje, że będzie prościej, myślę.
DANIEL: Tak, tak, to prawda. Nie zmienia to faktu, że wiedza na temat kontenerów klienta na razie raczkuje. Nie ma tak naprawdę nawet żadnych mini-projekcików rozwijanych przez tego klienta, które by wykorzystywały kontenery, ale zdecydowanie zgodzę się z tym, co powiedziałeś. Kultura, która by nam umożliwiła skok w kontenery, rzeczywiście jest na miejscu. Rzeczywiście mało co wykonywane jest ręcznie. W zasadzie wszystkie elementy aplikacji infrastruktury są w ten czy inny sposób trzymane w kodzie i realizowane przy pomocy pipeline’ów, co jest jakby nieodłączną częścią operacji już po wdrożeniu Kubernetesa. Więc tutaj jeżeli rzeczywiście klient nie miałby tak zaawansowanych procesów deweloperskich już teraz, no to byłoby to bardzo trudne, myślę, do przeskoczenia. 
DAMIAN: Czyli podsumowując, jeżeli ktoś z naszych słuchaczy będzie się mierzyć z podobnym problemem, mianowicie ktoś przyjdzie do niego albo on czy ona będzie stał przed wyzwaniem przeprowadzenia takiej migracji, to zaraz po odhaczeniu wszystkich nudnych rzeczy typu compliance i wymagania z perspektywy prawnej, to drugim krokiem byłoby sprawdzenie czy w organizacji, w której chcemy taką migrację przeprowadzić, jest już ta kultura DevOps albo na jakim ona jest poziomie. Potem dopiero możemy myśleć o kolejnych krokach już stricte związanych z kontenerami. 
BARTEK: Zdecydowanie, absolutnie się zgadzam, świetne podsumowanie Damian. No to co, w takim razie może byśmy coś technicznego w tym naszym procesie zaczęli malować. No i skoro opowiadaliśmy o tym, że mamy wszystko pięknie przedstawione w formie kodu, to dlaczego niskim narzutem pracy nie mielibyśmy spróbować najpierw tak skonstruować pipeline’y dodatkowe w całym procesie CICD, aby produkowały nam obraz kontenerowy z każdego serwisu. Takie podejście pozwoli nam szybciutko zweryfikować, czy te serwisy są, użyję takiego dosyć częstego słowa, kompatybilne, może tak to nazwę, z technologią kontenerową i czy to jest coś, co my łatwo możemy przerzucić w stronę właśnie Kubernetesa. A nie ryzykujemy tutaj w przypadku, przynajmniej tak mi się wydaje, poprawcie mnie proszę, jakimś specjalnie dużym ryzykiem finansowym, czy ryzykiem efortu programistów, prawda? A byłoby to również ciekawe dla zespołu, taki eksperyment.
DAMIAN: Ja bym powiedział, że nawet jeśli ta migracja finalnie nie wypali, to zespół deweloperski zyska kompetencje z zakresu kontenerów, a do tego prawdopodobnie ułatwi sobie życie podczas dewelopmentu, po prostu podczas codziennej pracy, bo zamiast uruchamiać gdzieś, czy korzystać z chmurowych rozwiązań, będą mogli sobie, nie wiem, jakiś komponent tego systemu uruchomić bardzo szybko jednym poleceniem. Czy to będzie baza danych, czy to inna usługa z pewnością może im to się przydać, nawet jeżeli ta migracja finalnie nie doszłaby do skutku. 
DANIEL: Dobra, czyli jeżeli dobrze Was rozumiem, postaram się to podsumować, bo nie wiem, czy do to mnie dotarło. Czyli sugerujecie, że potencjalnie dobrym, nisko kosztowym krokiem byłoby napisanie pipeline’ów, które tak naprawdę biorą kod aplikacyjny i zamykają je w obrazy kontenerowe, nie uruchamiają tych kontenerów na razie w żadnym środowisku, po prostu byłyby to obrazy kontenerów, które sobie gdzieś na boku siedzą w jakimś registry i dałoby nam to potencjalnie po pierwsze możliwość zweryfikowania, czy nasza aplikacja i jej komponenty są łatwe bądź trudne w zamknięciu w taki obraz, a po drugie dałoby potencjalnie troszkę uproszczeń w temacie budowania środowisk deweloperskich. Dobrze Was zrozumiałem? 
BARTEK: Ja myślę, że jak najbardziej i to co wydaje mi się można byłoby tutaj od razu jeszcze dodać, taki dodatkowy smaczek, to moglibyśmy już na tym etapie wprowadzić pewnego rodzaju skanowanie tych obrazów. To byłby taki pierwszy krok w stronę security, w stronę zabezpieczenia, coś co będziemy później z pewnością eksplorować znacznie bardziej, ale niskim narzutem, jakiegoś tam wysiłku moglibyśmy również poprawić bezpieczeństwo już na starcie tych kontenerów i też zasugerować być może jakieś zmiany nawet w obecnym środowisku dzięki takiemu skanowaniu. Nie wiem, czy oni mają, czy ten klient ma zaimplementowany jakiś secure supply chain obecnie, a jeśli nie to byłby jakiś pierwszy taki kroczek w tym kierunku.
DANIEL: Pewnie, to ja może tylko rozwinę troszkę, użyłeś stwierdzenia secure supply chain. Zakładam, że chodzi Ci o taki supply chain w procesie software development lifecycle. Klient na ten moment posiada, powiedziałbym, bardziej narzędzia niż procesy w tej kwestii rozwinięte, co nie zmienia faktu, że być może byłby to też dobry powód, żeby te procesy rozwinąć. Ten pomysł z zamknięciem kodów w kontener jest ciekawy. Ja myślę, że klientowi by się spodobało to, że można zrobić jakiś pierwszy krok, tak naprawdę nie ryzykując tego, że będzie jakiś negatywny wpływ na całą platformę. Przy okazji zespół deweloperski, zespół techniczny ogólnie mówiąc nabędzie trochę nowych umiejętności, no bo przecież będą musieli nauczyć się jak tworzyć w sposób, powiedzmy, zgodny z dobrymi praktykami te obrazy kontenerowe, a przy okazji, tak jak chyba wspomniał Damian, można by było tych kontenerów użyć, żeby łatwiej powoływać do życia środowiska deweloperskie na lokalnych maszynach deweloperów. Podoba mi się ten pomysł. Podoba mi się ten pomysł i nawet chyba wiem, co można byłoby zrobić w kroku drugim, już nieco bardziej zwiększając ryzyko i powiedzcie mi, co o tym myślicie. Skoro mamy wiele serwisów, one już działają na produkcji i w każdym innym środowisku i mamy już teraz obrazy, w których mamy zamknięty kod tych serwisów, to potencjalnie moglibyśmy zmienić serwisy, które teraz działają w taki sposób, aby używały właśnie tych kontenerów, a nie kodu bezpośrednio, co pozwoliłoby nam zobaczyć, czy w ogóle te obrazy działają. Widzicie jakieś problemy? 
BARTEK: Jak działają.
DANIEL: Tak, to prawda.
BARTEK: Nie, myślę, że to jest, ja bym się podpisał pod tym, że to jest taki naturalny krok kolejny. Spróbujmy jak działają, wykorzystajmy je, zobaczmy, co się będzie działo. Zobaczmy oczywiście w takiej formie bezpiecznej, wrzucając to na głęboką wodę. Świetnie, z ciekawości jak wiele tych instancji, typów infrastruktury, które ma klient, dałoby się tak przestawić?Jakieś web app jest tam, może jakieś Azure Functions? 
DANIEL: Tak, w większości są to aplikacje webowe. Powiedziałbym, że część z nich, raczej mała, to są aplikacje z jakimś frontendem webowym. Znakomita większość to są po prostu API, które gdzieś pod spodem komunikują się ze sobą i dostarczają rzeczywiste funkcje biznesowe. Więc pod tym kątem rzeczywiście wydaje się to dość naturalny drugi krok do zrobienia.
BARTEK: One są skalowalne jakoś horyzontalnie, wertykalnie? Jak to działa? 
DANIEL: To jest też dobre pytanie. Przyznam szczerze, że nie wiem, czy wszystkie z nich są skalowalne. Podejrzewam, że większość z nich powinna być skalowalna, bo na stan mojej wiedzy aktualnej wiele z tych serwisów są serwisami bezstanowymi, więc z natury rzeczy powinny być w stanie skalować się bardzo łatwo. Na pewno są też serwisy, które jakiś stan posiadają, serwisy, które uruchamiają jakieś zadania w tle. Te pewnie byłoby troszkę trudniej skalować, ale rzeczywiście myślę, że jest to też warty punkt do przedyskutowania z klientem, bo będzie to miało też wpływ na to, w jaki sposób możemy później zaplanować ewentualną strategię releasową.
BARTEK: Świetnie, dzięki. To fajna wiadomość, że są bezstanowe. 
DAMIAN: To może podsumujmy temat. Czyli zbudowaliśmy obrazy kontenerowe, trzymamy je już w repozytorium, możemy je uruchamiać lokalnie i teraz kolejnym krokiem byłoby uruchomienie tych obrazów w chmurze w usługach, które zezwalają na to, żeby wskazać konkretny obraz dockerowy i po prostu uruchomić to jako kontener. Myślę, że abstrahując od chmury Azure, można to osiągnąć również w innych chmurach i nawet jeżeli nasi słuchacze będą mierzyć się kiedyś z problemem podobnym w innej chmurze niż Azure, to również jest to taki krok wspólny, który można rozważyć przy potencjalnych migracjach.
DANIEL: Myślę, że tak. Myślę, że na stan mojej aktualnej wiedzy też o innych chmurach typu AWS czy GCP, to również byłoby możliwe zadanie. W przypadku tego klienta sporym ułatwieniem jest fakt, że serwisy, , które wykorzystuje klient celem hostowania elementów platformy, już teraz wiem, że one wspierają możliwość również działania w oparciu o obrazy kontenerowe. Więc ta zmiana by nie była jakoś specjalnie trudna. Tak mi się przynajmniej wydaje na ten moment. 
BARTEK: Ja jeszcze chciałbym nawiązać do czegoś, co Damian wspomniał przed momentem o środowiskach deweloperskich. I to jest myślę też również bardzo ważna rzecz, aby napomnieć, że mając te serwisy już skontenerowane, możemy ułatwić również pracę programistom, bo oni będą mogli korzystając z różnego rodzaju narzędzi, czy to jest Docker, Desktop czy Launcher, będą mogli sobie uruchamiać te kontenery już u siebie i symulować o wiele prościej experience taki developerski. Myślę, że to jest też bardzo dobry benefit. 
DAMIAN: Zdecydowanie tak i do tego bardzo, powiedzmy, małym kosztem patrząc z perspektywy całej migracji, jest to bardzo mały koszt, zarówno czasu jak i pieniędzy.
BARTEK: Wspominaliśmy również o tym takim pierwszym skanowaniu, który moglibyśmy wykonać już w registry, już na tym etapie i również prowadzić taki proces cyklicznego skanowania tych obrazów kontenerowych, ale to również daje dodatkową funkcjonalność jaką jest Software Bill of Materials. Wiem, że Damian Ty miałeś okazję kiedyś coś pracować z SBOM-em, jeśli dobrze pamiętam. Możesz powiedzieć jakie benefity można czerpać z takich informacji jak ten SBOM? 
DAMIAN: Jasne, więc generalnie każdy software musi gdzieś być hostowany i każdy software potrzebuje jakichś zależności, jakichś bibliotek, frameworków i tym podobne. Jeżeli weźmiemy jeszcze do tego technologię kontenerową, dochodzą nam do tego też często paczki związane z samym systemem operacyjnym. Nie oszukujmy się, w dzisiejszych czasach kontenery to tak naprawdę Linux, więc będziemy tutaj mówić głównie o paczkach i wszelkiego rodzaju narzędziach, które są związane z Linuxem. I teraz wprowadzając weryfikację SBOM-u, jesteśmy w stanie też zweryfikować, czy nie tylko sam kod, który tworzą programiści jest bezpieczny, bo do tego będą inne narzędzia, które powiedzmy, będą statycznie analizować sam kod wytworzony przez programistów, czy też dynamicznie, bo tu też mamy kilka technik, ale sam SBOM, czyli Software Bill of Materials pozwoli nam zweryfikować, czy te paczki, które są niezbędne do uruchomienia tej aplikacji, na pewno są bezpieczne i czy są zgodne z regulacjami w tym przypadku bankowym. 
DANIEL: To wydaje mi się jest jedna z kluczowych rzeczy, która byłaby potrzebna i być może nawiązując trochę do tego, co powiedziałeś wcześniej Bartek, byłby to naturalny sposób na rozszerzenie tego supply chaina software’owego o kolejne elementy bezpieczeństwa tego supply chain. Dodatkowe skanowanie, tudzież nawet raportowanie Bill of Materials z danego kontenera myślę, że byłoby przydatne, dlatego też ten klient powiedziałbym, że bardzo zależy mu na tym, aby wszystkie biblioteki były pozbawione jakichkolwiek krytycznych podatności. Jest to jedna z rzeczy, które naprawdę spędzają sens powiek bardzo wielu inżynierów na co dzień, więc myślę, że dodatkowe źródło informacji o tym, że coś jest nie tak, jak najbardziej byłoby też benefitem, chyba którego klient się nie spodziewa w tym wypadku, więc myślę, że jest to fajna rzecz warta też zanotowania. 
BARTEK: Super, fajnie, słuchajcie, to te wszystkie rzeczy, które żeśmy dotychczas opowiadali i planowali, to są takie rzeczy, które te koszty nie będą wysokie, ale wydaje mi się, że prędzej czy później będziemy musieli przejść do etapu weryfikacji kosztów infrastruktury. To myślę, że kolejnym krokiem byłoby weryfikacja kosztów infrastruktury oraz weryfikacja kosztów całego projektu i sprawdzenie, czy dalej ten biznes case spina, czy dalej te wymagania postawione przez klienta za taką cenę są do osiągnięcia. 
DANIEL: Jak najbardziej ma to sens. Ja zastanawiam się, kiedy mówisz koszty infrastruktury, bo ja jak najbardziej się pod tym podpisuję. Zastanawiam się, jakby co tak naprawdę warto byłoby ująć w takich kosztach. Nie wiem, czy macie jakieś doświadczenia, bo koszty infrastruktury to pojęcie jest dość ogólne. Ja wiem, że też wielokrotnie Wy oboje mieliście doświadczenia z wycenianiem i z kosztorysami projektów cloudowych. Jakie w ogóle komponenty byście brali pod uwagę w takiej wycenie kosztów? Ja myślę, że to jest dość ważne dla mnie, bo nie ukrywając, to będzie dość kluczowa informacja dla klienta, zanim tą decyzję podejmie ostateczną. 
BARTEK: Zacznę od tego myślę najbardziej oczywistego i takiego w cudzysłowie prostszego, bo jest to po prostu klaster kubernetesowy na Azurze. Jego będzie trzeba jakoś na tym etapie już mniej więcej zmierzyć, zaprojektować jak ma być duży ten klaster, ile ma mieć nodów, jakich rozmiarów, ile tam ma być mocy obliczeniowej. To myślę, że jest takie pierwsze serce całego tego przedsięwzięcia, ale wiemy, że to serce często wcale nie jest najdroższe, tylko te satelity na około, które gdzieś tam się pojawiają. To byłby taki pierwszy krok myślę w projektowaniu całego tego przedsięwzięcia, więc ten klaster. No i musimy na ten klaster pointegrować, pospinać, po dodawać różne dodatkowe rzeczy i teraz myślę, że to jest ten moment, kiedy moglibyśmy sobie powymieniać chyba takie komponenty, które wygenerują koszty, a które będą nam potrzebne.
DAMIAN: Dobra, to ja mam parę pomysłów co by mogło być kosztem. Często zapominamy o takich podstawowych sprawach jak monitoring aplikacji. Myślimy o migracji do Kubernetes, ale musimy wiedzieć, że migracja do Kubernetesa może wiązać się z pewnymi zmianami w komponentach, które służą do monitorowania tych aplikacji. Co o tym myślicie Panowie? 
DANIEL: Słuszna uwaga, ja właściwie nie pomyślałem o tym jak na razie. Jest to ciekawy punkt. Klient na ten moment monitoruje swoją platformę w dość taki dokładny sposób. W większości używają natywnych mechanizmów Azure, żeby to osiągnąć. Pytanie czy te natywne mechanizmy będą w stanie być użyte już po migracji. To jest w sumie ciekawy punkt również do przeprowadzenia jakiegoś assessmentu i zobaczenia czy rzeczywiście jest tak jak mówisz, że niektóre z tych elementów nie będą musiały być w jakiś sposób rozszerzone, zmienione, dopasowane, cokolwiek. To jest bardzo dobra uwaga. 
DAMIAN: Dla mnie zaraz po bezpieczeństwie to jest taki drugi krytyczny punkt. Bezpieczeństwo to czy nasze pieniądze, które w banku trzymamy, czy one faktycznie są, jak to się mówi, bezpieczne, a druga sprawa, czy końcowi klienci będą mieć dostęp do tych usług na przykład, żeby sprawdzić stan konta albo zrobić przelew. Więc jeżeli cokolwiek, jakkolwiek by się zadziało źle z tą aplikacją, to musimy reagować zanim to klient do nas zadzwoni i powie, że nam system bankowy nie działa. 
DANIEL: Prawda, dobra uwaga. 
BARTEK: Na ten monitoring myślę, że również można dorzucić jakby wszelkiej maści software as services, które będziemy chcieli używać i licencje z tym związane. Wiemy, że chmura Azure dostarcza całkiem niezłe rozwiązania związane z bezpieczeństwem klastra kubernetesowego, jak jest dobrze zaprojektowane oczywiście. Niemniej są lepsze rozwiązania na rynku, które można byłoby rozważyć całe takie security suits, ja bym nawet powiedział, które pozwalają jakby monitorować bezpieczeństwo klastra i zarządzać nim aktywnie. To jest zdecydowanie coś, co ja bym tutaj polecał w tym kosztorysie rozważyć, a także związaną z tym analizę całej architektury bezpieczeństwa. Słyszę, że klient jest jakby dojrzały, więc myślę, że nie będzie to jakieś duże ćwiczenie, ale jakby spojrzenie na bezpieczeństwo klastra z punktu widzenia tego bardzo fajnego frameworku 4C dostępnego na stronach Kubernetes, czyli Cloud Cluster Container i Code jest naprawdę fajne, bo przynajmniej pokazuje jaka jest nasza tutaj dojrzałość w pewnych obszarach. Reasumując, wszelkiej maści Software as a Service, wszelkiej maści licencje aplikacyjne, które są nam potrzebne, to jest coś, o czym często się zapomina.
DAMIAN: Czyli z tego, co dobrze rozumiem, mowa tutaj o licencjach na przykład takich jak dodatkowy software związany z monitoringiem, może z bezpieczeństwem, a może z użyciem kontenerów na lokalnych maszynach deweloperskich, bo przypomnijmy Docker Desktop od jakiegoś czasu jest płatnym narzędziem dla dużych firm, można to nazwać firmę typu Enterprise, nie wchodząc już w szczegóły licencyjne. Więc to też mogą być potencjalne koszty tej migracji. I jeszcze nawiązując do bezpieczeństwa, warto podkreślić to, co Ty powiedziałeś Bartek bardzo słusznie o czterech warstwach bezpieczeństwa, że to na bezpieczeństwo Kubernetes nie patrzymy tylko z perspektywy samego klastra, ale fajnie zostało to zaproponowane przez mądrych ludzi jako cztery takie warstwy, które wcześniej wymieniłeś i też warto, żeby nasi słuchacze o tym pamiętali, gdy będą mierzyć się z bezpieczeństwem Kubernetesa. 
BARTEK: Ja myślę, że pokrótce moglibyśmy jeszcze wspomnieć tutaj o paru ważnych aspektach jakby takich, które mi przychodzą na myśl, żeby też za długo może o tym kosztorysowaniu tutaj nie rozmawiać, takie rzeczy jak koszty związane z rozszerzeniem całych pipeline’ów infrastructure as a code o obiekty kubernetesowe, czyli tak zwane deploymenty, pody, serwisy, wszystkie jamle, o jak to się zwykle, jak to się… 
DANIEL: Wszystkie jamle. 
BARTEK: Wszystkie jamle. Koszty związane z integracją całego klastra w obecnym środowisku. My jeszcze nie rozmawialiśmy o tym, jak będziemy te serwisy przenosić na ten klaster, ale to jest kluczowy aspekt, żeby ten klaster był obecny w całej infrastrukturze klienta. Wszelkiej maści automatyzacji związane z samym klastrem. Wprowadzamy nową warstwę abstrakcji do naszej infrastruktury w formie właśnie Kubernetesa. Ona wymaga swoich własnych automatyzacji i zdecydowanie to jest często kosztowne. No i również ciekawa rzecz, a często pomijana, no to są nowe koszty wsparcia. Będziemy musieli przeszkolić ludzi, być może trzeba będzie dodać jakąś dodatkową, przynajmniej w tym początkowym etapie, moce do supportu, żeby oni byli w stanie to wesprzeć, to nowe rozwiązanie. To jest dodatkowy poziom skomplikowania. No i co? To by trzeba było chyba zmultiplikować jeszcze na testowe produkcyjne środowiska. O tym o czym żeśmy mówili. Więc to nie jest tanie, jak zwykle powtarzamy wszystkim klientom, z którymi pracujemy, że Kubernetes jest raczej drogą technologią wbrew pozorom, ale jest na pewno warta uwagi. 
DANIEL: Co często spotyka się z niemałym szokiem klientów, ponieważ jak to open source’owa technologia, darmowa, jak ona może być droga. Wszystko co darmowe koniec końców okazuje się dość drogie z powodów, które właśnie wymieniłeś. Ja myślę, że ta lista różnego rodzaju elementów w takim kosztorysie, którą wymieniłeś jest bardzo ciekawa. Po raz kolejny zrobiłem sobie notatki i pewnie przygotuję się dobrze do tej rozmowy z klientem, bo myślę, że te finalne koszty mogą być dla klienta dużym zaskoczeniem zwłaszcza, że tak naprawdę jeszcze nie mówiliśmy o tym, ile taki projekt tak naprawdę może trwać i jak sama migracja, ile za sobą sama migracja tak naprawdę pochłonie. Ale dobrze, do tego pewnie jeszcze przejdziemy za chwilę. 
BARTEK: I to pewno będzie też dobrym inputem do weryfikacji z klientem, czy dalej chce. To mógłby być taki checkpoint, prawda? 
DANIEL: Właśnie, to jest chyba kolejny checkpoint. Jak dobrze pamiętam, to był taki checkpoint wcześniej. To jest bardzo fajny element w takim, powiedzmy, wachlarzu umiejętności architekta, żeby dać klientowi możliwość decydowania na wielu etapach i jakby na każdym etapie dostarczać pewne wartości jak najniższym kosztem, żeby wspomóc dalszy proces decyzyjny. Myślę, że tutaj się to sprawdza idealnie.
DAMIAN: Dobrze, czyli co? Weryfikujemy z biznesem czy koszty infrastruktury całej tej otoczki, bezpieczeństwa, przeszkolenia ludzi i tak dalej. Czy to pokrywa się z wymaganiem biznesowym, jakie dostaliśmy na początku? Przyjmijmy, że tak, bo przyjmujemy, że tak. Więc od czego zacząć? Od razu siadamy do kodu i tworzymy klaster wyklikując go w Azur i wdrażając QC TLR, czy może jakoś inaczej do tego byśmy podeszli? 
BARTEK: Mnie ciarki przeszły po plecach. Nie, trzeba byłoby chyba napisać jakiś dokument, nie? Jakąś szeroko rozumiane HLD i LLD. To jest coś, co zawsze gdzieś tam stosujemy w naszych podejściach. Tutaj tylko może napomknę pokrótce, że dla nas HLD jest taką częścią bardziej biznesową, LLD to jest dokument czytany bardziej przez osoby techniczne, ale obydwa te dokumenty mają takich pięć filarów, które zawsze staramy się mieć w tej dokumentacji i one nam pozwalają się upewnić, że o niczym nie zapomnimy, kiedy projektujemy jakąś architekturę. No i to są te filary, pozwolę sobie wymienić, bo to jest coś, o czym warto pamiętać, to jest secure oczywiście, czyli bezpieczeństwo całego rozwiązania, monitor, o czym wspomniał wcześniej Damian, czyli jak monitorujemy na wskroś tą solucję, konfiguracja, czyli wszelakiej maści decyzje podjęte, no bo w końcu dokumenty architektoniczne to są dokumenty pełne decyzji, protect, czyli różnego rodzaju business continuity, disaster recovery rozwiązania i wreszcie govern, czyli część taka compliance’owa, patrzenie na to, jak jesteśmy zgodni z wymaganiami, jak jesteśmy zgodni z regulacjami na przykład i w jaki automatyczny sposób patrzymy na te wszelkie zmiany. Także takich pięć filarów ja zawsze staram się szukać w dokumentacji technicznej, w dokumentach HLD i LLD. Myślę, że w tym rozwiązaniu Danielu też bym ich szukał. 
DANIEL: Zdecydowanie taki jest też mój cel. Ja szczerze mówiąc, biorąc pod uwagę nasze też wspólne doświadczenie sprzed lat z budową różnego rodzaju serwisów opartych o kontenery, ja sobie nie wyobrażam czegoś takiego, jak siadanie wprost od razu i implementowanie w tej skali rozwiązania. Ja jakby rozumiem testowanie, próbny koncept i tak dalej, ale jakąś część uwagi należy poświęcić przemyśleniu tego jak to rozwiązanie oparte o Kubernetesa będzie właśnie integrować się z środowiskiem infrastrukturalnym klienta, bo wiadomo to, co projektujemy zwykle nie wisi w przestrzeni, nie wisi w pustce, tylko jest jakby częścią większego ekosystemu. Więc zwykle tym tematom poświęca się dużo uwagi i z mojego doświadczenia lepiej zastanowić się nad nimi na początku, nawet jeżeli miałaby to być krótka faza designu, bo oczywiście pisanie HLD-ków i LLD-ków w zależności od tego o jakim tutaj mówimy podejściu do rozwijania tego typu projektów, to może być kilka dni, kilka tygodni, kilka miesięcy nawet, w zależności od tego oczywiście jaki jest tutaj apetyt klienta na poświęcenie czasu na projekt, ale jakiś etap projektowania musi nastąpić, czy tego chcemy, czy nie. Przy tego typu rozmiarze zmiany myślę, że jest to nieuniknione, zwłaszcza też, że to taka obserwacja moja, może się zgodzicie, a może nie, ale ogólny poziom wiedzy na temat kontenerów w naszej społeczności IT nie tylko polskiej, on nie jest zbyt wysoki. Ja nie uważam się za absolutną alfę i omegę może tego tematu, ale widzę, że bardzo wiele moich kolegów dopiero raczkuje w temacie i myślę, że siadanie do implementacji bez odpowiedniego designu najpierw może się skończyć podjęciem niechcący bardzo wielu decyzji, które koniec końców okażą się straszne w skutkach i mogą tak naprawdę spowodować, że to rozwiązanie będzie nieużywalne. Więc jak najbardziej zgadzam się i ciekawe również podejście z tymi pięcioma filarami. Ono przynajmniej myślę umożliwia wejście w jakiś taki framework, w jakieś takie ramy i zastanowienie się, czy ja w ogóle jako projektant czy architekt czy designer, zwał jak zwał, czy ja w ogóle myślę o wszystkim, o czym powinienem myśleć. I jest to zwłaszcza przydatne, jak mówimy o technologii, której jeszcze tak do końca nie znamy, albo co do której jeszcze wiedzę u siebie rozwijamy. 
BARTEK: Zabawię się w product managera. Danielu na kiedy? Będzie to w przyszłym tygodniu? Czy potrzebne są dwa? Bo chciałbym coś pokazać biznesowi. 
DANIEL: Świetne, świetne pytanie.
DAMIAN: Cytując ostatnie takie pytanie, bo ja muszę project plan ułożyć. 
BARTEK: O tak to dokładnie. To jest bardzo dobre. O czym my tu rozmawiamy w ogóle? Jaki to jest rząd wielkości? Bo wiadomo, że nie mamy co estymować, ale jak nam się wydaje? 
DANIEL: Ja myślę, że temat wykonania odpowiedniego projektu i fazy migracji, czyli już wykonania tego, co w tym projekcie sobie założymy, raczej liczyłbym w miesiącach czy kwartałach niż w dniach czy tygodniach. Jakby stopień zmiany nawet w przypadku tak dojrzałego klienta wydaje się na tyle duży, że ja bym bał się, widząc estymacje pokroju jeden miesiąc czy kilka tygodni zwłaszcza, jeżeli ta estymacja zawierałaby w sobie również samą migrację tego systemu. Więc takie jest moje pierwsze przeczucie. Nie wiem, co o tym myślicie. 
BARTEK: Kwartały dla mnie, kwartały. 
DAMIAN: Zdecydowanie tak. 
BARTEK: Żartując, że kontenery to automatyzacja jest. Ja myślałem, że to wszystko szybko będzie. 
DANIEL: Wszystko samo się zrobi.
BARTEK: Wszystko samo się zrobi. Nie, kwartały, kwartały. Zobaczcie, że też nie rozmawiamy o tym, jak zespół będzie ustrukturyzowany, kogo tam potrzebujemy, jak on ma wyglądać, ale już jakby przesuwamy się w stronę kwartałów. 
DAMIAN: I to nie jest też tak, że my chcemy straszyć, żeby kogoś odwieźć o tej decyzji, tylko po prostu jesteśmy realistami. Kilka projektów już zrealizowaliśmy i to są nasze doświadczenia. 
BARTEK: No, dokładnie. Dobra, no to co? Tutaj żeśmy przegadali ten czas związany z budową. Znowu jest checkpoint z klientem, czy sytuacja ma sens i czy dalej są chętni. No to przyjmijmy, że jakby ten klaster gdzieś tam będzie projektowany, on będzie zdeployowany, zrobiony. Przedyskutujmy proszę o tej samej migracji tego rozwiązania w stronę kontenerów? Co tutaj możemy powiedzieć i zasugerować?
DAMIAN: Zakładając, że mamy kilkadziesiąt tych serwisów, czyli tych powiedzmy mikro komponentów całego systemu, pewnie dałoby się tutaj wyróżnić kilka podejść, jak zaprojektować proces migracyjny. Czy robić to na przykład jakoś per środowisko, na przykład migrujemy całe środowisko deweloperskie, następnie testowe, następne produkcyjne, a czy może migrujemy się tak jakby bardziej agile, czyli kilka mikro komponentów tudzież jeden mikro komponent migrujemy na Kubernetesa i zobaczymy jak to się będzie zachowywać. Trzeba by się zastanowić, które w ogóle z podejść jest możliwe, jakie są jego wady i zalety. 
BARTEK: To ja od razu może zauważę względem tego co powiedziałeś, tych dwóch podejść, one są zgoła różne, ale wydaje mi się, że to podejście, o którym wspomniałeś, w migrowaniu jednego czy kilku mikro komponentów przez wszystkie środowiska aż do produkcji, jest dość ciekawe, bo ono bardzo szybko da nam informację taką powiedzmy end to end. Bardzo szybko, relatywnie szybko może tak, będziemy wiedzieć czy całe to podejście ma w ogóle sens. Oczywiście zagrożenie tego jest takie, że jest to dość skomplikowane przedsięwzięcie i jest to też tak powiem all or nothing. Albo nam się uda, albo nam się nie uda, więc zrobimy wszystko, żeby doprowadzić do release na produkcję przynajmniej jednego komponentu. Ja tu widzę też takie zagrożenie z tym podejściem związane, że i tu popraw mnie jeżeli Damian, masz inne zdanie, ale mamy wtedy działające równolegle dwa środowiska infrastrukturalne i jedno nowe oparte o Kubernetesa, na którym mamy zdeployowany ten jeden mikroserwis czy kilka mikroserwisów, które zdecydowaliśmy się przenieść i całą masę innych komponentów, które działają dalej w starym dotychczasowym modelu. Więc tutaj trzeba było duży położyć nacisk na to, żeby jednak ta integracja tego klastra kubernetesowego była bardzo dobrze przeprowadzona z istniejącym środowiskiem. Nie wiem czy masz na ten temat jakieś dodatkowe jeszcze przemyślenia. 
DAMIAN: Ja uważam, że jak najbardziej słuszne tutaj podjąłeś takie powiedzmy punkty krytyczne, no bo wyobrażam sobie sytuację w ten sposób, że zmigrowaliśmy, nie wiem, pięć spośród pięćdziesięciu tych komponentów do Kubernetesa i teraz jeżeli mamy tutaj taki aspekt, że to ma działać praktycznie 99, 9% czasu, no to w momencie gdy faktycznie mamy jakiś problem, to gdzie szukać tego problemu? Czy to był problem z Kubernetesem, czy może z tymi serwisami pasowymi? Czy już ten zespół, powiedzmy, zdobył na tyle kompetencji, aby poradzić sobie z jakimś ewentualnym trouble shootingiem na przykład aplikacji, które działają na Kubernetes i jak do tego podejść, bo z pewnością proces wykrywania błędów w aplikacjach, które działają w modelu takim pasowym w chmurze versus aplikacji, które są wdrożone w Kubernetes, będzie zupełnie inny. Więc zgadzam się, migracja serwis by serwis taki bardziej podejście agile ma swoje wady. 
BARTEK: Jakby też nie zrozum mnie źle, ja widzę bardzo duże zalety tego procesu, no bo tak jak wspomniałem, przynajmniej widzimy end to end, jak działa nowe rozwiązanie. To jest niewątpliwie bardzo przydatna rzecz również z tej perspektywy, że może ona być też kolejnym punktem takim decyzyjnym, że jeżeli udowodnimy na jakimś jednym czy kilku przykładach, że taka migracja zrobiona end to end rzeczywiście może nie jest taka straszna, jak nam się wydaje, to może być duża zachęta do dalszej migracji. Z drugiej strony mamy to podejście, o którym wspomniałeś, środowisko po środowisku, czyli powiedzmy, że jeżeli dobrze rozumiem, na przykład migrujemy sobie całe nasze devowe środowisko i zamykamy je w klatce kubernetesowym i testujemy tak naprawdę integracyjnie całość tego systemu już w Kubernetes. Dobrze to zrozumiałem? 
DAMIAN: Tak, dokładnie. Generalnie chodzi o to i też byłem częścią takiego projektu, gdzie właśnie w ten sposób odbywała się migracja. Przepinaliśmy po prostu ruch po zakończeniu pracy nad jednym środowiskiem. Przykładowo zmigrowaliśmy środowisko testowe i cały ruch został przepinany z istniejących pasów, że tak się w skrócie wyrażę, czyli aplikacja TEC tutaj działała już na chmurowych usługach i po prostu po migracji, po zakończeniu migracji jednego środowiska do Kubernetes ruch końcowy został po prostu przepinany. Czyli mieliśmy taki jakby trochę blue green, ta migracja w stylu takim blue green. Zrobiliśmy środowisko obok tylko, że ono było już na Kubernetesie, a później puściliśmy na nie ruch użytkowników.
BARTEK: Okej, to brzmi ciekawie i potencjalnie wydaje się podejściem troszkę mniej ryzykownym, no bo jednak możemy całość testu przeprowadzić na nieprodukcyjnym środowisku. To na pewno byłoby też zachęcające. Ja myślę, że chyba jedno i drugie rozwiązanie, jedno i drugie podejście, service by service i environment by environment ma swoje zalety i wady. Ja myślę, że przynajmniej na tyle na ile teraz o tym myślę, w dużej mierze może zależeć wybór podejścia od tego, jaki apetyt na ryzyko ma dany klient. 
DAMIAN: Dokładnie, finalnie decyzja leży po stronie klienta. My jesteśmy tutaj po to, żeby wymienić wady, zalety, zaproponować jakie mamy opcje i uświadomić klienta, żeby wybrał najlepsze dla niego rozwiązanie. 
DANIEL: Okej, to brzmi ciekawie. Trochę zastanawia mnie jeszcze, nawet w oderwaniu już od tych dwóch podejść, powiedzmy, że już jedno z nich wybraliśmy i zakładam, że klient w jakiś sposób tę decyzję podejmie, to jak wyglądają etapy takiego procesu migracji? Już nawet powiedzmy, że weźmiemy ten jeden serwis. Zakładam, że taka migracja, takie przejście z klasycznego serwisu na serwis oparty o kontenery ma jakieś standardowe kroki, które pewnie się odbędą. Czy Wy macie jakieś doświadczenia z tym związane z wcześniejszych projektów albo wiecie, coś wam tam w głowie świta, o czym powinienem pamiętać, a co nie jest może takie oczywiste? 
BARTEK: Pamiętajmy, że mamy już obrazy gotowe w registru, co ułatwia sprawę.
DANIEL: Mamy obrazy, to prawda.
BARTEK: Więc teraz te obrazy powinniśmy w jakiś sposób wykorzystać na przykład przy pisaniu znanych nam YAML-i, tudzież kubernetesowych obiektów.
DAMIAN: Albo hand chartów na przykład. 
BARTEK: Albo handchartów i zapięcie tego w formie jakiegoś pipeline’u do deployowania, żebyśmy mieli CICD, który będzie nam mógł natychmiast te obiekty zdeployować. No i testy, testy, testy, testy, testy to jest najważniejsza rzecz. Głęboko ja zawsze sugeruję używanie test managerów, testerów automatyzacji infrastruktury. To jest klucz do sukcesu oraz zaplanowanie odpowiedniego odbioru tego serwisu na późniejszym etapie przez run, bo się jakby support całkowicie zmienia tego/ Także takie cztery myślę strefy bym wymienił.
DAMIAN: To szybkie podsumowanie zróbmy sobie, czyli tak, wybraliśmy już to podejście jak migrować, więc tworzymy obiekty kubernetesowe, aktualizujemy nasze istniejące pipeline’y CICD po to, żeby już nie wdrażały binarek, tylko wdrażały handcharty, obiekty kubernetesowe w Kubernetesie, zmiana modelu wsparcia, czyli po prostu musimy przygotować się na potencjalne incydenty, bo zawsze coś może się wysypać i musi być ktoś, kto będzie w stanie na to zareagować no i przede wszystkim to co Ty podkreślałeś Bartek, testy, testy i jeszcze raz testy.
BARTEK: Ja myślę, że słuchajcie moglibyśmy jeszcze tak długo, długo tutaj opowiadać, ale też czas się nam powoli kończy. Ja bym chciał tak jakby zebrać to wszystko, o czym żeśmy rozmawiali tutaj i pozwolę sobie na takie małe podsumowanie. Proces migracyjny do Kubernetesa jest skomplikowany i kosztowny, natomiast nie chcielibyśmy absolutnie straszyć. To jest fajna szansa też dla rozwoju projektu. Otwiera nowe możliwości takie jak do eksploracji jak DAPR, Service Mesh, same nowe komponenty, które pomaga jakby Kubernetes nam tutaj funkcjonalności wdrażać. Absolutnym benefitem jest to, że projekt jest nowocześnie prowadzony, nie mamy długu technologicznego. Również fakt, że ten projekt, o którym Daniel wspominałeś, tutaj opowiadałeś, jest, ma wszystkie prerekwizyty spełnione i jest naprawdę dobrym kandydatem do konteneryzacji. Cały czas ja mam problem z tym driverem biznesowym, coś co mi tutaj nie rezonuje. To jest jakby taka rzecz, która gdzieś sprawia, że ja mam taki kłopot trochę z tym projektem, z tą decyzją. No i wreszcie myślę, że jest coś, co jest oczywiste w każdej pracy architekta, jest istotnym uświadomienie product ownerowi, jakie są potencjalne ryzyka i koszty tej zmiany. No i też jakie benefity oczywiście, prawda. Tak myślę, że tak bym podsumował nasze dywagacje tutaj i dyskusję. Mamy nadzieję, Danielu, że pomogliśmy. 
DANIEL: Jak zawsze powiem, że nie, bo mi skomplikowaliście ilość myślenia, ale oczywiście pół żartem, bo serio to jest, że oczywiście, że pomogliście. Ja jestem świadom tego, że technologie oparte o kontenery są technologiami na ten moment jeszcze dość skomplikowanymi. Nie wszystkie są w takim miejscu rozwoju, które ułatwiłoby łatwe użycie na szeroką skalę, dlatego nie ukrywajmy, ale nasi klienci potrzebują nas i naszym zadaniem jest upewnienie się, że będziemy w stanie jakość klienta przez te wszystkie skomplikowane narzędzia i procesy przeprowadzić w sposób w miarę nie ryzykowny. Dlatego ja doceniam bardzo takie właśnie rozmowy, bo może nie mówiliśmy o jakichś niskopoziomowych szczegółach rozwiązań sieciowych w Kubernetesie, które też są ciekawe, tudzież innych skomplikowanych mechanizmów samego Kubernetesa, ale przynajmniej i ja mówię, może nawet przede wszystkim uświadomiliście mi i myślę też chyba słuchaczom, że jest pewna ilość tematów, które trzeba, mówiąc kolokwialnie, posprzątać zanim się zejdzie do technicznego mięsa. Tematów, które później nam oczywiście ułatwią dalsze rozmowy z klientem i ułatwią implementację zaprojektowania i implementację rozwiązania i myślę, że pod tym kątem ta rozmowa bardzo mi pomogła, bo też uświadomiła mi, że jeszcze jest kilka tematów, które muszę z klientem podjąć i decyzji, które klient będzie musiał podjąć, zanim w ogóle przystąpimy do jakiejkolwiek implementacji. 
DAMIAN: To jeszcze jedno słówko ode mnie. Oczywiście zgadzam się z tym, co powiedziałeś, że takie rozmowy są bardzo cenne z perspektywy zrozumienia problemu i uświadomienia klienta, że Kubernetes nie jest kolejnym pasem, czyli po prostu nie migrujemy się na kolejną platformę, która z domysłu będzie utrzymywana przez chmurę. Poniekąd tak, ale poniekąd to my będziemy też musieli na nią czuwać i to byłoby dla mnie chyba jeden z największych minusów w tej migracji. Abstrahując od całego szeregu plusów i benefitów to to, że mieliśmy wcześniej pasy, a teraz mamy Kubernetesa, będzie to z pewnością zmiana jeżeli chodzi o utrzymanie całego środowiska. 
BARTEK: Super, wiemy wszystko. Teraz trzeba to tylko zrobić.
DANIEL: Tak jest. Dzięki. Dzięki serdeczne. 
DAMIAN: Dzięki. 
BARTEK: Jeżeli ten temat, o którym dzisiaj rozmawialiśmy jest dla Was, drodzy słuchacze, interesujący, jest kilka materiałów, które mógłbym z czystym sercem polecić celem doczytania i troszkę rozszerzenia swojej wiedzy. Jest to z pewnością dokumentacja Microsoftu zwana Well-Architected Framework, a zwłaszcza jej sekcje poświęcone czemuś, co nazywa się Azure Kubernetes Service oraz pokrewna dokumentacja Microsoftu, Azure Architecture Center, gdzie znajdziecie gotowe przepisy na sprawdzone architektury, również zawierające klastry kubernetesowe. Nie jest to oczywiście literatura, która da Wam gotowe przepisy dla Waszych przypadkowych klientów, ale zdecydowanie pokaże dobre praktyki i nakieruje Was na jakieś ciekawe rozwiązania albo przynajmniej nakieruje na miejsca, w których coś więcej możecie doczytać. Oprócz tego wspomnieliśmy w dzisiejszej rozmowie o tym frameworku 4C w kwestii bezpieczeństwa kontenerów. Framework ten jest dobrze opisany również na stronach dokumentacji samego Kubernetesa i jest to na pewno literatura, którą warto sobie przyswoić. Nie jest to temat skomplikowany przynajmniej powierzchownie, a daje nam fajną możliwość zrozumienia obszarów, w których musimy się poruszać, jak chcemy mówić o bezpieczeństwie kontenerów. Również polecam przeczytanie w dokumentacji Kubernetesa opisu strategii release’owych, czyli Blue Green oraz kanary release’ów, o których dzisiaj wspomnieliśmy. Jest to też temat całkiem dobrze pokryty w tejże dokumentacji. Chciałbym polecić Wam więcej dokumentów czy też więcej materiałów o całości tego tematu dzisiejszego o migracji do Kubernetesa. Niestety, szczerze przyznam, że z takimi materiałami się nie spotkałem póki co w internecie, a przynajmniej nie w formie, która dawałaby jakieś duże benefity z ich przeczytania czy też przyswojenia sobie. Stąd też nie ukrywam, powstał pomysł na dzisiejszy podcast. Damian, czy Ty masz jakieś inne materiały, które mógłbyś polecić słuchaczom?
DAMIAN: Takich materiałów jest jak na lekarstwo w internecie. Ciężko mi cokolwiek polecić, jeżeli mam być szczery. Może poza jedną pozycją, która mogłaby ułatwić taką kulturę DevOpsową, prowadzenie takiej kultury DevOpsowej w organizacjach, jeżeli jeszcze jej nie ma, bo to też warto podkreślić coś, co dzisiaj mówiliśmy, że takim absolutnie wymaganiem wstępnym do migracji do Kubernetesa jest ta kultura DevOpsowa i ten mindset, który powinni mieć deweloperzy i nie tylko deweloperzy, ale również powinien być świadomy tego biznes. Więc z mojej strony polecę pozycję, która może ten mindset poniekąd przybliżyć, może pokazać jak ta kultura DevOpsowa powinna wyglądać i jak powinien wyglądać nowoczesny model dostarczania oprogramowania i taką pozycją jest książka Continuous Delivery autorstwa Jess Humble. Z czystym sumieniem mogę ją polecić. Jest to taka dość gruba cegła i myślę, że taki dobry wstępniak do prowadzenia kultury DevOpsowej w organizacjach.