Odcinek w którym lekko marudzimy na przehypowanie rzeczywistości. Czasem aż odechciewa się śledzenia newsów.
Co poza tym? Rozmawiamy o konferencji Open AI Dev Day i możliwości budowania własnych, customowych chatów GPT - hit czy kit? Szymon analizuje alternatywę dla outboxa. Na dokładkę wyżymamy Serverless Vector Search for AI, przeglądamy CubeCon i newsy do AKS-a, a na koniec - mówimy o kłopotach Okty z bezpieczeństwem.
Mimo tego marudzenia na początku - sporo się dzieje. Jak zwykle, rozmawiamy bez filtrów i upiększeń, więc na wielu tematach nie zsotawiamy suchej nitki. Za to potrafimy docenić naprawdę ciekawe pomysły. Co przeważyło tym razem? Posłuchaj!
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 na Patoarchitekci.io, numerek odpowiedni, gdzieś lewo, prawo, góra, dół, ogarniecie tak naprawdę. I oczywiście pato to the moon, czyli poleć nas babci, koledze, koledze pewnie lepiej, szefowi, bo skalujemy się wszerz i w górę. Łukaszu, co tam masz?
Łukasz Kałużny: Zaczniemy od tego jak bardzo mi się nie chce i chyba Tobie również.
Szymon Warda: Ciężki czas.
Łukasz Kałużny: Tak, ciężki czas. Ale o co mi chodzi? Bo to wynikło w sumie w naszych prywatnych rozmowach. Ostatnio miałem jakieś dyskusje na Discordzie Order of Devs. Mianowicie praca 9-5 nie jest złą rzeczą. Im jest się starszym, tym mniej chce się gonić króliczka z nowościami.
Szymon Warda: Zastanawiam się czy się mniej chce gonić króliczka z nowościami, czy bardziej widzi się brak sensu niektórych nowości i gonienia za tymi nowościami, widzi się, że pewne nowości umrą dość szybko.
Łukasz Kałużny: No właśnie, wiesz co? I dobrze, że to stwierdziłeś. Ja np. przestałem śledzić jakieś biblioteki developerskie, frameworki i inne rzeczy. Czasami coś wejdzie na radar, ale tą część np. przestałem zupełnie oglądać, bo większość odgrzewa stare kotlety i to tak mocno.
Szymon Warda: Tak, oczywiście, wymyślamy koło na nowo, to w ogóle bez dwóch zdań, ale też poziom hype’u jest taki, że co roku mamy coś wyhype’owane pod kosmos, co rozwiąże absolutnie wszystkie problemy i potem tak powiedzmy sobie, tak bardziej już teraz czekamy, aż to się ustabilizuje i będzie zwykłym narzędziem, a nie wyhype’owanym złotym czy srebrnym bardziej nabojem.
Łukasz Kałużny: To tak jak patrzę teraz na LLM-y, którymi się teraz zajmuję i to jest w ciągu ostatnich lat czwarta czy piąta technologia, na którą warto było więcej spojrzeć, bo jest przehype’owana, ale ma potencjał.
Szymon Warda: Problem z takimi technologiami jest to, że żeby zrozumieć, gdzie ona jest nie przehype’owana, gdzie są granice jej użyteczności, to trzeba w nią trochę wejść i pobawić się. Żeby to zrobić, trzeba mieć trochę więcej czasu. Ale znowu wydaje mi się, że to się spokojnie buduje w narzędzia, które będą wykorzystywane po prostu jako kolejny element, klocek budowlany tak naprawdę.
Łukasz Kałużny: Też, ale chcesz budować te klocki i w tym tkwi cały urok, jeżeli np. wchodzisz w taki temat.
Szymon Warda: Ewentualnie budowanie z klocków też.
Łukasz Kałużny: Więc to takie rzeczy. I takim smętnym marudzeniem na początek. Mamy brzydki, w momencie nagrywania mamy nie poniedziałek, ale brzydki wtorek, jak popatrzymy za okno. I teraz z rzeczy, które ja wygrzebałem na dzisiaj, to po pierwsze konferencja Open AI Dev Day. Było trochę ogłoszeń, dwa takie, na które warto zwrócić uwagę. Pierwsze jest to, że Open AI doładowuje swoje własne data retrieval, dobudowuje sobie. Czyli dużo startupów od baz wektorowych i innych tego typu rzeczy. Właśnie dostała tym announcementem po dupie i to tak…
Szymon Warda: Tak w kontekście hype’ów i jak szybko umierają.
Łukasz Kałużny: Tak, dokładnie, właśnie ten cały retrieval… Inaczej, nie dziwi mnie to, bo chcą pokryć, druga sprawa, inwestycje Microsoftu, które są gdzie ich klienci Microsoftowi, Enterpise’owi tej funkcjonalności potrzebują i nie chcą używać jakichś tam dziwnych open source’ów i innych rzeczy, tylko: dajcie nam to gotowe. To jest często mentalność, żeby mieć święty spokój przy budowie i utrzymaniu potem. I to jest jedna rzecz. Druga rzecz, która się pojawiła to a propos budowania z klocków, czyli GPTs, czyli budowanie własnych customowych wersji czata GPT.
Szymon Warda: Nie wiem czy widziałeś, pojawił się tweet odnośnie, nabijając się, ponieważ nasz kochany Elon też odpalił swój model i pojawił się tweet, który mówił: zbuduj mi lekko rasistowskiego bota. No i automatycznym wyborem był i nazwa Grok, która właśnie jest nazwą dla modelu muskowego de facto, czy dla sztucznej inteligencji muskowej tak naprawdę.
Łukasz Kałużny: Tak, gdzieś ten mem mi przeleciał. Jest dobry. No i właśnie o co chodzi? Że no-code’owo albo low-code’owo możemy zbudować własną zcustomizowaną wersję czata GPT. I tam są, oprócz tego, że możemy podać dość dużą instrukcję, żeby go sobie po prostu opisać, w jaki sposób ma działać, raczej spróbować, to drugim elementem, który ciekawiej pokazuje jedną taką rzecz, która się dzieje, to oprócz tego uploadu danych, które już przed chwilą wspomniałem, jest również wywoływanie własnych API w takim chacie.
Szymon Warda: I to jest naprawdę fajne.
Łukasz Kałużny: Tak i to będzie robić nam różnicę. ChatOps dla wszystkich, można by rzec.
Szymon Warda: Taki poziom, powiedzmy, demokratyzacji jest dla mnie sensowny, znaczy się to jest radialne. Zastanawiam się na ile takie modele wyjdą z poziomu: o, zbudujmy sobie, o, pobawmy się i umrą w ciągu tygodnia.
Łukasz Kałużny: No właśnie to jest ciekawe. W teorii gdzieś tam jeszcze jest monetyzacja tego. Z drugiej strony jestem ciekaw jak to wjedzie do takich pełnych modeli, gdzie będziesz mógł wykorzystać te funkcjonalności poprzez API. To będzie już ciekawsze.
Szymon Warda: Tak, API to robi wartość. No bo coś, co może zbudować w ciągu jednego dnia, monetyzacja tego, no tak, trochę może być ciężko, powiedzmy sobie szczerze. Nie za bardzo. Dostęp do jakiś API, które są wewnętrzne, które są charakterystyczne dla tej organizacji - tak, tu widzę wartość. Ale dalej to brzmi jak fajne informacje dla inwestorów. Natomiast realne wykorzystanie? Nie kupuję do końca.
Łukasz Kałużny: Wiesz co, ja patrzę co za tym idzie. Np. pamiętasz tą falę… z 2017, to była fala chatbotów, 2017-2018. I to można powiedzieć, jeszcze tylko dodać customowego UI-a i zakończyliśmy tą fazę własnych chatbotów.
Szymon Warda: Tak, dokładnie tak.
Łukasz Kałużny: Dobra, co u Ciebie?
Szymon Warda: Ja też trochę pomarudzę. Wygrzebałem taki wpis: Alternatywa dla Outboxa. Nazywa się to Listen to Yourself - słuchaj samego siebie. I idea w skrócie… W ogóle na czym polega Outbox? Outbox polega na tym, że zanim wyślemy wiadomość, to nie wysyłamy jej na kolejkę, bo kolejka może się wywalić, może się nie udać, generalnie wysyłanie do kolejki jest nietransakcyjne. I chcemy połączyć transakcję pisania na bazie z transakcyjnością de facto zapisu do kolejki, czy przyjęcie wiadomości przez kolejkę. Czyli mamy dwa systemy, czyli mamy transakcję rozproszoną, a że jeszcze kolejki nie wspierają najczęściej tego samego koordynatora transakcji, to generalnie pomysł jest skazany na porażkę.
Szymon Warda: Więc pomysł jest taki, że będziemy sobie zapisywali, my lokalnie do naszej tabeli jakiejś outboxowej i z tej tabeli outboxowej będziemy asynchronicznie wysyłali na kolejkę. Dzięki temu mamy transakcyjność operacji, że wiadomość zostanie wysłana. I kolejny fakt, że wiadomość z Outboxa będzie pobierana i wysyłana i to możemy ponawiać ile chcemy. A ponieważ mówimy o komunikacji asynchronicznej, to i tak nie powinniśmy liczyć na to, ile czasu nam zajmie wysłanie. Teraz jaka jest alternatywa? Alternatywa jest taka generalnie, że de facto nic nie zapisujemy do bazy, tylko wysyłamy wiadomość i na tą wiadomość sami nasłuchujemy, dzięki temu mamy zapewnienie, że się wydarzy.
Łukasz Kałużny: Ktoś chciał na siłę wymyślić jakiś nowy wzorzec.
Szymon Warda: Moja reakcja była w zasadzie: ok, to wygląda jak prezentacja dla juniorów na konferencję. W ogóle: o! Jezus Maria. I kolejna rzecz, zobacz o ile to jest łatwiejsze w implementacji na demie, jest super łatwe. Problemy jakie z tego wynikają oczywiście to jest to, że nasz zapis do bazy danych może się nie udać tak naprawdę i nie oszukujmy się walidacja będzie na poziomie bazy. Constraint, itd., to jest punkt spójności de facto. I co byśmy nie zrobili będzie od groma walidacji na poziomie bazy danych i to baza nam powie czy możemy czy nie możemy zapisać tak naprawdę.
Łukasz Kałużny: Tak zastanawiam się, biorąc ze świata dotnetowego np. MassTransita czy NServiceBusa, przecież zaimplementowanie tam Outboxa to jest dosłownie przeklejenie paru exampli z dokumentacji, bo do tego się sprowadza.
Szymon Warda: Łukasz, tak, ale doskonale wiemy, że logika nie zawsze idzie w parze z tym, czemu to robimy tak naprawdę. Jest to pomysł na wymyślanie. W ogóle ten cały, jak poszperałem w ogóle skąd to się wzięło i kiedy się wzięło, to znalazłem wpisy z 2017 roku, już były wpisy o tym tak naprawdę. Mówię: ok, było to coś co mnie ominęło w kontekście nie śledzenia wszystkich nowości i moje wrażenie jest takie, że Jezu, ktoś po prostu potrzebował pokombinować. Ale żeby obronić cały case, pomysł nie jest taki głupi jak się wydaje, a wydaje się bardzo głupi, więc poprzeczka jest dość nisko postawiona, gdzie to faktycznie ma jakiś sens? W bardzo wąskim przypadku tak naprawdę. Ma to sens, np. zbieranie danych odnośnie jakichś peratur, itd., rzeczy, które po prostu addytywnie dodajemy zawsze i nie ma tam żadnej logiki. Niestety ten wzorzec pomimo, że ma bardzo wąskie zastosowanie, on zaczyna się pojawiać jako alternatywa dla Outboxa, czym absolutnie, absolutnie nie jest.
Łukasz Kałużny: Nie wiem, ja podchodzę tak, jeżeli coś jest zupełnie bezstanowe, bez bazy danych, nie udało się wysłać wiadomości, odrzucamy request. Bardzo proste, kolejka, jest baza danych, jest Outbox. Zastanawiam się teraz jak ten człowiek podchodzi do backupów, bo spójności nie uzyska żadnej na koniec.
Szymon Warda: Wiesz co, wydaje mi się, że to by w teorii działało. Znaczy, Łukasz, pamiętajmy, to jest głównie wzorzec na prezentację na konferencję.
Łukasz Kałużny: To tam zawsze będzie działać.
Szymon Warda: Tam będzie zawsze działało, bo tam program jest generalnie mały. W tym zastosowaniu dla mnie jedynym sensownym rozwiązaniem, to jest po prostu Kafka i po prostu replay loga, ponowienie tego loga, przejście przez całość. I w tym momencie de facto bazę, jako taką, traktujemy jako coś, co po prostu jest tylko modelem odczytowym tak naprawdę, bo w tym momencie staje się tym baza. Super proste jak się patrzy na prezentację. To będzie piekielnie trudne w większej implementacji, niż demo 45-minutowe. Ale no ok, takie pomysły się pojawiają. Więc to było takie coś, co chciałem sobie pomarudzić i naprawdę robimy straszne kółko i trochę to bezsensu tak naprawdę, na skalę gdzie to jest hype’owane. Tyle.
Łukasz Kałużny: Dobra, to u mnie coś, co się pojawiło znowu. Na początku miałem to zanotowane jako do logów - World Fast Log Analysis Lambda, SQL, JSON, S3. Na stronie już się zrebrendowali na Serwerless Vector Search For AI, jak teraz otworzyłem. Ale wróćmy do tego, co zauważyłem i czemu wpadło mi to w oko. Projekt jest na LAR. Projekt, który zrobił ciekawą rzecz. Za pomocą Lambdy był w stanie przeprocesować PB danych za 50 dolców, przeskanować.
Szymon Warda: Chciałbym zobaczyć tego demo, coś, co mogę sam odpalić, bo to brzmi naprawdę optymistycznie.
Łukasz Kałużny: No właśnie, ja tego nie odpalałem. Można odpalić sobie local demo. Raczej ciekawostką t,o co jest zrobione, to cała logika jest wrzucona na AVX512 Assembly. Czyli całą logikę pod spodem zrobili bardzo, bardzo niskopoziomowo, na bardzo niskopoziomowych rzeczach, tam patrząc się jak to będzie wyglądało na bytecode i którędy.
Szymon Warda: Ale dalej mimo wszystko niskopoziomowo. Ale kwota…
Łukasz Kałużny: Chciałbyś to zobaczyć.
Szymon Warda: Kwota brzmi…
Łukasz Kałużny: Absurdalnie nisko.
Szymon Warda: Tak, brzmi za nisko o rząd albo dwa rzędy wielkości.
Łukasz Kałużny: Inaczej, jak to się na GitHubie, nasza cloudowa platforma oferuje 150 dolców za PB danych. Nadal w diabły tanio.
Szymon Warda: Tak, aż tak nierealnie tanio. Szczególnie, że w tym momencie mówimy o kosztach AWS-owych. Chyba że tam po prostu nic z tymi logami nie robią, to otwarcie pliku może tyle kosztować.
Łukasz Kałużny: Mnie bardziej chodzi o sam proces przskanowania tego. Jest to przeskanowanie JSON-ów po prostu. Nadal nawet jeżeli dwa rzędy wielkości więcej by kosztowało, to i tak to są kwoty, które przy analityce rozwalają mózg, jeżeli chodzi, że jest to super tanio. Jak znajdę kiedyś chwilę, będę chciał sobie sprawdzić te QRS-y faktycznie lokalnie czy to działa poprawnie.
Szymon Warda: Ok, to teraz GitLab DevOps Security Report. Nie jest może krótki, ale de facto tam treści jest tak różnie. Nie jest zły, też żeby nie było. Ale co ciekawe, kilka punktów z wyżymanych. Demografia to są głównie developerzy, więc ciekawie zaczyna się robić. Miejsce, 66% to są Stany Zjednoczone, co też fajnie pokazuje gdzie GitLab de facto ma swoje główne interesy tak naprawdę, bo to mało używane, większość mimo wszystko siedzi na GitHubie. Cały raport skupia się wokół całego ruchu shift left, bo w całym DevOpsie mamy dwie możliwości. Albo shift left, czyli przesuwamy de facto te badanie aplikacji, weryfikację, testy, itd., bardziej w kierunku developmentu, czyli żeby to było wykonane jak najwcześniej. Jak mamy tą taką pętelkę DevOps’ową, to właśnie o to chodzi. Albo mamy shift right, czyli przesuwamy to, że bardziej na platformie, dużo później de facto developerzy mają tą pętle zwrotną swoich formacji co im działa, co im nie działa. Ogólnie konsensus jest taki, że robimy shift left, jak najbardziej to jest taki dobry kierunek, w który należy iść. Kilka wniosków, które uważam, że są ciekawe. To, z czym się zgadzam, to że ogólnie ruch w kierunku shift left idzie i to idzie dość mocno, ale narzędzia do wspierania całości są jeszcze mocno niedojrzałe. Jest duża fragmentacja, co tam się dzieje. I to jest takie trochę klejenie z wielu małych kawałków, co, kto dodał de facto. Podpisuję się pod tym rękami i nogami. Jest to trochę niedojrzałe. Kolejne ciekawostki. Mniej organizacji używa Agile’a, scruma w 2023 niż w 2022 i to zauważalnie mniej. Ale żeby nie było, to samo dotyczy kanbana, waterfalla i leana. Generalnie pokazane jest, że jakby wszyscy przesunęli się w kierunku - robimy coś innego, czyli robimy po swojemu i nie dajemy temu żadnej nazwy tak naprawdę.
Łukasz Kałużny: Inaczej i pewnie, przepraszam, muszę teraz zaszydzić i w większości przypadków jest to waterfall iteracyjny ze scrum’owymi, kanban’owymi praktykami.
Szymon Warda: To mnie zdziwiło. Raczej zdziwiło tak na zasadzie po co? 38 ludzi od bezpieczeństwa mówi, że są częścią zespołu deweloperskiego. I teraz policzmy sobie, czyli mamy w zespole człowieka od bezpieczeństwa, od frontendu, mamy od testowania, mamy od infrastruktury, mamy jakiegoś developera generalnie, mamy jakiegoś testera. To już jest 6 osób, czyli cały zespół. Mnie to fascynuje, ten taki pęd, że zespół musi być absolutnie samowystarczalny, albo patrzymy, że skill tego zespołu nagle to jest na poziomie całej organizacji de facto. Realnie zespół to jest 6, góra 10 osób tak naprawdę, żeby to w ogóle miało sens. I 10 osób to już jest masę roboty. W takim razie naprawdę pewne zachowania, czy naprawdę każdy zespół musi mieć człowieka od bezpieczeństwa? Nie ma sensu żadnego w ogóle.
Łukasz Kałużny: No way. Wiesz co, to jest całe rozbicie w ogóle przy tym shift left. Wszyscy zapominają, że tam jest gdzieś coś w postaci jakiegoś internal development platform czy kawałka cloudu, którego jednak ktoś utrzymuje i standaryzuje, więc brzmi to komicznie.
Szymon Warda: Tak, brzmi to strasznie komicznie, takie wynaturzone niesamowicie. Znowu 34% to nie jest mało. Ustalmy, to jest naprawdę zauważalne.
Łukasz Kałużny: I teraz pytanie, czy tak jak powiedziałeś, developer określił się, że jest odpowiedzialny za security. Czyli gówno prawda jest odpowiedzialny za security.
Szymon Warda: Nie, to, że ludzie bezpieczeństwa, czyli że jest bezpiecznikiem de facto. Więc ciekawe. Ale ogólny wniosek, że ludzie twierdzą, że masę narzędzi jest, jest duża granulacja i że są przehype’owane. Snyk… Dobrze, to takie wnioski z raportowe. Co tam masz dalej?
Łukasz Kałużny: Ostatnie dwie pierdoły na koniec. Teraz jakoś niedawno był CubeCon i Microsoft w trakcie tego pokazuje zwykle newsy do AKS-a. I pokazał dwie przyjemne rzeczy, przyjemne pierdoły. Pierwsza, już kiedyś wspominaliśmy o takim projekcie OpenCost, co do trakowania costów między innymi Kubernetesa. I na bazie tego powstał add-on do AKS-a - AKS Cost Analysis add-on. Więc jeżeli ktoś używa Azure’a + właśnie AKS-a, to trafiła piękna rozliczalność. I teraz co jest najważniejsze? Docelowo jest to wintegrowane w portal Azure’owy, czyli można sobie pooglądać ładnie koszty i zejść też na poziomy. Microsoft przyjął sobie przeliczniki. Prawdopodobnie są one dobre, bo nie wgłębiałem się jeszcze, które pokazują ile dane obiekty kosztują też na spaceach. I to taka bardzo przyjemna pierdoła. Druga rzecz, która się pokazała, to streamowanie artefaktów. I o co chodzi? W tym wypadku Microsoft ma taki projekt, kiedyś nazywał się Teleport, czyli żeby jak najszybciej wystartować duże obrazy. Duże obrazy na AKS-ie właśnie, kontenerowe. To się miotło, gdzieś też o tym wspominaliśmy, w AWS-ie było pierwsze to dla container zrobione, ten streaming artefaktu. I Microsoft, wreszcie udało im się to wprowadzić dla siebie, do swoich produktów. Więc teraz jest publiczne preview powodujące to, że nasz obraz nie musi zostać cały ściągnięty, żeby AKS go sobie wystartował.
Szymon Warda: Ładne, przyda się.
Łukasz Kałużny: Raczej to rozwiązuje problem: mam za duży obraz, trochę tak częściowo.
Szymon Warda: Tak, ale już dla korporacji, gdzie faktycznie zapakowaliśmy do obrazów te wszystkie stare aplikacje de facto Enterprise’owe i tam wpakowaliśmy do Kubernetesa, to rozumiem, takim jest rozwiązaniem pewnym.
Łukasz Kałużny: Jest rozwiązaniem, ale możemy poszydzić.
Szymon Warda: Jak szydzimy, to generalnie pamiętajmy o tym, że nie tylko my szydzimy. Ukradł moje serce wpis Cloudflare’a, który brzmi “How Cloudflare mitigated yet another Okta compromise”, więc raczej wpis. Jeżeli duża firma, a Cloudflare jest dużą firmą i reputowaną firmą, mówi, że jak udało im się po raz kolejny mitigować atak de facto, problem, gdzie Okta też nie jest małą firmą, to to znaczy, że generalnie poziom wkurzenia już w CloudFlarze na Okta, zresztą w ogóle w sieci też, wzrósł dość dramatycznie. No bo pamiętajmy, że takie wpisy dostają zielone światło od kogoś, żeby taki a nie inny był tytuł, a tytuł jest konkretny. Ale w ogóle czym jest Okta? Okta jest narzędziem do identyfikacji IMFA i dzięki temu możemy sobie różne uwierzytelniać. Na czym polegał problem de facto? Co robi Okta? Podczas debugowania sesji, klient: coś mi nie działa. Proszę o wysłanie pliku HAR z Chroma. I czym jest plik HAR? Dla tych, którzy nie wiedzą, żeby uważali de facto. To jest nagranie całego ruchu, łącznie z ruchem sieciowym. A co w tym ruchu sieciowym jest? Są tokeny ciasteczkowe de facto, czyli takie nasze tokeny uwierzytelniające, dzięki którym nie musimy się logować przy każdym request’cie. No i okazało się, że pliki HAR wyciekły i zaczęły być używane, używane właśnie jako admini tak naprawdę z kontami administracyjnymi. Co się w ogóle działo? Że wykrył po… nieco po 30 minutach od tego, jak ich admin podzielił się plikiem HAR z Okta na życzenie Okta, to jest dość ważne, ktoś próbował użyć danych z pliku do utworzenia konta z uprawnieniami admina. 30 minut, to jest…
Łukasz Kałużny: Niezły czas.
Szymon Warda: To jest naprawdę dobry czas. I wtedy oni poinformowali Okta o tym fakcie włamu. To samo, Cloud też ich poinformował. Wtopa. Jestem ciekawy jak się Okta z tego wygrzebie.
Łukasz Kałużny: To jest trzecia albo czwarta wpadka.
Szymon Warda: Tak, łącznie z tym, że Ars Technica też zajęło się tym artykułem, zajęło się tą wpadką. Będzie ciekawie, bo już wkurzenie jest duże.
Łukasz Kałużny: Niektórzy chyba z 1Password dostali prośby o reset swoich haseł głównych.
Szymon Warda: Tak to się działo. A kolejny wpis, już ostatni, fajny wpis odnośnie znowu niezrozumienia i przehype’owania i zbytniego uproszczenia podejścia, tym razem do modelowania danych. Tak że AWS tłumaczy, ale bym tu trochę szukał jednak gruntu pośredniego. O co chodzi? Chodzi o to, że przez długi czas właściwie przy modelowaniu baz [niesłyszalne 00:17:41] kolumnowych, a szczególnie jeżeli chodzi o DynamoDB, bo DynamoDB właśnie jest tą bazą tego typu, nawet szef rozwoju Dynamo mówił, że generalnie potrzebujesz jednej tabeli i po prostu odpowiednio budujesz klucze, budujesz klucze partycji, budujesz klucze wierszowe i jednej tabeli. Co się okazało? Okazało się, że przydałoby się trochę więcej tabel niż jedna tabela, bo to prowadzi do pewnych wynaturzeń. Wpis fajnie analizuje skąd to się wzięło de facto, że to się wzięło z faktu, że kiedyś autoskalowanie działało gorzej, nie było konsumpcji na żądanie, nie było dostosowywalnej adaptive capacity de facto. I on fajnie pokazuje, że te wzorce zachowania albo dobre praktyki, które mieliśmy powiedzmy sobie 7 lat temu, 8, 10 lat temu, one niedokładnie dopisują się do sytuacji obecnej, że teraz można łatwiej to zrobić. I fajnie pokazuje też de facto jak te rzeczy powinny się rozwijać i z czego wynikają takie proste uproszczenia, że skoro tak kiedyś było, to tak musimy robić i że na ślepo powtarzamy tą opcję, że potrzebujesz jednej tabeli nie rozumiejąc z czego to w ogóle wynikało. Wpis jest naprawdę niezły, do poczytania tak trochę, bo wiadomo, że rzeczami o modelowaniu nie zawsze wszystko można przekazać słownie nie pokazując po prostu rysunków. Ale powiedziałbym, że tutaj też jest trochę błąd w komunikacji samego AWS-a, bo faktycznie oni bardzo długi czas komunikowali, że tak, jedna tabela, a nie tłumaczyli z czego to wynika, itd. Więc dobry wpis odnośnie modelowania danych.
Łukasz Kałużny: Nie jest tak, jest sprawy, ale zawsze mnie to ciekawiło, bo to był jedyny dostawca, który mówił o tym. Zobacz, że w Mango zawsze: utwórz kolekcję i inne rzeczy. W Microsofcie w NoSQL tak samo: utwórz sobie tabelę, bo i tak płacisz za całe konto storage’owe, a nie za tabelę. Ta historyczność tutaj ciekawie pokazuje dlaczego, czyli żebyś nie narzekał na naszą infrastrukturę .W modelu i w jednej tabeli, żebyś nie narzekał na naszą…
Szymon Warda: Tak, zalecenia odnośnie modelowania wynikały z tego jakie mieli ograniczenia na poziomie technicznym po prostu. Więc fajny artykuł, fajnie pokazujący i trochę otwierający oczy w kontekście tego, z czego wynikają niektóre zalecenia systemów, wszystkiego innego. Wynikają z tego, jak to działa pod spodem de facto i rozumienie jak działa baza danych, system jest krytyczny, nie oszukujmy się.
Łukasz Kałużny: Dobra, no to kończymy.
Szymon Warda: Kończymy.
Łukasz Kałużny: Na razie.
Szymon Warda: Hej!