➡️ 04.06.2024 Architektura 101
Cześć! W dzisiejszym odcinku Patoarchitektów wnikamy w zawiłości serverless, innowacji bazodanowych i systemów operacyjnych nastawionych na bazy danych. Omawiamy praktyczne implikacje technologii serverless, przeanalizują wpływ nowych trendów w bazach danych graphowych, oraz zgłębiają potencjalne przełomy jak BDoS – system operacyjny zorientowany na bazy danych. Na stole kładziemy pytania o skalowalność, wydajność i rzeczywistą użyteczność nowinek technicznych. Czy te technologie naprawdę mają szansę na zmianę gry w branży IT, czy to kolejne puste obietnice? Sprawdzimy!
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 odcinka pewnie na dole albo gdzieś w opisie. I oczywiście na Patoarchitekci.io. Dobrze, od czego Łukaszu zaczynamy? Szkolenia?
Łukasz Kałużny: Od szkoleń, czyli na naszej stronie znajdziecie link w opisie: patoarchitekci.io/szkolenia, znajdziecie harmonogram otwartych szkoleń na cały rok. Najbliższe to Architektura 101, w której pokazuję w jaki sposób projektować rozwiązania nie patrząc tylko na kod. Czyli w szczególności jeżeli programujesz i uważasz, że trochę brakuje Ci wiedzy jak wygląda wszystko poza kodem to zapraszam. Dużo osób z tego sporo wyniosło z tego co mi wiadomo. A Ty Szymonie?
Szymon Warda: Ja szkolenie z observability. Mianowicie dwa podejścia. Jedno takie klasyczne, wcale nie znaczy, że złe, z Application Insights, czyli łatwe podpięcie APM-a pod aplikacje. A drugie, jak postawić najsensowniejszy obecnie stos opensource’owy do pełnego observability, czyli logi, metryki i tracing. Czyli Prometeusz + stos grafanowy, czyli Tempo, Loki i sama Grafana, łącznie z alert managerem. A na końcu to przykryjemy jeszcze małą ilością fajnego Service Mesha, który się wpina, mianowicie przez Pixi. Ciekawe podejście do tego jak zbudować platformę do monitorowania i jak dodać monitorowanie + całe observability do istniejących produktów. Dużo, praktycznie, z językami zapytań i z tym jak to w ogóle wszystko poinstalować i pogodzić. Także też zapraszam.
Łukasz Kałużny: Dobra, a jak byście chcieli mieć to szkolenie albo inne prywatnie zorganizowane w firmie, też zapraszamy. Dobra, to ja z newsów zacznę od czegoś, co jest, Szymon określił, że nieistotne i jak się chwilę zastanowić to prawdopodobnie tak. Bazy graphowe doczekały się ISO do swoich, do swojego języka, czyli do GraphQL Language, który jest odpowiednikiem SQL-a właśnie w postaci normy ISO.
Szymon Warda: To ja wyjaśnię czemu to jest dla mnie nieistotne. Ponieważ w ogóle całość wyszła od Neo4j’a, producenta najsensowniejszej bazy Graphowej i najbardziej sensowny z tego punktu widzenia, że mamy dwa języki graphowe jako takie. Jest Gremlin Apache’owy, taka dość stara specyfikacja, m.in. Cosmos DB z niej korzysta, taka bardzo, idziemy po wierzchołkach, itd. Bardzo ręczna, niezbyt, znaczy dalej użyteczna, ale niezbyt elastyczna. A Neo4j wprowadził Cyphera. Jest to taki wyższy język wyższego poziomu, bardzo taki, trochę dziecko miłości pomiędzy ASCII Artem a SQL-em. Mega potężny język. Ja teraz czemu to jest dla mnie nieistotne? To jest to, że Cypher jako specyfikacja został opublikowany kilka lat temu i mało kto go podjął. Może teraz, w dobie AI, kiedy bazy graphowe mają kolejną próbę wejścia na główny rynek, to zyska. Ale nie wydaje mi się po prostu. Szansa już była, a to są dalej bazy do bardzo niszowego zastosowania. A Cypher jest trudny…
Łukasz Kałużny: Raczej w sensie, widzisz, standaryzacja tak, bo SQL jest prawie tak stary jak ja, jeżeli dobrze pamiętam, nawet nie, starsze, 87 rok, specka SQL-owa wyszła. Może 10 lat za późno, jak nie 15 i lepiej.
Szymon Warda: Dla mnie to jest kto miał spróbować implementować Cyphera, ten już tą próbę podjął. Jakoś nie widzimy tego, żeby dużo było adopcji. Były zgłoszenia do Cosmosa, żeby implementował i oni powiedzieli, że na razie nie, bo za małe jest użycie tych języków, tych baz danych.
Łukasz Kałużny: Miałem taką rozmowę z kimś apropos, że gdzieś tam użyto w systemie, stwierdzono, że wszystko będzie latało na graphach, cały system. Oczywiście okazało się jedną wielką porażką, że to co miało być szybkie, było szybkie, a reszta była upierdliwcem, którego nie wiedział nikt jak to utrzymywać. I to jest takie…
Szymon Warda: To jest ta opcja generalnie, że bazy graphowe są fenomenalne do bardzo wąskiego zbioru problemów i tam ich nic nie pobije. Ale takiego ogólnego, tzw. general purpose usage nie mają sensu, bo po prostu się nie skalują i to nie będzie działało dobrze.
Łukasz Kałużny: Dobra, co od Ciebie?
Szymon Warda: Ode mnie ciekawa inicjatywa. Normalnie bym ją olał, ale za chwilę może zobaczycie czemu nie. BDoS - Database Oriented Operating System. Więc brzmi już ciekawie generalnie, brzmi jak jakiś szalony pomysł. Platforma do hostowania serverlessowych funkcji typescriptowych, która obiecuje kilka rzeczy: wykonywanie funkcji raz i tylko raz, co jest ciekawe w systemie rozproszonym, operowanie na czasie, czyli cofanie się w czasie, replaying, powtarzanie funkcji, itd.
Łukasz Kałużny: I time travel debugger. To mi się rzuciło.
Szymon Warda: Tak, czyli po prostu replay. Tak, to nazywa się bardzo ładnie jako time traveling. Po prostu odtwarzamy z zdarzeń. Autoskalowanie, HA, transakcyjne wykonywanie. I to jest ciekawe generalnie, co oni przez to rozumieją, bo nie precyzują dokładnie, co przez to rozumieją, bo to jest wykonanie funkcji, albo się wykonała, bo się nie wykonywała, no nie? Co jest teraz ciekawe… A i coś nie jest do końca opensourcem. Całość brzmi jak taki trochę mokry sen kogoś tuż po studiach. Ale kto to tworzy? Mike Stonebreaker, twórca Ingressa, Postgresa i VoltDB, nieźle. Matei Zaharia, twórca Apache Sparka. Więc to nie są osoby, które by rozkręcały coś, co nie będzie miało większego sensu. Udało im się parę rzeczy dobrych zrobić, więc jestem ciekawy, co z tego wyniknie.
Łukasz Kałużny: Tak, tylko jeszcze jest co-founder Databricksów, founding advisor. Tylko to jest też w postaci cloudu, więc znowu kolejna usługa, gdzieś tam…
Szymon Warda: Gdzieś, która jest oderwana, która nie ma do końca swojego zbioru na dane. Jestem ciekawy w jakim to kierunku pójdzie, bo to są zbyt doświadczeni ludzie, żeby rozkręcać coś, co jak się na to patrzy, to za bardzo nie ma przyszłości.
Łukasz Kałużny: Tak, to jest, wiesz, albo jest to ich duży eksperyment spełnienia jakiegoś mokrego snu z całej ich kariery, też tak może być.
Szymon Warda: Ale żeby nie było, też mokry sen, jak patrzę na te wszystkie funkcje, to kilka wniosków. Po pierwsze, bazy relacyjne mogą się skalować, bo to stoi pod spodem na bazie relacyjnej, ale przede wszystkim ten zbiór funkcji, które opisują, to jest to samo, co np. robi Azure Durable Functions. Tu nie ma za bardzo różnicy, no nie? Ale w ogóle też dziwi mnie to, że to w ogóle powstało. To co mówiliśmy w odcinku poprzednim, to jest to, że hype na serverless trochę minął. Może to będzie w kontekście całej lambda architecture i całego stosu pod dane, tak też może być. Ale jakoś nie widzę sensowności tego pomysłu, mimo że brzmi bardzo fajnie.
Łukasz Kałużny: Czy wiesz co, ja całość na to patrzę trochę inaczej. Tam były też, zauważ, mi się rzuciło, teraz kurde nie pamiętam jak się nazywał jeden z rozproszonych rozwiązań cache’owych w Javie, który jest też bazą danych, serverlessem i innymi rzeczami. Gdzieś sobie coś jest i w finansówce ma tam zastosowanie. Wyleciała mi totalnie nazwa, jeżeli sobie przypomnę to i znajdę to zalinkuję co miałem na myśli. I druga za tym idąca rzecz, wszystkie frameworki do aktorów, bo zobacz, że jak trochę popatrzysz na to, to teraz to co mi się rzuciło tak jak zacząłeś mówić, to jest, że to jest bardziej platforma do odpalania aktorów.
Szymon Warda: Tak, bo całe środowiska serverlessowe nadają się idealnie pod model aktorów. Ale dalej nie widzę w ogóle potrzeby rynkowej na to, jest to, raczej będę obserwował, jestem ciekaw jak to się rozwinie.
Łukasz Kałużny: Raczej jest, inaczej, sam pomysł nawet brzmi jak mokry sen, tylko że jest to w postaci cloudu, który jest gdzieś obok. Gdyby to było…
Szymon Warda: Opensource, to by to miało sens większy.
Łukasz Kałużny: Raczej opensource, albo żeby działało jak Databricksy. W sensie czyli że jest na każdym cloudzie np., bo to już Ci gdzieś to odcina i wiesz, tak popatrzyłem sobie na pricing, to masz tam 4 tiery i widać, że to hostowane jest na AWS-ie, więc ciekawe.
Szymon Warda: Dobrze, co tam Ty znalazłeś?
Łukasz Kałużny: Dobra, następna rzecz od JenAI-a chyba patrząc się jak wyglądają wszystkie announcementy w niższych technologiach, to najwięcej czasu idzie tam teraz. Mam wrażenie, że LLM-y mają, więcej się poważnego dzieje niż działo się na początku hype’u z blockchainem, to tak w sensie, bo idzie. I z tych newsów teraz to Lama 3, jeżeli sobie popatrzymy. Może nie news jak teraz tego słuchacie, to nie jest już aż takie świeże. Więc nowy model od Mety, który wypada nieźle. Ale coś innego mnie tutaj zainteresowało w tym, bo ma dużo ciekawych rzeczy. Ale najciekawsze było odpalanie tego lokalnie na Raspberry Pi 5 i jest filmik właśnie Lama 3, 8 bilionów, działa tam z prędkością 1,89 tokena na sekundę.
Szymon Warda: OK, to brzmi imponująco.
Łukasz Kałużny: Tylko Szymon, pamiętasz co mówiliśmy? Że będzie to szło w kierunku coraz bardziej większej dostępności, żeby odpalić to lokalnie.
Szymon Warda: To bardziej pewnie pokazują to w kontekście, że da się na urządzeniach mniejszych niż wielki, wielki serwer. I obstawiam, że bardziej to jest ukłon, bo teraz w ogóle też, to jest też nowa wiadomość, co robi Meta? Meta chce, żeby ich, to się nazywa chyba Horizon OS, stał się systemem operacyjnym do headsetów VR-owych. Więc obstawiam, że Meta przez to Raspberry Pi chce pokazać, że można to odpalić na mniejszych urządzeniach.
Łukasz Kałużny: Nie, wiesz co, to ktoś sobie odpalił po prostu całościowo, ale też pokazuje np. to też co gdzieś tam wokół Apple’a się dzieje, jak upchnąć LLM-a w telefon.
Szymon Warda: Albo w coś podobnego, tak.
Łukasz Kałużny: Albo pierwszą warstwę.
Szymon Warda: Żeby te strzały do jakiegoś RAG-a, który siedzi w internecie, były rzadsze i szybsze. Możliwe.
Łukasz Kałużny: Dobra, teraz co u Ciebie?
Szymon Warda: U mnie całkiem ciekawy wpis na medium od Decathlona. Oni mieli taką serię wpisów odnośnie backends for frontends, czyli tworzenia odpowiednich backendów dla frontendów, czyli dla weba, mobilek, itd. Seria jest ok, powiedzmy sobie, ale jest, ostatni wpis z serii, czwarty, jest całkiem ciekawy z prostego punktu widzenia, pokazuje alternatywy. Mianowicie pokazuje co można robić zamiast backend for frontends. Prawda jest taka, że skupia się to głównie na mobilkach, bo tam faktycznie ta potrzeba jest największa. I tak listując co można zrobić zamiast: over-the-air update, czyli wymuszanie aktualizacji klientów, żeby byli zgodni z naszym backendem?
Łukasz Kałużny: Nie.
Szymon Warda: Czy to się zawsze uda? Może być różnie, ale może być. Pomysł, który, ja już dawno tego nie widziałem, ale faktycznie kiedyś to było promowane dość mocno, HATEOAS tzw., czyli Hyper Media as an Engine of Application State. O co w tym chodzi? Chodzi o to, że generalnie wrzucając response’a naszego, dane, np. mamy order i od razu jako link w danych orderu załączamy link do szczegółów tego orderu. Dzięki temu możemy po naszym zbiorze odpowiedzi chodzić jak po sieci, po webie.
Łukasz Kałużny: Inaczej, czyli to jest rzecz, bez której rzekomo nie masz, to jest też trochę prawda patrząc się tym, jest to prawidłowa implementacja resta, takiego prawdziwego rest API, patrząc się na pierwotny pomysł.
Szymon Warda: To jest o tyle fajne, że to znacząco zwiększa odkrywalność tego API tak naprawdę, więc pomysł jest fajny. Ja tego praktycznie nie widziałem w użyciu. To jest taka jedyna rzecz. I temat ostatni, mianowicie Server Driven UI jako alternatywa do budowania backends for frontends w kontekście mobilek. Więc to jest też ciekawe podejście w jakim to kierunku idzie. Artykuł dobrze napisany, fajnie pokazuje alternatywy, jest fajnym mentalnym ćwiczeniem jak podejść do problemu nie wykorzystując zawsze tego samego rozwiązania. Niekoniecznie mówię, że pozostałe będzie sensowne, ale w sensie, żebyśmy umieli pokazać, że są i jakie one mogą być, jakie mamy plusy i jakie mają minusy. Tak że warte przeskrolowania przynajmniej. Dobrze, co u Ciebie?
Łukasz Kałużny: Jedna rzecz jeszcze do tego, komentarz, tu GraphQL się nie pojawił.
Szymon Warda: nie pojawił się, faktycznie.
Łukasz Kałużny: Bo zobacz, że właśnie BFF, czy jest to API gateway czy natywna implementacja, też jeszcze z takich uwag, bo jest to ciekawe jak popatrzysz. Bo mógłbyś o BFF-ach powiedzieć, czy to jest implementowany w kodzie czy jednak API gateway i trochę o tym problemie o którym piszą. Brakuje GraphQL-a, który rzekomo miał zbawiać świat, jak to się chyba też w jednym z ostatnich odcinków się nabijaliśmy.
Szymon Warda: Tak, nabijaliśmy się nie raz. Wydaje mi się, że oni bardziej wykorzystują backend for frontends do wersjonowania swojego API. Bo nawet z tych rozwiązań to wynika, że generalnie, że jak przychodzi aplikacja na to, żeby móc wygasić backend, ewentualnie wspierać bardzo stare aplikacje. Więc w sumie tego GraphQL-a i tak musiałbyś w pewnym momencie też wersjonować jakoś tam. Tylko mówię, dość wąskie zastosowanie, rozwiązanie tego co oni mają. GraphQL ogólnie rozwiązuje problem backends for frontends w pewien sposób tworząc nowe problemy, ale im chyba trochę o co innego chodziło mam wrażenie, tak czytając całą tą serię i alternatywy. Ale tak, może pomóc.
Łukasz Kałużny: Dobra, idziemy dalej. To jest rzecz, która się dzieje i o tym też wspominamy. Tekst Discorda o tym jak przenoszą się do Cloud Development Environment, czyli odpalanie wszystkiego sobie gdzieś na VM-ce w cloudzie. Krótki, nie ma tutaj aż tak za dużo mięsa, tylko patrząc się na całą układankę tą, zobacz ja np. wyrzuciłem, teraz rok temu od siebie z kompa, prawie wyrzuciłem narzędzia developerskie, prawie, na rzecz GitHub Codespaces. I pojawiają się VM-ki, niestety z bycia konsultantem, VM-ki z VPN-ami, bo tego nie przeskoczę w GitHub Codespaces, tam gdzie potrzebuję go użyć. Ale teraz ten cloud development zaczyna być, te środowiska cloud developmentowe zaczynają stanowić naprawdę niezłą alternatywę.
Szymon Warda: To w ogóle była jedna z naszych predykcji na ten rok, że będzie to się rozwijało coraz bardziej swoją drogą, tak mi się wydaje. Ja się tego jednocześnie boję, bo to może być implementowane w korporacjach w absolutnie tragiczny sposób, taki… Każdy chyba korporacyjny… Starsi słuchacze pewnie mieli taką przyjemność, że pracowali na terminalach, czyli przychodzili do pracy, logowali się na zdalny pulpit, który reagował jak nie wiem co i tam mieli super ograniczone środowisko, na którym niewiele mogli zrobić i to było kodowanie. To jest przeszłość, bez dwóch zdań, jak najbardziej. Jestem ciekawy co do wsparcia i właściwie to tyle, co się wydarzy.
Łukasz Kałużny: Wiesz, z drugiej strony pójdziesz, jak popatrzysz nawet na Google’a, to oni przecież już od lat w ten sposób pracują, pozbyli się kodu ze stacji i ludzi.
Szymon Warda: Przy wielkich monorepo to po prostu jest nieutrzymywalne.
Łukasz Kałużny: I w sumie GitHub się tym też chwali, że większość przesiadł właśnie też na swoje Codespaces, czyli robią dogfooding.
Szymon Warda: Muszą. Ciekawe. Dobrze, często mamy jakieś tam wpisy, które mają może mało praktyczne zastosowanie. Nie jest takie coś, że kogoś ucieszy: o, to użyję. Czasami pojawiają się takie małe rzeczy, a cieszą. A teraz rzecz, która nie jest mała, a cieszy. Mianowicie Postgres wspiera .Neta. Co jest ważne, nie chodzi tu o drivery. Chodzi o to, że w składni, w procedurach, funkcjach Postgresowych, procedurach, funkcjach, triggerach, rekordach, całych funkcjach tabelarycznych możesz normalnie zrobić po prostu $$ i mieć kod .Netowy.
Łukasz Kałużny: Kod .Netowy albo F Sharpowy.
Szymon Warda: Tak, albo F Sharpowy, dokładnie tak. I to jest, nie musisz mieć funkcji wbudowanych osobno, masz wsparcie dla 43 z 46 typów, które Postgres ma, jest w pełni sprawny, działa z innymi językami, mają tego ponad 1000, w sumie to nie jest aż tak dużo, 1000 unit testów. Czyli dla mnie to jest takie, naprawdę, Postgres będzie powoli wypierał dużo rzeczy.
Łukasz Kałużny: To jest zaskakujące.
Szymon Warda: Mnie to też zdziwiło bardzo mocno, tym bardziej, że SQL się, SQL Server ma to od lat dwudziestu…
Łukasz Kałużny: Nie, zapomnij, CLR-y to było takie jak dodatki javowe do Oracle’a.
Szymon Warda: Tak i to było tragiczne, ustalmy, to było tragiczne, niebezpieczne, wymagało wyższych uprawnień bazodanowych, to było złe. Ale szczerze mówiąc było kompilowane i dodawało się DLL-kę, itd. Ale tu masz…
Łukasz Kałużny: Tak, natywny język.
Szymon Warda: Tak, natywny język. Jest to imponujące, bo pewne rzeczy po prostu łatwiej robi się w kodzie prawdziwym niż w SQL-u jako takim.
Łukasz Kałużny: Dwa szybkie przemyślenia. Wiesz co, po pierwsze, czy JavaScript nie wystarczył? To jest taki ten, w sensie tak, takie coś, że możemy zastosować normalny język w środku, normalny język programowania z jego normalną logiką rozumowania przy algorytmach przy zaimplementowaniu czegoś versus SQL. Bo widziałeś w jaki sposób niektóre SQL-ki są pisane krzywo, żeby coś osiągnąć w procedurach składowanych.
Szymon Warda: Tak, szczególnie tak, jak musimy odpowiednią odpowiedź wygenerować, jakieś operacje na starych rekordach robić, jakieś tam splity, jakieś merge, jakieś wyszukiwania, operacje na tekście generalnie. Tak, to wygląda źle.
Łukasz Kałużny: W sensie nie, to czy na liczbach w ogóle operacyjne. Sam pomysł uważam za świetny, tylko właśnie pytanie jest, czy faktycznie coś poza JavaScriptem było potrzebne? Tak zupełnie, zupełnie szczerze, bo jestem ciekaw po prostu motywacji, która za tym stała. I druga rzecz, jak dużo osób będzie tego używać.
Szymon Warda: Ja tego nie widzę w kontekście czy było potrzebne. Jest to ukłon w kierunku środowiska i to jest miły ukłon. Druga rzecz, jak będzie potrzebowała, to jest na zasadzie takiej, wiesz co, że jak potrzebujesz, to masz tą alternatywę i pokazuje, że Postgres ładnie pochłania kolejne ekosystemy tak naprawdę. Dla mnie to jest to, że to nie jest już tylko język dla baz danych, dla Pythona, ewentualnie dla niektórych PHP-owców. Więc to jest ciekawe. Dobrze, lećmy do kolejnego.
Łukasz Kałużny: Dobra, to co zostało na koniec?
Szymon Warda: Dla mnie, często mówimy o gigantach, jak to, co się dzieje w Facebooku, Google’u, itd., nie aplikuje się do tego, co robią wewnątrz korporacji. I ciekawy wpis, niestety nie mam linka, bo to jest z newslettera od Practical Engineer.
Łukasz Kałużny: Nie, już wrzuciłem linka, znalazłem to akurat.
Szymon Warda: A, udało Ci się, to gratulacje. I on opisuje jak jeden z średniej wielkości włoski bank robił update wersji Oracle’a, to jest pierwszy. I spowodowało to problemy w dostępie od 7 do 11 kwietnia. I problemy były takie, że po prostu sporo systemów znacząco zwolniło albo nie działało. I teraz Practical Engineer mówi prosto: to zróbcie restore bazy. I to pokazuje jego trochę niezrozumienie tego, jak działają duże instytucje finansowe i że to był Oracle. Jeżeli mówimy, że to położyło większość systemów, to ja zakładam, że to było albo systemem transakcyjnym, albo było frontem do systemu transakcyjnego. Czyli transakcyjny był replikowany, w sensie w formie normalnej, jakiejś takiej użytecznej, do Oracle’a i tam wszystkie systemy sięgały do tego. Scenariusz, który ja zakładam, że tam się wydarzył - podbili wersję Oracle’a, zaczęli używać, Oracle podbił wersję pliku bazodanowego, zaczęło to działać horrendalnie wręcz wolno. I teraz co mogą zrobić? Mogą tak, mogą zrobić restore VM-ki, VM-ek oracle’owych. Ale…
Łukasz Kałużny: Nie robisz tego, bo jest… Inaczej, robisz restore bazy danych. Oznacza, że musisz zrobić restore na początek VM-ki albo zdowngrade’ować. Zazwyczaj odinstalujesz, instalujesz niższą wersję, robisz cały setup, odgrywasz full backup, z tego full backup, który pewnie przed tym updatem był zrobiony. I nawet nie było chętnego, który by wpisał “drop database” przed zrobieniem tego full restore’a.
Szymon Warda: Tylko cały problem polega na tym, że takie bazy jak Oracle i systemy bankowe, to mówią bazy, które z reguły mają kilka terabajtów tak naprawdę. Tak w sensie, tak z 10 tera będą miały lekką ręką.
Łukasz Kałużny: To w ogóle, to chyba developerka.
Szymon Warda: Więc teraz zrobienie restore’a tak ogromnej bazy, to jest, po pierwsze to musi być zaplanowane w kontekście wydajności macierzy, żeby ona to wydłużyła, trzeba to całe miejsce udostępnić, bo to nie będzie nadpisanie. To jest horrendalna procedura operacyjna całej organizacji. To nie jest takie proste. W ogóle samo proste kopiowanie tych plików i włączenie tego RAG-a, to są realnie dni. Więc to fajnie pokazuje jak on do końca nie rozumie skali, jak działają organizacje, które mają ogromne zbiory danych i nie mogą tego trzymać w chmurze. Czy nawet w chmurze by to zajęło dużo czasu, nie oszukujmy się.
Łukasz Kałużny: Tak, w chmurze jeszcze dłużej. Nie, wiesz co, ja pamiętam ile przewidywało się, bo… Inaczej, takie scenariusze awaryjne tam jeszcze w starych czasach onpremowych miałem okazję ćwiczyć. Czyli sprawdźmy ile będzie trwał full restore gdyby jednak te wdrożenie nie poszło. Bo takie rzeczy się robi. Inaczej, dwa dni offline. Naprawdę dobry, ten, naprawdę dobry…
Szymon Warda: 4 w sumie generalnie.
Łukasz Kałużny: Co?
Szymon Warda: Oni mieli 4 w sumie, ale to nie jest taki tragiczny czas, tak.
Łukasz Kałużny: W sensie odzyskali dane na koniec dnia. Raczej suma sumarum nie stracili danych, bo to jest w ogóle najważniejszy element tej całej układanki. Pewnie mają dużo do poprawy. Wiesz, patrząc się na skomplikowanie, bo jak podnosisz w takich, to są dość monolityczne środowiska i zazwyczaj podnosisz drivery w aplikacjach, poszły jakieś update’y driverów i innych rzeczy i nagle się okazuje, że ta pajęczyna na zasadzie zrób restore, zazwyczaj to jest już taka ostateczność, której nikt nie chce podjąć decyzji: robimy… Inaczej, zresztą rollback to jest najgorsza możliwa rzecz, która może się zdarzyć. Robisz ją na samym końcu, kiedy naprawdę pula się wyczerpała i już tylko piekło się pokazuje.
Szymon Warda: Tak, tym bardziej, że w tym momencie te wszystkie systemy takie, już pajęczynka właśnie, które go konsumowały, nagle są, totalnie się rozjeżdżają. Cała analityka, raportowe, a bank ma dużo rzeczy do raportowania i dalej nagle tam jest totalny pierdolnik.
Łukasz Kałużny: Fajnie sobie mówić o Uberze, jak zniknie Ci historia przejazdów, to nawet tego nie zauważysz.
Szymon Warda: Banki mają trochę gorzej. Więc taki ciekawy wpis, który pokazuje jawnie, że te światy trochę inaczej wyglądają. Tyle tak naprawdę.
Łukasz Kałużny: Trzymajcie się, na razie.
Szymon Warda: Na razie. Hej!