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 lub gdzieś tu na dole. Poradzicie sobie, będzie spoko.

Szymon Warda: Dobrze. Szkolenia.

Łukasz Kałużny: Tak, szkolenia. Więc wpadnijcie na Patoarchitekci.io/szkolenia. Zobaczcie co w tym momencie jest dostępne, jak i na naszego Discorda, gdzie nawet do tego odcinka mogliście dorzucić swoje pytania.

Szymon Warda: Ja dorzucę tylko to, że Łukaszowi w końcu udało się zmolestować mnie i jest termin na Observability, kolejna iteracja. Ale lista oczekujących jest większa niż pojemność szkolenia, tak że się zalecam śpieszyć raczej.

Łukasz Kałużny: Dobra, to słuchajcie, dzisiaj jest odcinek, ja bym powiedział trochę suchar, bo Szymon od dwóch lat uważał albo trzech, że po co w ogóle o tym rozmawiać, więc będzie ze mnie dzisiaj szydził. Z naszej takiej codziennej praktyki w Protopii, jeżeli chodzi w szczególności o konsultacje typu gaszenie pożaru w częściach aplikacyjnych gdzieś hostowaniach, to część z tych nudnych rzeczy i tak jest standardem, który jest nie do końca spełniany. No właśnie, to o czym dzisiaj?

Szymon Warda: The Twelve-Factor App. Ale tutaj Łukasz to jest obszar, w którym trzeba wprowadzić trochę historii, bo jest to tak stara lista. Właściwie tak to trzeba nazywać.

Łukasz Kałużny: To ja może przejdę od tego w ogóle czym to jest. To był taki zbiór 12 praktyk, które w tamtym okresie, kiedy powstało, miało mówić o tym, jak projektować nowoczesną aplikację, jak wygląda skalowanie i hostowanie takiej aplikacji w różnych środowiskach. I jak popatrzymy, pewne rzeczy będą trącać myszką, tak to nazwijmy, albo będą mogły wyglądać staro. Dobra i sama koncepcja jest z 2011 roku i powstała na bazie platformy Heroku. I to są takie. Heroku cloudem nigdy nie był w prawdziwym, był takim passem, ale no kurde, to się w… Może lepiej nie wchodźmy.

Szymon Warda: Miał bardzo duże wykorzystanie tak naprawdę. W pewnych obszarach Heroku naprawdę był wykorzystywany i to działało, działało całkiem przyjemnie, prosto, itd.

Łukasz Kałużny: Raczej było genialną platformą dla Ruby’ego, Pythona, Node’a i w szczególności w momencie MVP bootstrapowania to było mega. No i Heroku właśnie stworzyło te 12 Factor App, żeby ustandaryzować wdrażanie tych aplikacji i przez to może wtedy ta działka startup’owa bardzo mocno się rozlewała na świat, jeżeli chodzi o technologie. To poszło to szeroko. I zapamiętajcie 2011 rok. No i co? Przejdźmy z czego się składa.

Szymon Warda: Więc pierwsze jest moim ulubieńcem generalnie, który chyba świadczy o tym, jak bardzo to wali myszką. I co więcej, czemu ja do końca nie widzę, co tu jest do rozmowy tak naprawdę, żeby trzymać code base w repozytorium.

Łukasz Kałużny: Tak i to jest w ogóle pierwsza rzecz, jak zobaczycie, code base. Ja, jak sobie to spisywałem, przygotowywałem się do odcinka, Szymon, to zauważ, że Git wtedy był nowością w korpach.

Szymon Warda: Ok, ale Git był nowością. To się zgadza, ale było dużo innych form repozytoriów i mimo wszystko w 2011 roku to wersjonowanie kodu nie było nowością.

Łukasz Kałużny: Ale nie było też, raczej nowością nie, ale dopiero stawało się szeroko przestrzegane.

Szymon Warda: Może inaczej, to też jest ważne, to co powiedziałeś odnośnie historii. Oni to robili dla startupowców często, ludzi, Heroku też było kierowane do ludzi, którzy nie do końca kodowali. Jak się zaczął Node rozwijać, to masę było ludzi, którzy po prostu zaczynali się tego uczyć i faktycznie nie mieli tych praktyk. Co jest jeszcze ważne odnośnie code base? Tam jest napisane, na stronie 12 Factor App, że jest single repo. Co też jest taką ciekawostką, bo zakłada właśnie pojedyncze repo, co już teraz odchodzimy, zmieniamy, to już nie jest takie wykute w skale.

Łukasz Kałużny: Wiesz co? Pojedyncze repo, w zależności jak pójdziesz tam, część interpretacji, bo ja sobie pogrzebałem, to też ta oryginalna jest taka, że jedna aplikacja, jedno repozytorium. To było oryginalne stwierdzenie tutaj stojące za Twelve-Factor.

Szymon Warda: Możemy się przeciskać. Na 12factor.net jest tam zdanie: single repo.

Łukasz Kałużny: Dobra, odsyłamy do odcinka o repo, bo kiedyś taki nagraliśmy w kontekście mikroserwisów.

Szymon Warda: Tak, faktycznie było. No racja.

Łukasz Kałużny: Dobra. Następną rzeczą są zależności: jawnie deklaruj i izoluj zależności. I tutaj chodziło o to, żeby jawnie wpisywać wszystkie zależne biblioteki i inne rzeczy. Jak przełożymy na dzisiejszy czas, to wszystkie zależności, które możemy zrobić gdzieś tam w NPM-ie, requirements od Pythona, NuGet, to jest już standard, o którym nie myślimy.

Szymon Warda: Tak, ale faktycznie w 2011 roku na przykład część języków nie miało wsparcia do tego, żeby pobierać zależności automatycznie. Z tym się zgodzę jak najbardziej. I było to kopiowanie po prostu DLL-ek. Jak najbardziej to się odbywało.

Łukasz Kałużny: O tak, przypomniałaś mi .Netowego gaca.

Szymon Warda: Tak, dokładnie, o tym też właśnie chciałam powiedzieć. Więc to ma jakiś tam sen. Obecnie to jest…

Łukasz Kałużny: Wiesz co Szymon? Częściowo to rozwinęliśmy też na infrastrukturę, bo zauważ, powiedzieliśmy: to powstało przed czasami konteneryzacji i Kubernetes i wszystkich serverlessowych i innych jawnych modeli. I zobacz.

Szymon Warda: To też się zgadza.

Łukasz Kałużny: Zobacz, że tutaj Dockerfile na przykład wchodzi w grę, w którym też teraz już jawnie tak by design wrzucasz, w zależności, nawet od strony infry pod spodem systemu operacyjnego.

Szymon Warda: Tak. Dockerfile jest dobrym przykładem, ale bardziej Twelve-Factor mówi o tym, żeby mieć Dockerfile’a, a nie żeby pushować docker image, bo to jest bardziej ta bajka. Tak żeby było to porozdzielane. Zresztą o czym w ogóle mówią kolejne obszary i kolejne punkty tego Twelve-Factora? Dalej, konfiguracja. Opowiadaj.

Łukasz Kałużny: Dobra. I tu zaczyna się zabawa, jak zestarzało się to bardzo. Chociaż nie, to zależy. Tu jest bardzo mocne “to zależy”, bo chodziło o to, żeby przechowywać konfigurację w środowisku i konfiguracja ogólnie per środowisko jest ok, must have. I tutaj jak pójdziemy w detale, to mówiło się o tym, żeby to były zmienne środowiskowe.

Szymon Warda: No bo Linux.

Łukasz Kałużny: Tak, Linux i to było pierwotne, plik dotenv i jedziemy, tudzież podane do procesu. A zobaczcie, w dzisiejszych czasach to jest często nadal, powróciliśmy do plików konfiguracyjnych. Jeżeli pójdziemy dalej to jakieś poświadczenia są mapowane z jakichś vaultów, keyvaultów, KMS-ów natywnie pobierane przez apkę. Czy z drugiej strony mamy soft do feature managementu i configuration managementu. Nie wiem jak Azure App Configuration lub inne tego typu rozwiązania.

Szymon Warda: Znaczy ja tu jedną rzecz obronię. I czemu to się trochę zestarzało? Bo kiedyś konfiguracje to były proste klucz-wartość. Teraz coraz częściej mówimy o konfiguracji w formie JSON i to wpychanie w zmienną środowiskową już nie jest takie miłe i przyjemne. Co więcej, często mamy tak, że mamy konfigurację, a dopiero w podsekcjach chcemy je zastąpić odpowiednimi obszarami. Więc to się zrobiło dużo trudniejsze. Znowu gdzieniegdzie chcielibyśmy decydować, mamy Fluxa, którego tak bardzo lubię, który generalnie częściowo nakłania do tego właśnie, żeby.. W ogóle problem jest z Kubernetesem właśnie, że wstrzykiwanie tych sekretów i co tam dalej z nimi robić w tym repo. Więc dyskusyjne bym powiedział. Obecnie, czy to powinno być w środowisku, czy powinno być wstrzykiwane przez providerów typu keyvault? No fajnie by było tak naprawdę. To w tym momencie rodzi się problem z zarządzaniem tym keyvaultem, w którym są wszystkie te sekrety, no nie?

Łukasz Kałużny: Trzeba to mieć. Sposób dostarczenia to jest duże “to zależy”.

Szymon Warda: Znaczy ogólnie, bo jaka była idea za tym? Idea za tym była taka, żeby sekrety nie były w repo, bo o to chodziło tak naprawdę.

Łukasz Kałużny: I druga rzecz, żeby dało się skonfigurować w ogóle aplikację, a nie hardcore’owana.

Szymon Warda: I opcja, żeby wywalić sekrety z repo jest jak najbardziej słuszna, żeby nie było. W którym kierunku to dalej pójdzie? To się dalej rozwija, bo różne zespoły mają różne potrzeby, prawda? Też zależy od organizacji.

Łukasz Kałużny: Kolejne są Baking Services, czyli usługi wspierające. I oryginalnie było: traktuj usługi wspierające jako dołączone zasoby, tak to można byłoby skwitować.

Szymon Warda: I ja to rozwinę. Bo o co chodzi? Chodzi o to, żeby zasoby zewnętrzne, czyli generalnie podajemy po prostu URL do bazy, podajemy connection stringa, a nie jest to hardcodowane w aplikacji jako kiedyś było.

Łukasz Kałużny: Albo odpalane razem z aplikacją.

Szymon Warda: Też druga opcja, dokładnie tak. Zakładamy, że to leci po localhost, itd. W sensie rozbijamy nasz system na poszczególne serwisy, które mogą być niezależnie hostowane.

Łukasz Kałużny: I to po dziś dzień ma sens i to nie ma co tutaj z tym dyskutować.

Szymon Warda: Tak.

Łukasz Kałużny: Dobra, co mamy następne?

Szymon Warda: Build, release, run - budowanie, wydawani, uruchamianie. To się zestarzało bardzo mocno, bo chodzi o to, żeby po prostu porozdzielać te kroki.

Łukasz Kałużny: Inaczej. Przedpotopowe podejście do CI/CD.

Szymon Warda: Trochę tak. Wiesz co, wydaje mi się, że też trochę podejście do tego, co robić z takimi programami, które po prostu jak je uruchamiasz, to one nagle zaczynają się dopiero przygotowywać do uruchomienia. Też może być ta pozostałość.

Łukasz Kałużny: Tak, samo jest sensowne, żebyś miał oddzielnie builda, a release to jest wdrożenie odpowiedniego builda. I run to jest de facto uruchomienie tego release’u. To gdzieś samo technicznie ma sens.

Szymon Warda: Tak. I kolejne lecimy - procesy.

Łukasz Kałużny: A ja bym się, słuchaj, jest tak, procesy, czyli uruchamiaj aplikacje jako jeden lub więcej bezstanowych procesów. I tu są dwie rzeczy. Wtedy nie było kontenerów, więc proces był normalną funkcją hostowania.

Szymon Warda: Ale kontener jest podobnym poziomem izolacji. Znaczy trochę niższym de facto.

Łukasz Kałużny: Tak, ale ciągle mówi, żebyśmy odpalali tam powiedzmy jeden główny proces, a pobocznych nie hostowali w tym samym kontenerze, tylko używali sidecarów. Więc od tej strony to nadal ma sens.

Szymon Warda: Czy to nadal ma sens? I jeżeli mówimy o tym, co jest łamane tak naprawdę, to to akurat zdarza się, że jest łamane. Bywają różne pomysły: a co tu można by pokolejkować? Co tu można by zrobić? Napiszmy własny system DotXYZ.

Łukasz Kałużny: Tak, albo Supervisord, żeby odpalić w jednym kontenerze wiele procesów, bo mamy jakieś gówno.

Szymon Warda: Jeszcze jeden element doprecyzuję tutaj, bo tu jest takie założenie, że to są procesy, które mają share nothing architecture, czyli niczym się nie dzielą, czyli nie mają jakiegoś tam… Tu głównie chodziło o to, że one nie wymieniają się pamięcią, że nie mają jakiegoś streama, z którego…

Łukasz Kałużny: Nie ma żadnego IPC i innych takich elementów.

Szymon Warda: Dokładnie tak. Czyli po prostu nie nadpisują sobie, nie mamy problemu równoległości. To ma ręce, ma nogi tam, gdzie powinno mieć.

Łukasz Kałużny: Dobra, siódemka jest oczywistością.

Szymon Warda: Tak, siódemka, czyli mianowicie port binding, czyli określanie, które porty są wykorzystywane. W czasach Docker to tak ciężko inaczej, to wymusza.

Łukasz Kałużny: Ale niekiedy jak ktoś nie pamięta na czym chodzi jego aplikacja, troubleshooting jest ciekawy.

Szymon Warda: Jest to po prostu szukanie dwukropka z numerkiem.

Łukasz Kałużny: Dobra, następna rzecz i to jest, ja się nad tym zastanawiałem i to nadal ma sens, bo disposibility, czyli jednorazowość, efemeryczność pojedynczej instancji, maksymalizuj odporność przez szybki start i właśnie bezproblemowe wyłączanie, włączanie.

Szymon Warda: Tak. Znowu, to jest wszystko ładnie, wszystko piękne, że włączamy, wyłączamy. Jednak miałeś sytuacje, w których musiałeś na przykład dodawać proby, musiałeś dodawać sytuacje w Kubernetesie, że aplikacji trochę chwilę zajmuje wyłączenie i włączenie.

Łukasz Kałużny: Bezproblemowe, więc graceful shutdown. Zauważ, oryginalnie jest, ja tutaj tak to skróciłem, ale oryginalnie jest w tym greatfull shutdown jako przy disposibility, masz w oryginale graceful shutdown, czyli czyste wyłączanie się, żeby aplikacja się prawidłowo sama składała. Nie ma tutaj czasu, jest szybki start i złożenie się potem prawidłowe, więc to jest nadal aktualne. Szybki start może nie jest już takim problemem, ale graceful shutdown, no sorry, w praktyce nadal są z tym jazdy jeżeli proby są źle poustawiane w Kubernetesch na przykład, czy innych cloudach.

Szymon Warda: Proby, ogólnie czasy wyłączenia zajmują trochę dłużej, bo to też jest takie… Są sytuacje, w których aplikacja po prostu potrzebuje coś więcej zrobić.

Łukasz Kałużny: I wiesz co? W dzisiejszych czasach jest to spoko, pod warunkiem, że zrobisz healthchecki. Do healthchecków jeszcze przejdziemy.

Szymon Warda: Będzie w sekcji brakujących rzeczy. Dobra, to śmigamy do kolejnego. Dev/prod partiality, czyli rozdzielenie dev/proda.

Łukasz Kałużny: Jego względna równość.

Szymon Warda: Ta, dev/prod parity. Chodzi o to generalnie, żeby one były do siebie w miarę podobne, co jest bardzo ważne i żeby były rozdzielone. I tu bym się zgodził, że z tym faktycznie jest największy problem obecnie, jeżeli już mamy mówić.

Łukasz Kałużny: Że nadal to występuje.

Szymon Warda: Nadal występuje albo nadal występuje taka opcja, że na przykład ten dev albo test jest kompletnie inny od proda, to, że utrzymanie ich, żeby były podobne po prostu nie występuje. Tego developerzy nie pilnują, a potem na to psioczą, że coś im nie działa. To wynika głównie z lenistwa po prostu, tu nie ma wytłumaczenia.

Łukasz Kałużny: Dobra, kolejne będzie - concurrency, bo pominęliśmy to. Czyli współbieżność to chyba złe określenie będzie, żeby zrównoleglać procesy. Czyli że jeżeli potrzebujemy się skalować, to powinniśmy robić to horyzontalnie.

Szymon Warda: Zgadza się. Znowu różne aplikacje mają różne charakterystyki, różne charakterystyki jeżeli chodzi o skalowanie, działanie i optymalny rozmiar. Więc to do końca tak nie wygląda. I to też się…

Łukasz Kałużny: Zestarzało inaczej.

Szymon Warda: Zestarzało się inaczej, ponieważ po pierwsze mamy całe taski w .Necie i te nasze maszyny wirtualne, które gdzieś tam, znaczy maszyny wirtualne, runtime’y, które wykonują nasz kod, one dużo więcej robią, że to niekoniecznie muszą być procesy, mogą to być wątki albo coś zbudowane na bazie wątków.

Łukasz Kałużny: Wiesz co? Nie i zobacz, że teraz ta całość, ja bym to wyrzucił do kosza i powiedział o horyzontalnym skalowaniu instancji aplikacji w tym miejscu już.

Szymon Warda: To w tym momencie pokrywamy się bardzo mocno z procesami tak naprawdę, bo te punkty są do siebie bardzo, bardzo podobne, jedno i drugie.

Łukasz Kałużny: Tylko wiesz i wtedy to historycznie… Raczej nadal męczysz się w niektórych rozwiązaniach na temat skalowania się workerami. Weźmy na przykład Node’a. Nadal jeden tam, powiedzmy jeden CPU, jeden core, jeden worker, są nadal takie rzeczy w konfiguracji.

Szymon Warda: Zgadza się, jak najbardziej. Redis, w ogóle teraz pozmieniali, to inna bajka. Dobra, lećmy dalej. Logi.

Łukasz Kałużny: Logi. Traktuj logi jako strumień zdarzeń, czyli wysyłaj na stdout, stderror.

Szymon Warda: Tak. Ogólnie chodzi o to, żeby aplikacja nie martwiła się tym jak zapisywać logi, tylko po prostu: wyrzucaj, w porządku.

Łukasz Kałużny: Więc inaczej, ma sens nadal.

Szymon Warda: Raczej ktoś musiałby się natrudzić, żeby zrobić inaczej.

Łukasz Kałużny: Raczej tak, bo potrzebowałbyś sidecara, przestrzeń tymczasową na pliki. Ewentualnie można też walić bezpośrednio z logera, z aplikacji do jakiejś usługi.

Szymon Warda: Albo samemu otwierać plik i tam pisać, to też by było mało ładnie. Ale nieważne. Przejdźmy - admin processes, czyli to, żeby rzeczy typu migracje danych, itd., odpalać jako osobne procesy.

Łukasz Kałużny: I to jest, jak porównasz, to jest chyba, kiedy zaczynasz robić to prawidłowo, job na Kubernetesie albo na CI/CD staje się normą.

Szymon Warda: Tak i ja zastanawiam się tak naprawdę, co z takimi sytuacjami, kiedy aplikacja wstaje, patrzy, że schemat jest inny i zaczyna się migracja, bo takie sytuacje zdarzają się jak najbardziej.

Łukasz Kałużny: Bo zapomniałeś przełączyć domyślnej flagi.

Szymon Warda: Tak. Albo, żeby tak było, często jest tak, że takie jest działanie niepożądane tak naprawdę, czyli że developerzy zakładają, że tak powinno być. Gorzej jak potem, bo to lokalnie działa świetnie, prawda?

Łukasz Kałużny: To czemu na produkcji nie będzie działać.

Szymon Warda: A na produkcji potem włączają to, skalują to do załóżmy trzech instancji i patrzą czemu mają logi na bazie albo błędy. I nagle trzeba dużo bardziej skomplikowany flow jeżeli chodzi o działanie dorobić. I wydaje mi się, że ze wszystkich to ten element jest chyba najbardziej dyskusyjny w tej sytuacji. Jak to tam powinno działać i co z tym zrobić?

Łukasz Kałużny: Raczej sam kierunek, że jest to w ogóle wskazane, to się nie zestarzało.

Szymon Warda: Znaczy jedna rzecz jest ważna tutaj, to jest myśl tego punktu jest to, że to powinno być w repo. Te taski migracyjne powinny być w repo, nie obok tak naprawdę. I to się przyjęło. Ja już widzę, że tak. Rzadko widzę, żeby to było łamane. Już mało kto chce ręcznie SQL-a pisać, bo też chyba mało kto umie tego SQL-a napisać.

Łukasz Kałużny: Jedno. I drugie, żeby te skrypty konsolowe właśnie, to wszystko było zdefiniowane i odpalane oddzielnie, a nie przez aplikację samą w sobie. Dokładnie.

Szymon Warda: Dobra, to teraz przejdźmy do tego, czego brakuje.

Łukasz Kałużny: Dobra, ja bym pierwsze wrzucił z praktyki, rzecz, z którą chyba mamy najwięcej na co dzień w konsultacjach, to są healthchecki po dziś dzień.

Szymon Warda: Znaczy to jest naprawdę fascynujące, ponieważ to jest chyba jedna z rzeczy, która jest na dokumentacji Kubernetes i w ogóle na szkoleniach jako takich.

Łukasz Kałużny: Raczej każdy cloud provider ma na temat aplikacji, jeżeli są kontenery albo hosting aplikacji, jest przynajmniej jeden healthcheck wymieniony.

Szymon Warda: Zgadza się i jest to najczęściej łamane. To naprawdę jest ciekawe jak to działa. Bez healthchecków to nie ma opcji, żeby ta aplikacja w jakimkolwiek klastrze zadziałała dobrze.

Łukasz Kałużny: Więc dla przypomnienia, mamy dwa podstawowe healthchecki, jak popatrzymy, w szczególności w kontekście graceful shutdown, tego disposability całego. Czyli jest to liveness, czyli endpoint w aplikacji, który mówi czy aplikacja w ogóle żyje. I jeżeli przestanie odpowiadać, to należy zrestartować aplikację. Drugi to jest readiness i on jest mega ważny, bo mówi czy można, jeżeli aplikacja coś wystawia, jakieś API, cokolwiek, to odpowiada czy aplikacja jest już gotowa do działania i czy można dopuścić do niej ruch.

Szymon Warda: Dokładnie tak. Tam jeszcze mają oczywiście odpowiednie delay’e na wstanie późniejsze, tego trochę tam jest, ale to jest dalej temat, który omawiamy na szkoleniu w ciągu pół godziny, jakoś tak.

Łukasz Kałużny: Ale kwintesencją readinessa i graceful shutdown jest to, że kiedy zaczyna się shutdown aplikacji, readiness powinien się przełączyć na odpowiadanie, że już nie jest gotowe, obsłużyć do końca requesty i aplikacja powinna się ładnie złożyć i nie dostawać już requestów.

Szymon Warda: A właśnie, mówimy o szkoleniach, mówimy o szkoleniach, to jakby ktoś był zainteresowany, to jeszcze Protopia Tech i tam mamy już taką pełną, pełną ofertę szkoleń.

Łukasz Kałużny: Dobra, i ostatni typ healthchecku to startup probe. Nie używajcie tego. Czyli aplikacja wolno wstaje i powinno się sprawdzać, czy ona już wstała czy nie.

Szymon Warda: Ma to swoje zastosowanie, zdecydowanie. Ma swoje zastosowanie, ważniejsze są odpowiednie ustawienie delay, według mnie. Dobra, to lecimy dalej. Ty wypunktowałeś, żeby nie było, Łukasz tutaj przygotował głównie materiał pod to, bardzo, bardzo chciał zrobić odcinek, więc jak najbardziej, wzorce zwiększające niezawodność. Mi się tylko tutaj uśmiecha generalnie nasza dyskusja o tym, że circuit breaker powinien być. Jeśli chodzi o circuit breaker…

Łukasz Kałużny: Retry’e, outbox pattern.

Szymon Warda: I ciekawe jest to, że dodałeś outboxa, bo retry’e mają swój sens, często w ogóle biblioteki już mają to wbudowane. Outboxa najczęściej widzę, że go nie ma i najczęściej też widzę opcję, że ludzie nie wiedzą, że on powinien być. To jest największy problem tak naprawdę.

Łukasz Kałużny: Tak, albo zakładamy, że kolejka zawsze będzie działać.

Szymon Warda: O jak się bardzo mylimy. Albo co więcej, że zawsze będziemy mogli do niej wysłać wiadomości, że zawsze przyjmie, albo że zawsze odbierzemy, albo że nie myślimy o tym, że to jest transakcja, czyli łączymy jedno z drugim.

Łukasz Kałużny: Te trzy podstawowe wzorce, które większość bibliotek i frameworków ma w sobie w jakiś sposób zopiniowane jak tego użyć.

Szymon Warda: Doprecyzuję tak naprawdę. Większość bibliotek do łączenia z bazami danych tak naprawdę. Może niektóre, odnośnie kolejek, przy reszcie już tego tak bardzo nie widzę.

Łukasz Kałużny: W sensie masz zawsze jakiś dodatek. W springu masz dodatek do zrobienia circuit breakera, retry’a, w .Necie masz… Inaczej, każde z tych rozwiązań ma jakiś dodatek, który jest w danym środowisku uznany, że ten jest dobry.

Szymon Warda: Z tym się zgodzę, ale bardziej chodzi mi o taką opcję, że na przykład łączysz się z bazą i tam masz parametr, np. ile masz retry’i zrobić, to z reguły już jest. Przy innych rzeczach jest to często pomijane, co jest trochę upierdliwe. Dobra, kolejny obszar to jest, rzuciłeś ciekawą rzecz, bo to jest zarządzanie tożsamością aplikacji.

Łukasz Kałużny: I ogólnie tożsamością.

Szymon Warda: Tak. Mam trochę miks czy to powinno być w takim, powiedzmy, nowym Twelve-Factorze, czy jakkolwiek byśmy go nazwali. Bo fajnie, tylko co, mówimy nagle, że wszyscy muszą lecieć po OAuth, itd.?

Łukasz Kałużny: Wiesz co, raczej bardziej jak lecimy z user to service. I drugie, co jest bardziej zaniedbane, service to service.

Szymon Warda: Okej, to z tym się zgodzę. Szczególnie service to service jest kompletnie…

Łukasz Kałużny: Dlatego nazwałem to tożsamością aplikacji, bo zobacz, że user to service jest jakoś na wejściu zadbany rynkowo.

Szymon Warda: Znaczy zadbany, po prostu działa z pudełka.

Łukasz Kałużny: Tak. A service to service, wiesz ile razy jest narzeźbiony tym ręcznym wystawianiem JWT-ków, API, tych tokenów i innych takich rzeczy.

Szymon Warda: Tak. Jeszcze jest inna opcja, jeszcze jest user to service w komunikacji asynchronicznej. To też jest ciekawy obszar, który z reguły jest na zasadzie, że: ale to my tego tu potrzebujemy? I tam jest dopiero rzeźbienia. Kolejna opcja, zarządzanie sekretami.

Łukasz Kałużny: Tak i tutaj zobacz, że Twelve-Factor: w dzisiejszych czasach uważamy to za problem, kiedyś nie było to w ogóle postrzegane jako problem.

Szymon Warda: Właśnie sugerujesz, że co? Żeby wszyscy właśnie używali Key Vault?

Łukasz Kałużny: Bardziej bym powiedział, że eksternalizacja tych sekretów tak na poważnie. Bo wiesz, z jednej strony masz sekrety Kubernetesowe, tak jak hostujesz aplikacje.

Szymon Warda: Które są takie trochę nie do końca.

Łukasz Kałużny: Tak, są nie do końca, ale są.

Szymon Warda: Są, ale one też nakłaniają do tego, żeby ludzie znowu wracali do sekretów w repo. To jest aż za łatwe.

Łukasz Kałużny: Jeżeli chodzi o techniki GitOpsowe, to tak, tutaj masz rację. A z drugiej strony masz, jak lecisz w cloudach, to masz keyvaulty, jakieś tam KMS-y, w zależności od dostawcy. Czy jak lecisz w on-premie to masz vaulta od HashiCorpa, plus parę innych rozwiązań do tego.

Szymon Warda: Zgadza się, problem jest taki co zrobić… Znaczy tak, jeżeli mówimy o prodzie, jest to w ogóle bezdyskusyjne, prawda, to w ogóle inna opcja. Natomiast co zrobić z taką opcją, jak robimy shift left i to developerzy sobie powiedzmy stawiają środowiska dynamicznie, itd., muszą skonfigurować. Właśnie nam nie chodzi o to, tak mi się zdaje, że nam nie chodzi o to, żeby stawiając deva na przykład zwracać się do adminów: ej, ustawcie nam sekrety.

Łukasz Kałużny: Nie, one powinny wynikać z CI/CD po prostu i IJAC-a.

Szymon Warda: Z tym się zgodzę. Dla mnie jedna rzecz, która jest tutaj ciekawa, to jest, którą też Kubernetes bardzo mocno pcha, to jest to, żeby używać tożsamości, żeby w ogóle pozbyć się tych sekretów. To jest najlepsze.

Łukasz Kałużny: Tylko to zrobisz w cloudach. Zobacz, że głównie zrobisz to w cloudach. SPIFI i inne rzeczy w on-premie się nie przyjęły.

Szymon Warda: Zgadza się. A co więcej, nie zrobię tego na przykład w takich bibliotekach typu właśnie do PostgreSQL, itd., które nie wspierają tego natywnie i muszę robić własne strzały HTTP, itd.

Łukasz Kałużny: Dam tu gwiazdkę, dam tutaj taką dużą gwiazdkę, nienawidzę tego robić, ale jest jeszcze Kerberos ciągle i da się go zrobić na Kubernetesie.

Szymon Warda: Tak. Z sekretami problem jest i problem będzie, póki nie umówimy się, że to po tożsamości i środowisko, sorry, ale głównie linuksowe przyjmie, że faktycznie są te rzeczy i można z nich korzystać.

Łukasz Kałużny: Dobra.

Szymon Warda: Śmigamy.

Łukasz Kałużny: CI/CD, to jest taki zabawny, bo zobacz, że tam ok, jest na temat buildu, releasu, ale nie ma już takich dokładnie praktyk pod spodem, nie wiem, testów i innych takich rzeczy, które nie były wtedy normą.

Szymon Warda: Znaczy dla mnie cały Twelve-Factor to jest takie zbuduj aplikację for dummies, taki zbiór naprawdę bazowych praktyk. ITen element The Twelve-Factor App, ten element aplikacyjny, bo to nie jest coś, co mówi o aplikacjach, więc normalnie bym nie dorzucił tego czy CI/CD. Ale w kontekście jak bardzo to jest szerokie, tak, zgodzę się, tym bardziej że CI/CD jest z pudełka i wszędzie.

Łukasz Kałużny: Dobra. Kolejna rzecz to komunikacja między usługami. Brakuje, jak byśmy powiedzieli sobie uniwersalnie, jak to zrobić. To była moja pierwsza myśl, że tego brakuje. Z drugiej strony, czy to trzeba specyfikować jako wskazówkę? Chyba, że for dummies.

Szymon Warda: To jest bardzo zależne od aplikacji. To jest jedna rzecz. Druga rzecz to jest to, że dyskusja czy używamy GIPC, czy używamy HTTP jest w każdym projekcie i będzie zawsze miała swoich wyznawców, bo to jest kwestia już religii.

Łukasz Kałużny: A może zróbmy GraphQL-a Szymon.

Szymon Warda: Tak, super. Moje zdanie o GraphQL-u doskonale znasz i mamy chyba zbieżne w tym temacie.

Łukasz Kałużny: Tak. Chociaż stabilizuje się, ostatnio zerkałem, zaczynają…

Szymon Warda: GraphQL ma sens w pewnych obszarach i jest naprawdę, naprawdę fajny. W komunikacji wewnątrzserwisowej, sorry, ale tego nie widzę.

Łukasz Kałużny: Dobra, kolejny punkt. No właśnie i teraz to jest pytanie czy to powinno być czy nie? Orkiestracja.

Szymon Warda: Dorzucenie tego spowoduje, że Twelve-Factor postarzałby się bardzo i tak się postarzał i by się związał z czymś konkretnym, mówiąc wprost, z Kubernetesem. A orkiestracja znowu jest ciężkim tematem. To jest temat mimo wszystko nie developerski, bym powiedział. To nie jest temat dla tego, dla kogo powstał Twelve-Factor, czyli dla ludzi, którzy budują swoje aplikacje.

Łukasz Kałużny: I wrzucają go na prostego PaaS.

Szymon Warda: Dokładnie tak. I nie oszukujmy się, większość systemów nie potrzebuje orkiestracji i nigdy nie będzie go potrzebowało.

Łukasz Kałużny: Tak, Docker Compose for the win.

Szymon Warda: Tak. Ruch tam będzie taki, że naprawdę wystarczy jeden kontener i będzie w porządku. Dobrze. Ostatni.

Łukasz Kałużny: Dobra, skalowanie stanu. I to jest taka rzecz, która mi wpadła. Zauważ, że nie ma tutaj jak sobie właśnie podejść do cache’y, baz danych i innych takich rzeczy i skalowaniem tego w tym miejscu.

Szymon Warda: Dobrze, to jest w ogóle ciekawe, bo ostatnio właśnie jak robiłem audyt, to właśnie był ten problem. Mianowicie, że ok, mamy cache, głównie nas tu boli cache aplikacyjny i mamy aplikację, która chodzi w wielu instancjach. Jedna aplikacja dostaje request, inwaliduje swój cache, ale pozostałe instancje nie mają o tym zielonego pojęcia, że ten cache powinien być zinwalidowany. Więc w takim razie jak obsłużyć to, żeby ten cache po prostu usunąć i wyczyścić? I to jest mega często pomijane. O tym po prostu ludzie nie myślą.

Łukasz Kałużny: To jest ciekawy w ogóle problem, bo jak zobaczysz, w świecie Javy było popularne działanie cache’y po multicast’cie.

Szymon Warda: Najfajniejsze było też z Redisem, czyli właśnie z takim multicastem, formą multicasta, a nie tam robisz pub/sub…

Łukasz Kałużny: Kolejkę albo klucz po prostu kasujesz, który jest dostępny, tudzież pamiętasz o TTL-ach.

Szymon Warda: Można też zrobić. Dobrze, podsumowanie? Czego tam brakuje i jak to w ogóle wygląda i co o tym myślimy?

Łukasz Kałużny: Słuchaj dobra, zestarzało się tak dwojako moim zdaniem, bo część jest aktualna, ale jest też multum, multum braków, jak byśmy zaczęli grzebać, jak mówisz zróbmy aplikację for dummies.

Szymon Warda: Tak jest to for dummies. Zastanawiam się, w sumie dalej istnieją odbiorcy tego typu rzeczy. Pewne rzeczy zostały zastąpione przez technologię Docker, bo już sporo leci, pewne stały się jakimiś tam dobrymi praktykami, po prostu weszły biblioteki. Mimo że my jesteśmy najczęściej zanurzeni w tym korpo światku, raczej nie doradzamy osobom poszczególnym, które robią swoją pierwszą aplikację, bo to trochę nie nasza bajka, ale wydaje mi się, że ta grupa odbiorców dalej istnieje i po prostu jest tak naprawdę. Więc tu jednak przyznam Ci rację, ma to jakiś sens. Może kwestia naszej bańki, w jakiej się obracamy, że rzadziej widzimy te problemy, o których mowa. No ale on dalej istnieje faktycznie.

Łukasz Kałużny: Dobra.

Szymon Warda: Powinny być dalej omawiane? Nie, wydaje mi się, że to istnieje, ma się i koniec.

Łukasz Kałużny: Nadal aktualne jest zerknięcie czy w niektórych miejscach, jak robimy, jesteśmy z tym zgodni, z niektórymi z punktów.

Szymon Warda: Tak, dobra rzecz dla ludzi, którzy na studiach, tuż po studiach, którzy piszą swoje pierwsze aplikacje, chcą coś wystawić.

Łukasz Kałużny: Jedna rzecz, jak używacie Kubernetes i tak będę sprawdzał te disposibility przy audycie.

Szymon Warda: Dobrze, to co, kończymy?

Łukasz Kałużny: Kończymy.

Szymon Warda: Trzymajcie się.

Łukasz Kałużny: Na razie.