Ostatnie Patoszkolenie w tym roku👇
Cloudflare po raz kolejny na celowniku Patoarchitektów. Na co tym razem warto zwrócić uwagę?
Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Cześć! Słuchacie Patoarchitektów w wersji short. Prowadzą Szymon Warda
Łukasz Kałużny [ŁK]: i Łukasz Kałużny. Linki do tego odcinka znajdziecie na: patoarchitekci.io/44. Pobędziemy jeszcze chwilę z krótką formą, bo jesteśmy z Szymonem zawaleni projektowo.
SW: A Q4 jest straszny.
ŁK: Jest straszny, tak. Wrzesień jest straszny. A potrzebujemy chwili, aby przygotować mięsiste odcinki. Plus niedługo będą też goście w różnych tematach. Teraz chcemy z Wami wejść w większą interakcję. Jeżeli macie do wersji short jakieś linki, swój komentarz, który chcecie, abyśmy przytoczyli (może być również głosowy i możecie go wrzucić) albo chcecie poznać po prostu nasze zdanie na temat, który podrzucicie – od teraz wprowadzamy dla Was taką możliwość. Więc sprawdźcie patoarchitekci.io/short albo zerknijcie do opisu odcinka. Przypominamy również o GitHubowym UserVoice, który był kilkukrotnie już inspiracją do dłuższych odcinków. Dobra.
SW: Znaczy, bardziej chyba standaryzujemy, bo pomysły zawsze wpadały: kanały typu Twitter, linki albo rozmowy, a teraz po prostu standardzik. Dobra. To ja się wtryniam z linkiem w takim razie. Cloudflare. To będzie jeden link. Pamiętam, jak zaczynał się Cloudflare: od prostego ataku przed DOS-em i to było tyle. Obecnie poszli w mega ciekawym kierunku, bo rozwinęli bardzo dużo usług. Wprowadzili R2, czyli odpowiednik S3 backetów Amazonowych. Czyli to, od czego zaczynała każda chmura. Zaczęli budować całą platformę, można powiedzieć, że zestaw usług, tak: Cloudflare Zero-trust. Wokół tego zbudowali coś, co naśladuje VPN-a, czyli Cloudflare Access, Secure Web Gateway, wprowadzili API Managemend Endpoint , co jest w ogóle ciekawe. To jest takie API Gateway, ale skierowany w kierunku mierzenia metryk, platencji, błędów. Nie tak jak my znamy Enterprise Gateway do hostów.
ŁK: Pierwsza warstwa. Ale pierwsza warstwa.
SW: Tak, ale zrobili to naprawdę fajnie. Teraz wykorzystują taką, którą zrobili, Area 1 do wyszukiwania phishing ataków na maile. Zrobili cały Cloudflare Data Loss Protection, który ma całe rule do śledzenia ruchu i obserwowania, czy nie ma wycieków danych. Mają cały zestaw gotowych ruli, żeby obserwować, co wycieka, a co nie wycieka. Jestem pod wrażeniem, bym powiedział, bo naprawdę rozwinęli się strasznie, w fajnym kierunku.
ŁK: Dobra. Bo idąc po kolei… Ja wziąłbym na początek część aplikacyjną. Bo, powiedzmy sobie, mamy 3 scenariusze. Mamy rzecz typowo aplikacyjną u nich w stosie teraz. Druga rzecz to jest to, co jest powiązane z…
SW: Networkingiem. Typowym.
ŁK: Networkingiem i ochroną taką anty DDOS.
SW: Tak.
ŁK: I trzecią rzeczą jest cały scenariusz, który budują… enterprisowy. Tak jak o tym DLP wspomniałeś między innymi. I lecąc z perspektywy ich offeringu, który jest w ogóle… w tych darmowych tiarach albo cenach jest… no śmieszny.
SW: Jest śmieszny, tak.
ŁK: Śmiesznie tani.
SW: Ale też i dobry. To nie jest tak, że on jest tani, bo jest badziewny.
ŁK: Właśnie nie… Nie, właśnie o to chodzi. I całość na przykład… Zaczynając od storage który poszedł, jest świeżynką. No to lecąc, najbardziej fajną rzeczą jest w tym region, automatic. Jeżeli nie masz wymagań, to robi to z perspektywy, gdzie jest uploadowane, to tam zaczyna przenosić te dane albo pobierane, cachowane, więc…
SW: Ale to też jest bardzo spójne z tym, jak oni to robią. Oni po prostu mają od groma Egee Data Center…
ŁK: Dokładnie.
SW: …i po prostu są w stanie to porozrzucać de facto. To się super wpisuje w ich use case.
ŁK: Tak, dokładnie. I lecąc tym use casem. Rzecz, która dla mnie jest niesamowita w tym offeringu, który się łączy, to są workery.
SW: Tak. Bo wcześniej workery były kulawe bez R2.
ŁK: Tak, właśnie. Bez R2 były…
SW: No były kulawe.
ŁK: …były typową bezstanówką. O. Bo to jest lepsze określenie. Były typową bezstanówką.
SW: Tak, zgodzę się. A więc duży limit tego, co możesz zrobić w aplikacjach bezstanowych, de facto. A i tak finalnie musiałeś z jakąś usługą chmurową się komunikować.
ŁK: Czyli tak. Ale lecimy. Przy czym od storage’u mieli jeszcze key-value use store’a. Więc to też nie jest tak, że było źle, bo mieli dobrze rozproszonego key-value use store’a. Więc mamy fajną platformę. Lecąc ich workerami, które są, bo o tym ciągle zapominamy, to workery ładują nam niesamowite możliwości przetwarzania dosłownie na Edge’u czegoś, czego reszta dostawców cloudowych nam nie daje. Można położyć to naprawdę…
SW: Ale też się w tym kierunku przesuwa. Żeby nie było.
ŁK: Tak, przesuwają. Ale jako pierwsi mają najszerzej rozwiniętą platformę produkcyjną.
SW: Tak. Oni przez to, że chronili się przed DOS-em, mają dużo data center i na realnej faktycznie krawędzi.
ŁK: Tak, i CDN-ów. Bo to jest ważne, że to leci sobie przy CDN-ie. Więc może jeszcze, żebyśmy nie poszli sobie za daleko, teraz sam sobie przywalę. Te workery to jest serverless, de facto. To jest po prostu function as a service, albo jak kto woli: lambda, google function czy azure function. I pozwala… Jedna wada, że tylko Java Script, i bodajże już WebAssembly tam wjechało, ale nie dam sobie teraz ręki za to uciąć, bo nie sprawdzałem tego. Ale leci wszystko na izolowanym na V8 na Node.js, wiec możemy pisać. I kolejną rzeczą, która jest jeszcze, to cały ich stos do Web Site Developmentu. Mają całą zabawkę, którą do static page’y i innych page’s, i rzeczy związane ze streamowaniem, jak i przeróbką całych i składowaniem obrazków assetów, więc tutaj jest…
SW: Tak, to już pominąłem…
ŁK: Tak, bo ja wiem, bo to jest ten…
SW: …nic super nowego. Ale tego jest dużo.
ŁK: Dużo. Właśnie o to chodzi, że jako taka platforma aplikacyjna do zrobienia dużej części frontowej, brakuje im jakiejś dokumentowej albo relacyjnej bazy a’la Cosmos DB czy Spanner Google’owy, żeby móc tworzyć coś naprawdę większego na tym stosie.
SW: Tak. Ja bym się z tym zgodził. W sensie… Relacyjnego raczej nie pójdą, bo w tym momencie tego nie rozproszą po wielu data center, de facto, po wielu wyjściach, ale… To zaczyna mieć na tyle ręce i nogi, że to już nie jest tylko front aplikacji… Znaczy, powiem tak… Do rzeczy prywatnych to jak najbardziej część aplikacyjna jest w porządku. Mnie dużo bardziej interesuje i robi wrażenie to, co oni robią z całą platfromą zero-trust. Bo to zaczyna powoli być faktycznie używalne w firmach i przy coraz większej gamie projektów.
ŁK: Tak. Więc zero-trust jest właśnie dużą. Jedna rzecz, która tam może być trochę, że… jak ja na to patrzę znając cały stos enterprise’owy, że jeszcze nie do końca wpisuje się w cały model. Troszeczkę… Tak samo jest, bo mamy zerotrustowy odpowiednik neon corb, który troszeczkę lepiej… To jest zero-trust od Google czy to, co Microsoft u siebie robi i nie nazywa wszędzie zero-trustem wokół workspace’ów. I tam one trochę lepiej się w to wpisują niż [niezrozumiałe] Cloudflare. On się tak nie wgryza w ten ekosystem jeszcze.
SW: Znaczy… nie, żeby nie było. Oni się… Im do takiego prawdziwego enterprise jest jeszcze daleko, dlatego że cały endpoint management to nie jest taki API Gateway, de facto. To nie zastąpi niczego. Mają jeszcze usługę z [niezrozumiałe], która też jest biedna na ten moment czasowy. Na teraz to nie jest [niezrozumiałe], jakiego znamy chociażby z Azure czy z innych dostawców chmurowych, czy nie tylko…
ŁK: Oj, Azurowy ssie więc… I jak gdyby jest…
SW: Wiem…
ŁK: Ten Cloudflare’owy jest lepszy. Pod tym względem.
SW: Łukasz, nie oceniam, wymieniam. (śmiech) Nie wylewamy z rana. Ale mi się podoba to, że faktycznie, że jeżeli oni zrobiliby faktycznie tego [niezrozumiałe], dobrego API Gatewaya, to wydaje mi się, że to by była duża konkurencja na rynku. Sporo by zamieszali, gdyby to było faktycznie zrobione dobrze. Taki porządny API Gatewaye. Jeszcze potem spiąć z VPN-ami. Super.
ŁK: No to by potrafiło zrobić. Dobra, to może przejdźmy…
SW: Dobra. Śmigamy do Twojego.
ŁK: Mojego. Dyskusja prowadzona na… Efekt takiego researchu pod pewną dyskusję, którą miałem. Pozdrawiam przy tym Piotrka Stappa, bo to z nim dyskutowałem. Było pytanie dość ciekawe architektoniczne: mamy milion użytkowników i w jaki sposób wysłać im jak najbardziej realtime’owo albo near realtime’owo powiadomienia. Macie aplikacje, macie jakąś apkę i chcecie jak najszybciej wysłać prosty message, nazwijmy to: „Hello world”, ale pingając, że coś się zadziało.
SW: Czyżby mBank znowu dostawał powiadomienia? (śmiech) Przepraszam.
ŁK: Dobrze, że mnie tam nie ma. (śmiech). Ale tak… Case, jeżeli kojarzę, to tam chodzi bardziej o część akcji reklamowych i innych takich rzeczy.
SW: Tak. Ale, Łukasz, mówisz realtime. Określmy więc, o jakiej skali. Realtime to taka magiczna wartość, która nigdy nie jest prawdziwa, de facto.
ŁK: De facto mówimy o czasie zbliżonym do 2 sekund.
SW: To jest faktycznie bardzo realny realtime.
ŁK: Tak, tak, tak. Nazwijmy to górną granicą. No i tak się zastanawiałem, usiadłem z kalkulatorem. Idąc, bo ta rozmowa była, gdy byłem gdzieś tam… Szedłem i rozmowa, że tak powiem z kalkulatorem po drodze: ile do tego będzie potrzeba serwerów. I rzuciłem sobie, że to będzie pewnie kilka maszyn 4-corowych, żeby coś takiego obsłużyć. I zakładamy, że lecimy websocketami, bo jest to najbardziej wydajny sposób do takiej rzeczy. Serwery…
SW: Do… szybko będzie, tak.
ŁK: Tak, szybko. No i potem, po całej dyskusji, usiadłem zobaczyć, jak świat sobie z tym poradził, bo często ludzie takimi wynikami się chwalą. I na przykład taki… Tom co właśnie jest linkiem: appwrite. Jest takie repo i mają realtime 1 milion. I, słuchajcie, jakie trzeba zasoby, żeby właśnie… Ogólnie polecam cały wpis, ale jakie trzeb zasoby, żeby taki milion websocketowy utrzymać? Wystarczył 32-corowy, 128 GB serwer. Pojedynczy.
SW: To nie jest dużo. To wcale nie jest dużo.
ŁK: No właśnie… przeliczyłem się z zasobami dwukrotnie, bo ja powiedziałem, że 2 razy. Że jak zrobimy to porządnie, to będzie trzeba 2 razy tyle zasobów, żeby coś takiego utrzymać. I tutaj zrobiło to na mnie wrażenie, że 32 cory, 128 GB, że ta skala nie musi być duża.
SW: Największe wrażenie to robi transfer, bo mówimy o 8 TB transferu, de facto. Więc tego… Nie, ale websockety faktycznie są bardzo…
ŁK: Dobra. Ale tak: websocket są tutaj cholernie wydajne pod tym względem. I w ogóle polecam wam zrobienie takich ćwiczeń czasami i zastanowienie się, jak coś zrobić, jak coś zaprojektować i jakie z tego liczby wyjdą. A potem zobaczyć, jak świat do tego podchodzi.
SW: Tak. Podstawowe ćwiczenie z psychologii nauczania się. Dokładnie. Dobry link - testowanie. Przeglądam wpis – faktycznie jest dość treściwy, mięsisty i to wygląda całkiem nieźle. Opisowy, ale mimo wszystko naprawdę dobry.
ŁK: Jest tak opisowy… Ciekawostką jest… Najbardziej polecam, bo to jest zawsze problem, jak przygotować system operacyjny pod spodem. Developersko o tym nie myślimy, a problem cały jest, jak zrobić infrastrukturę. I jest tutaj opisany cały problem, ma on tutaj swoje ładne miano, to jest C10K problem, czyli problem optymalizacji socketów, ile przez to przepchniemy. I jest pokazany ich konflikt również, w jaki sposób został skonfigurowany sam stos w Kernellu Linuxowym od strony sieciowej. Jakie parametry zostały tam w sys CTLU wrzucone, żeby to w ogóle miało rację bytu. Bo tam się dzieje cała zabawa. Na domyślnych ustawieniach tego nie wyciągniemy.
SW: Tak. Ale tego jeszcze w ogóle jest bardziej, ładniej w Dockerze. Dobra, wpis warty uwagi, zdecydowanie. To kończymy na dzisiaj?
ŁK: Kończymy.
SW: Na razie, hej!
ŁK: Na razie.