Przygotujcie się na prawdziwy rollercoaster w dzisiejszym odcinku. Bierzemy pod lupę finanse GitHuba i Copilota – czyżby dopłacali do tego biznesu? Google rzuca światło na disaster recovery, a Cilium świętuje swoje graduation w CNCF. W Cloudflare pojawia się Hyper Drive – sprawdzamy czy to w ogóle warte zainteresowania. I na deser – nowy tool do incident response od Grafany. Bądźcie z nami, bo dzisiaj będzie się działo!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny.
Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka oczywiście na Patoarchitekci.io, z numerkiem gdzieś na dole w opisie ogarniecie, wierzymy w Was.
Łukasz Kałużny: I klasycznie “Pato to the moon”, czyli poleć nas babci, cioci, wujkowi albo koledze z pracy, tudzież zostaw lajka, komentarz albo follow aplikacji, w której słuchasz. Dobra Szymonie. To co w tym tygodniu w ramach shortów?
Szymon Warda: W ramach shortów chyba spory news z Microsoftu generalnie. To była informacja o tym, że de facto MS/GitHub dopłaca do Copilota. Miesięczny koszt około 20 dolarów, a realnie wychodzi kosztowo około 80 dolarów. Czemu to wrzucam? Z kilku powodów. Po pierwsze, to pokazuje, jak dużo jeszcze wokół LLM-ów czeka nas optymalizacji kosztowych. Kolejne to jest ile to realnie prądu pochłania, bo tu mówimy głównie prąd, ale dla mnie to też ciekawe spojrzenie na to, jak będzie wyglądało hostowanie tych LLM-ów przez firmy na onpremie, nie w chmurze de facto, gdzie ta wydajność kosztowa będzie dużo niższa i koszty przez to będą dużo wyższe.
Łukasz Kałużny: Wiesz co, teraz popatrzmy sobie, model jest ciężki. Inaczej, powiedzieć o prądzie, to od razu miałem to dorzucić do newslettera, ale zostawię to tutaj, bo jest o prądzie. Microsoft wrzucił takie ogłoszenie o pracę, które się nazywa Principal Program Manager Nuclear Technology.
Szymon Warda: Generalnie atom, idziemy w tym kierunku i to się będzie działo.
Łukasz Kałużny: I to się broni. Małe reaktory się bronią. Akurat SMR, jeżeli dobrze pamiętam ten skrót, czyli te małe reaktory, które rzekomo też w Polsce mają zacząć powstawać dla przemysłu się bronią, więc całość. I wiesz, z tymi modelami jest tak, że tu jest potężny model, za tym stoi potężne, czyli jest ten kodeks razem z GPT-4 teraz, który jest w diabły drogi do zbudowania i utrzymania. I pytanie jest - czy takie open source’owe modele delikatnie zfaine-tune’owane pod nas, takie jak np. StarCoder, czy nie będą lepszym rozwiązaniem, które też są tańsze do utrzymania de facto?
Szymon Warda: Wiesz co, ale mówimy o takiej opcji, mówimy: delikatne fine-tune’owanie. Ale delikatne fine-tune’owanie i danie temu modelowi całej wiedzy, to jest potężna infrastruktura tak naprawdę. To jest zbudowanie systemu do analityki tak naprawdę, tylko takiego, który jeszcze umie zaciągać i którego musimy już uczyć na GPU. I to nie na jednym GPU, tylko na całej bandzie. Więc kosztowo to będzie niezłe wyzwanie.
Łukasz Kałużny: Tylko że wiesz, odpalenie potem będzie o wiele tańsze.
Szymon Warda: Pytanie właśnie czy będzie? Bo w tym momencie zobacz, bo weźmy sobie tą chmurę, czyli tą opcję generalnie, że płacimy za użycie, że płacimy, możemy to skalować w górę i w dół. Możemy, po pierwsze, skalować w górę i w dół w kontekście czasu generalnie, kiedy z tego korzystamy. Możemy skalować w górę i w dół przy uczeniu rozwiązań itd. Czy firmy będą miały na tyle dużo infrastruktury ludzkiej chociażby, żeby to ogarnąć, bo z reguły tego nie ma? Zobaczmy jak wygląda całe kupowanie hardware’u na onpremie. Jest kupowanie na maksa tak naprawdę.
Łukasz Kałużny: Nie, nie, to robisz na cloud… Musisz to robić na cloudzie. Raczej z takich ciekawostek, jeżeli dobrze pamiętam cenę, to wytrenowanie na Google’owych TPU kosztowało ich, właśnie nie pamiętam który model, ale chyba właśnie StarCoder, to jest koszt 150 tys. dolarów.
Szymon Warda: Ale w tych właśnie granicach mówisz o wytrenowaniu na Google’owym. A ja mówię o takiej sytuacji - co będzie jeżeli firma będzie chciała wejść w LLM-a, ale będzie musiała być na onpremie? Czy dana lista nie będzie mu mogła wyrzucić. To jest w ogóle coraz mniej realne.
Łukasz Kałużny: Raczej wiesz, odpalasz sobie jakieś Llamy, inne open source’owe modele na GPU. Bo wiesz, odpalenie modelu jest o wiele tańsze niż trzymanie takiej multitenant infry jaką ma przykładowo Microsoft w tym miejscu.
Szymon Warda: Oczywiście, ale to będzie… Stawiam, że teraz jest ogromny hype. Ten hype jest głównie na trzymanie i korzystanie z usług chmurowych i to jest sensowne. Ten cały pęd w kierunku tego, żeby jednak trzymać… Znaczy pęd, gdzieniegdzie niektóre organizacje po prostu muszą trzymać na onpremie, to dość szybko będzie wiadro zimnej wody. Tak że chyba jednak nie. Będzie coraz więcej usług, które będą miały sens tylko i wyłącznie przy ogromnej skali chmurowej, jako usługi. Po prostu tyle. A co tam Łukaszu masz?
Łukasz Kałużny: Dobra. Rzecz, która mi się rzuciła w oczy w ostatnim czasie, jak jesteśmy już przy Microsofcie, to w MS-ie ktoś zaczął liczyć pieniądze na Azurze i utrzymywaniu starych usług i API. I na początku, pod koniec września, na początku października wywaliło announcementami o wycofywaniu się z różnych starych API i nieużywanych kawałków usług.
Szymon Warda: Pojawiło się tego trochę.
Łukasz Kałużny: Tak. Więc ktoś wpadł, że tak powiem, z Excelem albo Power BI-em i pokazał, że tabelka utrzymanie do używających klientów i zarobków się nie spina, taka rzecz, albo dług technologiczny w środku. Więc trzeba było wskazać, że za rok, dwa będziemy z tego schodzić i dziękujemy.
Szymon Warda: Inna bajka jest to, że generalnie dorzucenie tych wszystkich ludzi do tego, żeby dodanie AI-a do każdej usługi też pochłonęło zasoby ludzkie i trzeba było po prostu ludzi przerzucić. Więc nagle ktoś stwierdził, że i tak nie mamy ludzi na utrzymanie tego. I to co mówisz, Excel po prostu i patrzymy okej, to nam się po prostu nie opłaca. I w sumie bardzo dobrze.
Łukasz Kałużny: Tak, więc jest sporo ubijania, niektóre z dłuższym, niektóre z o wiele krótszym czasem.
Szymon Warda: Dobra, to teraz ja. Krótki artykuł. Ciekawy artykuł od Google. Przy czym uwaga, bo takie od Google aplikowanie tego co Google mówi, to często jest błędna receptura na tragedię w projekcie, ale ten jest w miarę sensowny, powiedzmy sobie - Disaster Recovery Across a Million Pieces. O co chodzi? Ciekawy tok odnośnie tego jak przeprowadzać i jak myśleć w ogóle o Disaster Recovery. Tam jest parę punktów, które chciałbym podkreślić. Przede wszystkim to, co podkreślają i to, co chyba każdy z nas wewnętrznie czuje, to jest: pogódź się z niezgodnościami. Czyli w systemie rozproszonym, jeszcze jak mamy jakiś system na kolejkach, itd., szansa, że zrobimy backup spójny i potem spójny restore jest praktycznie zerowa tak naprawdę, bo to jest super, super trudne i faktycznie jednak ten system cały czas żyje tak naprawdę. Więc jak mamy więcej niż jedną bazę danych, więcej niż jeden obiekt do robienia backupu i restore’a, to nierealne. I potem co proponują? I sobie życzą, może nie jakieś super odkrywcze, ale mimo wszystko fajnie jest je usłyszeć: nie da zrobić się spójnego restore, trzeba wbudować systemy rekoncyliacji. Czyli do tego, że restore’ujemy kilka źródeł albo jedno źródło i potem system dochodzi do tego, co jest spójne. Co jest ciekawe, w tym? To, że zalecają rekoncyliację dwukierunkową tak naprawdę. Czyli nie jest to, że mamy jedno źródło prawdy i to się rozsyła, tylko jednak systemy muszą się między sobą dogadać.
Łukasz Kałużny: I wiesz co? Tutaj jest jedna rzecz, którą bym rzucił. Jest piękne słowo, które kurde kuleje, czyli idempotentność w systemach.
Szymon Warda: Zgodzę się. Tylko problem jest z idempotentnością taki, że ona jest, po pierwsze, bardzo droga w implementacji, bo wymaga naprawdę często więcej kodu. I kolejna rzecz to jest to, testowanie jest absurdalnie ciężkie. Jak nie przetestujesz, to nie będzie działała.
Łukasz Kałużny: Wiesz, jak mówi np. o kolejkach i o tej spójności, bo to jest takie pierwsze, to tym tańszym kosztem są Inbox i Outbox Patterny.
Szymon Warda: Ale to Ci nie gwarantuje idempotentności tak naprawdę.
Łukasz Kałużny: Raczej nie, dobrze zrobiony Inbox i Outbox… Raczej głównie dobrze zrobiony Inbox może Ci to spróbować zagwarantować.
Szymon Warda: ‘Spróbować’ jest kluczem, zmniejszy szanse, ale dalej może wystąpić sytuacja, że będziesz miał taki case, że wiadomość będzie powtarzał po raz drugi.
Łukasz Kałużny: Właśnie i tutaj Inbox powinien Cię uratować, jeżeli poprawnie to obwalisz, całość.
Szymon Warda: Nie, tu można by się dużo kłócić, ale generalnie raczej będę się trzymał, że nie do końca, nie zawsze.
Łukasz Kałużny: Inbox jest właśnie po to. Ale dobra, trzeba zrobić odcinek o Inboxie i Outboxie.
Szymon Warda: Łukasz ostatnie słowo musi mieć na wierzchu.
Łukasz Kałużny: Tak, dokładnie. Dobrze zrobiony Inbox jest idempotentny. Niestety brakuje gotowców na to.
Szymon Warda: Trzymaj się infrastruktury, część software’ową bardziej zostaw mi.
Łukasz Kałużny: Dobra, lećmy dalej.
Szymon Warda: Ciekawe też wprowadzają podejście, czyli Backup Availability Consistency. To oczywiście nic nie jest odkrywczego, bo tu mówimy o całym CAP-ie, czyli generalnie spójności i jak się zachowują systemy rozproszone, czy są spójne, czy są dostępne tak naprawdę. Ale fajne podkreślenie tego, że de facto ten sam koncept aplikuje się bardzo mocno do backupów. Tyle. Artykuł nie jest jakiś bardzo długi, parę punktów dobrze jest z niego usłyszeć, tylko tyle tak naprawdę. Co tam dalej masz?
Łukasz Kałużny: Następnie to przejdziemy do Infry.
Szymon Warda: Dobrze, dobrze, jest w tym.
Łukasz Kałużny: Cilium uzyskało graduation w CNCF-ie. Czyli EBPF, że tak powiem, EBPF-y i security, sieciówka, observability z wykorzystaniem właśnie EBPF-u w postaci Cilium przechodzi do takiego okresu już dojrzałego, że tak powiem, w adopcji, w określeniu jeżeli mówimy o stack CNCF-owym. Więc dla słowa wspomnienie, dla tych, którzy nie wiedzą, Cilium to jest driver sieciowy dla Kubernetesa, który pod spodem korzysta z tzw. Extended Berkeley Packet Filtering, czyli EBPF. W skrócie polega to na tym, że z user space’u w systemie operacyjnym możemy wstrzykiwać kod i przetwarzać procesy pomijając stack sieciowy kernela, czyli przyśpieszać to i można budować dzięki temu mikroprogramy, które pozwalają np. uzyskać observability czy jakieś elementy filtrowania innych tego typu i budować rzeczy na poziomie sieci, a nie kodu naszej aplikacji.
Szymon Warda: Nawet niekoniecznie tylko sieci. Warto by, bo w EBPF-ie po prostu wstrzykujemy się do poziomu kernela de facto, co dwa odcinki temu właśnie Pixi też odnośnie debugowania innych rzeczy. Tak że zdecydowanie przyszłość service-meshy i właśnie takiego trackowania powoli odchodzą już w przeszłość.
Łukasz Kałużny: Raczej tak samo Istio Ambient, o którym kiedyś mówiliśmy.
Szymon Warda: Tak, w ogóle EBPF trochę schodzi na psy.
Łukasz Kałużny: Tak, ale w całości to taki sygnał, że tak, to jest kierunek, który można zacząć robić. I dla mnie te observability i transparentny MTLS to są takie dwa feature’y, na które tam mocno patrzę.
Szymon Warda: Dobra, to jeżeli idziemy w technologie fajne i ciekawe, to dawno nie było nic o naszym przyjacielu, czyli CloudFlare. CloudFlare wypuścił fajną usługę - Hyper Drive. I teraz uwaga, CloudFlare twierdzi, że Hyper Drive przyspiesza kwerendy do scache’owanych baz postgresowych od 17 do 24 razy, nie procent, razy. Dla niescache’owanych między 6 a 9 razy. Znowu, wartości są absurdalnie wręcz wysokie. I teraz, tu trochę wchodzi takiego dziwnego marketingu, trochę ich rozumiem, bo teraz na czym oszczędzają? Są dwa obszary, jak to działa. Pierwszy to jest to, że cache’ują kwerendy, co jest ciekawe, czyli cache’ują kwerendy do wyników. I to jest ok. Fajna technologia, jak najbardziej ma to miejsce.
Łukasz Kałużny: Standardowy, tak jak to we wszystkich ORM-ach możemy sobie zrobić cache’ing łatwy, czy w innych kawałkach, że tak powiem, rozwiązań.
Szymon Warda: Tylko, że to jest ten cache drugiego poziomu, czyli pozaaplikacyjny de facto. Bo tutaj to jest o tyle fajne, że po prostu dajemy innego connection stringa i to działa. Drugi element, z którym mam trochę problemu, jeżeli chodzi o reklamowanie, to jest to, że optymalizacja wynika z tego, że de facto Hyper Drive trzyma connection pull do SQL-a. Czyli coś co powinno się normalnie dziać w aplikacji. I w takim razie to faktycznie, bo ten check musi być, uwierzytelnienie, itd., nawiązanie protokołu TCP/IP, itd. Musi się wydarzyć. I to, ponieważ będzie trzymany, więc mamy pull’owanie, nie trzeba budować. I teraz normalnie pulling połączeń SQL-a powinien być w aplikacji. Dlatego mam problem z tym, że ok, to tutaj nie będzie zysku.
Łukasz Kałużny: Wiesz co, tylko robimy to dla Serverlessu.
Szymon Warda: Właśnie o to chodzi. To jest usługa, która… Te wartości będą super widziane właśnie w kontekście Serverlessu i takiego Serverlessu w kontekście właśnie CloudFlare-a, czyli że te Cloudlfary faktycznie mogą co chwilę być gdzie indziej. I w tym momencie to już ma sens, bo dla takich Serverlessów rzeczy, które nawet nie trzymają tego w pamięci, nie żyją zbyt długo ma to sens, bo one nie będą pullowały tej aplikacji. Ten będzie występował za każdym razem, tak że ciekawa usługa. Obecnie w preview i mnie bardzo cieszy, ciekawi, interesuje w jakim kierunku idzie CloudFlare i jaką sobie niszę znalazł, bo ta nisza jest naprawdę ciekawa bardzo.
Łukasz Kałużny: Taki compute na edge. Ciekawe kiedy zacznie być Enterprise Ready, od tej strony, ta platforma. Bo offering sieciowy już jest zbudowany u nich Enterprise Ready, gdzie jest najwięcej kasy. I pytanie teraz, czy ten offering również zacznie być pokazywany jako Enterprise w pewnym momencie?
Szymon Warda: Wydaje mi się, że oni zbudowali tą swoją niszę, jednak mimo wszystko jako coś, co przyspiesza zwykły Enterprise, czyli Azure’y, AWS-y i GKE, czyli google’owską platformę i oni będą wokół tego chodzili tak naprawdę, jako taki szybki Enterprise powiedzmy sobie.
Łukasz Kałużny: Wiesz, raczej trochę feature’ów jest potrzebnych na workerach, żeby powiedzmy przeszły security vetting całej układanki, żeby zostały dopuszczone.
Szymon Warda: Dobra, ale jestem też ciekawy jak będzie ten Hyper Drive wyglądał w praktyce tak naprawdę. Jakieś pierwsze testy publiczne.
Łukasz Kałużny: Pierwsze problemy z cachem i walidacją.
Szymon Warda: M.in. tak. Z czym, to jest ważne, bo Hyper Drive działa też globalnie. To jest też ciekawe.
Łukasz Kałużny: Czyli po prostu edge zapinają Ci tam, gdzie pewnie po pierwszym połączeniu zaczyna się connection pulling z danego regionu po prostu.
Szymon Warda: Tak i pewnie inwalidacja cache’a, jeżeli chodzi pewnie po jakichś kolejkach. Redisowe są najszybsze, jeżeli chodzi o inwalidację.
Łukasz Kałużny: Dobra, lecimy teraz z terraform, pierwszy z dwóch na dzisiaj. Wyszedł Terraform 1.6. Ogólnie bym to zupełnie pominął gdyby nie to, że został wprowadzony framework do testu. I to jest rzecz, którą mam… Nie rozumiem unit testów na poziomie Infrastructure as Code.
Szymon Warda: Ja uważam, że one może mają sens, jeżeli ten IaaS byłby naprawdę skomplikowany. Na pwno byłoby co testować. Ale według mnie to będzie wyglądało na zasadzie: generalnie testujemy. Tak samo jak takie przykładowe testy są zawsze na konferencjach, jeśli chodzi o unit testy. Sprawdzamy czy element dodał się do listy, czyli realnie testujemy framework Java’owy albo tintowy. To nie ma sensu.
Łukasz Kałużny: Tak, raczej powiem Ci tak, bo zastanawiając się, przed rozmową z Szymonem mieliśmy: tak, nie ma to sensu. I teraz jedna rzecz wpadła apropo naszej wcześniejszej rozmowy i tego, że to nie ma sensu. Ogólnie jestem przyzwyczajony do tego, że testem jest po prostu środowisko developerskie, że IaC robimy, wrzucamy przez CI/CD, czy się deploy’uye czy nie. To jest jedno podejście. Gdzie takie podejście może być? Słowo klucz, które mnie wprowadziło na to, że ma to taką kapkę sensu, kropelkę, to jest jak mamy moduły, które są wykorzystywane przez innych i zawarliśmy tam, zamiast zrobić to, proste jak budowa cepa, to naładowaliśmy tam IF-ów. To jest jedyne miejsce, ale znowu to jest tak, jak testowanie Helmu. Jeżeli potrzebujesz testu to przekombinowałeś.
Szymon Warda: Właśnie, to teraz wracam do tego, czyli testujesz IF-y tak naprawdę, czyli testujesz czy jest IF i czy IF działa. Bo gdzie tu do końca jest logika? Czyli znaczy, że kodu musi tam od groma w tych modułach, muszą być skomplikowane? Czy naprawdę te moduły powinny być aż tak skomplikowane? Czy naprawdę chcemy tak komplikować życie?
Łukasz Kałużny: Właśnie dlatego mówię, bo testujesz logikę input, output, czy na podstawie tego case’u te IF-y wyprodukowały mi ten output? I to jest pytanie, czy nie przekombinowałeś z założeniami w tym miejscu, tak jak z Helmem zresztą?
Szymon Warda: Ustalmy, test Jaca żeby nie było, że ktoś wyrwie z kontekstu, że testy Jaca jak najbardziej mają sens. Tylko pytanie, czy chcemy po prostu robić unit testy na tak bardzo małym, granularnym poziomie? I tu mamy taką sporą wątpliwość, bo to zaczyna śmierdzieć trochę.
Łukasz Kałużny: Chyba, że piszesz w Plumi, to tam niestety pij, rób.
Szymon Warda: Tak, dobrze. To teraz ja coś ciekawego dorzucę. Artykuł od GitHuba: Lessons Learned from Building Copilot. I artykuł jest właśnie o tym jak GitHub budował Copilota, itd. OK, jest to słaby bardzo artykuł jeżeli chodzi o LLM-y i Copilota. Ale to jest bardzo dobry artykuł, jak się na to spojrzy z perspektywy jak w ogóle budować software, jak zarządzać cyklem życia, jak podchodzić w ogóle do produktów. Wzięli na warsztat książkę, która mi się kiedyś tam obiła o uszy, fajne podejście, “Find It, Nail It, Scale It” i fajnie opisują poszczególne kroki w kolejnych fazach. Czyli np. Find It: get clear on who you want to help, focus on simple problem first, balanced product ambition with quality, meet people who whey there are.
Szymon Warda: Mega ciekawy artykuł do przeczytania tego, żeby nie budować to, co już parę razy mówiliśmy, takiego opus magnum, żeby w odpowiednich fazach życia produktu, czyli generalnie wpierw szukamy co w ogóle budujemy, zawężamy ten case. Potem jak już mamy nasz problem, to doprecyzowujemy go, potem go skalujemy i co w której fazie zrobić. Naprawdę dobry do przeczytania. Nie jest, długi jest parę minut powiedzmy sobie jeżeli chodzi właśnie co kiedy robić i żeby się nie śpieszy takimi rzeczami jak testowaniem, optymalizacją. Kosztowa itd. Jest w skali de facto, jak już wiemy, że to działa. Dobre kubełki, trochę zimnej wody na to co gdzie powinno wyglądać i że chodzi o software development. Nie jeżeli chodzi o LM, bo tam LM u praktycznie nic tam nie ma. Dobra, ja znowu stara formę Open tofu ma swojego pierwszego build alpha owego, czyli przypominający open tofu. To jest open source owy fork nie zarażony licencją nie pozwalającą komercjalizacji. Taka forma. No i poleciał pierwszy build. Pierwszy release taki alpha w 1.6. Zobaczymy jak zacznie się to rozjeżdżać teraz. Czyli nie umarło tak szybko. Mimo wszystko coś wypuścili, coś wypuścili, więc zobaczymy jak ten jest niby pod skrzydłami Linux Foundation, więc zobaczymy co z tego wypali. No mam teraz czarną dziurę. W takim razie za rok co się będzie działo z Open Tofu? Jakie są Twoje produkcje? Wiesz co, jestem ciekaw, bo na razie nikt duży za tym nie stanął i sądzę, że nie stanie.
Łukasz Kałużny: Jest dobra rzecz, którą można dorzucić. Moment, jest nowa usługa od Google’a, która de facto z takiej perspektywy wchodzi w tę komercjalizację licencji, dorzuca ją do linków do odcinka i de facto duzi nadal będą stali za HashiCorpem, bo tam jest gotówka.
Szymon Warda: Czyli co, z OpenTofu będzie kolejny Linux desktop de facto, czyli siłowanie, żeby coś odpalić. Jest to bardzo możliwe.
Łukasz Kałużny: Raczej wiesz co, sądzę, że za rok ludzie się znudzą tym, którzy to próbują ciągnąć, bo trzeba pamiętać, że kasa na to troszeczkę pochodzi z Visiców i innych rzeczy. Więc jeżeli coś nie ma siły przebicia, to ginie w takim środowisku.
Szymon Warda: Zgadza się, a oni podeszli do tego, że i tak istniejemy, bo nie chcemy mieć licencji komercyjnej i na tym robić kasę, więc kasy z Visicu tam nie będzie, bo z definicji nie robimy kasy na tym de facto, chyba że na supporcie. Na supporcie dużo nie zrobisz.
Łukasz Kałużny: Bo wiesz, i pytanie np. co taki space lift czy parę innych, zaraz im ta kasa zniknie i tyle.
Szymon Warda: Dobra, to ja jeszcze kolejny obszar, który czasami wspominamy i który faktycznie coraz bardziej lubię, czyli cały stos grafanowej, co tam Grafana kombinuje ze swoimi narzędziami. Grafana Sift. Nie shift tylko S I F T. O co chodzi? Tool odnośnie incident response, czyli jak coś się wali to co właściwie robimy? I czemu o tym wspominam? Dlatego, że jest to tool oparty na, jak to Grafana twierdzi, na ML-u de facto, czyli jeszcze jakimś AI-u. To jest tool, który ma nam pomóc w diagnozie co się wywaliło, gdzie się wywaliło i co się dzieje. Z minusów, jest to dostępne tylko i wyłącznie w obecnie Grafana Cloudzie. Ale bardzo mnie to cieszy, ponieważ jak już mamy Grafanę, mamy wszystkie toole, które wspierają wszystkie wartości, to ułatwienie diagnozy tego co się wydarzyło, jak Cię gdzie budzą o czwartej w nocy, itd. i zbieranie danych sensowne, to jest super obszar właśnie na prowadzenie ML-a. Jako taki faktycznie copilot de facto do diagnozowania co się wywaliło w infrastrukturze albo w naszym systemie. Bo często to są bardzo proste rzeczy, o których zapominamy.
Łukasz Kałużny: Raczej chodzi o korelację zdarzeń po prostu, automatyczną korelację zdarzeń, które niestety nie mają ze sobą powiązanych ID-ków i anomaly detection też.
Szymon Warda: Wiesz co, korelacje korelacjami, ale to jest zbieranie bardzo dużej ilości sygnałów. Na przykłąd załóżmy, że np. o, certyfikat wygasł, albo załóżmy, że gdzieś wolumen się przypomni itd. To jest nagle ogarnięcie dużego zbioru, powiedzenie okay, to jest to, sprawdź to, to, to, to. Fajny tool jeżeli chodzi o wsparcie. Też w becie obecnie jeszcze leży w preview. Ja będę się temu przyglądał, bo to może być bardzo, bardzo sensowne.
Łukasz Kałużny: Martwi mnie, że tylko w cloudzie.
Szymon Warda: Mimo wszystko preview i wydaje mi się, że to też będzie obszar… Znaczy też muszą zarabiać. Nie mogą zrobić tak, że będzie wszystko self-hosted. Dla mnie sensowne mimo wszystko. Ciekawie będzie.
Łukasz Kałużny: Tak, bo chyba anomaly detection nadal się nie pojawiło w tym.
Szymon Warda: Właśnie szukałem i też go nie znalazłem.
Łukasz Kałużny: Chyba nadal się nie pojawiło, bo samo anomaly detection jest w cloudzie. De facto tam jest kilka algorytmów statystycznych używanych do tego.
Szymon Warda: To jest też super feature. To jest, od razu wytłumaczmy, to jest to, że budujemy alerty nie na bazie, że coś wykroczyło poza pewną metrykę…
Łukasz Kałużny: Tylko jest poza cyklem życia.
Szymon Warda: Tak i w sensie, że coś dzieje się inaczej niż normalnie się dzieje w tym przedziale czasowym, bo coś się działo abnormalnego.
Łukasz Kałużny: Tak, jak ktoś chce jest coś takiego jak, to jest od GitLaba wpis, to zostawię tak tylko, pokazuje jak zbudowali w 2019 roku, pokazują anomaly detection, właśnie jak wygląda statystyka za tym idąca i tzw. Z-Score. W jaki sposób robi się anomaly detection zwykłą statystyką i pokazują dokładnie w jaki sposób można sobie to fine-tune’ować, takie podejście. Niestety nie jest takie piękne jak plugin, który wszystko graficznie rozrysowuje, pokazuje. Trzeba sobie samemu zrobić takie query.
Szymon Warda: O dziwo pod spodem jest matma i to skomplikowana z reguły matma. Kto by się spodziewał?
Łukasz Kałużny: I dochodzimy do tego, że na koniec dnia to i tak jest matematyka.
Szymon Warda: Dokładnie. Co tam jeszcze masz Łukaszu?
Łukasz Kałużny: Nie, kończymy.
Szymon Warda: Dobrze. Przypominamy, że jeszcze będzie jeszcze short and sweet, ale to już dostaną użytkownicy w newsletterze, do którego zachęcamy oczywiście. Dobra, trzymajcie się.
Łukasz Kałużny: Na razie, hej!