Patorachitekci short! Sprawdź, co słychać z observability, czy coś kwantowego w IT się pojawia coraz bardziej oraz ukochane przez wszystkich koszty chmurowe!
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. Linki do tego odcinka znajdziecie na: patoarchitekci.io/41. W ramach przypomnienia: są to odcinki short (czyli krótkie) o pojedynczych linkach, żebyście mieli trochę więcej czasu na inne rzeczy. Ale też abyśmy mogli się podzielić tym, co wygrzebaliśmy i znaleźliśmy ciekawego. Dobrze, to zaczynamy. Łukaszu.
ŁK: Dobra. Mam 3 artykuły. Zacznę od Overview: Shifting Left Observability in Practice. O co chodzi z tą całą zmianą w lewo? Niektórym może się ona źle kojarzyć, innym – bardzo dobrze. Jeżeli popatrzymy na piękną ósemkę nieskończoności i całą pętle wytwarzania zgodnie z DevOpsem, to development jest po lewej stronie, a operation – po prawej. I jeżeli popatrzymy, to ta linia ma przecięcia. Całość jest dość słusznie wskazana w artykule: observability de facto jest ciągle bardziej po stronie operacyjnej, po stronie Ops-ów. Parę miesięcy temu miałem szkolenie z REP Monitoringu dla zespołu deweloperskiego jednego klienta. Okazało się, że deweloperzy nie mają dostępu do metryk K8s-owych czystych i do Prometeusza na produkcji.
SW: Brak dostępu do takich danych jest bardzo popularnym problemem.
ŁK: Tak. Nawet przy budowie własnego monitoringu i dashboardów. Samo podejście bardzo fajnie pokazuje problem i wyjaśnia, dlaczego powinno to pójść w lewo… W dobrych praktykach okazuje się, że to deweloperzy… Ogólnie – jeżeli zespół jest samowystarczalny (czyli ma DevOpsa na pokładzie), jest w stanie dostarczać produkt na produkcję i go utrzymywać. De facto to ten zespół powinien być odpowiedzialny i powinien być właścicielem niezawodności rozwiązania, co oznacza, że powinien je monitorować od samego początku.
SW: Zgadza się. Tylko tu wchodzimy w antyczne problemy, które najczęściej występują, czyli po pierwsze: security. Nie wiem, z jakiego powodu, ponieważ metryki nie powinny zawierać niczego wrażliwego, ale często firmy nie chcą ich podawać. Drugim problemem jest cały system on call-i i jak go rozłożyć.
ŁK: Tak. I to są już inne historie. W szczególności on call-e są zupełnie inną historią. Pokazuje to ciekawą rzecz: bardzo dużą dziurę pomiędzy deweloperką, a działaniem na produkcji. Słusznie to zauważono też w tym artykule i są to informacje z praktyki. Prawdopodobnie zauważyłeś to samo: że jest bardzo duża dziura pomiędzy tym, jak zbieramy dane, co logujemy i jak to wygląda na środowiskach deweloperskich, a jak na produkcyjnych.
SW: Zgadza się. Jest gorzej, tak naprawdę. Deweloperzy zazwyczaj piszą alerty i wysyłają metryki, są odpowiedzialni za produkcję wszystkich eventów czy przykładowych dashboardów, które są z reguły kompletnie niezrozumiałe albo powinny wyglądać zupełnie inaczej dla ludzi Obs-ów, którzy nie znają tego systemu, więc… W takiej sytuacji takie rozdzielenie kompletnie nie ma sensu. Zgodzę się, że to trzeba połączyć i zespół powinien być odpowiedzialny.
ŁK: Ciekawą rzecz zauważyłeś. Zastanawiałem się, czy to wtrącać, czy nie… Każdy na system patrzy z innej perspektywy. Ops-i chcą prosty dashboard z informacją, że w ogóle jest problem. Chcą żeby ktoś im w ogóle powiedział, że jest problem. A niektórzy deweloperzy –pamiętam właśnie taką styczność – chcą już mieć metryki JVM-a. To jest agregowane ze wszystkich instancji.
SW: A to wiesz co… Powiem Ci, że bym się z tym trochę nie zgodził, ale tylko w kontekście jednego case’u. W sytuacji, gdy właśnie wprowadzamy przypadek, żeby zespoły deweloperskie zaczęły monitorować produkcję i były za nią odpowiedzialne. Jeżeli mają system, w którym zależą od systemów zewnętrznych, których w pełni nie rozumieją, to dla nich pierwszą rzeczą, którą potrzebują jest application map. Czyli high-levelowy rzut: jakie są systemy, co z czym się wywaliło czy co z czym nie działa. I to jest właśnie podejście do innego mindsetu. Jeśli na system patrzą deweloperzy, to zakładają, że znają jego każdy kawałek. Ops-i natomiast zakładają, że nie mają pojęcia, co jest w tych maszynach, co tam siedzi i chcą mieć ogólne metryki. Natomiast jeśli deweloperom da się systemy, których do końca nie znają i nie wiedzą, jak działają, to nagle też chcą mieć high- levelowy overview całego systemu – application map czy cokolwiek innego, co…
ŁK: Tak. Ale to jest później, jak zaczynasz już utrzymywać na produkcji swój system. Zaczynasz to wtedy upraszczać.
SW: Zgadza się w zupełności. Te potrzeby po prostu ewoluują w różny sposób, tak naprawdę. Od wąskiego spojrzenia, gdy prosimy o dokładne metryki, po szersze spojrzenie, gdy nagle stwierdzamy, że tych informacji jest za dużo na wąskie metryki, nie wszystko znamy i potrzebujemy mieć ogólny overview.
ŁK: Tak. I ostatnia ciekawostka z tego artykułu, na którą można różnie patrzeć, jednak biorąc pod uwagę koszty tooli do składania logów, warto zwrócić uwagę. Log everything and make sens later. Bo jest takie coś, że… Bardzo często sam to popełniałem, więc wiem, o co chodzi w niektórych miejscach: logujemy aż za dużo, żeby potem (w razie czego) móc z czegoś wyciągnąć informacje. Czyli mamy podejście: „nie będę się zastanawiał, co się dzieje, tylko będę logował wszystko i jak coś się stanie, to prawdopodobnie będę miał szansę dojść, co się stało”. I tu jest słuszna krytyka tego podejścia.
SW: Już się bałem, że za chwilę będziesz za tym, aby logować wszystko, bo kiedyś się przyda. Już miałem się nie zgodzić, bo to jest tragiczne podejście. Wtedy można utonąć w morzu informacji i znalezienie konkretnego problemu na produkcji zajmuje dużo więcej czasu. Tak, zgadzam się w zupełności, z tym co mówisz – zbyt wiele logowań danych jest prawdziwym problemem i jest drogie.
ŁK: Tak. Jest drogie. I o tym też jest wspomniane w artykule. Przy czym to jest błąd każdego początkującego architekta, TechLeada, który dostaje kawałek systemu, który ma też utrzymać produkcyjnie… I jest to standardowa klasyka. Trzeba się tego nauczyć.
SW: Tak. To występuje zawsze. Jeśli się powie, że jest za mało rzeczy logowanych, to deweloperzy dorzucają absurdalną ilość logów i potem trzeba z tą sinusoidą dojść do jakiejś optymalnej wartości.
ŁK: Dobra. Co przez Ciebie, Szymonie, zostało wygrzebane?
SW: Co u mnie wygrzebane? Dwa linki, ale w miarę krótkie. Jeden jest dla mnie trochę zabawny inicjalnie wpis, ale później pokazujący różne spojrzenia na to samo, tak naprawdę. Jest to wpis z Cloud Irregular o tym, że coraz więcej deweloperów spotyka się z problemem… Uwaga, uwaga!… kosztów w różnych chmurach, w wyniku… Param, param, param!… rekurencyjnych funkcji lekkich, czy tam lambd, czy azure function czy cloud functions google. Czyli po prostu to, że mamy nasze micro – bo wtedy mówimy o takich prawdziwych micro serwisach…
ŁK: Nano nawet. (śmiech)
SW: …które faktycznie skalują się fenomenalnie. Tak, nawet nano. Wszystko jest fajnie, tylko jeśli nagle mamy jakiegoś babola albo źle zaprojektowany proces, to one skalują się w nieskończoność. I są fajne historie, w których ludzie szli spać z rachunkiem na pięć dolarów, a budzili się z rachunkiem na pięć tysięcy dolarów. Po pierwsze: trochę mnie to bawi, bo to są problemy, które kiedyś ubijały monolity, a teraz powodują, że mamy wyższe rachunki chmurowe. Ale czemu o tym mówię? Gdyby mnie to tylko bawiło, to niekoniecznie bym ten link wrzucał. Ale! Co mnie trochę przestraszyło i co pokazuje, jak inaczej patrzymy na pewne aspekty, to jest morał wynikający z tego artykułu: cloud providers muszą się jakoś przed tym zabezpieczyć, bo nie ma obecnie mechanizmu, jak się przed tym zabezpieczyć. I potem jest małym druczkiem dodane post scriptum, że faktycznie to jednak cloud providers mają mechanizmy do obrony przed tym. Są budżety azurowe i są jeszcze inne mechanizmy… Ale… Czemu to jest ważne? Bo to pokazuje, jak ważny jest – jeżeli chodzi o budżety i pilnowanie kosztów, monitorowanie i tak dalej – governance. Prosty governance w każdej sytuacji, nawet jak jest prosty systemik na funkcyjkach i wydaje się, że i tak się nic nie może popsuć. Może.
ŁK: Znaczy, wiesz co… Przypomina mi to tegoroczne zlecenie zbijania kosztów, gdzie jednym pytaniem zaoszczędziliśmy połowę kwoty kosztów systemu. Okazało się, że żadna ze stron nie wykorzystuje komponentu, który zżera połowę rachunku systemu.
SW: Tak. Takie rzeczy się zdarzają, oczywiście. Ale w ogóle pilnowanie kosztów, taki najbardziej trywialny governance jest konieczny, tak naprawdę. I jest bardzo łatwy do zrobienia.
ŁK: Dobra. Drugi link – bardziej mnie ciekawi. Tamten jest zabawno-przerażający i życiowy.
SW: Tak, i życiowy. A drugi jest…
ŁK: A ten jest przyszłościowy.
SW: Przyszłościowy jest, no bo… Od wielu lat słyszę o tym, że jak pojawią się komputery kwantowe, to w tym momencie będziemy w głębokiej wiadomo gdzie, bo wszystkie nasze algorytmy do szyfrowania, salary day, nie istnieją – po prostu nie ma opcji, aby one działały. Bo komputery kwantowe koszt obliczenia tego prywatnego klucza upraszają np. z kilkuset lat do kilku minut tak naprawdę. No i teraz, co z tym zrobić? Otóż generalnie się okazało, że był ogłoszony konkurs i powstały algorytmy, które są w stanie sobie z tym poradzić. Cały mechanizm jak sobie z tym poradzić, mianowicie tym głównym algorytmem, który prowadzi całą dyskusję jest Kyber. No to wchodzimy w fizykę kwantową, probabilistykę i – generalnie – w zawiłą matmę. Ale upraszczając, jak to działa i jak możemy to wykorzystać? Otóż Cloudflare – ale nie tylko, bo przy okazji jeszcze Amazon – zaczął wspierać algorytmy hybrydowe, czyli: mamy klucz, który ma dwie ścieżki. Jeżeli odbiorca wspiera normalne, obecnie wykorzystywane algorytmy, to lecimy standardowym procesem. Natomiast jeżeli wspiera Kybera, to w tym momencie lecimy tak zwanym post-quantum algorytmem, który jest odporny na ataki i na rozszyfrowania wykorzystując komputery kwantowe. Ponieważ jest to Cloudflare to można z tego skorzystać już teraz, więc to po prostu działa. Co mnie cieszy? Cieszy mnie to, że jako IT zaadresowaliśmy problem zanim on nas bardzo mocno ugryzł.
ŁK: Jest to ciekawe… Miałem z Markiem Grabarzem wczoraj rozmowę właśnie o komputerach kwantowych i podejściu do tego tematu. I jak bardzo się czujemy, próbując to zrozumieć, jak bardzo… nawet rozumiejąc podstawy fizyki kwantowej, jak bardzo leżymy w tym obszarze, nie mając problemu z tymi abstrakcjami.
SW: To jest już skomplikowana matma. I naprawdę niezły kawał fizyki tak naprawdę.
ŁK: Tak. I to co jest ciekawe, mieliśmy wspólny wniosek, że dopiero prawdziwe algorytmy, kiedy gdzieś dojdzie do użycia komercyjnego, to będzie tak jak z informatyką lata 50., 60. – że dopiero w latach 70. unormowały się wszystkie bazy, które stanowią nam obecnie informatykę i wszystkie rozwiązania. I z komputerami kwantowymi prawdopodobnie jesteśmy w odpowiedniku lat 50. w informatyce.
SW: Pewnie tak. Jestem przekonany, że jeżeli będzie Kyber szeroko wykorzystywany, to okaże się, że ma milion dziur i będziemy się z niego śmiali, jak mogliśmy popełnić tak karygodne błędy. Ale cieszy mnie w tym całym ruchu to, że to się pojawiło i że adresujemy problemy. To jest przede wszystkim ważne.
ŁK: Jestem ciekaw, co będzie konsekwencją, tak jak mamy AS-a, który w Stanach, wiadomo, jest przez instytucje, przez NIST polecany. Co znajduje się w FIPS-ie i co pójdzie dalej w tamtym kierunku, co przyjdzie jako oficjalne standardy.
SW: Otwiera się nowy świat. Komputery kwantowe to nie będzie coś, co będziemy wykorzystywali w domu. To będzie coś, co będzie typowo chmurowe i jako…
ŁK: Usługa
SW: Tak, nie oszukujmy się. To jak chłodzenie czegoś do temperatur bliskich zera, nie jest…
ŁK: Ale inaczej… coś bym… coś bym wymyślił. Wierzę w to, że będzie mocny przeskok technologiczny, ale dojdźmy do prawa Moore’a w przeliczeniach kwantowych i wtedy będzie można zobaczyć.
SW: Tak. I to chyba tyle, jeżeli chodzi o linki. Kończymy?
ŁK: Kończymy. Na razie.
SW: Na razie, hej!