#Microservices #Kubernetes #Serverless #DevOps #Cloud Native #Platform Engineering
80-stronicowy dokument bezpieczeństwa dla Kubernetes. Łukasz mówi wprost: “To zupełnie nowa skala problemów”. A to tylko jeden z wymiarów analizy platform dla mikroserwisów.
Szymon i Łukasz rozbijają IaaS, PaaS, kontenery, Kubernetes i serverless na pięć wymiarów: przenoszalność, bezpieczeństwo, automatyzację, monitoring i koszty. Werdykt? “Sam goły Kubernetes to nie jest platforma aplikacyjna, tylko runtime do orkiestracji”. O serverlessie? “Jest vendor lock-in. Sorry”. O Cloud PaaS? “Automatyzacja jest po prostu super” - ale tylko jeśli nie walczysz z filozofią dostawcy.
Największa patologia? Wchodzenie w Kubernetes bez zrozumienia, bo “jest tam tylko serce i marketing, umysłu zabrakło”. Rada dla rozsądnych: “Zacznij od PaaS bardzo często, jeżeli masz cloud’a”. A jeśli musisz mieć K8s - weź gotowca, nie buduj sam platformy.
Czy twoja organizacja właśnie popełnia któryś z tych błędów?
Linki i ciekawe znaleziska
Transkrypcja
Szymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…
Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io/28. Przypominamy również o Facebooku i Twitterze, gdzie możecie znaleźć różne ciekawe rzeczy. To co Szymonie?
Szymon Warda: Łącznie z rapsami.
Łukasz Kałużny: Tak, łącznie z ostatnim rapowaniem. Myślałem, że nie powiesz o tym. Tak, ostatnio rapowaliśmy w ramach Hot16Challenge i tak, zainteresowanych tam odsyłamy. Być może pojawiliście się tutaj właśnie z tego wyzwania. Dobra Szymon, to z linków co wygrzebałeś?
Szymon Warda: Z linków? Nic technicznego, ale coś co może mieć bardzo duże odbicie jeżeli chodzi o techniczne. Mianowicie kolejne informacje, plotki o tym, że amerykański Justice Department przygotowuje kolejny już antitrust lawsuits. I czym są antitrust lawsuits? To są generalnie bardzo duże z reguły kary, które jak pamiętamy, może niektórzy pamiętają, one między innymi swego czasu o mało co nie doprowadziły do rozbicia Microsoftu z monopolu po prostu. To są pogłoski, oczywiście niepotwierdzone, ale to już jest trzecia pogłoska, ponieważ pamiętajmy, że Unia Europejska przygotowała prawie 3 miliardową karę dla Google’a w kontekście manipulowania wynikami wyszukiwania pod kątem wyników wyszukiwania dla sklepów. Teraz jest opcja przygotowana a propos online advertising. I jeszcze jest kolejny antitrust lawsuit w kontekście dominancji, jeżeli chodzi o rynek wyszukiwania. I tak, jeżeli byśmy mówili o pojedynczej sprawie, to nie jest taki bardzo ogromny, nie jest taki pewnik. Ale to już jest kolejny przewidywany sztorm, który się zbiera nad Google’m. I nie oszukujmy się, ta dominancja, jeśli chodzi o wyniki wyszukiwania, jest dość znacząca. Każdy kto przeklina generalnie, że docsy microsoftowe przepinają się na polskie wyniki, to właśnie dlatego, że Google teraz dużo mocniej promuje strony polskie.
Łukasz Kałużny: Nie broń, Microsoft też próbuje promować lokalne języki.
Szymon Warda: Tak, jak najbardziej, też przełączają, żeby nie było. Ale to zaczęło się głównie z tego, że Google zaczął dużo mocniej promować w wynikach wyszukiwania strony, które są w języku osoby wyszukującej.
Łukasz Kałużny: Tak, to i ocena pod mobilki. Raczej to jest ciekawe, bo w Stanach chyba jest to plus drugie takie nastroje są też anty Amazonowe. Jest anty Google’owe i anty Amazonowe. Amazonowe są chyba zupełnie na takim naszym poletku, nazwijmy to gdzieś tam, raczej na poletku gdzieś etyki i innych takich rzeczy monopolistycznych, a Amazon gdzieś na części takiej biznesowej dostaje. Więc to jest ciekawy w ogóle trend, że to się może wydarzyć w tym roku.
Szymon Warda: Co dla mnie jest fascynujące, to jak pamięta się powiedzmy te wszystkie rozmowy i wszystkie antitrust lawsuit sprzed 15, 20 lat, to one się kręciły zawsze wokół Microsoftu. Teraz, jak mówi się o tych wszystkich antitrust lawsuit, MS prawie nigdy nie pada w plotkach nawet tak naprawdę, ogarnęli ten temat całkowicie praktycznie.
Łukasz Kałużny: Czy marketing robi swoje i podejście, że jest to cloud first, ale jak to mają te swoje empowering every people and every company.
Szymon Warda: Tak, ale też są zgodni z wieloma i są bardzo proaktywni, że chodzi o wiele praw, chociażby w Unii Europejskiej, jeśli chodzi o prawa.
Łukasz Kałużny: Tak, to jest akurat gdzieś tam podejście, jest to duża zaleta, że trochę mają inny PR w pewnych miejscach, który może tak nie dotyka.
Szymon Warda: Dobrze Łukaszu, co u Ciebie?
Łukasz Kałużny: Wiesz co, wpis jest taki może w ogóle zupełnie z nami niezwiązany na pierwszy rzut oka techniczny, na temat M365, Microsoft 365. I to jest wpis na takim starym polskim blogu W-Files gdzieś tam jednego z takich dziadków Community Nexora. I ma bardzo fajną perspektywę, która dotyczy zupełnie w ogóle architektury i wykorzystywania teraz produktów. Mianowicie, że pewne funkcjonalności rzeczy trzeba oceniać w kontekście platformy, czyli inwestycje, wykorzystanie. Tam mówię akurat o mechanizmach DLP, ale chodzi o całość, że powinniśmy z myśleniem tak naprawdę przy tym, co teraz robimy, odejść od pojedynczych pudełek produktów, a skupić się na tym, jeżeli coś jest platformą, to ocenić to dokładnie jako platformę, czyli świadomie, czyli przestać myśleć. To właśnie Nexar bardzo fajnie uchwycił, żebyśmy przestali usilnie myśleć on premise’owo o pewnych rzeczach, kiedy robimy to w świecie takim czysto cloudowym. Oni mówią to akurat takiego tego modern workplace całego takiego productivity. Ale to na nasze takie części projektowania rzeczy, architektury, dobieranie rozwiązań też ma bardzo dużą rację bytu.
Szymon Warda: Jak najbardziej tak. To jest ta potęga, czemu Microsoft między innymi bardzo łatwo wchodzi w korporacje i czemu Azure jest w korporacjach? Bo korporacje już z reguły mają umowy 365, więc ten ekosystem już jest otwarty. Tak, to jest słuszna bardzo uwaga.
Łukasz Kałużny: Ewentualnie nowe dokupienie to rozszerzenie.
Szymon Warda: Tak. Dobrze, przejdźmy do naszego głównego tematu, bo kontynuujemy temat z poprzedniego odcinka i naszą całą serię, sagę można powiedzieć o mikroserwisach, patologiach, overhead’ach i wszystkim co się wokół dzieje.
Łukasz Kałużny: Tak, patoserwisach.
Szymon Warda: O, bardzo dobra nazywa.
Łukasz Kałużny: Patoserwisy.
Szymon Warda: To trzeba wypromować.
Łukasz Kałużny: Oj tak.
Szymon Warda: Dobrze, to o czym dzisiaj Łukaszu?
Łukasz Kałużny: Dzisiaj bierzemy rzecz, o której już bardzo myślimy, a czasami podejmujemy decyzję i robimy, czyli o platformie aplikacyjnej, na której odpalamy nasze mikroserwisy, sposobie ich odpalenia. Konkretniej, nie myśląc teraz o bazach danych i innych rzeczach, tylko ta część, taka moc obliczeniowa, gdzie to faktycznie odpalamy.
Szymon Warda: Czyli to, co będzie hostowało naszą warstwę aplikacyjną.
Łukasz Kałużny: Tak, dokładnie, dokładnie.
Szymon Warda: Dobrze, to skoro już mówimy o tym poziomie i skoro to jest kontynuacja poprzedniego odcinka, no to zaczniemy od naszych obszarów analizy. Pierwszy obszar analizy - jak spojrzeć na nasze platformy?
Łukasz Kałużny: Wiesz co? I wyszło nam w naszych rozmowach i też jak przygotowaliśmy się, że pierwszym wymiarem będzie przenoszalność tego rozwiązania. Bo dużo osób mówi o agnostyczności, vendor lockingach, multi cloudach i innych rzeczach. Więc na pierwsze idzie przenoszalność, jako pierwszy taki wymiar do analizy.
Szymon Warda: Dobra, drugi.
Łukasz Kałużny: Bezpieczeństwo i sieć, bo jest on istotny i w teorii potrafi kopnąć w tyłek.
Szymon Warda: Tak. I tutaj wyjaśnijmy, czemu połączyliśmy obydwie rzeczy. No bo często będzie tak, że bezpieczniki będą sensownie jak najbardziej, powiedzą, że izolacja, niektóre maszyny, żeby nie były dostępne publicznie, jest ważne. Więc to się wlicza jak najbardziej w bezpieczeństwo. Trzeci wymiar.
Łukasz Kałużny: Automatyzacja i wdrażanie nowej wersji. Tutaj to połączyliśmy ze sobą bardzo świadomie, o czym chyba później w trakcie, dlatego.
Szymon Warda: I dorzuciliśmy tutaj autoskalowanie, bo to jest element automatyzacji.
Łukasz Kałużny: Tak, czy jest to rzecz platformy, czy danej platformy, czy nie.
Szymon Warda: Tak, dokładnie.
Łukasz Kałużny: Tak, to będzie dobre określenie.
Szymon Warda: Czwarty wymiar.
Łukasz Kałużny: Monitoring, bo trzeba wiedzieć, co się dzieje.
Szymon Warda: Tak, odsyłamy do odcinków o observability, jakby ktoś miał wątpliwości. Ostatni.
Łukasz Kałużny: Najbardziej przez nas znienawidzony, czyli koszty. Bo na koniec dnia ktoś się pyta: ile to będzie kosztować?
Szymon Warda: Tak. No i wchodzi teraz tutaj wielka dyskusja, która nam trochę zamieszała w platformach, które będziemy omawiali. Czyli mówimy tutaj na Cloud i on premise i będziemy rozróżniali, ponieważ są znaczące różnice przy użyciu konkretnych platform. Więc to uprzedzamy, trzeba mieć na uwadze.
Łukasz Kałużny: Tak. Niektóre rzeczy są połączone, bo w niektórych miejscach doszliśmy do wniosku, że trzeba to połączyć. W niektórych to rozbiliśmy, to w zależności od potrzeby.
Szymon Warda: Dobrze, to teraz przejdźmy przez platformy. Jaka jest pierwsza platforma? Bo idziemy niejako od dołu.
Łukasz Kałużny: Zaczniemy tak naprawdę od IaaS-u, częściowo PaaS-ów i kontenerów, czyli sposobie odpalania tych binarek, naszych aplikacji. Przy czym o kontenerach teraz bardzo fajnie. Nie mówimy tutaj o kontenerach odpalanych w Kubernetesie.
Szymon Warda: Tak, dokładnie.
Łukasz Kałużny: To jest kontener odpalany na usłudze albo goły na VMce, nie na Kubernetesie.
Szymon Warda: Dobrze, to jak już idziemy do poziomu wyżej, to oczywiście kolejny będzie Kubernetes.
Łukasz Kałużny: Kubernetes i tu będzie on rozbity faktycznie na dwa, na on prem i na clouda, bo będziemy znacząco gdzieś wskazywać na te rozbicia.
Szymon Warda: Bo różnica jest znacząca. Faktycznie Kubernetes pozwala fajnie Clouda wykorzystać. I trzeci poziom świadomości jest…
Łukasz Kałużny: To serverlessem, do którego też częściowo odsyłamy do jednego z odcinków, jak i w sumie o Kubernetesie, do jednych z pierwszych odcinków.
Szymon Warda: Tak, i tu od razu powiedzmy, że o ile są opcje serverlessa na on premie, to tak naprawdę one są znikome i w naszej dyskusji raczej je pominiemy. Jest KEDA, jest Knative, ale no nie po prostu.
Łukasz Kałużny: Inaczej, mieliśmy naszą wewnętrzną dyskusję i to się… Powiedzmy, że jeżeli będzie ktoś tego potrzebował, to wiedział i skorzysta z tego. To nie jest rzecz, którą trzeba wiedzieć i robić na siłę.
Szymon Warda: Tak, i to wymaga naprawdę dużych organizacji, które by utrzymywały nową platformę. W większości przypadków nie ma sensu w to iść. Idąc, tak naprawdę wchodzimy teraz, przeanalizujmy sobie tak naprawdę kolejne platformy. Czyli mamy wymiary, mamy o czym będziemy mówili. To teraz przechodzimy przez kolejne punkty. I punkt pierwszy, czyli popatrzmy sobie na kontenery w on premise, kontenery w cloudzie i PaaS-y dojdziemy. To tak naprawdę o jakim hostowaniu, o czym w ogóle w tym momencie mówimy? Jaki tutaj masz?
Łukasz Kałużny: Jeżeli sobie popatrzymy na runtime’y, to one są tam wymieszane, jeśli chodzi o kontenery i PaaS-y binarkowe w Cloudzie. Bo możemy powiedzieć, że w Microsoft mamy App Service, w Googlu mamy App Engine, Cloud Runa, Fargate AWS-owy, więc jest cała taka przestrzeń gotowych usług, do których możemy albo wrzucić naszą binarkę, skompilowany kod i jest tam framework aplikacyjny, który vendor za nas utrzymuje, albo możemy odpalić tam swój kontener w tym.
Szymon Warda: Mamy jeszcze ACI - Azure Container Instances, bo chyba ominąłeś.
Łukasz Kałużny: Może tak, może nie, ale ogólnie usługi do odpalania tych kontenerów jako usługi, bądź binarek w postaci właśnie PaaS-owej.
Szymon Warda: Tak. I one są gotowe, dojrzałe i naprawdę można z nich korzystać, jak najbardziej.
Łukasz Kałużny: Tak. I tutaj też wrzucamy niejako, kiedy mówimy o on premisie, to mówimy o po prostu VM-kach z kontenerem albo z binarką. I tak samo też będziemy wspominać i przecinać cloudowy IaaS, cloudowe VM-ki. I teraz ważne co przez to wszystko myślimy? To słuchajcie, to jest kontekst taki, że robimy to podręcznikowo, nazwijmy to podręcznikowo i lecimy z automatyzacją tych rzeczy. Czyli nawet jeżeli korzystamy z IaaS-u, to będziemy mówili o automatyzacji. To jest taki istotny wymiar, żeby się nie pogubić. To nie będzie, Szymon to świetnie określił, nie RD-kujemy się do tej VM-ki, czy nie zapinamy sesji SSH, żeby coś skonfigurować.
Szymon Warda: Tak, czyli keysety azure’owe i generalnie konfigurujemy to, co nam chmura daje, czyli konfigurujemy to, że nasze VM-ki są dostawiane albo są usuwane z naszej infrastruktury.
Łukasz Kałużny: Więc to ta perspektywa istotna czy skaling grupy w AWS-ie i traktujemy to PaaS-owo. Dobra.
Szymon Warda: To teraz przejdźmy przez wymiary. Naszym pierwszym wymiarem, o którym mówiliśmy, chyba taki często rozważany, to jest właśnie przenoszalność. I tu oczywiście rozbijamy cloud w kontekście cloud on prem. Jak to wygląda Łukaszu?
Łukasz Kałużny: Wiesz co? I teraz tak, od samej strony aplikacji, jeżeli będziemy korzystać z mechanizmów wstrzykiwania do runtime zmiennych środowiskowych, to będzie… Rzucając od razu przykładem, w wielu usługach PaaS-owych możemy wziąć jakiegoś Vaulta do kluczy, na przykład azure’owego Key Vaulta i usługa, taki App Service pobierze nam referencje z takiego Key Vaulta i wstrzyknie nam do aplikacji taki config, bądź wstrzyknie nam bez żadnej integracji od strony kodu. Czyli z perspektywy aplikacji, jeżeli nie integrujemy się z żadnymi rzeczami, które są czysto u jednego vendora, korzystamy z API jednego vendora, to jest to przenoszalne, czy to będzie binarka, czy będzie to kontener. Jeżeli nie ma zależności do danej platformy, on realnie jest przenoszalny.
Szymon Warda: To lecimy teraz w takim razie PaaS, ale bez runtime w kontenerze.
Łukasz Kałużny: Czyli to jest znowu te mocne. To zależy od tego, czy wgrzaliśmy się w platformę czy nie. Sama aplikacja z perspektywy, to jest ważne, sama aplikacja z tej perspektywy, możemy ją przenieść, jeżeli nie zintegrowaliśmy się za mocno z tymi API management’owymi i innymi, które są wokoło, które są sexy i bardzo przyjemne.
Szymon Warda: Tak, czyli dochodzimy do takiego dość oczywistego wniosku, że na tym poziomie tego vendor lockingu nie ma, chyba że go sami wprowadziliśmy na poziomie kodu aplikacyjnego. Tyle.
Łukasz Kałużny: Tak. On się pojawi potem z perspektywy danych, storage’y i innych rzeczy, z perspektywy data’y czy okolic.
Szymon Warda: Ale to już nie jest wymiar niejako platformy. To lecimy dalej. Security.
Łukasz Kałużny: Tu rozbijamy już bardzo wyraźnie na cloud, na kontenery i kontenery takie cloudowe as a service i PaaS-y versus on premis i cloud IaaS, to będą takie dwa przecięcia. Tutaj słuchaj, jak tu się chyba zgodzimy DDoS lata, DDoS, te części takie zabezpieczeniowe, one są przecudne tak naprawdę w warstwie PaaS-owej, jeżeli tego używamy. 1 rzec,z jeżeli chcemy to kontrolować, to potrafi bardzo drogo kosztować.
Szymon Warda: Chociaż nawet jak pojedziemy czystym IaaC-em, to mimo wszystko Azure i dowolny dostawca chmury, te ataki DDoS-owe nas obroni, bo to jest w jego interesie oczywiście. Ataki bezpieczeństwa, wiadomo, że to spada na nasze barki. Tak.
Łukasz Kałużny: Czyli jest to. Ja bym rzucił o bezpiecznikach. Będą w PaaS-ie i w kontenerach. Niestety będą mieli ból tyłka o braki.
Szymon Warda: Tak, będą braki. Będą o to, że niektóre PaaS-y są domyślnie dostępne publicznie. Od tego się już odchodzi, większość dostawców chmurowych już pozwala na to generalnie, żeby one były prywatne. Jest to dalej istniejący problem.
Łukasz Kałużny: W niektórych miejscach. I druga rzecz, z bólów takich bezpieczeństwa, że pewne rzeczy przychodzą, nazwijmy to, by design od danego vendora, sposoby hardeningu czy obcięte dla nas dostępy. Czyli taki bezpiecznik na przykład może być zdziwiony, że ma dostęp tylko do kawałka sandboxa i nie może zobaczyć niczego poniżej, bo to dostawca odpowiada za to, żeby tak naprawdę zarządzać tym za nas.
Szymon Warda: Tak.
Łukasz Kałużny: To jest też genialną zaletą.
Szymon Warda: Fajnym wymiarem chmury jest to, że generalnie mamy cały system ról, uprawnień i możemy zarządzać dostępem niejako nie tym ludzi operujących na poziomie platformy. To jest też bardzo, bardzo fajna i ciekawa rzecz. Dobrze, to teraz powiedzieliśmy sobie o cloudzie. To teraz jak to wygląda na on premie i w takim cloudowym IaaS-ie.
Łukasz Kałużny: Dobra, to pierwsza rzecz, która jest zupełnie realna. Mamy pełną kontrolę nad siecią, czyli bez żadnego problemu zrobimy sobie, nawet jeżeli będziemy robili to w cloudzie i robimy to na IaaS-ie, możemy to schować za siedmioma firewallami i tyle. I każdy jest w starym świecie i czuje się pewnie.
Szymon Warda: Bezpiecznie, dokładnie. Możemy robić sieci, segmentacje, wszystko.
Łukasz Kałużny: Tak, wolę użyć ten. Za to na duży minus, utrzymanie może być realnym bólem.
Szymon Warda: Niestety tak. To jest kwestia, ja bym określił, że security. To bardzo mocno widać w kontekście tego, że często organizacje, jeszcze widzę organizacje, które się boją robić update’y i te update’y kiszą na przykład przez trzy miesiące, żeby one były wygrzane. Co jest, w tempie, w jakim są obecnie dziury znajdywane, naprawdę realnym zagrożeniem.
Łukasz Kałużny: Więc to. Druga rzecz, troszeczkę powiedzieliśmy o kontenerach, że możemy taki workflow odpalić jako kontener na takiej VM-ce bez żadnego Kubernetesa. Co jak wiem, jeżeli wiemy co robimy to jest naprawdę takie stand alone. Standalone’owe farmy też potrafią się sprawdzić, w szczególności jak instancja potrzebuje dużo zasobów. I teraz taka rzecz, że tu pojawia się nowa cegiełka, którą już w sumie znowu niestety musimy odesłać troszeczkę o szerszy kontekst do odcinka o Dockerze ad domino 2020, który był kilka kilka odcinków temu. I tam jest cały kontekst security, bo trzeba będzie wokół kontenerów na przykład zbudować sobie całe flow’y security. I są dwie części. Będzie CI/CD, której teraz nie poruszamy od strony security, ale z drugiej strony utrzymanie tego i skanowanie tego w runtime’ie, żeby mieć pewność, że wszystko jest ok.
Szymon Warda: Tak, biorąc to wszystko w on premie, bierzemy na siebie całą odpowiedzialność i to wygląda dużo gorzej. Dobra, kolejny wymiar, jeżeli mówimy o automatyzacji, provisioning, czyli wgrywanie nowej wersji. Zacznijmy od najprostszego, czyli na on premie, gdzie na on premie automatyzacja wygląda jak?
Łukasz Kałużny: Inaczej, jak sobie jej nie wystrugamy to nie istnieje po prostu. I chyba trzeba powiedzieć, że ten punkt trzeci, teraz mi jeszcze taka rzecz wpadła do głowy, że ta automatyzacja razem z monitoringiem, o którym powiemy i skalowaniem, to jest chyba takie clue całych platform mikroserwisowych, jeżeli chodzi o część aplikacyjną.
Szymon Warda: Potrzebne.
Łukasz Kałużny: Żeby to podkreślić, że to jest te mięso, które powinniśmy rozważać.
Szymon Warda: Tak, to są elementy, które nas nie bolały przy monolitach, przy takich systemach, które były wielkie, miały monstrualne VM-ki pod siebie. Przy serwisowej aplikacji, przy budowaniu platformy to nas dużo bardziej zaboli. To idziemy kawałek dalej. Cloud IaaS.
Łukasz Kałużny: Wiesz co, cloud IaaS. I teraz tak, zacznijmy, automatyzacja istnieje. Jest ona. Trzeba się trochę napracować. I teraz co ważne? Platformy nas wspierają w tym. Czyli czy weźmiemy AWS-a, weźmiemy Amazona, czy weźmiemy Google’a, są praktyki jak używać w pełni zautomatyzowanych IaaS-ów. I ważne, nie trzeba tego wymyślać na nowo. Są packery, deployment skrypty dla instalacji, cloud init, więc jest duża mnogość opcji dostarczenia aplikacji, jak i powołania tego środowiska. Tylko trzeba nie wymyślać koła na nowo. I fakt, trzeba się będzie troszeczkę napracować, przynajmniej na starcie.
Szymon Warda: Ja tu dodaję, zawsze dodaję takie jedno ostrzeżenie, że nie wolno patrzeć na tą automatyzację, szczególnie w kontekście skalowania, jako na taki srebrny pocisk, który przeskalujemy się w ciągu ułamków sekund. Nie, nie, to z reguły trwa i trzeba brać na to poprawkę. Więc generalnie sama konfiguracja, samo zdefiniowanie jak powinno wyglądać skalowanie też nie jest łatwym procesem. Trzeba nad tym się pochylić i poświęcić na to trochę czasu.
Łukasz Kałużny: Ale inaczej, skalowanie, platforma nas w skalowaniu wspiera, jak już umiemy wystawić odpowiednie metryki.
Szymon Warda: Zgadza się, jak najbardziej. Dobrze, to teraz idziemy generalnie na cloud’owego PaaS-a.
Łukasz Kałużny: Dobra i z cloud’owym PaaS-em jest tak, moglibyśmy określić, patrząc się w stronę automatyzacji, to jest po prostu super. I tutaj nie możemy, nie ma co powiedzieć. Większość posiada toolingi z perspektywy takiej DevOps Experience, Developer Experience, to jest już dojrzałe w kontekście automatyzacji. Jest mnogość opcji, które możemy wybrać i będą poprawne.
Szymon Warda: Zgodzę się jak najbardziej i ja nie ukrywam, że jestem dużym fanem jeżeli chodzi właśnie o cloud’owego PaaS-a, bo daje taki doskonały środek w kontekście, trudno, w kontekście wejścia i daje to całe piękno, jeżeli chodzi o skalowanie chmurowe, z jednym ale…
Łukasz Kałużny: Zostawmy to na podsumowanie.
Szymon Warda: Tak, z jednym ale, ta filozofia dostawcy i walka z tym, że każdy dostawca robi to trochę po swojemu i walka szczególnie na poziomie aplikacyjnym, jak to powinno wyglądać, nie jest dobrym pomysłem. Go with the flow.
Łukasz Kałużny: Inaczej, dokładnie, go with the flow, to jest taki… W ogóle inaczej, przy cloud’zie to jest podstawowe, nie walczymy z filozofią dostawcy. Koniec. Jeżeli tak rekomenduje i sami nie rzeźbimy czegoś niesamowitego, to nie ma sensu. No i skalowanie. Tutaj, inaczej, moglibyśmy powiedzieć, że jest super, bo tak jest, ale są pewne przypadki. Takie AC i w Azure się nie skalują, nie można powiedzieć, że chcemy mieć 10 instancji tego samego kontenera, bo trzeba sobie to zrobić w jakimś template, skrypcie, innej rzeczy. Więc nie ma takich autoskalerów.
Szymon Warda: Ale mamy auto skalowanie na poziomie app service’ów, gdzie możemy to zrobić odpowiednio, do konkretnego przypadku użycia.
Łukasz Kałużny: Tak, więc to są, nazwijmy, to jest właśnie te przejście, o którym trzeba pamiętać.
Szymon Warda: Tak. Kolejny wymiar - monitoring. I idziemy pierw cloudowe.
Łukasz Kałużny: Dobra, cloudowe. Po prostu jest basic i to co dają dostawcy po prostu jest godne już do użycia. O tak, można tego spokojnie użyć. Niektórzy mogą narzekać, że na danej platformie czegoś im brakuje, albo mają wąski zakres do użycia. Ale to jest cena tego, że jest to wygodne i szybkie do zrobienia.
Szymon Warda: Tak, to co ja lubię, to jest to automatyczne wstrzykiwanie agentów do monitorowania do wewnątrz VM-ki. Czyli my się tym nie martwimy, tylko VM-ka, którą dostajemy niby z czystym systemem operacyjnym, jeden przycisk i mamy tam agenta, który nam zbiera większość metryk, takich na poziomie systemowym.
Łukasz Kałużny: Tak, albo 10 linijek w terraformie czy w ARM-ie, które mówią, że ma być zdeploy’owany razem z tym wszystkim.
Szymon Warda: Tak. I to jest bardzo, bardzo wygodne, bo znowu idąc teraz dalej, na on premie jest z tym gorzej. Więc jakby tu…
Łukasz Kałużny: Jeszcze trzeba dodać, są też third party usługi, które się monitorują, ale nie tak genialnie. Bo tak, bo musimy coś już zadbać od tego.
Szymon Warda: Tak.
Łukasz Kałużny: No dobra i on prem. Jeżeli wykorzystamy tool SAS-owy, to może być fajnie. Jeżeli wykorzystamy SAS-owe toole do monitoringu.
Szymon Warda: Tak, jest z tego sporawo, nie są z reguły tanie, to trzeba zaznaczyć.
Łukasz Kałużny: Raczej tak. I druga opcja jest taka, że kiedy niestety musimy z jakichś przyczyn mieć ten monitoring on premowo, lokalnie razem z tym, to tak naprawdę mamy dwie opcje albo budujemy coś samemu, bierzemy jakiegoś ELK-a, Grafanę, Prometheus’a, Jaggaer’a, albo wydajemy worek kasy na Splunk’a, Dynatrace’a.
Szymon Warda: Tak i pamiętajmy, że jak się wchodzi w cenniki, szczególnie Splunk’a, to doskonale teraz można zrozumieć czemu te cenniki wyglądają jak wyglądają, bo to jest dość wąskie grono klientów, które za bardzo nie ma wyboru. Po prostu regulacje mówią, że dane o logach muszą być u nich i koniec kropka.
Łukasz Kałużny: Kropka. A potem zarchiwizowane na 5 czy 10 lat i prawnicy mogą jeszcze nie pozwolić tego po tym czasie skasować, bo coś.
Szymon Warda: Tak może być, dokładnie.
Łukasz Kałużny: Tak. I teraz ważne, IaaS-a, liczymy tutaj, taki IaaS cloud’owy, liczymy do clouda. Bo możemy wykorzystać sobie stamtąd, a jak ktoś chce to może się skrzywdzić i budować własny stos, bo może mieć to w niektórych miejscach, jeżeli coś robimy dużego, może gdzieś ten własny stos przy cloud IaaS-ie mieć sens.
Szymon Warda: Jak najbardziej. Dobra. Ostatni wymiar - koszty.
Łukasz Kałużny: Dobra. Zaczynając może od on premise’u, to jest bardzo ciekawe, bo to jest też trochę moja zmiana myślenia w ciągu ostatnich dwóch lat, bo są to koszty inwestycyjne. Czyli zazwyczaj taki on prem to są koszty inwestycyjne.
Szymon Warda: Wyjaśnij Łukaszu czym jest koszt inwestycyjny.
Łukasz Kałużny: Czyli taki, który robimy jednorazowo, a potem amortyzujemy sobie księgowo. I te koszty, czyli tzw. capex i on, mimo że marketing o cloud’zie mówi, że opex jest taki świetny…
Szymon Warda: Wyjaśnij.
Łukasz Kałużny: To w wielu branżach… Opex to są koszty operacyjne, czyli takie koszty, które płacimy co miesiąc. I teraz, co ważne, w wielu branżach, mimo mówionego marketingu przez dostawców cloud’owych, ten capex nie jest zły, jest nawet preferowany względem kosztów operacyjnych ze względu na to, jak są robione wyceny i inne rzeczy, w jaki sposób są raporty giełdowe i inne zabawki wystawiane, za co zarząd jest nawet wynagradzany i za co ma bonus CFO. Więc jest różna perspektywa, ale tak. Czyli on premise to jest zwykle, to będzie rzecz inwestycyjna upfrontowo. Druga rzecz, trudno policzyć taki prawdziwy, takie pełne TCO z mojej perspektywy. Często widziałem, że w wielu nawet dojrzałych organizacjach był z tym problem.
Szymon Warda: To ja jeszcze wyjaśnię, TCO - Total Cost of Ownership, całkowity koszt posiadania.
Łukasz Kałużny: Dobra i takie przypadki, jak mówiłem właśnie o tym Total Cost of Ownership, to mamy przypadki, zawsze to mnie fascynowało, potem widzisz wewnętrzny cennik kosztu maszyny wirtualnej i ona na przykład z licencją na Windowsa 2 core’y, 4GB RAM -u kosztuje 800 czy 900 zł miesięcznie. A w niektórych organizacjach jeszcze więcej.
Szymon Warda: To masz jeszcze dobry case, że te koszty są widoczne. Często w ogóle te koszty są, że tyle potrzeba i na poziomie zamawiającego nie jest to widoczne, co często, bardzo często prowadzi do overprovisioningu, bo bierzemy na zapas albo bierzemy sytuacje, bo i tak obetną. Więc tutaj widać maszyny, które są po prostu, mają utylizację na poziomie 20%, bo raz na jakiś czas mają peak do 50 i wszyscy się przestraszyli.
Łukasz Kałużny: Tak, dokładnie.
Szymon Warda: Dobra, a jak to wygląda w kontekście cloud’owym? Tutaj jest magia.
Łukasz Kałużny: Tu jest odwrót, czyli jest opex i większość tego TCO jest widoczna na rachunku po prostu.
Szymon Warda: Ja jeszcze dorzucę, bo to faktycznie większość jest opex, ale możemy zrobić capex’a przez rezerwowanie na ileś lat do przodu. Różne kombinacje z optymalizacjami kosztowymi możemy wprowadzić jak najbardziej.
Łukasz Kałużny: Tak, tak, czyli można tam płacić upfront, płacić miesięcznie i mówimy, że jakąś pulę capacity przedkupujemy u danego dostawcy, na przykład na app service’y i dostajemy też za to zniżki, więc są pewne pola manewru. Czyli mamy na przykład to, co wiemy, że system na pewno weźmie, to możemy mieć zarezerwowane czy to w IaaS-ie, czy to w PaaS-ie. A te wszystkie skoki w górę, które istnieją, mogą być już rozliczane tak zupełnie opex’owo, dodatkowo. Więc to jest dobra rzecz.
Szymon Warda: Normalna.
Łukasz Kałużny: Pay as you go. I rzuciłbym problem, który jest to, co powiedziałeś o overprovisioningu, bo przez myślenie on premowe on często potrafi występować.
Szymon Warda: Tak, przenoszenie myślenia on premowego do clouda występuje i to dalej wygląda, że wygląda tak, że faktycznie są maszyny w chmurze, które dalej mają użycie 20%, bo ludzie nie polegają na skalowaniach, nie polegają na wszystkim co chmura daje.
Łukasz Kałużny: Albo boją się zeskalowywania w dół. To jest taki najczęstszy przypadek. Boją się zmniejszania instancji, włączania autoskalerów, zmniejszania rozmiarów instancji autoskalerów. Druga sprawa, boją się skalowania w dół poniżej jakiejś pewnej liczby, kiedy widać mimo, że nie ma tej utylizacji, to jest duży ból.
Szymon Warda: Tak, to co ja widuję to jest to, że coraz częściej wprowadzają autoskalowanie na poziomie czasowym, że poza godzinami pracy jest skalowanie w dół albo skalowanie węższe, czyli mamy mniej maszyn. Jedno i drugie może występować. Więc to już stało się powoli standardem i to mnie cieszy bardzo mocno.
Łukasz Kałużny: Tak, to już powoli zaczyna być. A i TCO można o wiele łatwiej policzyć i na papierze kurde, zawsze wyjdzie wyższy, bo mamy więcej rzeczy po wystawione na dzień dobry na naszym rachunku, więc je widać po prostu, wszystkie elementy.
Szymon Warda: Zgadza się. Tak naprawdę dochodzimy do takiego trochę wniosku, że czemu połączyliśmy PaaS-a i IaaS-a? Bardzo prostego. Bo to, czy aplikacja potrzebuje dostępu do rzeczy poza aplikacyjnymi, typu jakichś systemowych, bierzemy IaaS-a. Jeżeli nie potrzebuje, to automatycznie idziemy w PaaS-a. I tu opcje, jeżeli chodzi o chmurę, mamy bardzo, bardzo do siebie podobne. Takie małe podsumowanie, jakby ktoś nie wyłapał.
Łukasz Kałużny: Dobra.
Szymon Warda: Idziemy do kolejnego, czyli idziemy do Kubernetesa.
Łukasz Kałużny: Tak.
Szymon Warda: W takim razie…
Łukasz Kałużny: K8s.
Szymon Warda: Dobrze. Jak wygląda przenoszalność?
Łukasz Kałużny: Wiesz co jeszcze słowem wstępu, rozbijmy. Jest Cloud i on premis. I tutaj będziemy troszeczkę poruszać przy Kubernetesie jeden bardzo ważny koncept, który też staramy się powtarzać, jest to, że sam goły Kubernetes to jest kawałek z klocków do budowy platformy, do platformy aplikacyjnej. Sam goły Kubernetes to nie jest platforma aplikacyjna i taki czysty runtime. On tylko potrafi zorkiestrować. Brakuje mu dużej ilości rzeczy. I w on premie trzeba kupić drugi produkt, a w Cloud wziąć Manage, żeby można było mówić o platformie.
Szymon Warda: Pierwsze, na on premie i tak z reguły mało kto poleci takim gołym gołym. Po drugie, definicja gołego jest taka bardzo płynna, bo instalacje, które uważamy za gołe, często mają już pewne rzeczy predefiniowane. Mieliśmy dość sporą rozmowę a propos Metrics Server, który domyślnie nie jest, a w instancjach Dockera, który instalujemy, już jest, więc to też się rozbija. Ale jak najbardziej ważna różnica. Dobrze. Wymiary?
Łukasz Kałużny: Wymiary. No to co? Przenaszalność.
Szymon Warda: Pierwsze, jak wygląda?
Łukasz Kałużny: No jest genialna.
Szymon Warda: Ale?
Łukasz Kałużny: Ale pomiędzy różnymi Kubernetes’ami. Czyli jak go shiftujemy… Inaczej, naszą aplikację można realnie wziąć i w większości przypadków w bardzo łatwy sposób zabrać i wyrzucić do innego Kubernetesa u innego dostawcy.
Szymon Warda: I to jest ważne. To są ruchy, z reguły możliwe są ruchy w obie strony, czyli z on prema na clouda, z clouda na on prema, albo i więcej, z clouda na clouda.
Łukasz Kałużny: Tak, więc jest to możliwe od części aplikacyjnej. I druga bardzo ważna rzecz, jeżeli traktujemy go PaaS-owo, tego Kubernetesa i nie integrujemy tego od strony kodu, to jest troszeczkę dokładnie to samo podejście, co przy PaaS-ie, o którym mówiliśmy, tam vendor locku, który można zbudować.
Szymon Warda: Tak. To czyli jeżeli nasz kod nie jest świadomy tego, że chodzi w Kubernetes’ie, to jak najbardziej, generalnie możemy tą przenoszalność mieć. Mam wątpliwości czy jest sens takiego robienia. Różnie może być, zależy od użycia organizacji, czy ona faktycznie chodzi czasem w Kubernetes’ie, czy czasem chodzi po prostu na serwerach [niesłyszalne 00:32:19].
Łukasz Kałużny: Inaczej, jak ktoś zacznie dostosowywać się do filozofii nie cloud native tylko Kubernetes’a, to w gratisie dostanie potem wymianę całej filozofii, jak będzie chciał to porzucić.
Szymon Warda: Zgadza się, jak najbardziej. I teraz temat, trudniejszy wymiar, security. Czemu jest trudniejszy, Łukaszu?
Łukasz Kałużny: Wiesz co? Bo dostajemy całą potężną, nową skalę problemów. Dostajemy, ja się śmieję ze standardu bezpieczeństwa, jest CIS Benchmark dla Kubernetesa. CIS to jest taki, zawsze zapominam nazwę organizacji, zalinkujemy. Jest to taki benchmark bezpieczeństwa, taki zestaw kontrolek, czyli jak należy sobie skonfigurować, żeby było bezpiecznie. I dostajemy chyba teraz 80 stron dokumentu, jak powinien zostać Kubernetes bezpiecznie skonfigurowany. Czyli dostajemy całą nową… To jest cała nowa skala problemów, która dochodzi. Nie nazywajmy tego wyzwań, bo to są realnie problemy, które trzeba zaadresować i to nawet w wersjach Manage.
Szymon Warda: I kilka problemów, jakie trzeba zaadresować. Największe ryzyka w Kubernetes’ie?
Łukasz Kałużny: Wiesz co, cały role-based access, całe nadawanie dostępów do środka i cały model operacyjny w środku, to będzie to. Rzucając dalej, cały model sieciowości, o którym zaraz sobie w bezpieczeństwie jeszcze bardziej wejdziemy. To czekaj, liczę jeszcze z dyskusji od strony security i cały ten API serwer i cały ten flow przy zabezpieczaniu kontenerów, czyli upewnienie się, że ktoś nie wyhostuje nam kontenera w trybie privilege. Myślenie o kodzie, któremu ufamy, nie ufamy, czyli trusted versus untrusted code. Czyli przychodzi cała taka skala różnych zagadnień, które tam są. I to jest duża problematyczność i utrzymaniowo aktualizacje mogą być dla niektórych też wrzodem na tyłku.
Szymon Warda: Tak.
Łukasz Kałużny: Jeżeli w szczególności o security.
Szymon Warda: Dużo tu się może wyprostować w kontekście tego, co się zmienia w kontekście Dockera. Zobaczymy, tam są ruchy. Znowu odcinek Docker anno dominium 2020 i sporo problemów odejdzie, ale na chwilę obecną trzeba nauczyć się z nimi żyć.
Łukasz Kałużny: Tak i co ważne? Problemy security, w sensie ta skala problemów występuje w wersjach manage. Czyli nawet jeżeli weźmiemy Kubernetesa Manage, to też tam trafimy na część rzeczy do zrobienia i trzeba się pochylić nad tym.
Szymon Warda: Dobrze. Wspomniałeś o sieci. I sieć w Kubernetes’ie to jest fajny temat. Co tam może pójść nie tak, a co może pójść okej?
Łukasz Kałużny: Dobra. Pierwsze - poziom abstrakcji. Jeżeli ktoś nie siedzi w OPS-owych bebechach, nie ma backgroundu OPS-owego albo nie interesuje się siecią, to poziom abstrakcji, który w środku jest, potrafi wprowadzić ból głowy. Naprawdę ludzie, osoby nawet zaawansowane mogą mieć problem z ilością abstrakcji, które tu latają.
Szymon Warda: Tak. I co ważne, pamiętajmy, że te sieci, które mamy w Kubernetes’ie, to nie są te sieci, które znamy od 40, 50 lat. To się zmieniło, więc niejako poziom umiejętności ludzi jest też dużo, dużo niższy.
Łukasz Kałużny: Tak i on jest troszeczkę narzeźbiony tam, nazwijmy to. Ta sieciówka została dorzeźbiona po OPS-owemu, zducttape’owana w niektórych miejscach. I co przez to? Łatwo się skrzywdzić, o tak, ja to określę po prostu jako łatwo się skrzywdzić. Dając przykłady, w szczególności w cloud’zie łatwo przez pomyłkę wystawić swoją aplikację bezpośrednio na świat.
Szymon Warda: Tak albo nie zauważyć, że została wystawiona. Mała zmiana i nagle okazuje się, że coś, co powinno być prywatne, jest bardzo mocno publiczne.
Łukasz Kałużny: Bo zapomnieliśmy dodać na przykład właśnie annotation, które steruje load balancer’em, żeby było to prywatne.
Szymon Warda: Tak, ale pamiętajmy, że Kubernetes też jest platformą, która rozwiązuje pewne rzeczy. Moje ulubione - secrety.
Łukasz Kałużny: Tak.
Szymon Warda: Tu jest jedno wielkie ale.
Łukasz Kałużny: To powiedz, jak już zacząłeś.
Szymon Warda: Secrety są w base64 i trzeba na to bardzo, bardzo uważać.
Łukasz Kałużny: Tak.
Szymon Warda: Ale są integracje. Znowu jak wchodzimy na przykład security i wchodzimy w cloud’a, to w tym momencie możemy tu ładnie pointegrować z Vaultami do Secretów i to już w tym momencie zaczyna działać już dużo lepiej.
Łukasz Kałużny: Tak, więc tutaj jest secrety i inne zabawki. To też jest taki aspekt, o którym trzeba pamiętać, że on z pudełka fajnie wygląda, a potem i tak trzeba to poprawić.
Szymon Warda: I jeszcze jest ostatni element, jak mówimy o Kubernetes’ie, mój.
Łukasz Kałużny: I w sumie, tak, Twój, Twój mesh, Twój mesh ukochany.
Szymon Warda: Tak, oczywiście.
Łukasz Kałużny: Ale on nie jest z pudełka. Czyli inaczej certy, całe service meshe dają fajne rzeczy, ale one aktualnie żyją bardziej wewnątrz, a mamy świat zewnętrzny.
Szymon Warda: To ja to doprecyzuję generalnie, o co było. Mianowicie o to, że dodatki, które są budowane na Kubernetes’ie, często dodatki do platformy właściwie, czyli na przykład service meshe, dają nam jedną fajną rzecz, że komunikacja wewnątrz i pomiędzy serwisami w danym meshu odbywa się po MTLS-ie. Czyli mamy cały problem potwierdzania identity serwisów i kto ma do kogo dostęp, kto może z kim rozmawiać ogarnięte i wszystko leci po SSL-u bez wiedzy aplikacji. I to jest częste wymaganie, jeżeli chodzi o bezpieczeństwo w wielu systemach, dużych organizacjach i częsty powód, czemu firmy idą właśnie w service mesha. O tym trzeba pamiętać. Zgodzę się w pełni, nie jest to z pudełka. Często nawet meshe nie mają tego domyślnie włączonego. Jest to feature, który dużo łatwiej jest zrobić w meshach i na Kubernetes’ie. Dobrze.
Łukasz Kałużny: Dobra.
Szymon Warda: Kolejny obszar - automatyzacja.
Łukasz Kałużny: Dobrze, automatyzacja. I to jest bardzo ważne. Tak, jeżeli już go mamy, jest fajnie i genialnie, jeżeli ten Kubernetes już stoi gotowy do akcji.
Szymon Warda: Tak, Konfiguracja Kubernetesa i kwestia tej platformy, która nie jest platformą, nie jest trywialna i wymaga sporo wiedzy.
Łukasz Kałużny: Tak, więc sobie tak zostawmy. Czyli jeżeli mamy wdrożonego, to jest plus. Jeżeli na przykład zaczynamy projekt i mamy wdrożyć Kubernetesa, to ode mnie zawsze będzie to samo: idź, weź z pudełka. Jeżeli robisz w on premie, weź nie wiem, Ranchera z supportem, najlepiej Open Shifta. Weź wszystko jak producent mówi i tego użyj, bo zazwyczaj potem trafisz na różne ciekawe rzeczy. W cloud’zie użyj Manage i weź wszystkie gotowe komponenty, jeżeli zaczynasz z Kubernetes’em. Inaczej się zakopiesz i przepalisz kilka sprintów, czy co tam masz w projekcie, w backlogu, przepalisz godziny na to, żeby przygotować sobie środowisko.
Szymon Warda: To jeszcze dopowiem. Jak idziesz w chmurowego, po pierwsze weź wszystkie komponenty, tak, i weź integracje, które chmura oferuje, bo to jest też bardzo ważne. Rzecz, która jest wspaniała natomiast, jeżeli chodzi o Kubernetes’a, to są oczywiście deploymenty aplikacji.
Łukasz Kałużny: To, co powiedzieliśmy, że właśnie te deploymenty, jak już jest, jest genialne. Cała idea, że Orchestrator jest w stanie zrobić deployment i praca po naszej aplikacji jest nieduża. To jest tak naprawdę implementacja potem health checków w odpowiedni sposób.
Szymon Warda: Dokładnie. Doprecyzujmy. Mamy tu Blue Green, mamy tu Canary, mamy tutaj bardzo dużo opcji. Tych opcji jest jeszcze więcej, jak na to dorzucimy mesha, ale to już jest osobny temat. Co jeszcze jest fajne?
Łukasz Kałużny: Autoskalowanie. Chyba raczej, przepraszam, autoskalowanie z to zależy.
Szymon Warda: Tak. To mów o gwiazdkach. Gdzie i co?
Łukasz Kałużny: To zależy. Autoskalowanie ma dwa wymiary. Czyli ma wymiar pierwszy, to jest aplikacji, a potem zasobów całego klastra. I w cloud’zie i w on premie fajnie, bo wszystko to się robi. W sensie aplikacja może się skalować w obu tych przypadkach. Potem zaczyna się zabawa z dostawianiem nowych instancji. I tak jak w cloud’zie, to jest.
Szymon Warda: Doprecyzuję, nowych maszyn do klastrów.
Łukasz Kałużny: Nowych instancji maszyn w klastrze, tak, to jest dobre doprecyzowanie. Więc dostawianie nowych instancji to jest już w on premie. Klastry są zazwyczaj statyczne.
Szymon Warda: Tak.
Łukasz Kałużny: I się nie oszukujmy. A w cloud’zie jest to po prostu z pudełka.
Szymon Warda: I to właśnie są te integracje, o których mówiłem. Wykorzystajmy to, bo to jest ta potęga, która naprawdę się nam przyda.
Łukasz Kałużny: Której w teorii włączasz po prostu, jeżeli bierzesz manage, w GK chyba w ogóle jest z pudełka, mówisz min max i jazda potem.
Szymon Warda: Dokładnie.
Łukasz Kałużny: I potem trzeba skonfigurować tylko skalowanie aplikacji, żeby to się zadziałało.
Szymon Warda: Dobra, monitoring. To wymiar.
Łukasz Kałużny: Przepraszam. Dobra, reguła jest tak, prawdziwy monitoring oczywiście dla Snyku i tam ruchu sieciowego, to są meshe czy jakieś twistlocki, aqua’y, żeby zobaczyć co się dzieje w środku. Jeżeli chodzi o resztę, to w gołym nic nie ma, więc musimy wziąć jakieś gotowe komponenty, zbudować sami. To będzie to samo, co już mówiliśmy, żeby się nie powtarzać, przy IaaS-ie on premowym. Czyli albo bierzemy gotowe rozwiązania i sobie dostawiamy w on premie, albo w cloud’zie bierzemy to, co jest, jakiś dostawca, czy SaaS do tego monitoringu.
Szymon Warda: Tak, jest trochę lepszy generalnie w Kubernetes’ie, ale dalej to nie jest nic idealnego. Musimy doinstalować komponenty, żeby to było wspierane. I to jest dalej monitorowanie na poziomie z reguły po prostu samych kontenerów.
Łukasz Kałużny: No i to jest ten Metrics Server, który już tak bebechem Szymona zaskoczyłem akurat jak to omawialiśmy, że jakbyście postawili gołego Kubernetes’a na przykład Kubeadm’em, który jest tam takim jednym z prostszych sposobów, to nie ma tego Metrics Servera.
Szymon Warda: Tak, jest to faktycznie, że taki goły, goły Kubernetes. Dobrze, koszty.
Łukasz Kałużny: Ludzkie są znaczące, bo trzeba się przy tym nagrzebać.
Szymon Warda: Tak.
Łukasz Kałużny: I w cloud’zie, nieważne gdzie. W niektórych jest prościej.
Szymon Warda: W cloud’zie oczywiście jest łatwiej, bo jednak to autoskalowanie, te integracje są za nas załatwione. W on premie?
Łukasz Kałużny: Tak, to są już te koszty ludzkie, są znacznie wyższe, bo musimy wybudować to wszystko pod spodem, jeżeli nie weźmiemy gotowca. I właśnie, jak chcesz mieć wsparcie albo gotowca, to licencjonowanie niektórych potrafi zabić.
Szymon Warda: Nie jest tanie, ale jest często, po pierwsze, wymagane, po drugie, jak najbardziej zasadne i jak się pobawimy już próbą postawienia Kubernetesa na on premie ręcznie, to już rozumiemy czemu te licencje tak wyglądają.
Łukasz Kałużny: Tak. I tam będzie potężna ilość różnych meandrów, które będą produkować koszty. Na przykład sposób jak zrobimy load balancery, czy może jakaś integracja z F5, żeby to się zachowywało natywnie i potem może okaże się, że dedykowana F5 albo dedykowany FortiGate’cik, bo nam security nie pasuje. I jest tam dużo takich meandrów, które leci.
Szymon Warda: Dobrze, to zamykamy Kubernetesa i przechodzimy do ostatniej platformy - serverlessa. I tu kilka słów wstępu. Pierwsze.
Łukasz Kałużny: Mówimy tutaj, są rzeczy na niby na on prema, ale powiedzmy sobie, to nie są platformy wtedy, to jest wzięcie jakiegoś frameworka. Więc tu w serverlessie skupiamy się tak naprawdę tylko na cloud’zie i tak naprawdę na function as a service, jeżeli popatrzymy na coś, co pozwala wywoływać nasz kod.
Szymon Warda: Tak i tu od razu powiem, bo to jest jedna rzecz, która nie pasowała nam do żadnych z wymiarów, ale pamiętajmy, że to jest wybitnie platforma, która będzie nas karała za pisanie większych serwisów, większych kawałków kodu. Przykład? Takie rzeczy jak dependency injection nie działają tak fenomenalnie, jak jesteśmy przyzwyczajeni z aplikacji, takich zwykły binarek. Więc tu wybitnie mówimy o platformie, w której trzeba go with the flow bardzo mocno, nie walczyć i tworzyć aplikacje w pewien sposób. O ile poprzednie dwie platformy pozwalały hostować różne aplikacje i małe, i duże, to tu wybitnie mówimy małe, małe serwisy.
Łukasz Kałużny: Raczej z tym IDI-em to tak jak ja mówiłem, ja mam taką dziwną perspektywę, że to chyba świat .Netowy na to najbardziej marudził. To jest moja taka perspektywa na brak IDI-ów, które Microsoft wreszcie dospawał u siebie na przykład.
Szymon Warda: Ale też tak nie w pełni dospawał, to nie jest aż takie idealne. Zgodzę się, Node tutaj nadaje się dużo lepiej do pisania małych rzeczy, ale też w pewnej skali nagle okazuje się, że dependency by się przydało.
Łukasz Kałużny: Tak, dobra i to co powiedzieliśmy o odcinku serverless’ie, może mogłoby to w przenoszalności, ale pozwala się skupić na kodzie biznesowym i to jest jego duży plus.
Szymon Warda: Tak. Dobra, idziemy przez wymiary. Pierwszy - przenoszalność.
Łukasz Kałużny: I tyle. Jest vendor lock. Sorry.
Szymon Warda: Tak, ja dopowiem, że jest serverless framework, który trochę abstrahuje tą platformę, ale to dalej nie jest kod stuprocentowo przenoszalny. Łatwiej jest go przenieść, ale godzimy się z vendor lockiem. Koniec, kropka.
Łukasz Kałużny: Inaczej i potem im więcej mamy tych rzeczy tam, tym trudniej będzie. Zawsze będzie to refaktoring i będzie go więcej do zrobienia. Czyli skala refaktoringu rośnie z ilością pracy, którą już włożyliśmy w system.
Szymon Warda: Pamiętajmy też, że platformy serverlessowe nakłaniają do korzystania z usług PaaS-owych i SAS-owych, innych, typu kolejki i tak dalej, i tak dalej.
Łukasz Kałużny: Wymuszają, to jest lepsze określenie, wymuszają.
Szymon Warda: Nie chciałem tego tak ująć, ale tak. Więc w tym momencie liczymy się z dużo większym przepisaniem aplikacji, że ten vendor lock jest coraz silniejszy. Security, kolejne. Dajesz.
Łukasz Kałużny: To mamy najmniejszą warstwę ataku z tego wszystkiego co powiedzieliśmy. Najwięcej jest oddelegowane do dostawcy, który to często może zrobić lepiej za nas. Tutaj użyję świadomie, często, bo czasami ludzie od security mają rację, czasami nie mają racji co by chcieli chronić. Ale przez tą mniejszą warstwę mamy też mniej rzeczy, które można zabrać stamtąd, przez to jak to jest rozizolowane.
Szymon Warda: Nawet jeżeli wystąpiłaby eskalacja, a byśmy mieli błąd aplikacji, gdybyś z aplikacji wyeskalował do hosta, to tam niewiele jest w tym hoście, bo i tak jesteśmy w wirtualizowanym runtime’ie, więc na przykład naszych secretów, dostępów nie ukradnie, bo za bardzo nie ma ich tak naprawdę tam.
Łukasz Kałużny: Raczej weźmie te, które są tam akurat dostępne dla danego kawałka. To powiedzmy, że izolujemy ten kawałek, że może dostać to, co jest przypisane do tego.
Szymon Warda: Tak. Ale teraz wchodzimy w kwestię sieciową, jak to wygląda? To jest też element bezpieczeństwa.
Łukasz Kałużny: Jest źle, jak z siecią w PaaS-ach. O tak, źle jest jak jest… Bo inaczej, taki czysty PaaS poszedł trochę dalej, jeżeli chodzi o sieciowość. I tu jest tak, że chyba Azure ma akurat, będzie w tym, ja będę porównywał tutaj Azure i AWS, to akurat sieciowo Lambda wygląda o wiele lepiej, o tak, jest o wiele bardziej dojrzalsza. Tak jak wolę tooling i pewne rzeczy w Microsoft, tak Lambda jest o wiele lepiej sieciowo.
Szymon Warda: Tak. A jak mówimy o dostępach w ogóle, to w tym momencie ruszymy ten nasz, jak żeśmy ładnie ustalili, love hate relationship, jeżeli chodzi o dostęp do funkcji w Azure, czyli na bazie kluczy.
Łukasz Kałużny: Niektóre dają statyczne. W ogóle parę usług daje w serverless’ie statyczne dostępy do autoryzacji, bo to nie jest uwierzytelnianie, tylko autoryzacja. I co, zdefiniowaliśmy sobie oboje, że to jest do MVP genialne.
Szymon Warda: Tak, potem zaczyna być lekkim problemem, bo ten klucz łatwo żeby wyciekł. Tym bardziej, że może być przekazywany w get’cie i może być przekazywany generalnie w poście, ktoś linka wklei.
Łukasz Kałużny: Tak, więc to, powiedzmy, że nie jest to przyjemne. Dobra.
Szymon Warda: Automatyzacja. Czyli tu gdzie serverless błyszczy.
Łukasz Kałużny: Tak. Dobra, to chyba będzie Twoje podejście, ale że ta platforma pozwala utrzymywać realnie wiele wersji naraz naszego kodu.
Szymon Warda: Tak, to jest ta opcja, że wdrożenie nowej wersji i utrzymanie starej wersji, jeżeli jest wykorzystywana, nic nas tu nie boli, nic nas nie kosztuje. Jak zobaczymy, że ona jest niewykorzystywana przez na przykład miesiąc, możemy ją ubić i platforma to bardzo ładnie wspiera. Jedyne ale są limity na całkowity rozmiar projektu funkcyjnego i trzeba o tym pamiętać.
Łukasz Kałużny: Czyli tam kodu i innych rzeczy. Ja bym jeszcze rzucił, że teraz powiedziałeś, że to jest pięknie. Pamiętajcie, że pomijamy warstwę bazodanową tego wszystkiego i data’ową.
Szymon Warda: Tak, bo inaczej byśmy się zakopali w temacie na długo, długo.
Łukasz Kałużny: I tak już jest długo. Dobra.
Szymon Warda: Ja jeszcze dorzucę. Mi brakuje tutaj tego, co właśnie jest w Kubernetes’ie, czyli całego canary deploymentu, ładnego przełączania i wsparcia w platformie na to, żeby tym ruchem ładnie orkiestrować. Ty skontrujesz to, że w tym momencie od tego mamy API Gateway, ale to też przydałoby się do ruchu wewnętrzn,ego.
Łukasz Kałużny: Dziękuję, dziękuję. Tak więc to jest tam cała ta zabawa. Inaczej, budowanie jeszcze… Inaczej, serverless też karze za budowanie tych chainów, jak ludzie budują, w jaki sposób implementują potem, że są duże chainy synchroniczne i tutaj gdzieś potem całe orchestracje tym powinny być zrobione.
Szymon Warda: Tak, elementem, który jest bardzo upierdliwy, jeżeli chodzi o automatyzację, który jest potrzebny przy automatyzacji, to jest całe stworzenie mapy serwisów. Kubernetes nam to daje niejako trochę, a tutaj z racji na ilość zbudowanie tej mapy serwisów tylko z observability może nam wynikać.
Łukasz Kałużny: Dobra i na papierze autoskalowanie jest cudowne w tym.
Szymon Warda: Tak, są kruczki z dostrajaniem, jak najbardziej. Ale zgodzę się, że tutaj skalowanie… Znaczy zakładamy, że jak mówimy o Azure, mówimy o consumption planie, nie mówimy o tym planie hostowanym.
Łukasz Kałużny: Tak. Znaczy jeżeli mówisz tam Azure. I AWS-ie też Lambda… Inaczej, to z tym autoskalowaniem w ogóle… Inaczej, z autoskalowaniem cold startami dużo dostawcy robią, więc to jest ciągle taki bardzo płynny temat, o tak.
Szymon Warda: Tak. Monitoring.
Łukasz Kałużny: Jest natywny i na tym kończymy dyskusję. Bierzemy co dany dostawca daje i przykro mi, niestety może to kosztować drogo i to jest ich marża właśnie na serverless.
Szymon Warda: I tutaj byśmy zalecali włączenie tego rozszerzonego oczywiście, żeby tych metryk mieć trochę więcej i mieć obserwowanie. Ale tak, będzie kosztowało i jest natywny. Jest też wsparcie third parties, one często w ogóle polegają na logach, na analizowaniu logów, działają, natywny działa lepiej po prostu. I ostatni obszar - koszty.
Łukasz Kałużny: Dobrze, to jest tak, błyszczy, tak na dzień dobry błyszczy, bo jak nie używamy, to niby nie płacimy.
Szymon Warda: Tak.
Łukasz Kałużny: Przy większym użyciu są różne historie, o tak, to jest takie potężne konsultanckie, to zależy. Można znaleźć historie, gdzie rachunki zostały zbite bardzo realnie.
Szymon Warda: Dziesiątki tysięcy na setki dolarów.
Łukasz Kałużny: Tak, z serverlessa na IaaS-a kontenery albo z kontenerów właśnie na serverlessa. Więc historie są w obie strony z kosztami, więc to jest takie potężne. To zależy od każdego przypadku.
Szymon Warda: Tak, dobrze to powoli przeszliśmy przez platformy. Powoli wrapujemy ten odcinek. Po pierwsze, to popatrzmy jaki jest stan tych platform, jak to inni robią, jak na to w ogóle nasz cały biznes patrzy.
Łukasz Kałużny: Dobra, to moja perspektywa jest taka, od 2017 roku jak ktoś myślał tak naprawdę o mikroserwisach, to były to kontenery i w pewnym momencie był tam jeszcze Docker Swarm i inne zabawki. Ale w pewnym momencie w 2017 zaczął być taki przeskok, że mikroserwisy będą, kontenery i Kubernetes.
Szymon Warda: Tak i Kubernetes podbił serca i umysły.
Łukasz Kałużny: Tak, można znaleźć przykłady, gdzie ludzie jeszcze używają Swarma, używają gdzieś pełnej automatyzacji na samych kontenerach IaaS-ów, ale to z mojej perspektywy… Inaczej, Kubernetes nie jest, jeżeli ktoś robi mikroserwisy, to często ten Kubernetes jest i nie jest to tylko rzecz, która jest taka mocno shype’owana, ale ona gdzieś też niestety w tym ekosystemie występuje realnie.
Szymon Warda: Zgadza się. Jest to powoli standard rynkowy. To o czym rozmawialiśmy, to że obaj widzimy tą szansę, że ten opis infrastruktury w formie YAML-i zostanie, czy to będzie Kubernetesa, czy będzie dla innych platform, ale to będzie, bo to ma sens jak najbardziej.
Łukasz Kałużny: Tak, ma sens. I co ważne, jeżeli chodzi o K8s to znowu kurde wychodzi nam odcinek o nim, jak tego nie lubię, to on jest teraz w tym momencie na szczycie tej górki adopcji. Jak sobie popatrzymy na wykres, to jest chyba ten moment, gdzie dochodzimy już do tej górki.
Szymon Warda: Tak. To teraz przejdźmy - nasze opinie, czyli kiedy używać, kiedy nie. Łukasz, lecisz pierwszy.
Łukasz Kałużny: Dobra, to będzie takie, że zacznij od PaaS bardzo często, jeżeli masz cloud’a.
Szymon Warda: Zgadzamy się.
Łukasz Kałużny: Tak. Jeżeli masz dużo kontenerów, weź Kubernetesa, ale takiego gotowego. Nie buduj sam platformy aplikacyjnej, jeżeli nie masz zespołu, który będzie utrzymywał platformę aplikacyjną, jest w stanie to dostarczyć, zbudować, to weź gotowca i o tym zapomnij, pogódź się, że się nie pobawisz, bo od tego nie są projekty najczęściej. Czyli nie baw się na koszt klienta wewnętrznego czy zewnętrznego. Jeżeli robisz MVP, możesz, to użyj serverlessa. Ja jestem w tym zakochany pod tym względem, w szczególności do jakichś małych, szybkich rzeczy albo startów. W szczególności, że potem ten kod biznesowy łatwo go zabrać, te kawałki kodu biznesowego, jak gdzieś tam użyjesz potem zwykłej relacyjnej bazy danych i innych zabawek, które są dostępne albo będziesz przechodził na PaaS-a. I jeżeli chodzi o IaaS-a, czy to on premowego, czy tego mocno on premowego, czy takiego mocno zautomatyzowanego, on jest ciągle naprawdę spoko pod warunkiem, że masz dobrych opsów, devopsów, którzy potrafią to robić.
Szymon Warda: Tak, jak jest organizacja dojrzała w tym obszarze, to jak najbardziej, czemu nie. Dobra, to teraz trochę moja perspektywa. Zgadzamy się w zupełności z tym, że zacznij od PaaS-a. Taki dobry środek w kontekście progu wejścia, dojrzałości platformy, jak najbardziej. W kontekście Kubernetesa zgodzę się z Tobą, że jak masz dużo kontenerów używaj Kubernetesa. Ja jeszcze jeden wymiar widzę. Jeżeli masz potrzebę, że musisz być uruchomiony na on premie i w cloud’zie, tu dla mnie nie ma lepszego wyboru niż Kubernetes po prostu. Przenoszalność, o której mówiliśmy, z cloud’a na on prema, z cloud’a na cloud’a, z on prema na cloud’a, błyszczy, jak najbardziej wykorzystujmy. Jeżeli chodzi o serverlessa, ja jednak chyba to MVP bym odpalił na PaaS-ie. Ale jest jeden wymiar, gdzie dla mnie jak najbardziej serverless błyszczy i to w AWS-ie i w Azure. To są durable functions i step functions, czyli orkiestraowanie innymi procesami biznesowymi przez sagi, które są wspierane właśnie w serverlessowych, które są świetnie zaimplementowane. One naprawdę działają super, są widoczne. W kodzie aplikacji dużo gorzej wyglądają.
Łukasz Kałużny: Proszę, powiedz mi jeszcze tą rzecz, którą powiedziałeś przed nagraniem do tego podsumowania.
Szymon Warda: Tak. Jedna rzecz. Tak, to jest durable functions i te funkcje, powiedzmy step functions, one służą do orkiestracji. To nie jest na dziesiątki tysięcy wywołań na sekundę.
Łukasz Kałużny: Tak, synchronicznych.
Szymon Warda: Tak, synchronicznych. Pamiętajmy, że to jest do orkiestracji. Orkiestracja z definicji, jak popatrzymy na wzorce komunikacji synchronicznej, synchronicznych systemów rozproszonych, to jest coś, co tylko mówi, co powinno być zrobione i bardzo szybko kończy swoją pracą. Tylko dobry menadżer, powiedzmy sobie, bez mikrozarządzania.
Łukasz Kałużny: Więc ja taką, chciałbym wyróżnić jedną patologię po tym odcinku.
Szymon Warda: Dajesz.
Łukasz Kałużny: Jeżeli pozwolisz, to taki będzie koniec. To jest bawienie się tym Kubernetes’em na siłę. O, to będzie taka patologia, żeby zachować tą patologiczność. To jest to wchodzenie bez zrozumienia w Kubernetesa, że jest tam tylko serce i marketing, umysłu zabrakło.
Szymon Warda: Tak, że jeden zespół wchodzi w Kubernetesa, a nie cała firma, bo to jest budowanie platformy w pewien sposób. Zgadzam się jak najbardziej. Dobrze kończymy ten odcinek. Dzięki.
Łukasz Kałużny: Dzięki. Na razie.

Wypełnij poniższy formularz, aby być na bieżąco ze wszystkimi
odcinkami Patoarchitektów
i uzyskać dostęp do dodatkowych
materiałów.