Ostatnie Patoszkolenie w tym roku👇
Patoarchitekci odkrywają, co łączy Basecamp, Dropbox i Netflixa. Posłuchaj i dowiedz się, dlaczego niektórzy rezygnują z rozwiązań cloudowych.
Ciekawe linki i inne znaleziska z tego odcinka:
Łukasz Kałużny [ŁK]: Cześć! Słuchacie Patoarchitektów short. Prowadzą Łukasz Kałużny
Szymon Warda [SW]: i Szymon Warda. Wszystkie linki do tego odcinka oczywiście znajdziecie na: patoarchitekci.io/48. I ważna informacja – konkrety dotyczące meetup’u z okazji 50. odcinka: Warszawa, 9 listopada, 18:00, hala Koszyki w przestrzeni Meta faceebookowej. Jest rejestracja, zapisujcie się.
ŁK: Tak, zapisy w linkach pod spodem. W linku do odcinka znajdziecie wszystkie potrzebne linki. Na meetupie organizowanym z okazji 50. odcinka będzie sesja AMA, więc jeśli macie jakieś pytania, to zadawajcie je albo w komentarzach na social mediach do tego odcinkach, albo w linku do formularza, który macie pod spodem (jeżeli wolicie być bardziej anonimowi).
SW: I też coś chyba powiemy przy okazji, nie tylko samo AMA.
ŁK: Tak, dokładnie.
SW: Dobrze, Łukasz, link.
ŁK: Dobra. Powrót z cloudów do serwerów fizycznych. I w tym wypadku jest to kawałek z Basecamp i ich usługi Hey. Może wprowadzając: Basecamp jest dość ciekawym w świecie technologiczno-biznesowym start-up’em, ponieważ zatrzymał się na pewnej wielkości organizacji i jest mocnym przykładem stosu technologicznego działającego i ciągnącego Ruby on Rails przez lata. Ich CTO David (znany też na Twitterze jako DHH) ciągnął to community i to wszystko do przodu. Kiedy nie miał wystąpić na Keynote ostatnimi czasem, bo główny prowadzący największej konferencji r@bbIT to było, jakby to ładnie określić… konsternacja o co chodzi, ale to przez jego poglądy. I całość ich softu, bo mają dwie duże usługi: Basecamp (do zarządzania projektami) i Hey (jako nowy rodzaj komercyjnego maila, który ma Cię odciążyć). I tutaj jest pokazane, dlaczego opuszczają chmurę w przypadku Hey - rachunek wynosi 500 000 dolców rocznie. Co patrząc się…
SW: To nie jest dużo.
ŁK: To nie jest dużo. Ale jeżeli popatrzymy, to w ich przypadku ściąga to 30% marży.
SW: OK.
ŁK: Chyba coś tak, gdzieś tam były cyfry. Ale ściąga im dość sporo marży. I w przypadku Hey, bo jest to usługa mailowa, to trzeba sobie zdać sprawę, ich głównym kosztem są RDS-y i zarządzany Elastic. I w przypadku, kiedy to jest workflow, który ciągle… Bo patrząc się: nie chcesz szukać swojego maila. Jeżeli wejdziesz, nie chcesz swojego maila searchować przez 30 sekund, jak Ci się lambda odpali i wszystko wykona. Jeżeli popatrzymy mają infrę, która po prostu musi razem z RDS-ami, czyli samorelacyjną bazą danych, musi stać. Więc przy tej architekturze prościej jest przerzucić się na blachy, trzymając takie coś.
SW: Ale to jest takie…Do softu mocno skierowanego do klientów mają mocno korporacyjną architekturę. Nic dziwnego, że to się nie będzie skalowało ani opłacało.
ŁK: Czy korporacyjną… Zobacz, z drugiej strony…
SW: RDS-y plus Elastic. Tak.
ŁK: No, ale słuchaj… Tak naprawdę to jest standardowy stos do budowy dużej usługi mailowej. Taki bardzo standardowy.
SW: Standardowy, dobrze to powiedziałeś. Czyli coś, co jest typowo korporacyjne. Jeżeli chcesz mieć coś pod klientów i pod clouda, to sorry - trochę inne podejście jak na mój gust.
ŁK: Wiesz co, z drugiej strony zobacz, jak wygląda Stack Overflow.
SW: Tak, ale oni są na blachach. O to właśnie mi chodziło.
ŁK: A Ci robią powrót na blachy. Więc dla mnie to jest… Mówienie, że pisanie softu jest… Bo były komentarze i takie, że ten soft jest napisany do dupy. Trochę tak jak powiedziałeś: pisany po staremu.
SW: Tak, tak uważam. Zawieszenie jeszcze: RDS-y, czyli bazy relacyjne.
ŁK: Tak, tak, tak
SW: Just in case.
ŁK: Bardzo relacyjne i zarządzane Elastic. Jak na to popatrzę, to alternatywę dla full-text search, której nie czardżujesz za stanie instancji, nie ma. Nie ma żadnego Pay as go…
SW: Nie ma, nie będzie.
ŁK: I wiesz… Przy tej architekturze full-text search to maila inaczej nie zrobisz.
SW: Tu się zgodzę. Ale dla RDS-ów to można przemodelować.
ŁK: Tak. Dla RDS-ów. Ale sądzę, że ten rachunek, wiedząc jak pewne usługi kosztują, zakładam, że te RDS-y to jest pikuś w porównaniu do…
SW: A bym nie stawiał… Zależy czy mają to poshardowane i zależy, czy mają to ładnie porobione. Bym wcale tak… moich pieniędzy nie obstawiał.
ŁK: Ale wiesz… Dobra. (śmiech) Ja obstawiam, że gdzieś 25 do 75, ale nigdy nie dowiemy się, kto ma rację przy całości. Ale pokazuje ten ciekawy trend… Przyznają się, że używają K8s-a, więc to nie jest już takie podejście, że lecą czysto na VMK-kach, tylko faktycznie mają jakąś warstwę abstrakcji. Więc… jest to ciekawe. Pytanie, czy koszty migracji… Czy nie byłoby taniej przemigrować się na EC2-ki po prostu i na duże klastry na EC2. To jest taka rzecz, której się nie dowiemy. Ale patrząc, ciekawy jest wątek ucieczki. Trzeba powiedzieć, że Dropbox robił przecież podobnie ze swoją usługą - wynosili się, żeby trzymać storage we własnym Data Center, czy przecież case z Netflixa, gdzie tak naprawdę w Netflixie gros kosztów to jest Edge dostarczanie, które budują samodzielnie.
SW: No mają pewien rozmiar skali, za którą będą dość mocno czardżowani. Przy tym rozmiarze i co oni chcą zrobić, i oni dokładnie wiedzą, co chcą zrobić, więc… No nie dziwię się.
ŁK: Tak, więc to są takie ciekawe przypadki. Jeżeli jest stała usługa, faktycznie to, co on pisze i mają stałe capacity, że muszą tylko dodawać węzłów, to faktycznie ten Bare Metal w jakiejś kolokacji czy usłudze, która daje dosłownie za ułamek ceny, może być dla nich dziś rozsądna.
SW: Nie wydaje mi się, żeby to był też taki duży ułamek. To też zależy, jak się to zaksięguje: koszty ludzi, koszty ryzyk, i tak dalej.
ŁK: Znaczy… To jest ciągle firma, która ma od 30 do 60 osób. To też trzeba wiesz… zobaczyć, że to nie jest… Patrząc przez pryzmat, że tę usługę budowało chyba z 10 czy 15 osób i utrzymuje ją z 4 czy 5, to jest takie…
SW: Ja bym się bał przy tym rozmiarze zespołów przejść na własne Data Center, bo musisz sporo ludzi dorzucić, kwestia on-calla…
ŁK: Raczej… Właśnie czy własne Data Center czy kolokacje, bo to też jest… Pamiętaj, że własne Data Center w dzisiejszych czasach…
SW: Masz rację.
ŁK: …to też będzie kolokacja, bo raczej… No nie ma tutaj, że budują, tylko wezmą Bare Metal gdzieś. Zobacz że… Pamiętam, jak się bawiłem jeszcze Packetem, czymś co teraz się nazywa Equinix Metal, to tam można było dostawać za ułamek ceny cloudowej (czyli za 2 dolce) za godzinę potężną maszynę z całą częścią, o której mówisz. Że pod spodem zachowywało się jak cloud.
SW: OK
ŁK: Więc to jest pytanie, u kogo wzięli, jak, na jakich zasadach. I znając ceny, gdzieś po swojej przeszłości jak wygląda hosting, jeżeli nie boimy się operations od strony systemu operacyjnego w górę, to te ceny są konkurencyjne. Tak jak pisał tutaj, że pół miliona dolców rocznie – ile za to może blach utrzymać.
SW: Jestem ciekawy, jak to będzie wyglądało za mniej więcej 2 lata tak naprawdę. Jakie będą ich wnioski. Dobrze, teraz ja się pochwalę. Mam dwa zestawy linków de facto. Jeden z serii: „O kurczę, nie wiedziałem, że tego potrzebuję”.
ŁK: (śmiech)
SW: Nie no, naprawdę. W sumie we dwóch siedzimy w budowaniu jakichś platform tak naprawdę. I często to są… Dla mnie jest problematyczne, albo tam gdzie widzę problem, to jest to, że budujemy platformy i dostarczanie jakości usług, jakości tej platformy dla developerów (głównie to są wewnętrzni developerzy). I często jest tak, że jak budujemy, to jest taki misz-masz różnych tooli. Tu gdzieś jest jakiś Elastic albo jakiś Loki, tu gdzieś jest Grafana, Prometheus, tu gdzieś jest Jaeger i nagle mamy cały zestaw tooli i mówimy developerom: Seria 5 linków i po prostu macie tu, szukajcie. I to jest problematyczne. Jest Istio, które ma możliwość bycia enterpointem, tam możemy wszystkie linki dorzucić, możemy to jakoś pożenić, ale tez nie jest idealne. I tak się przyglądałam właśnie release notes nowej Grafany i tam jest kilka rzeczy, które po pierwsze mi umknęły, a po drugie naprawdę twierdzę, że to mi się przyda. Pierwsza rzecz, która mnie trochę ruszyła, to było to, co mi umknęło. Mianowicie: Grafana wyprodukowała swoje Tempo i to 2 lata temu już. Narzędzie, które integruje się oczywiście z Grafaną, Prometeuszem, Loki i tak dalej; może konsumować logi Jaggerowe i zrobić nowe z OpenTelemetry, czyli cały tracing. I co jest teraz fajne. Teraz zrobili taki myk, że możemy te logi przechowywać w Grafanie. Całe tracy w Grafanie. Do tego stopnia, ze można na pojedynczych trace’ach zrobić kwerendę w Grafanie (czyli wyciąć metryki i przejścia w obie strony). To jeszcze jest w becie, ale jest fajne. Można w Grafanie dorzucić boardy takie APM-owe, czyli mówimy, że mamy takie SLA i w jakich przedziałach lecimy. I to mega fajnie wygląda. I ostatnia rzecz, która była z serii „Nie wiedziałem, że potrzebuję, ale bardzo tego potrzebuję”, to są publiczne dashboardy. No bo jeżeli mamy platformę, która ma SLA i jest to SLA publiczne, to przydałoby się publikować nasze metryki. To jest trochę upierdliwe, to nie jest trudne, ale upierdliwe, ponieważ to jest kolejny dashboard, który trzeba trzymać, jakąś prostą stronę, która będzie to odświeżała, wpisywać i tak dalej. Nic trudnego, ale to kolejna rzecz, którą trzeba monitorować. A to ma możliwości jeszcze w Alphie - wystawienia pewnych dashboardów jako publicznych. Czyli pierwszy krok: wystawienie naszego SLA w formie APM-owych rzeczy jako publiczny dashboard.
ŁK: Dobra, przeszkodzę Ci, bo Tempo… Miałeś powiedzieć o tym, że Tempo jest do pricingu. Zabrakło tego.
SW: Tak.
ŁK: Zabrakło. Zajechałeś się. Z całości (bo sobie sprawdziłem), z rzeczy, które wyróżniłeś, to faktycznie super rzecz, że trace’y teraz można zaciągać z Jaegera, Zipkina i OpenTelemetry.
SW: Tak
ŁK: I to jest największa zaleta dla mnie. Że jest kompatybilny z szeregiem rzeczy.
SW: Dla mnie jest to, że w tym momencie potencjalnie mogę się UI-a jaegerowego czy zipkinowego pozbyć. I mogę to wszystko mieć w jednym toolu. Odchodzi mi jeden front-end do utrzymania. Czyli ten front-end do uwierzytelniania. Jeden front-end do linkowania i mam płynne przejście w Grafanie między trace’ami a metrykami, co jest super kluczowe.
ŁK: Tak. Druga rzecz, którą sobie sprawdziłem, bo byłem ciekawy, okazuje się, że Tempo już się dorobiło: jest piękna aplication mapa trace’ów.
SW: A to mnie akurat umknęło. O, to bardzo dobrze.
ŁK: Właśnie teraz, jak mówiłeś, sprawdziłem, czy dorobili się wreszcie Grafów na podstawie trace’ów. I tak, dorobili się, jest śliczniusi, że tak powiem, na bazie query, które masz. Trace’ujesz metryki, normalnie Ci rozrysowuje diagram ze wszystkimi metrykami. Więc razem z trace’ami, wyliczaniem metryk z trace’ów i innych rzeczy, no powoduje, że: WOW! Rzeczą, o której mówiłem jeszcze kilka miesięcy temu, twierdziłem twardo że zbudowanie podstawowego APM-a z open-source’u jest drogą przez mękę…
SW: Tak, bo dobry tool do posiadania aplication mapy, czyli takiej mapy, gdzie widzimy wszystkie serwisy, komunikacji miedzy nimi i gdzie mamy failure rate, czas i tak dalej. Prosty tool, ale taki entrypoint do czynienia, że coś się wywaliło.
ŁK: Tak, to łącząc Tempo z OpenTelemetry, które teraz… A zobaczymy na szybko sprawę, bo wczoraj oglądałem z innego powodu, zobaczmy, ile jest tych… Szybciutko… Dobra, mamy… Z głównych mamy: .NET-a, Gollanga, Java, JavaScript, Pythona, PHP-a, Rubbiego, Rusta, Swifta, C++, więc w sumie cały główny stos mamy pokryty przez OpenTelemetry. No to można włączając tracing w OpenTelemetry w łatwy sposób możemy sobie zbudować na dzień dobry takiego bardzo podstawowego APM-a.
SW: Ja bym powiedział, że nawet więcej niż bardzo podstawowego. Bardzo podstawowy to jest prosta Grafana z metrykami plus search.
ŁK: No tak. Tu masz dobre zdanie. Tu masz tracing, więc bardziej rozbudowany. Z punktu widzenia APM-a trochę podstawowy, bo nie będzie anomalii detection, z których, no nie oszukujmy się, wygodnie się korzysta.
SW: Tak. Nie ma takiej inteligencji, ale wokół tego też są projekty procesowe. Teraz wyleciała mi nazwa, ale są projekty, które wykorzystują różne modele AML-owe.
ŁK: A druga rzecz: nie ma takiego wejścia głęboko w język, żeby pokazać Ci dokładnie query i inne rzeczy,
SW: Tak, nie ma toola, który będzie wchodził w kod de facto. Tak. Ale ogólnie bardzo fajny kierunek, w którym się Grafana rozwija. Żeby właśnie zebrać to w jednym miejscu.
ŁK: Teraz kusi mnie, żeby sprawdzić, jak wygląda komercyjna wersja enterprisowa. Aż będę musiał sobie podejrzeć, ile ten stos kosztuje. Jak porzucimy chęć posiadania full-text searcha na logach i będziemy umieli je zalabelkować, to wtedy Loki się już sprawdzi genialnie. Zrobi…
SW: Tak.
ŁK: Zrobi jedno miejsce.
SW: Do sprawdzenia. Mam tez drugi link. Link ogólnie… Takie bardziej wrzucenie do przemyślenia. Bo: oczywiście MS wypuścił nową wersję .NETa i teraz… znaczy… wypuścił jako nową i dali wpis odnośnie tego, jakie są zyski wydajnościowe, jeżeli chodzi o przejście z 5 na 6. Ale… I oczywiście są w przedziale mniej więcej 20-50%. Wiadomo - MS publikuje więc… będą takie trochę optymistyczne, ale są. Ale nie to mnie nakłoniło do tej całej myśli. Zastanawiałem się, co się będzie działo, jak będą wyglądały projekty, które będą w trybie maintenance. Kiedyś mieliśmy projekty w C, C++, leciały w Javie, .NET, miały tam… czas utrzymania 10 lat. A obecnie czas życia tych frameworków to są 2 lata tak naprawdę. To jest krótko jak na skalę dużych projektów i dużych firm. Mnie zaskoczyło to, że już nie będziemy mieli takich projektów, które będą leżały jak skamienieliny i tylko działały. Będziemy musieli cały czas cały nasz stuck utrzymywać, update’ować i zmieniać SDK de facto, bo razem z wersjami frameworka zmieniają się też często SDK-i. Znaczy SDK wylatują, zmieniają się, są inne podejścia. I to będzie ciekawy problem na najbliższe parę lat.
ŁK: W ogóle drążąc, bo w grudniu muszę jeden projekt… Teraz w listopadzie muszę pomóc klientowi, będę musiał podbić, ale tak… 3 lata pomiędzy RDS-ami w supportu. To jest w ogóle… Ten czas się tak diametralnie skraca, i to jest jedna rzecz. Często są projekty, które przechodzą w fazę typowego maintenance, takiego utrzymania i ciągnięcia i nawet nie rozwijania ficzerów.
SW: Tak. To taki projekt, że nie ma developerów tylko Opsi to monitorują.
ŁK: Tak. Są takie i czasem coś poleci. Jestem ciekaw, jak to się teraz będzie rozkładało, bo wszystko leci do przodu. te wszystkie frameworki… Powiedzmy, że te 3 lata RDS-a to jest naprawdę dużo. Patrząc się na… Jeden wątek, który jeszcze trzeba tutaj dorzucić, to jest security i podatności w bibliotekach. Bo to security będzie kierowało upgrade’owaniem tego wszystkiego.
SW: Wydaje mi się, że tak. Ale też kwestie prawne tak naprawdę, czy lecimy i czy wykorzystujemy produkty, które są nieutrzymywane. To też może być ciekawe. Fajny temat, jestem ciekawy, co z tego wszystkiego wyniknie, jak do tego podejdą duże firmy. Bo będą musiały do tego w jakiś sposób podejść. Bo to znacznie zwiększy zapotrzebowanie developerów. Bo taki upgrade między wersjami, to nie będzie projekt na jeden dzień, to będzie projekt na dłuższy czas: z testami, ze wszystkim.
ŁK: No. W większości… Znaczy wiesz… Tak. Ale jeżeli podbijasz w miarę na bieżąco, czyli powiedzmy co ten RDS, to nie powinny być to straszne rzeczy. To nie jest tak, jak teraz te… Powiedzmy, że nie powinno być dużo takich przejść, jak było z pełnego .NETu, na .NET core na przed 2.1 jak ludzie się rzucali.
SW: Tak. Ale sobie doskonale zdajemy sprawę z tego, że to będzie odwlekane i nie będzie przejść co wersję, tylko będą przejścia co drugą wersję de facto. Tak to będzie wyglądało.
ŁK: I już nie będzie przyjemnego upgrade product.
SW: Tak. I to będzie kwestia ryzyka: wdrażamy nową wersję i wszyscy będą: „O Boże, co to się wydarzy”. I w tym momencie będą wszystkie testy, będzie kogo wkopać i potrzeba CI/CD w kodzie, żeby móc każdą wersję zawsze deployować, zbudować, będzie dużo dużo większa. To rodzi niesamowitą gamę problemów tak naprawdę, jeżeli chodzi o cykl życia aplikacji i utrzymania jej. Mega ciekawe. Jestem ciekawy, jak to się rozwinie.
ŁK: W komentarzach dajcie znak, co wy sądzicie na ten temat, bo też jesteśmy ciekawi waszej opinii, jak na to patrzycie, na to jak to leci.
SW: Dobrze, chyba kończymy.
ŁK: Kończymy. Na razie!
SW: Hej!
ŁK: Hej!