Patoarchitekci w wersji SHORT! Czy musimy na nowo wynajdywać koło? Przypomnij sobie, jak zadbać o stabilność!
Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Cześć! Słuchacie Patoarchitektów. Prowadzą Szymon Warda
Łukasz Kałużny [ŁK]: i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na: patoarchitekci.io/38. Dzisiaj forma eksperymentalna dla nas – nowy format, żeby pojawiać się u was regularniej w słuchawkach. Będziemy dyskutować o tym, co nam wpadło w oko, o jakichś ciekawych linkach albo będziemy dawać wymiksowany komentarz dotyczący tego, co się dzieje na rynku. Czyli to co zwykle robiliśmy jako wstęp do długich odcinków, będzie teraz regularną krótszą formą. Więc… Szymonie, co przygotowałeś?
SW: Ciekawy artykuł odnośnie do AirBnb i AirBnb’s microservices architecture journey to quality and engineering. Ciekawy artykuł, bo to trochę powtórka tego, co od wielu lat wiedzieliśmy, ale parę ciekawych rzeczy znaleźli. Przede wszystkim, opisali proces, w jaki podchodzą u siebie do optymalizacji. I to jest całkiem fajne. Co można złapać? Po pierwsze, define the problem(s), czyli identyfikujemy, jaki jest problem. Kolejne to find solution(s) to improve, czyli znajdujemy, jak możemy rozwiązać dany problem. Następnie, make the solution used, czyli zaczynamy używać te rozwiązania, aby zweryfikować i mieć dane oraz metryki w kontekście, czy to jest w ogóle używane i czy spisuje się poprawnie. Potem, increase the solution adoption, czyli podejście: skoro jakoś działa, to zwiększamy skalę wykorzystania i patrzymy, czy może coś znajdziemy. Czyli robimy ładny cannary rollout, tylko w formie biznesowej – co jest bardzo ważne. Jednak najciekawszy punkt jest na końcu, czyli solve the solution’s scaling challenges. Czemu to wymieniam? Często skupiamy się na tym, że mamy rozwiązanie, optymalizujemy, żeby działało w odpowiedniej skali, a potem się okazuje, że jest ono w ogóle nie używane, nikt go nie chce albo z innego powodu jest nieopłacalne, aby go wdrożyć. Bywa, że optymalizujemy i robimy testy wydajnościowe tylko po to, żeby potem stwierdzić, że to nie ma sensu. A najlepsze testy wydajnościowe będą na produkcji. Przynajmniej przy jakimś procencie trafficu, nie oszukujmy się.
ŁK: To jest właśnie ten problem, że ta trójka jest tu istotna: skalowanie i zwiększanie adopcji nie jest w planach od początku, tylko jest iteracyjnym krokiem. I to jest dla mnie rzecz, która wydaje się oczywista, ale chcemy nadal budować to bizancjum.
SW: Tak. I jest jeden z przypadek, gdzie owner biznesowy miał takie podejście, żeby na produkcję szybko wdrażać zmiany. Jeżeli coś było użyteczne, gwarantował zespołowi czas na refaktor tego. Tak to zmieniło drastycznie podejście do deploymentu, że deployment nowych funkcjonalności trwały mniej niż tydzień (od pomysłu do tego, żeby weszło na produkcję). Z reguły to były trzy-cztery dni.
ŁK: Tak. I to jest w ogóle ciekawą rzeczą w dużej skali.
SW: Ale nie chodzi o dużo skalę, chodzi o to, że…
ŁK: Ale właśnie wiesz… o różne rzeczy. Tylko ja mówię przy skali, bo tam wychodzą najciekawiej fuck’upy. Czytałem dość ciekawe opinie niektórych ludzi z Facebooka, że ludzie od budowy platform infrastrukturalnych, gdzie kodowali, przez 5 lat nie napisały żadnego unit testu, ale za to napisały masę performance testów. Zasada była taka, że jak masz feature flagi – możesz szybko wchodzić na produkcję, ale masz być dostępny w razie problemów, aby je naprawiać.
SW: To się zgadza. Jednak ja na to patrzę z jeszcze innej perspektywy. Jak często jest taka opcja, że biznes coś chce, póki to jest na rysunku? Szczególnie UI – póki jest na rysunku, to będziemy dumali, może przycisk w lewo pięć pikseli itd. Itd. Dwa miesiące rozmyślań, a później nie jest to robione. A na nawet w kontekście biznesowym: zrobić, może wyglądać brzydko, może wyglądać gorzej, niech biznes zacznie używać i zobaczmy, czy faktycznie będą wykorzystywać oraz jakie są ich potrzeby. Ludzie mają tak, że dopiero jak widzą, że mogą wykorzystać, dopiero wtedy faktycznie mają konkretny feedback. Może się to wydawać proste, w zupełności wystarczy.
ŁK: Wiesz co… Jak o tym mówisz, od razu mi się nasuwa, że wytwarzanie softu nadal jest mocno waterfallowe, bo ludzie zapomnieli, że z założenia… Agile był trochę wcześniej, jak o tym mówiliśmy, i chodziło, aby często deployować i wdrażać zmiany nieco sprint, tylko jak jest coś gotowe – wdrażać bez czekania i zbierać feedback. Mam wrażenie, że cały ten loop wraca w sercu do waterfalla i do udawania zwinności.
SW: Mnie się wydaje, że to wynika z braku zaufania – że zespoły nie ufają, że jak wypuszczą coś na produkcję, to będą miały czas na zmiany. A znowu biznes, jak mówi: „O! Mamy na produkcji!”, to znaczy, że to już jest gotowe. Nie. Od tego, że to działa, jest daleko, do tego, żeby to było production ready. To jest długa droga. Ale idąc dalej. Jakie problemy sobie zidentyfikowali? Ownership, brak IaC, czyli owner, żeby zespoły mogły tworzyć infrastrukturę i observability, czyli weryfikacja ownershipu. Potem jest całkiem ciekawa seria wpisów. Pierwszy punkt jest normalny, ale pozostałe są dla mnie trochę prześmiewcze, tak naprawdę. Jednak problemy mikroserwisu zdefiniowali. Złożoność jest bardzo rozproszona w przypadku małych mikroserwisów – faktycznie, jak mamy proces, to on się wszędzie rozchodzi.
ŁK: Klasyka.
SW: Tak, rozpływa się. Brak stabilnych punktów kooperacji. Faktycznie, jak mamy serwis, który robi jedną rzecz, to ciężko jest cokolwiek gdzieś dorzucić. Ale! To jest tak: ciężko jest określić skalę rażenia przy wdrożeniu, bo dotykamy wielu mikroserwisów i to jest ten sam argument, który był przy monolitach: ciężko określić skalę rażenia zmiany, ponieważ dotykają potencjalnie całego serwisu. A tu mamy: ciężko określić skalę zmiany, bo potencjalnie dotykamy wielu serwisów. Ta sama argumentacja, tylko w drugim kierunku. Idąc dalej, kolejny argument: jest dużo więcej hakowania, ponieważ nie ma jawnego ownershipu niektórych serwisów, gdyż trzeba pododawać kod i on się po prostu rozpływa. I to jest znowu ten sam argument, który był przy monolitach: że jest więcej hakowania, bo jest lack of ownership de facto.
ŁK: Cały problem sprowadza się do tego, Amazonowe przemyślenia to pizza team, to jest jedyny poziom niezależności, a powyżej tego zawsze będzie burdel.
SW: Będzie burdel.
ŁK: Tak. Pokazuje, że będziemy się… Im mamy więcej ludzi, tym większy będzie burdel.
SW: Znaczy… nawet nie chodzi o ilość ludzi. Chodzi o to, że brak ownershipu, to jest problem społeczny, zespołowy. Próbowaliśmy go rozwiązać przez rozwiązania techniczne, a rozwiązania techniczne nigdy nie rozwiążą problemów ludzkich tak naprawdę.
ŁK: Raczej tak. I druga sprawa, że ten wpis dość fajnie pokazuje… Samo AirBnb, jak popatrzymy, nie jest w porównaniu do tego z czym walczą w niektórych typowych korporacjach z softem – oni nie mają aż tak dużo domen biznesowych.
SW: Tak. Chociaż, swoją drogą, mają bardzo dobrą analitykę. Ale tak. Zgodzę się, że mają…
ŁK: Jeżeli popatrzymy, to jest kilka domen. Jak sobie wyróżnimy wysokopoziomowe, to jest kilka obszarów i oni w swojej skali już mają takie problemy. To pokazuje, przy wbrew pozorom niezagmatwanym modelu biznesowym…
SW: No tak. Nie robią systemów księgowych, albo systemów ERP z elementami prawnymi, albo po prostu te rzeczy z reguły kupują. Ale jeszcze jest parę rzeczy fajnych w tym artykule. Fajny jest cały proces, jakim podeszli do śledzenia zmian. Przede wszystkim stworzyli osobny zespół, którego odpowiedzialnością będzie trackowanie postępów i ownership wokół całego procesu migracyjnego. I to jest bardzo fajne, ponieważ jeżeli mamy inicjatywę biznesową albo techniczną, to musi być ktoś, kto to spina i ktoś, kto tych ludzi pośpiesza. I to pokazuje, że ten temat jest dalej ważny, de facto. Dobrze. To jak śledzili? Przede wszystkim trackowanie postępu to jest normalna sprawa – jeżeli czegoś nie możemy zmierzyć, to nie możemy o tym mówić, nie możemy śledzić postępów itd. Musimy umieć trackować. Kolejny punkt, bardzo się na nim uśmiechnąłem, bo też to właśnie robimy: wygaszanie mało wykorzystywanych endpointów serwisów. Najprostszym sposobem do migracji czegoś jest usunięcie tego. Jeżeli jest coś mało wykorzystywane albo jest martwym kodem na zasadzie: „Fajnie, gdybyśmy tego użyli” lub: „Przyda się na później” – ubijmy to.
ŁK: Dokładnie.
SW: Od tego mamy GIT-a, że jeżeli te rzeczy będą ewentualnie potrzebne, ale pewnie i tak nie będą, albo napiszemy je zupełnie inaczej. Kod, który leży w repo od trzech lat i nikt go nie dotykał, gwarantuję, że nie będzie działał.
ŁK: Wiesz co, taka była moja rozmowa z klientem kilka miesięcy temu. Mam dokładnie tę samą filozofię. Klient upierał się, żeby od razu zaimplementować wszystkie możliwe konfiguracje, jakie będą. Powiedziałem: „Dajcie sobie spokój!”. Zróbmy interfejs, wrzućmy jeden, bo tam chodziło o providery uwierzytelniania, wykorzystajcie ten jeden provider uwierzytelniania i zobaczymy, kiedy w ogóle to zaimplementujecie…
SW: Zgadza się.
ŁK: Sprawdzałem ostatnio – nadal nie są potrzebne inne wersje.
SW: Bo to jest takie gdybanie. Dlatego właśnie wracamy teraz do tego pierwszego punktu, o którym mówiliśmy: żeby wypuścić, aby ludzie zaczęli używać. Bo wszyscy mówią: „A może by się przydało”, „A jak teraz nie zrobimy, to potem już tego nigdy nie zrobimy”. Realia są takie, że z reguły nie potrzebujemy bardzo wielu rzeczy. Co zrobili dalej? Jeden taki trochę framing z angielskiego. To jest błędnie ujęte. Czyli ustalili migrację, jako wartość dodaną biznesową, ponieważ to potem umożliwia im rozważenie innych strategii biznesowych. Czyli de facto pokazali, że to jest inicjatywa techniczna, ale ona wpływa na biznes i dochodowość spółki i jest kluczowym krokiem w rozwoju. To nie jest coś, co sobie IT wymyśliło i muszą zrobić, przez co nie mogą robić innych rzeczy biznesowych. Patrzą na zasadzie, że inaczej nazywamy rzeczy. Ale od tego, jak nazywamy te rzeczy i w jaki sposób komunikujemy je w organizacji, zależy, czy inicjatywa umrze czy nie umrze i ile na to pójdzie pieniędzy oraz czy ludzie będą się stresowali tym albo czy będzie frustracja, że IT znowuż coś robi, a my nie wiemy, co oni robią. I to jest bardzo, bardzo, bardzo kluczowe. Ostatnio oglądałem dokument dotyczący globalnego ocieplenia i tam było tłumaczone, że naukowcy są słabi w komunikacji społecznej i komunikacji do zwykłych ludzi. Nie możemy zrobić tego samego w IT, bo jak będziemy słabo komunikowali, to dalej będziemy niezrozumiali i koszty tego będą dużo większe. Podsumowując: krótki, całkiem fajny artykuł. Dużo tu jest rzeczy trochę zabawnych, kilka do wyniesienia. No niezły. Ogólnie jestem z niego zadowolony. Łukasz, co u Ciebie?
ŁK: Tak. Ja troszeczkę… Inna część technologiczna dla równowagi. Wpis ma może dwa lata, ale przeżył drugą młodość jakiś czas temu. Rzeczy, które chciałbym wiedzieć na produkcji przed użyciem RabbitMQ. Spis tych rzeczy jest bardziej klasyczny, jest bardzo fajny, mówiąc o wchodzeniu z nową technologią i użyciu jej na produkcji.
SW: Rabbit nie jest taki nowy. To nazwijmy…
ŁK: Raczej tak, ale to z perspektywy kompetencji, teamu etc. Zamieńmy tego Rabbita na kawkę, zamieńmy na dowolne inne słowo. I fajne jest podsumowanie, bo pokazuje, że wchodząc w technologię, za dużo zawsze zakładamy pozytywnych scenariuszy. I te czarno myślicielstwo jest przydatne przy wykorzystaniu nowych technologii. Pierwsza rzecz, którą bym tutaj zaznaczył: nie masz kompetencji, weź pomoc z zewnątrz, żeby zweryfikować, czy to ma sens. To jest pierwszy punkt w tym wpisie.
SW: To jest coś, czego zespoły prawie nie robią nigdy. Każdy… „A to zobaczę inne zespoły”, „A to ja zobaczę, jak to działa i wystawię np. Rabbita albo dowolny serwis”. Po prostu z best practices albo prostej instalacji. Tak, bardzo dobry punkt.
ŁK: Następną rzeczą, którą rzucił, to jest pokazanie użycia gotowców, gotowych bibliotek do komunikacji innych rzeczy. Już nie wchodząc w detale opisu tak naprawdę, ale wskazał, żeby użyć już gotowych bibliotek do komunikacji innych rzeczy z nową technologią, a nie lecieć low levelowo. Lecieli na czystym Rabbit kliencie pod spodem.
SW: Łukasz, ale tak przecież będzie szybciej. Co ty mówisz…
ŁK: (śmiech)
SW: (śmiech) Żartuję sobie. Jednak słyszałem takie argumentacje, że nie korzystamy z bibliotek, bo chcemy mieć lepszy performance.
ŁK: Tak, performance albo sami napiszemy swój wrapper, którym się przypniemy i zbawimy świat. I to jest to.
SW: Albo lepiej: nie chcemy się uzależniać od innej biblioteki, więc będziemy mieli swój kawałek kodu.
ŁK: Następne rzeczy, które mi się podobają, to jest część architektoniczno-operacyjna i świadomość tego, jak coś działa, rozwiązanie. Autor opisywał swoje różne problemy i wskazał np. rzeczy, o których zapominamy przy systemach rozproszonych, czyli network partitioning, który przy event streamingu, messagingu, potrafi być po prostu wrzodem albo przyprawić nas o wrzody żołądka (jeżeli mamy więcej niż jedną maszynę i chcemy mieć wysoką dostępność). I co jest ważne z tego punktu: warto poznać tę technologię i to, jakie ma prawidła i ograniczenia.
SW: Zawsze powtarzam klientom, że to, że potrafią używać Rabbita, wcale nie znaczy, że potrafią utrzymywać go na produkcji. To są dwa zupełnie inne skillsety i organizacja musi nabyć te umiejętności.
ŁK: Tak. I mój drugi ulubiony, to są pytania do zespołów, jak konsultujemy technologie. Czy widzieli, jak wyglądały upgrade’y w danej technologii? Jak się podniosą? I co muszą zrobić, żeby podnieść się do nowej wersji? Mieliśmy nawet taki fajny przypadek, że klient w ogóle założył, że nie jest potrzebny upgrade, wszystko idzie w cloudy i wszystko zrobi się samo.
SW: Odważnie.
ŁK: Tak. I było takie… Jakbym to nazwał… To brzmiało mniej więcej jak takie pacnięcie, jak zobaczył, co to oznacza. I tu chodzi właśnie o przewidzenie tych rzeczy operacyjnych. Kolejny punkt operacyjny to: jaki jest Twój plan, jeśli stracisz wszystkie wiadomości z Rabbita?
SW: Albo z dowolnego systemu kolejkowego.
ŁK: Albo z dowolnego systemu. Ogólnie: jaki masz plan obsługi tych przypadków.
SW: Znaczy… Ja bym skupił się na kolejkowym, bo na poziomie baz danych już się nauczyliśmy, że robimy backupy itd. Na poziomie systemów kolejkowych z reguły o tym w ogóle nie myślimy.
ŁK: Outbox i inbox patterny okazują się, że takie proste rzeczy, a tak bardzo potrzebne.
SW: Tak. Nawet taki fail Rabbita, gdy wiadomości już wyszły z inboxa, są w Rabbicie i nagle np. Rabbit się przekręca i nie mamy tych wiadomości, które były w kolejkach. Dobre, bardzo dobry punkt.
ŁK: Tak. Jak odtworzyć je potem np. z inboxa. Jak podejść do odtworzenia z inboxa. Następna rzecz jest bardziej… Ten punkt wrzuciłem, bo jest wyszczególniony, ale tak naprawdę… Konfigurowalność naszej aplikacji – tak to nazwijmy. Bo to jest dobre określenie. Chodzi o to, żeby w łatwy sposób w kodzie nie ustanawiać, że zapinamy się konkretnie na jednego Rabbita, tylko pozwolić działać na różnych adresacjach i innych rzeczach. Czyli jest to nieprzesadzona konfigurowalność. O tak. Trzeba walidować balast pomiędzy „nie będziesz tego potrzebował” – wcześniej wspominaliśmy o tym zdrowym rozsądku konfiguracyjnym.
SW: Znowu wracamy do tego, żeby nie pisać własnych driverów, własnych sterowników i własnych conectorów, tylko używać bibliotek, bo one już to mają ogarnięte.
ŁK: Tak, dokładnie. Dobra. I ostatnia rzecz, która zawsze mnie fascynuje, czyli pliki. A dokładniej: logi, które potrafią się w szczególności w takich systemach kolejkowych na dysku naprawdę rozrastać. Albo jeżeli na produkcję ktoś poleci z debugiem. Więc tu też jest ciekawostka operacyjna, żeby pamiętać o tym, że mamy logi, przyrosty. Log nie tylko w rozumieniu pliku z logami, ale też pliku bazodanowego, który się tak naprawdę zapisuje poprzez dopisywanie.
SW: Mieliśmy case, że jeden zaczął wysyłać wiadomości, dugi jeszcze nie zaczął odbierać – przez weekend Rabbit podbił sobie o kilkadziesiąt gigabitów w kolejce i w poniedziałek nie działał, jak powinien. To jest bardzo ważne, bo się mocno wiąże z observability i może właśnie z tym, jak się utrzymywać na produkcji, bo to nie jest baza danych. Więc osoby, które lubią mieć dziesiątki gigabitów w kolejkach…
ŁK: Szkoda, że nie ma z nami Piotrka Stappa, bo on ma taką – nie będę przytaczał za niego – ale z jednego z banków, w którym pracował, ma dobrą historię tego typu z Rabbitem, kiedy przyszła skala…
SW: A skala przyjdzie.
ŁK: …której nie przewidywali.
SW: Też skala w kontekście tego, że nagle nie ma więcej wiadomości, tylko ktoś nie konsumuje tych, które są i one po prostu rosną.
ŁK: Tak. To jest bardzo prosta rzecz. Dobra, to z mojej strony na dzisiaj tyle.
SW: No to w takim razie dziękujemy. Dajcie znać, jak się format podoba. Na razie!
ŁK: Na razie.