Ł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 Jagger 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.