Patoarchitekci rozmawiają nie tylko o programach i systemach, ale również o platformach edukacyjnych. Zobacz, co sądzą o Educative!
Ciekawe linki i inne znaleziska z tego odcinka:
SW: Cześć, słuchacie Patoarchitektów. Prowadzą: Szymon Warda
ŁK: i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie klasycznie na patoarchitekci.io/53 lub w linku na dole odcinka.
SW: Dobrze, masz parafialki.
ŁK: Co mam?
SW: Parafialki.
ŁK: Parafialki, tak. Architektura i kontenery. 12 grudnia. Czyli konferencja, którą organizuję troszeczkę w innym składzie. Jestem łącznikiem pomiędzy Patoarchitektami, a Architekturą i kontenery. Kilka ciekawych sesji. O dziwo, Szymon, zaskoczy Cię: dopuściliśmy dwie sesje z Terraformem.
SW: Ojej, ojej.
ŁK: O dwóch różnych punktach widzenia Terraforma, ale bez hejtu, tylko jak robić to poprawnie. Plus racje na temat budowy platform kubernetessowych z punktu widzenia jednego z inżynierów z banku. Oraz parę innych best practice. Jedna sesja architektoniczna live na żywo, bo wpadliśmy na pomysł, że zrobimy rysowanie architektury na żywo na podstawie tego, co widzowie będą sugerować i dyskutować na ten temat. Zobaczymy, co z tego wyjdzie.
SW: Ale to jest proste. Jeden kwadracik K8s, w drugim kwadracie chmura i generalnie nie wiem… Nie rozumiem, gdzie masz problem.
ŁK:No właśnie chciałbym te kwadraciki rozbić. Czyli uznajemy, że te atomy trzeba jednak rozbić.
SW: E tam. Dobrze.
ŁK: Dobra.
SW: Lecimy z linkami, tak. Mówimy o kwadracikach. Mam dwa ciekawe linki. Kontynuuję moją myśl uczenia i przekazywania trochę wiedzy. Bo w poprzednim odcinku rozmawialiśmy trochę właśnie o uczeniu, przekazaniu wiedzy dla początkujących managerów zespołów, managerów de facto. Ale tym razem problem, który od dawna miałem, jest dwojaki, tak naprawdę. Jeden to było to, że często spotykamy się z tym, że jeżeli szkolimy w jakichkolwiek organizacjach, to ludzie często nie znają podstawowych technik albo nie mają świadomości dobrych patternów. I z reguły znalezienie dobrego wprowadzenia do tego, jakie są podstawowe paradygmaty projektowania systemów, ale też jak są inne systemy, z których korzystamy zaprojektowane. I dorwałem. Ostatnio został mi polecony kurs na Educative: Grokking the Advanced System Design Interview. Jest naprawdę dobry. Jestem pod kolosalnym wrażeniem z kilku powodów. Po pierwsze, omawiają niby podstawowe rzeczy typu partycjonowanie itd.
ŁK: Wiesz co… Ale tak patrzę sobie, bo zerknąłem teraz, przepraszam, że tak wiesz… od razu wjadę. Zerknąłem tam. To nie do końca są proste rzeczy.
SW: Do tego właśnie dążę. Budują na bazie prostych rzeczy, a potem wchodzą w… jak działa Cassandra, jak działa Dynamo. I to nie jest tak, jak sobie myślimy: „A high level, wszystko jest fajnie, spoko”. Naprawdę wchodzą w detale. Są fajne animacje. Są fajne pytania. Naprawdę jest to zrobione dobrze. Często do takiego system design polecało się książki, to ewidentnie one w tym momencie wymiękają. Bo element interaktywności. Ja się wciągnąłem, bo to jest dla informatyka jak robienie dobrej krzyżówki. Super zrobione. Jestem pod kolosalnym wrażeniem.
ŁK: Tak. Wiesz co… Jedną rzecz tylko taką widzę. Tu akurat część modułów jest zamknięta, więc jestem ciekaw, jak wygląda. I widzę, że jest po prostu pokazane typowo per problem. Widzę, że są takie szybkie building bloki, a potem wprowadzenie już jak działa na konkretnych przykładach. Pierwszy, który zalinkowałeś, to takie wprowadzenie po building blokach, a drugie rozpoczęcie… Takie duże wrzucenie na głęboką wodę. Takie poważne.
SW: Tak. Bo jest też drugi link: Grokking Modern System Design Interview for Engineers & Managers. I to znowu jest… To absolutnie nie jest dla managerów.
ŁK: (śmiech)
SW: Nie.
ŁK: Wiesz co… może tak. Technical managers albo Engineering Manager.
SW: Nie, Łukasz, nie.
ŁK: By pasowało. Nie? (śmiech)
SW: Czytam teraz ten kurs i naprawdę nie jest dla managerów. Super zrobione, bo wchodzą od podstawowych zasad szacowania rozmiarów, ruchu, projektowania API, podstawowe rzeczy abstrakcji, jak się buduje. Takie podstawowe booting buildbox, czyli numerowanie, kolejność, sagi, orkiestracja. collision detection. W ogóle takie podstawowe elementy są wytłuszczone, a potem wchodzą w projektowanie a’la Twitter. Takie z reguły porównanie systemów, powiedzmy, dużej skali (których używamy), z reguły się kończą, że to jest takie machanie rękami albo:„O, tu dodamy to i po prostu działa”. Nie. A tam naprawdę jest zrobione na realnych kawałkach, jak to naprawdę działa. Fajne problemy są omówione. Super! Uważam, że ten kurs, szczególnie właśnie for manager, polecam szczególnie architektom albo osobom, które chcą być architektami, bo naprawdę daje do myślenia. Fajnie wiedzę też przy okazji porządkuje. Duże lepiej niż blogi.
ŁK: Wiesz co… Kiedyś po jednej z takich serii warsztatów i mega wyjazdu z Gutkiem popełniłem wpis, który określiłem: This is the basic stuff. To, co powiedziałeś, te wszystkie building i inne bloki, że troszeczkę zakładasz, że zrobisz sobie z ludźmi na sali… Jechaliśmy na zaawansowany warsztat na zasadzie: „Trzeba troszeczkę wskazać kierunek… Zamodelujmy i zobaczmy, co zrobić z waszą aplikacją, żeby ją zacząć modernizować”. I zakładamy sobie, że zrobimy 4-godzinny czy tam jednodniowy taki recap podstaw, czego możemy teraz użyć.
SW: Mhm
ŁK: Tych właśnie building bloków, które w Cloudzie zamieniasz na usługi i inne rzeczy, powinno wydawać się normalne. No niestety, trzeba było trochę więcej czasu poświęcić, żeby wyrównać tę wiedzę.
SW: Ale to jest normalne. Ta wiedza jest często… Często spotykam się, że albo ktoś ma takie podejście, że to jakaś magia, albo jest podejście, że wchodzimy w surdetale i właściwie skupiamy się w ogóle po co to jest. Dlatego właśnie jestem pod mega wrażeniem całości tego kursu, bo jest naprawdę super ustrukturyzowany.
ŁK: Wypada trochę ładniej, jak tak tylko kliknąłem na to, co nie jest paywallem, loginwallem. Wygląda lepiej niż popularny system design firmware z Githuba. To repo, które jest na Githubie.
SW: Dużo lepiej. Tak. W ogóle to, jak działa interaktywność, pytania, które prowadzą, quizy i tak dalej… Naprawdę są zrobione sensownie.
ŁK: Tak. Ja tutaj wrzucę, trochę przejdę do swojego linka i myśli na dzisiaj. Jest wpis sobie wpis na newstack.io na temat: SRE reability w Google i ich adwokatowania. Jedno zdanie, które jest na początku: w skali Google szansa miliona do jednego dzieje się cały czas.
SW: Ta myśl powtarza się dość regularnie, tak naprawdę.
ŁK: Tak, ale właśnie przypominając, jakie oni problemy rozwiązują. I moja myśl z tego jest następująca, bo zaliczyłem kilka problem shootingów produkcyjnych z leżącymi produkcjami ostatnio. My jako konsultanci, bo też powiedzmy sobie: konsultanci, doradcy nie z nazwy, że jesteś kimś od outsourcingu na godziny, tylko faktycznie (wchodzisz, wychodzisz, robisz robotę, wychodzisz albo konsultujesz, doradzasz, odbierasz słuchawkę i doradzasz, co zrobić), widzimy więcej takich problemów na rynku, które się dzieją. To jest troszeczkę w takiej skali: jeżeli coś się może sfakapić, niestety my to widzimy najczęściej.
SW: Zgadza się. Ostatnio właśnie jak pomagałem jednej firmie, to znowu była opcja tego, że… Mnie to pocieszyło, bo dało im takie prawidła, jak powinny wyglądać. Takie trochę prostsze: „Okej, zróbcie tak na start. Przez pierwsze pół roku pewnie Was ten problem nie dotknie, tak naprawdę. Więc zróbcie, a potem będziecie ewoluowali”. Normalnie, jak im się twarze ucieszyły, że mają coś prostszego i potem, gdzie mogą ewoluować. Więc to też jest taki problem, że nie ma co wyjeżdżać z armatą za każdym razem.
ŁK: Dokładnie. Wiesz co, miałem tak teraz w trakcie tych trzech wtop, które pomagałem odratować leżącą produkcję. I to dosłownie była leżąca produkcja. Z czym się spotkałem? To jest nadmierne complexity, nadmierne skomplikowanie rzeczy. To, co powiedziałeś, że można zacząć prościej. I tutaj jest jedna z ciekawych rzeczy. Jest założenie: zrobiliśmy, bo uważaliśmy, że tak powinniśmy to zrobić, że musimy to zrobić.
SW: Tu wrócę do talka, który mieliśmy na meet up’ie: problemy odnośnie MVP typu, że tak powinniśmy zrobić, albo: tak inni robią. Zróbmy, żeby to przede wszystkim działało. A potem możemy sobie komplikować życie. Ciężko jest odjąć complexity. Fajnie to… Znowu od jakiegoś czasu mamy taką tradycję, że właściwie niemalże co odcinek mówiłem o Elonie.
ŁK: Właściwie to samo chciałem… (śmiech). To samo chciałem powiedzieć. Ten sam. że SpaceX jego rzecz. Dlaczego to działa?
SW: Tak. Ale to nie jest, że SpaceX. Bo to jest z podejścia japońskiego prowadzenia, importowania. Ale to jest to, że zanim zaczniemy automatyzować, pierw trzeba usunąć.
ŁK: Tak, dokładnie.
SW: To jest super ważne. I tu Elon ma absolutną rację. I coś, co istnieje, zawsze będzie miało większy koszt niż to, co jest zautomatyzowane.
ŁK: Tak, ale w ogóle jest to fajnie powiedziane. Jeżeli masz problem, zastanów się, czy możesz usunąć jego źródło przez usuwanie elementu, który go generuje.
SW: Tak, tak.
ŁK: I komponentu. I to jest taka rzecz, która jest trochę… Lubimy się babrać w kodzie, a usuwanie jest najmniej przyjemną częścią z całości.
SW: O nie, taki dobry commit to już wywala tysiące linii, to jest…
ŁK: Ja wiem (śmiech), ale to ma… To jest ten PR, którego ktoś robi: zaakceptuj, bo nie chce nawet tego czytać.
SW: Tak, bo on przychodzi po dużej ilości testów. Ale realnie ja się z tym zgodzę, że… Szczególnie w dobie K8s-a, niektórych będę winił, gdzie można łatwo stawiać różne zabawki. Koszt wejścia organizacji w K8s-a jest duży, a koszt postawienia dobrego K8s-a jest jeszcze większy. I tam po prostu nagle wszystko powinniśmy zrobić.
ŁK: I słuchaj, i gdzie zabawki są. Przyjęło się, że zabawki są mocno promowane. Bo ile razy można pokazać, jak zrobić wreszcie prawdziwy zero downtime deployment. Przecież lepiej dorzucić sobie jakieś nowe zabawki.
SW: Mój drogi, przecież CV Driven Development dalej żyje i ma się dobrze. I ma się nawet coraz lepiej, bym powiedział.
ŁK: Wiem. Jest to problem. I taka ciekawostka, która mnie wczoraj dotknęła z tego wszystkiego, która spowodowała te przemyślenia. Jest to bug, który nazywa się containerd sporadic timeouts. To jest taka świeżyneczka, która wyszła w updacie Ubuntu, który jest popularnym blistrem, jakby nie patrzeć, w różnych miejscach. Które powoduje ciekawe zawieszanie się pod spodem… Container D robi ciekawą rzecz, bo freezuje działanie container D, czyli np. pod się dłużej stawia albo kontener powinien się już wyłączyć, od pół godziny się wyłącza i nic z niego nie strzeliło. Takie różne ciekawe zachowania. I często jest tak, że w trakcie troubleshootingu, jak idziemy sobie warstwa po warstwie i oglądamy, zaczynamy widzieć jakąś… ja to zawsze określam takim momentem magii: że, co tu się w ogóle dzieje? Wiesz, że jest spaprane, czujesz, że jest spaprane. Logi i inne rzeczy pokazują, że wszystko jest w porządku. I potem nagle natrafiasz na takie ustrojstwa, które właśnie są bugami. Tylko przy okazji, tak jak mój przypadek wczorajszy spowodował, było usuwanie miliona complexity przed zanim doszło się w ogóle do źródła, co jest nie tak.
SW: No nie oszukujmy się, K8s stał się tym elementem, na który patrzymy jak na wodę, de facto, prąd itd. To jest po prostu… Znowu będzie trochę, że po angielsku będą takie commodity, tak naprawdę. To nie jest coś, na co patrzymy. To po prostu działa. to jest niby sieć, a to nie jest tak proste.
ŁK: I to jest commodity w jednym momencie. Takie moje przemyślenie, które chyba muszę kiedyś zrobić na dłuższy talk, że to jest commodity, jeżeli aplikacja jest prawidłowo napisana.
SW: Nie. To jest commodity, póki się nie zepsuje, bo zepsuje się prędzej czy później. Tak samo, jak czasami woda i prąd.
ŁK: (śmiech)
SW: No nie? Idzie zima, więc…
ŁK: Co zrobimy… Wiem. Co będzie, tak z preppersami. Co będzie, jak prądu nie będzie przez dwa dni?
SW: Rura pęknie i nagle okazuje się, że nie mamy wody na cztery godziny. To będzie ten case. Wszystko to jest commodity póki mamy odpowiednio duże zasoby. Finansowe i ludzkie. Żeby to utrzymywać, żeby było commodity. Jeżeli odpalamy K8s-a na małym zespole, dla firmy, która nie ma odpowiedniej dojrzałości organizacyjnej i wiedzowej, to to nie będzie commodity. To będzie dodatkowa warstwa problemów.
ŁK: Tak. I dokładamy do tego zabawki albo elementy, które wydawało nam się.
SW: Albo które powinny być. Bardzo lubię tę opcję. Powinno być.
ŁK: To jest fajne powiedzenie.
SW: Must should I have generalnie. To jest fajne pogrupowanie, de facto. Zaczynamy od tego, które faktycznie musimy. Dobrze.
ŁK: Kończymy.
SW: Chyba się dogadaliśmy. Kończymy. Trzymajcie się. Hej!
ŁK: Na razie, hej!