Szymon Warda: Cześć! Słuchacie Patoarchitektów. Prowadzą Szymon Warda.

Łukasz Kałużny: I Łukasz Kałużny. Klasycznie wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io, tym razem /70 albo gdzieś na dole w Twoim playerze w podpisie. Dobra Szymon, co dzisiaj bierzemy na warsztat?

Szymon Warda: Fallacies of distributed computing, czyli czego powinniśmy się bać, jak mamy system rozproszony, a czego może nie powinniśmy się bać i z czego to właściwie wynika, że niekoniecznie powinniśmy się bać.

Łukasz Kałużny: I co? Dzisiaj sprawdzimy, jaka jest też aktualność tego. Bo chyba… Przechodząc do historii. O co chodzi? To jest rzecz, która się pokazała, kiedy systemy rozproszone zaczynały istnieć. Czyli lata ‘90.

Szymon Warda: Łukasz, może bardziej zaczęły być bardziej powszechne, bo istniały wcześniej - ale były powszechne po prostu.

Łukasz Kałużny: Tak, zaczęło się powszechne, czyli przestaliśmy się powoli logować na jeden serwer, żeby obsługiwać aplikacje. Więc pojawiało się rozproszenie i Peter Deutsch + inni z jego zespołu z Sun’a wtedy, który królował w takich rzeczach, w latach ‘90 zaprezentowali właśnie zestaw ośmiu takich błędnych założeń naszego postrzegania, które w tamtym momencie pokazywały istotę problemu i tego jak tam zaczną ewoluować… IT do tego co my teraz znamy i dość ciekawie jak na tamten okres, to w prosty sposób też przedstawiały te założenie, więc chyba nie ma co tracić czasu i przejdziemy sobie po prostu przez nie po kolei i skomentujemy.

Szymon Warda: Tak, lecimy. Pierwsze: Network is reliable, czyli mówimy, że sieć jest niezawodna i że wszystko zawsze nam dotrze i że wszystko z siecią będzie zawsze w porządku. Tak w bardzo, bardzo dużym skrócie. I co tu mamy? Z mojej perspektywy to jest tak… Zależy, na co patrzymy, bo jeżeli patrzymy na komunikację między backendami, to to się poprawiło znacznie. Tu widzimy poprawę strasznie między czasem, kiedy fallacies były napisane tak naprawdę. Obecnie sieć z reguły działa z moją jedną uwagą, potrafimy nagle przełączyć się, nagle zgubić jakiś pakiet, ale z reguły retry to ogarnia. Najczęściej - to widać z mojego doświadczenia - to jest połączenie z bazą danych relacyjną. Tam faktycznie są sytuacje, że nagle mamy przepięcie, ale retry to z reguły ogarnia. A z drugiej strony urządzenia mobilne - to dalej jest zawodne.

Łukasz Kałużny: Znaczy, powiedzmy sobie, że to, że sieć jest niezawodna to największy problem będzie występował nie w obrębie systemu, tylko klient-system.

Szymon Warda: Tak, bez dwóch zdań. Tak.

Łukasz Kałużny: To jest tam problem. Jedna rzecz, z której się mogę zaśmiać, że i tak osobny punkt, podpunkt powinien być do DNSa, że zawsze coś zawiedzie, bo zawsze wina DNSa.

Szymon Warda: Tak, albo się nie odświeża, albo coś w tym stylu, dokładnie tak.

Łukasz Kałużny: Albo się gdzieś to zwali. Dobra, czyli powiedzieliśmy sobie o tym, że właśnie przełączanie i inne rzeczy, czyli co trzeba mieć świadomość load balancerów, które mamy i wszystkich transparentnych rzeczy, które są pod spodem, które gdzieś celowo nawet wsadziliśmy w naszą infrastrukturę i że żyją. Retry i jeszcze circuit breaker czasami, jeżeli mówimy o integracjach z zewnętrznymi rzeczami.

Szymon Warda: Nie poznaję… Tyle lat namawiania i jednak się udało.

Łukasz Kałużny: Zawęziłem z zewnętrznymi systemami. Wewnątrz retry nam wystarczy w większości przypadków.

Szymon Warda: Tak. Ale w sumie dobrze dotknąłeś właśnie, że w ramach wewnętrznej komunikacji między naszymi backendami to problem występuje w małym zakresie, bo występuje w małym zakresie. Faktycznie on będzie istotny ze stanami zewnętrznymi, ale to z reguły nie przez samą sieć, tylko przez to, że te systemy, znaczy, mogą też nawalić, ale dla nas będzie w sumie nawet to samo. Tak naprawdę. Na to samo się skończy. Dobrze, idziemy do kolejnego?

Łukasz Kałużny: Wiesz co, tak. W sumie tutaj nie ma sensu dalej przy tym… Więc może podsumowując: tak, ten problem nadal występuje, ale już w zupełnie innym zakresie, czyli głównie my, świat zewnętrzny albo klient do naszego systemu.

Szymon Warda: Dokładnie. Kolejny. Latency zero, czyli mówimy, że ten narzut latencji na połączenie. Jest zerowa i w ogóle połączenie będzie praktycznie zawsze i będzie wszystko się z opóźnieniem nam działo. No i tu znowu pewna część de facto, kiedy to się bardzo mocno postarzało, można powiedzieć, no bo co; na połączeniach http albo jakikolwiek synchronicznych ta latencja jest niska, jeżeli mówimy o komunikacji. Nie mówimy między regionami, czyli między kontynentami. Tak naprawdę.

Łukasz Kałużny: No, nie jest już w ogóle problemem, o tak.

Szymon Warda: Tak, są sytuacje, kiedy nas to realnie zaboli, ale dla mnie osobiście to jest… Latencja ma znaczenie, ale to jeżeli mówimy o systemach opartych na wiadomościach i tu jest latencja do spójności systemu, tutaj dużo bardziej występuje. W komunikacji synchronicznej, ta latencja jest znikomym problemem. W asynchronicznej jak najbardziej występuje, ale to już jest trochę inny zakres niż oryginalnie było myślone.

Łukasz Kałużny: Problem jest fajny jeszcze jak mamy dużo małych requestów tak jak teraz, ale znowu to jest klient do naszego systemu.

Szymon Warda: Tak. Szczególnie właśnie w sieciach mobilnych tak naprawdę, bo tam nie wiemy, co się może dziać.

Łukasz Kałużny: Tak, kiedy tych requestów nawalamy. Zresztą odpalmy Facebooka i zobaczmy sobie ile tych requestów idzie, jak próbujemy załadować walla.

Szymon Warda: Tak, ale znowu z dużą ilością małych requestów… Będziemy mieli problemy też z bardzo wieloma innymi zachowaniami, więc jednak ta agregacja requestów jest konieczna tak naprawdę.

Łukasz Kałużny: Tak, też te opóźnienia są fetyszyzowane tak ogólnie. Żeby… To musi być szybkie i w ogóle.

Szymon Warda: Tak.

Łukasz Kałużny: W większości systemów to się nie sprawdza. OK, są branże gdzie to ma sens. Weźmy e-commerce’y, w których te opóźnienia gdzieś tam było widać, rzeczy gdzieś w apkach mobilnych, które muszą być w miarę real-time’owo. No i cały hyper-currency trading.

Szymon Warda: Dobrze to dotknąłeś generalnie, że to taki fetysz. Tak samo, jak lubimy się brandzlować nad mikrooptymalizacjami w kodzie, a nie patrzymy, że nasze SQL’e lecą n+1-kami, tak samo też nad tym lubimy się bazować. Ooo, co tu będzie.

Łukasz Kałużny: Tak.

Szymon Warda: Tutaj realnie milisekundy zaoszczędzimy tak naprawdę.

Łukasz Kałużny: Uwielbiam te rozmowy do cloud’u, czyli tam 21 milisekund. Jak tu mam 5, ale Twój request i tak się przerunuje 500 milisekund.

Szymon Warda: Tak dokładnie, żeby to było realnie naszym problemem… Dużo trzeba zrobić wcześniej, żeby to naprawdę śmigało, żeby to nas zabolało. Najczęściej nie jest to po prostu ważne. Dobrze. Bandwith is infinite - fallacy nr. 3. Czyli możemy naszą kochaną siecią wysłać wszystko co tylko byśmy chcieli. I znowu to wali myszką.

Łukasz Kałużny: Tak, ale po dziś dzień w niektórych przypadkach jest problemem.

Szymon Warda: Jest. I tu mam jak zwykle powiemy sobie o mobilkach, ale dla mnie problemem dużo częstszym to jest to, że zaboli nas… Jeżeli przesyłamy zbyt dużo, zaboli nas deserializacja tych obiektów tak naprawdę… Zanim zaboli nas częściej sieć tak naprawdę.

Łukasz Kałużny: Tak, plus wszystkie jakieś rzeczy procesowe, które batchowo Ci przewalają, że się nie zmieszczą w oknie etc. I znowu to jest gdzieś na poziomie często albo złego podejścia do tego po prostu, że zakładamy, że przewalamy za dużo naraz tak naprawdę… Zamiast gdzieś sobie to zbuforować i przerobić. Druga rzecz, gdzieś infra np. Czyli wszystkie migracje, backupy i inne rzeczy w których zaczyna to się robić tricky pod spodem.

Szymon Warda: Tak, ale właśnie powoli dochodzimy do tego wniosku tak naprawdę, że fallacies obecnie - znaczy trochę będziemy o tym później mówili, że one bardziej zostały zepchnięte na poziom infrastrukturalny, a nie na poziom tego, co powinniśmy i co realnie jest zagrożeniem na poziomie architektury systemów tak naprawdę. Mamy dużo więcej abstrakcji od tych lat ‘90.

Łukasz Kałużny: I niektóre nawet pomagają.

Szymon Warda: Tak. I są mniej leaky, niż by się wydawało. Dobrze, Fallacy nr. 4 Network is secure. I tu dużo mówimy o tym, bo faktycznie np. zero trust network jak najbardziej. Czy to jest realny problem większości systemów? Nie mówię, że wszystkich. Większości systemów. Najczęściej on jest secure, jeżeli mówimy o naszych backendach, na które trzymamy, ale najczęściej jest secure enough. Może tak to powiedzmy, bo powiedzenie, że on jest bezpieczny to jest inna bajka.

Łukasz Kałużny: Tak, z perspektywy sieci, bo tutaj całość polegała na tym, że sieć może być gdzieś naszym problemem, że będzie takim… Błędy w konfiguracji sieci albo tego jak jest zrobiona, że będą powodowały, że to ona może skompromitować nasz system.

Szymon Warda: Tak.

Łukasz Kałużny: Więc całość tej zabawy w dzisiejszych czasach trochę inaczej wygląda.

Szymon Warda: Co jest ważne to znowu komunikacja, klient - nasze backendy, czyli weryfikujmy certyfikaty, bo pod tym względem man in the middle to jest realne ryzyko. Głupio byłoby obudzić się, no z portkami spuszczonymi, że tak powiem.

Łukasz Kałużny: Więc całość technik. Inne… Jeżeli ktoś chce leniwie, to te wszystkie Service Meshe i inne zabawki też powodowały to, że się zamykały same… MTLS. Zamyka cały problem. Jeżeli mówimy wewnątrz systemu, pomiędzy systemami takiej komunikacji.

Szymon Warda: Tak - i z reguły wystarcza tak naprawdę. To jest realny problem. Jeśli zaczynamy mieć własną platformę, na której utrzymujemy wielu tenantów wewnętrznie.

Łukasz Kałużny: Tak.

Szymon Warda: I to faktycznie, ale to jest bardziej na poziomie tym, że chcemy zabezpieczyć naszą komunikację, żeby przypadkiem coś nie wyciekło poza ramy, które byśmy chcieli, niż ryzyko, że nagle nasza aplikacja zaczyna nasłuchiwać wrednie tak naprawdę.

Łukasz Kałużny: Wiesz co? Warto dodać tutaj tak naprawdę, że te wymagania trafimy też, jeżeli ktoś pracuje w jakiejś branży regulowanej, to i tak zapewnienie tego choćby na poziomie MTLSa, czy TLSa plus jakiś OAuth i inne rzeczy wynika z regulacji.

Szymon Warda: Tak.

Łukasz Kałużny: Że trzeba zapewnić integralność tego ruchu, który przychodzi, czyli de facto pod spodem TLSa.

Szymon Warda: Tak, no to znowu budujemy sobie kolejne warstwy, przez które potencjalny atak, potencjalny problem deweloperski nie wycieknie. Tak naprawdę.

Łukasz Kałużny: Tyle. Dobra. Następne.

Szymon Warda: Fallacy nr. 5. Topology doesn’t change, czyli nasza struktura - jak jest ułożona nasza cała sieć jest niezmienna. I dla mnie to, co się spotyka najczęściej to jest znowu, wracamy do tego co powiedziałeś wcześniej, czyli DNS-ów i objawia się najczęściej przez cachowanie HTTP clienta, który robi tego resolve, go stworzymy tak naprawdę, czyli pobiera mapowanie DNS na IP.

Łukasz Kałużny: W zależności od języka, są różnie… To jest zaimplementowane.

Szymon Warda: Tak, ale najczęściej o ten problem chodzi.

Łukasz Kałużny: Więc jedna rzecz. Druga to jest po dziś dzień hard-kodowanie IP-ków i fetyszyzacja sztywnych IP-ków.

Szymon Warda: Znaczy w ogóle… Wszędzie, gdzie mamy tego IP-ka, no to trzeba uważać, bo to się faktycznie potrafi zmienić.

Łukasz Kałużny: To jest jedno. Druga rzecz, która jest trochę… Właściwie… Ale znowu wchodzimy, że jest to część infrastrukturalna w dzisiejszych czasach. Co w sumie też to do tego dochodziło. Jakby nie popatrzeć, tylko tam były tego początki. To, że kto inny zarządza tą infrą i wprowadza tam zmiany.

Szymon Warda: Zgadza się, mamy też lepiej ułożone te procesy, mamy lepiej ułożone w ogóle jak infra działa, i te ułożone po prostu działają lepiej tak naprawdę.

Łukasz Kałużny: Tak, ale korpo przypadki, że ktoś zgubił reguły na firewallu, bo coś wymieniał czy rozwalił routing to jest nadal codzienność.

Szymon Warda: Tak, ale to fajnie pokazuje to, że kiedy to publikowano, to były fallacies, którymi realnie powinni przejmować się architekci aplikacyjni i systemowi. A tutaj de facto po raz kolejny pokazujemy to, że bardziej tym się zajmują osoby zarządzające infrastrukturą, taką już powiedzmy… Kabelkami, firewallami i tak dalej.

Łukasz Kałużny: Tak, albo na styku tych dwóch dyscyplin.

Szymon Warda: Dokładnie tak. Dobrze, fallacy numer 6. There is one administrator, czyli że mamy jednego administratora, czyli jedna osoba wprowadza zmiany w obrębie tego, co się dzieje wokół naszego systemu. I to jest chyba dead, że tak powiem, nieżywe, najbardziej nieaktualne.

Łukasz Kałużny: Tak, jest wielu adminów i trzeba się z tym pogodzić i z zarządzaniem. I to jest ten moment przechodzenia z właśnie rozrostu tego IT.

Szymon Warda: Tak, ale też przeszliśmy z tego… Fajnie pokazuje, że kiedyś to jedna osoba wprowadzała zmiany, a obecnie wprowadzamy te zmiany, przez kod po prostu. Powinniśmy generalnie. Ten, kto nie robi. No to może…

Łukasz Kałużny: Inaczej. Dużo tych osób kontrybuuje do wprowadzenia tych zmian.

Szymon Warda: Tak, dokładnie, w każdym razie widać - to ta wiedza nie siedzi w czyjejś głowie, to jest bardzo ważne, więc.

Łukasz Kałużny: Powinna nie siedzieć w czyjejś głowie.

Szymon Warda: No tak, zapędziłem się. Dobrze.

Łukasz Kałużny: Wiedza plemienna do dzisiaj jest problemem, ale tutaj o tym nie mamy.

Szymon Warda: Fallacy nr. 7. Transport cost is zero, czyli że przesyłanie danych nas nic nie kosztuje. I tu jest kilka tak naprawdę, bo obecnie nas kosztuje. Chmura nas zabilluje.

Łukasz Kałużny: Tak, za transfery, więc tak. Tutaj to jest ciekawe. Transfery się pojawiły i właśnie…

Szymon Warda: To są… realnie te koszty nie są duże, ale jeżeli mówimy o ilości, które przesyłamy. One potrafią być zauważalne zdecydowanie, szczególnie, że mamy usługi, które są billowane, też per dane wchodzące.

Szymon Warda: Albo przeprocesowane.

Szymon Warda: Tak, ale to na to samo się skupia. Z mojego punktu widzenia to jest, zanim nas zaboli sieć, koszt transportu, to zaboli najbardziej nas realizacja, czyli ponownie wysyłanie do dużych obiektów.

Łukasz Kałużny: No, całe przepisywanie, modła przepisywania na JSON’a potrafi kopnąć. Chociaż teraz no jest trochę już lepiej jeżeli popatrzymy na moc obliczeniową, ale znowu green coding i inne te trendy też ciekawie to unormują.

Szymon Warda: Ale to… Ile byśmy CPU nie mieli de facto, no to szkoda marnować cykle nawet 30 albo więcej procent na cały czas deserializowanie obiektów JSONowych. To dalej jest dość duży narzut. Nie oszukujmy się.

Łukasz Kałużny: Dobra i przejdźmy do ostatniego.

Szymon Warda: Dobrze. O fallacy numer 8. Network is homogenous, czyli sieć jest taka sama, można powiedzieć. Generalnie jest spójna, jest do siebie podobna.

Łukasz Kałużny: Stop. Bo jest to prawdą, ale już nie w części aplikacji… a infry.

Szymon Warda: Tak, znaczy na poziomie… Na poziomie aplikacji nas to po prostu z reguły nie interesuje tak naprawdę.

Łukasz Kałużny: Tak, trzeba być świadomym, że sieć potrafi dać ciała, ale już przestaje nas to interesować.

Szymon Warda: Tak. Boli nas założmy, jak co, mamy jakieś klastry między Kafki i klastry redisowe i klasy, gdzie musimy się między wieloma datacenter komunikować i jakieś… więcej fallbacków. Ale to jest… dość dalekie strategie tak naprawdę.

Łukasz Kałużny: Tak, druga sprawa, jakieś kompatybilności ze sobą, implementacji protokołów i innych rzeczy. Weźmy np. że Juniper potrafi się tam z Cisco pogryźć czy inne były historie. Teraz tego coraz mniej jest, no ale nadal niekompatybilności pomiędzy sobą.

Szymon Warda: Tak, dobrze. Więc podsumujmy tak naprawdę. Łukaszu, pierwsze, pierwszy wniosek.

Łukasz Kałużny: Pierwszy, takie… Całość jest taka, że trąci to myszką i w niektórych punktach, dla większości przypadków.

Szymon Warda: Dla architektów aplikacyjnych.

Łukasz Kałużny: Dla architekta, tak, może tak, architektów aplikacyjnych, systemowych. Jeżeli popatrzymy od strony infrastruktury, to część z tych rzeczy nadal jest realną rzeczą do zaopiekowania po stronie infry. Teraz. Przesunęliśmy ten poziom abstrakcji w dół.

Szymon Warda: Tak, ale też fajnie pokazuje, że problem dalej na poziomie infry występuje, ale jego ryzyko i zasięg jest dużo, dużo mniejszy.

Łukasz Kałużny: True.

Szymon Warda: Dobrze. Uwaga na cachowanie DNSów. To faktycznie potrafi zaboleć. I nieraz widziałem… I jest ciężki w debugowaniu. Później na to bardzo ludzie wpadają, że nagle to może być problemem de facto.

Łukasz Kałużny: Dlaczego automagicznie restart aplikacji pomaga?

Szymon Warda: Tak, dokładnie. To naprawdę potrafi spędzić wiele, wiele godzin i nie wiadomo czemu.

Łukasz Kałużny: Tutaj nie powiedzieliśmy jeszcze właśnie o… Cachowanie, TTLe, cała ta konfiguracja, która za tym idzie. Jeżeli popatrzymy też na tę całą, część taką sieciową, inną, w wielu przypadkach wystarczą rzeczy, które dostajesz gotowe z pudełka w ramach swoich abstrakcji i robisz by the book i retry w większości przypadków Cię uratuje wewnątrz Twojego systemu.

Szymon Warda: I też dodajmy, że z reguły jest konieczny. Przynajmniej z mojej perspektywy na poziomie komunikacji z bazą relacyjną… On z reguły jest konieczny, szczególnie, jeżeli mówimy o…

Łukasz Kałużny: Tak, w onpremie też się zdarza, że trzeba to ponowić. Tyle, nie ma co.

Szymon Warda: Jest dobrym zwyczajem.

Łukasz Kałużny: Dobra i w sumie jeszcze taka rzecz, myśl. Te wszystkie powyższe problemy. One wystąpią, ale często w wielkiej skali albo na poziomie infry. Nisko, niskopoziomowo.

Szymon Warda: Tak. I nie ma co się nad nimi brandzlować na poziomie “co będzie, jeżeli” w większości sytuacji, bo realnie będzie dużo więcej problemów wcześniej, zanim one wystąpią tak naprawdę.

Łukasz Kałużny: Tak. A jeżeli musisz się tym przejmować, to mam nadzieję, że przez skalę. Bo wtedy masz fajne problemy.

Szymon Warda: Tak, bo one występują w jakimś tam promilu przypadków. Ale jeżeli ilość przypadków jest dostatecznie duża, to będą dostatecznie częste. To się po prostu do tego sprowadza. W korpo aplikacjach z reguły tej skali nie ma.

Łukasz Kałużny: Dobra, to co, kończymy?

Szymon Warda: Kończymy, na razie.

Łukasz Kałużny: Hej.