Ostatnie Patoszkolenie w tym roku👇
Short #59 to prawdziwa patoarchitektoniczna uczta! Od Uber CD po eBPF Profiling, ten odcinek ma wszystko.
Zanurzymy się w świat zero downtime migracji baz danych i continuous profiling z Open Telemetry. Odkryjemy, dlaczego Uber stworzył własne narzędzie CD i jak Amazon Aurora Serverless radzi sobie z 10 000 węzłów.
Chcesz wiedzieć, jak nie robić PoC? Albo co się stanie, gdy Terraform i Azure się pokłócą? Posłuchaj i zostań prawdziwym patoarchitektem! SQLite z replikacją czeka na Ciebie.
Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: protopia.tech
Discord 👉 https://discord.gg/78zPcEaP22
Linki i ciekawe znaleziska:
azurerm_management_group_subscription_association ID broken in v4.3.0 · Issue #27449 · hashicorp/terraform-provider-azurerm · GitHubSzymon Warda: Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…
Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io lub pewnie gdzieś tu na dole, znając życie.
Szymon Warda: Tak. No to co Łukaszu, promujemy? Lecimy?
Łukasz Kałużny: Najpierw szkolenia, czyli w tym roku zostały jeszcze dwa, które prowadzimy otwarte. Ty prowadzisz Observability.
Szymon Warda: Zgadza się.
Łukasz Kałużny: A ja prowadzę Architektura 101. Observability, jak sama nazwa mówi, obserwowalność z perspektywy stosu opensource’owego jak i APM-ów, żeby pokazać jak to wygląda. A ja pokażę za to jak uporządkować sobie wiedzę na temat projektowania systemów.
Szymon Warda: Obydwa fajne. Na obydwa zapraszamy.
Łukasz Kałużny: Tak, Paotarchitekci.io/szkolenia lub też gdzieś tu na dole.
Szymon Warda: Jasne. Dobra, to lecimy. To ja zacznę, bo chciałem Cię przeprosić. Publicznie kajam się i muszę przyznać, że miałeś rację. Mianowicie o co? Odcinek o 12 Factor Apps jednak był potrzebny. I teraz czemu o tym mówię? Bo ostatnio dokopałem się do artykułu o Uberze, żeby nie było, że jakiś taki wykop co nie wiadomo co i jak, o tym jak Uber robi deployementy. Uber ma około 4,5 tysiąca serwisów pracujących. Czy zdajesz sobie sprawę jaki procent serwisów był deployowany automatycznie? Strzelaj!
Łukasz Kałużny: Dobra, bez wchodzenia w ten artykuł, bo nie pokazałeś mi go, załóżmy, że z 40.
Szymon Warda: Mniej, dużo mniej.
Łukasz Kałużny: What?
Szymon Warda: Strzelaj dalej. Dajesz!
Łukasz Kałużny: No dobra, to lecimy. Jeżeli to jest tak absurdalne, to pewnie z 10%.
Szymon Warda: Mniej - 7.
Łukasz Kałużny: What the…? Co tam się wydarzyło?
Szymon Warda: Z tych 7% dalej część wymagała manualnych kroków.
Łukasz Kałużny: Ta liczba mikroserwisów, jak teraz jeszcze widzę 7000 production deploymentów na tydzień. Przecież to w ciągu kilku tygodni dało to się zautomatyzować, patrząc się na czas, jaki ludzie tracili.
Szymon Warda: Z monorepo, więc w kontekście mają 4,5 tysiąca serwisów. Znaczy, że 4 tysiące 185 serwisów było wdrażanych na produkcję ręcznie. Ok, one może były mniej używane, może to były po prostu rzeczy, które leżały, nie były rozwijane, itd. Ale sama liczba razy ilość czasu potrzebna razy potencjał pomyłki, to są nawet dla Ubera, nawet przy ich skali to są tak ogromne liczby spalonego czasu, że to jest aż niemierzalne.
Łukasz Kałużny: Ty wiesz co? Dlatego ja mówię, że wiesz jak mi mówisz o ilości deploymentów i serwisów i inne rzeczy, to się dało automatyzować. Ale to też może oznaczać, słuchaj Szymon, jedną rzecz, nie zaglądając nawet w artykuł, ale słysząc te liczby, że większość tych serwisów byłoby jak z Twitterem, można byłoby skasować i nikt by nie zauważył prawdopodobnie.
Szymon Warda: Albo po prostu były trzymane, albo były rzadko wykorzystane, albo po prostu działały w trybie utrzymania takiego totalnego, albo nawet nie utrzymania, tylko że coś z tego korzystało. Tak, jest to możliwe. Ale teraz idziemy dalej w tym artykule. Co zrobił Uber? Napisali własny tool do CD, Continuous Deployment. Moje pierwsze pytanie jest: po co? Naprawdę, to jest taka grupa narzędzi, gdzie naprawdę ciężko będzie odkryć coś nowego. Tam nie za bardzo… Ok, oni mają taki przypadek, że co oni robią, to jest mianowicie to, że mają monorepo i w tym monorepo po prostu wykrywają co się zmieniło i co na który serwis wpływa. Fajny feature faktycznie, żeby nie wrzucać zmiany we wszystkich serwisach. Sensowne, jak najbardziej. Tylko to można prostym pluginem albo nawet zmianą wykryć w istniejącym narzędziu do continuous deployment. Teraz jaki jest główny taki atut nowego narzędzia? Bardzo ładny interfejs, który daje podgląd w czasie rzeczywistym, co się właśnie dzieje. To jest opis. Ok, może ładnie to jest rzecz względna generalnie, ale podgląd co się dzieje w czasie rzeczywistym jest funkcjonalnością każdego narzędzia do CD.
Łukasz Kałużny: Czy wiesz co ja mam wrażenie, po prostu nie chcieli wziąć Spinnakera od Netflixa.
Szymon Warda: Ja nie wiem co się tam wydarzyło, ale teraz chwalą się, że dzięki temu prawie 70% serwisów jest wdrażanych automatycznie.
Łukasz Kałużny: Znaczy powiem Ci tak, wyciągając to pokazuje absurd konfiguracji tego.
Szymon Warda: Znaczy tam jest dużo absurdów, bo tam jest po pierwsze to, że zbudujmy własne narzędzie zawsze, bo mamy unikalny problem. Nie macie unikalnego problemu.
Łukasz Kałużny: Raczej jedyna rzecz, która jest, w której mają unikalny problem przy tej skali to jest coś, co jest gdzieś tam na trzecim diagramie, czyli to jest mapowanie sobie wersji serwisów, commitów i innych rzeczy, zbudowanie zależności, co jest zdeployowane.
Szymon Warda: Zgadza się. Przy czym też uważam, że nie jest to problem unikalny, że ktoś już się nad tym pochylał.
Łukasz Kałużny: Tak, Backstage od Spotify się… Dlatego wiesz, trochę powiedziałem, że to jest na zasadzie choroba, która jest bardzo często w szczególności w big techu: not invented here. Czyli musimy napisać coś od nowa, bo nie było tu wykryte i jesteśmy unikalni.
Szymon Warda: Tak, też było ogłoszenie, że TikTok zrobił narzędzie do zarządzania dużymi repo gitowymi, gdzie MS już to zrobił, gdzie inni też już to zrobili, to mamy kolejne narzędzie już.
Łukasz Kałużny: Gitowymi, ale słowo klucz: gitowymi.
Szymon Warda: Tak. No więc tak Łukasz, generalnie jednak okazało się, że 12 Factor Apps jest potrzebny, a my musimy w Protopii szukać klientów za granicą, bo okazuje się, że jest duża potrzeba na nasze usługi.
Łukasz Kałużny: Dobra, idziemy po 12 Factor Apps, to ode mnie link, bo trochę była dyskusja, że szydzimy i pewnie z tego zrobimy już dłuższy odcinek na Discordzie, na który zapraszamy, gdzie możecie z nami podyskutować. Padło pytanie, bo przy 12 Factory Appsie okazało się, że chwilę poszydziliśmy, że bazy danych robimy, żeby działały u developera i zwykle z tego szydzimy, a na produkcji bywa już z tym różnie, w szczególności z migracjami schematu. I tu jest dobry link świeżo zupdatowany, bo w momencie nagrywania sprzed tygodnia, na temat podejścia w jaki sposób dokonywać migracji kodu. Migracji z kodu, z automatyzacji schematu, żeby zrobić zero downtime deployment.
Szymon Warda: Na bazie danych.
Łukasz Kałużny: Na bazie danych, dokładnie i z aplikacją działającą w locie. Więc artykuł świetnie przedstawia takie podstawowe kroki, żeby zrozumieć to, w jaki sposób podchodzimy. Ja sądzę, że z tego nagramy w ogóle odcinek, bo to jest dobry temat, w szczególności rzecz kontrowersyjna, którą powiem, jak myślisz, że masz NoSQL-a i to Cię uchroni przed migracjami, to jesteś w taaakim błędzie. Oj, żyjesz w takim błędzie.
Szymon Warda: Tak. Ale wiesz co? Artykuł jest świetny, bo faktycznie jest, może zabrzmieć dziwnie, ale z ładnymi obrazkami i faktycznie bardzo fajnie to tłumaczy. Jakość jest naprawdę świetna.
Łukasz Kałużny: W szczególności są 4 przypadki, czyli nowa kolumna, usuwanie kolumny, zmienianie typu danych i rename’owanie tabeli, czyli 4 takie podstawowe. Powinno być jeszcze kasowanie kolumny.
Szymon Warda: Tabeli.
Łukasz Kałużny: Przepraszam, tabeli, jeszcze tabeli. Ale kto kasuje tabele?
Szymon Warda: Znam trochę ludzi, którzy kasują. Ale dobra, ale mnie bardziej zastanawia to, że kto potrzebuje aż tak realnego zero downtime migration? Bo artykuł jest fajny, chociaż można robić, to on na koniec pisze, że to nie jest trudne. Zgadza się, to nie jest trudne kodowo, bo tam wyzwań w kodzie nie ma żadnych. To jest super trudne jeżeli chodzi o organizację całości.
Łukasz Kałużny: Ale ja zawsze mówię, że zero downtime to problem dyscypliny.
Szymon Warda: Tak.
Łukasz Kałużny: Problem procesu i dyscypliny. Zobacz teraz, że jak ja mówię w trakcie konsultacji klientom: ok, to musicie zrobić release, który robi tylko migrację danych, przygotowanie schematu i dopiero potem, np. dzień po deployujecie sobie aplikacyjkę czy od razu deployujecie, ale macie 2 release’y w danym momencie, jak sobie na to popatrzymy, żeby potem załadować funkcjonalność. Czy że macie korzystać z feature flag w ten sposób, że te feature flagi po powiedzeniu, że działa, zaczynacie kasować. To jest w ogóle problem.
Szymon Warda: Znaczy, bo to jest, teraz nakład zarządczy wokół tego, żeby ogarnąć co, kiedy się dzieje, po jakim release’ie, nie wiem, release się przesunął, no życie się działo projektowe, jest naprawdę bardzo duże. Ilość i potencjał błędu i skala tego błędu też nagle bardzo, bardzo rośnie. Także fajny artykuł. Wydaje mi się, że to jest… Wydaje mi się, no widzę, że to realnie jest problem bardzo małej grupy projektów. Mój apel nie wrzucajmy sobie tego problemu na siłę, jak go nie mamy.
Łukasz Kałużny: Raczej to jest w ogóle z zero downtimem, ja zawsze pytam, czy on jest faktycznie potrzebny? I tak jak nie potrzebujesz Service Mesha, żeby robić canary release’y.
Szymon Warda: Zgadza się, jeszcze jest druga opcja. Pytanie jest, czy jesteście gotowi za niego zapłacić, bo będzie dużo kosztował. Dobra, kolejny link ode mnie. Całkiem ciekawe nowinki, bo właśnie mówimy odnośnie szkolenia z Open Telemetry. To co się wydarzyło? Open Telemetry właśnie przyjął do siebie Continuous Profiling, że cały czas widzimy, zbieramy telemetrię z aplikacji bez potrzeby instrumentacji kompletnie. Robimy to oczywiście przy wykorzystaniu filtrów eBPF-owych, czyli tylko Linux. I co się wydarzyło jeszcze? Elasticsearch dał swojego agenta, który to zbiera. Więc dużo się dzieje. Teraz tak, w kontekście trochę liczb, na czym polega i w ogóle jak działa cały właśnie Continuous Profiling? Mamy agenta, który właśnie korzysta z filtrów eBPF-owych i zbiera telemetrię aplikacji. Jakie są plusy? Ta aplikacja o tym nie wie, nie musi być modyfikowana, nie musimy wstrzykiwać kodu, ograniczeń mamy bardzo, bardzo niewiele, nie musimy mieć jakiś wysokich uprawnień, jak to bywa na przykład z agentami instalowanymi, możemy to włączać i wyłączać, dużo dobrego. Narzut CPU jest około 1%, niektórzy mówią 2,5, Pixie maksymalnie mówi, że 2,5, więc całkiem nieźle.
Łukasz Kałużny: Jest niezły. Dobra, to ja Cię z jedną rzeczą tylko poprawię.
Szymon Warda: Jeszcze jedna rzecz. Wsparcie dla języków jest automatyczne, natywne. Dużo lepiej działają języki niskopoziomowe typu C, Java z flagą Preserve Frame Pointer też dobrze wychodzi i możemy modyfikować biblioteki zewnętrzne i komunikaty zewnętrzne bez potrzeby, że one nie muszą spełniać instrumentacji. Więc brzmi nieźle. Mów teraz.
Łukasz Kałużny: Sprawdzając nawet 4 godziny temu był commit do eBPF for Windows.
Szymon Warda: Wiesz co Łukasz? Chyba tak samo jak Docker for Windows, tylko w kontekście kontenerów windowsowych.
Łukasz Kałużny: Wiesz co, tutaj powiem Ci tak, to jest inna rzecz, bo z założenia powinien być ten sam bytecode co dla.. Nawet w FAQ-u jest o to pytanie: does this provide app compatibility with eBPF programs written for Linux? The intent is to provide source code compatibility for code that uses common hooks and helpers that apply across OS ecosystem. No właśnie, więc zobaczymy jak to będzie.
Szymon Warda: Sorry, nie widzę adopcji tego tak naprawdę. Druga sprawa jaka tam weszła, to powstał SIG, czyli Special Interest Group, który ma opracować podejście do Continuous Profiling i Open Telemetry w kontekście tego jak ma wyglądać uniwersalny model zbierania i zapisu danych, połączenie właśnie Open Telemetry Agenta, który obecnie istnieje właśnie z agentem do zbierania Continuous Profiling i w ogóle połączenie tego całego systemu. Wiadomości ciekawe. Pod tym linkiem, ja się nie zgadzam z tym, że samo Open Telemetry nie daje wartości, bo to tak nie jest. Continuous Profiling jest fajny, ale to jest jak picie z hydrantu. Tam jest dość dużo rzeczy i to jest bardziej do mierzenia wydajności. Open Telemetry jako taki jest do monitoringu. Monitoring a mierzenie wydajności czy profilowania aplikacji to nie jest to samo i są inne przypadki użycia.
Łukasz Kałużny: Wiesz co, raczej chcę, żeby powiedzieć może wprost, to jest kierunek w tym, żeby dało się zrobić uniwersalne źródło danych pod APM-y?
Szymon Warda: Zgadza się. Ciekawi mnie w tym momencie to, jakie wartości w tym momencie, jakie będzie value added takiego Dynatrace’a, New Relica, itd. Bo będzie znacząco niższa.
Łukasz Kałużny: Wiesz co, obstawiam, że ich modele ML-owe, które będą potrafiły zrobić korelacje i inne rzeczy, rzeczy, których nie masz po prostu w opensource, które wymagały datasetów i know how.
Szymon Warda: Ok, jeszcze może być załóżmy wsparcie dodatkowych języków, bo te języki po prostu… Trzeba zinterpretować to, co się dzieje na poziomie ML-a.
Łukasz Kałużny: Raczej wiesz, pytanie czy nie pójdzie to, że część rzeczy zacznie się pojawiać, czy może przypadkiem jak wiesz, jak już wchodzimy w Continuous Profiling na razie na takich a nie innych poziomach, ale czy gdzieś Zero Auto-Instrumentation nie zacznie się pojawiać w danych streamach, takie znane z APM’ów. Bo wiesz, zobacz, w jednym z newsów jest to, że np. Splang oddał swój silnik do Continuous Profilera, do .Netu np.
Szymon Warda: A to mi uciekło. To jest niezłe. Dzieje się dużo. Moje takie ostrzeżenie do wszystkich to jest to, że to nie jest znowu ten nasz srebrny pocisk i to nie załatwi wszystkiego. Chociażby dlatego np., że Pixie zbiera ten Open Telemetry z Continuous Profiling, zbiera do 24 godzin, bo tych danych jest naprawdę dużo. To nie jest tak, że sobie włączymy i będzie fajnie. Wydaje mi się to może skończyć się na tym samym, że zapomnimy o tym, że aplikację trzeba instrumentować i będzie Continuous Profiling, żeby uratować wszystko.
Łukasz Kałużny: Wiesz co, Continuous Profiling jest po to, żeby troubleshootować, trzeba to zaakceptować, ewentualnie widzieć na żywo co się paprze, a potem kasować te dane po kilkunastu godzinach.
Szymon Warda: Łukasz, my to wiemy. Mnie bardziej martwi co rynek zrobi i jak marketing pójdzie wokół tego wszystkiego.
Łukasz Kałużny: Wszystkie logi są nam potrzebne.
Szymon Warda: Oczywiście, że są potrzebne i oczywiście płacisz per gigabajt logów. Dobrze, nie marudzimy dalej. Śmigasz, co masz?
Łukasz Kałużny: Nie, nie marudzimy, marudzimy jeszcze bardziej, czyli z życia konsultanta w Protopii. To jest rzecz, którą często mi się zdarza z klientami robić, czyli proof of concept, czyli dowiedzenie sobie, że coś zadziała, coś nie. Jakbym miał przekazać dwie najważniejsze rzeczy, jeżeli chodzi o POC, to pierwsze to są założenia. Czyli wyznaczenie, jeżeli coś testujemy, to nie, że robimy POC, tylko formułujemy tezy, na które ma odpowiedzieć. Czyli jak np. czy dana technologia pozwala zrobić XYZ, którego potrzebujemy? Jakie ma ograniczenia? Może jakieś performance’owe testy? Określamy, co my potrzebujemy. I teraz bardzo ważna rzecz, która jest kolejna, POC kończy się sukcesem, jeżeli odpowiedzieliśmy na pytania.
Szymon Warda: Wiesz co, ja to swego czasu nazywałem generalnie POT, nie jest sexy, ale mimo wszystko, bo to jest proof of technology tak naprawdę.
Łukasz Kałużny: Tak, bo to jest przykład, do którego sobie referuję z ostatnich tygodni.
Szymon Warda: Wiem, do którego.
Łukasz Kałużny: Ty wiesz, ja tutaj nie mogę akurat zdradzić aż takich detali, ale tam było powiedzenie sobie właśnie tak czy ten koncept zadziała z tą technologią. Dlatego z jednej strony tak, te proof of technology ma gdzieś smaczek, bo zwykle sprawdzamy, czy jesteśmy zrobić albo właśnie czy dany koncept, jak idziemy w słownik, czy dany koncept zadziała.
Szymon Warda: Tak, dokładnie, bo to jest takie dość ważne, bo POC to jest bardziej właśnie ten taki biznesowy element. Moja rekomendacja jest taka, że w POC musi być POT, jeżeli wybieramy coś, czego nie znamy.
Łukasz Kałużny: Tak. I kolejnym elementem, który jest bo powiedziałem właśnie, że pacjent zmarł i operacja się udała, ponieważ wykonaliśmy procedurę od A do Z, to pacjent był słaby, nie przeżył. I tak trzeba na to troszeczkę bezdusznie popatrzeć. I największą wadą, jaką robimy w POC, to jest przywiązanie na siłę do technologii, że boimy się ją odrzucić.
Szymon Warda: Tak, że jak tu teraz, tą technologię, która tak ładnie brzmi, tak ładnie była opisywana, wpakować nogą, ręką albo jeszcze jakimś długim kijem do tego, co…
Łukasz Kałużny: Totalnie nie ma sensu. I to jest tak jak sobie popatrzycie, to pewnie jeszcze w paru shortach padnie tabula rasa w najbliższym czasie, ale dobrze podejść to i wyrzucić technologię i zastanowić się. To tak jak z dobrym POC jest jak z dobrym ADR, rozważa konsekwencje i inne opcje, które są, więc można powiedzieć, że POC to są realne testy ADR-a. Do odcinka, do ADR-ów zapraszamy, kiedyś taki popełniliśmy. Więc to takie moje narzekanie, że nie przywiązujmy się za bardzo do technologii przy POC-ach albo zmieńmy architekturę, jeżeli coś nie spełnia wymagań, a chcemy koniecznie skorzystać z tej technologii, co uważam czasami za głupotę, akurat upieranie się tak na siłę.
Szymon Warda: To mamy psychologii trochę.
Łukasz Kałużny: Tak, tak, ja wiem.
Szymon Warda: Powinniśmy zmienić zdanie.
Łukasz Kałużny: Tak, ja zdaję sobie sprawę, że to jest kontekst psychologiczny. Druga, że jak wdrożyliśmy cokolwiek, już uważamy, że to prawie produkcja. Przecież jest dowcip, że jak POC zadziałało, to już jest w sumie produkcją.
Szymon Warda: Patrząc po tym, jak Uber wdraża swoje serwisy, to można powiedzieć, że właściwie jest.
Łukasz Kałużny: Idealnie. Dobra.
Szymon Warda: Dobrze, to teraz lecę, bardziej z ciekawostek. Amazon Aurora Serverless, czyli baza danych relacyjna, która jest zgodna z MySQL-em i Postgress-em. Link pewnie widziałeś, ale co mnie zaciekawiło w tym linku? Link opisuje drugą wersję, co się zmieniło, itd. Ale pierwsza rzecz, która mnie zaciekawiła, to był fakt, że cała Amazon Aurora Serverless chodzi na około 10 000 node’ów. To jest mało.
Łukasz Kałużny: Jak na całość.
Szymon Warda: Przy skali AWS-a, itd., to jest naprawdę mało.
Łukasz Kałużny: Czyżby tak mało osób z tego korzystało?
Szymon Warda: No na to wygląda tak naprawdę.
Łukasz Kałużny: Bo wiesz, pytanie teraz jest, jak wygląda, też realne… Trzeba byłoby porozmawiać, może kogoś ściągnąć przy okazji omawiania re:Inventa i zapytać się jak wygląda popularność tych usług tak realnie, realnie. I też dajcie znać, czy w ogóle, jeżeli korzystacie z AWS-a, to jak u Was z Aurorą? I czy korzystacie z niej w wersji serverlessowej?
Szymon Warda: Ale co się tam zmieniło? Bo to umówmy, że to taka ciekawostka, że to faktycznie tak przy okazji wyszło. Co się zmieniło? Zmieniło się parę rzeczy. Wyszła wersja 2.0 i Aurora ma inną fajną feature, że umie się migrować między hostami, jeżeli się skalujemy. Okazało się, że 99,98% zdarzeń, które powodują skalowanie, mogą być obsłużone w formie skalowania wertykalnego, czyli zwiększenia ile jest przypisanych zasobów do konkretnej instancji na hoście. Czyli nie musimy przenosić instancji między hostami. To fajnie wygląda. I skupili się bardziej na tym właśnie jak zarządzać i jak optymalizować zużycie pamięci. Głównie tu chodzi o pamięć, baza danych, więc chodzi o pamięć głównie, bo one po prostu lubią tyle RAM-u, ile tylko mogą w kontekście właśnie hosta. Artykuł fajnie opisuje co tam w ogóle się dzieje, jakie są zmiany, więc jeżeli ktoś korzysta, okazuje się, że takich ludzi może być niewiele, z Aurory, to można by rzucić okiem i dowiedzieć się, co tam się wydarzyło i jak to działa. Bo ogólnie warto rzucić okiem i rozumieć jak usługa działa.
Łukasz Kałużny: Tak, z taką ciekawostką, która jest, że pozbyli się tam częściowo tego proxy.
Szymon Warda: Tam jest coś, fajnie to opisali.
Łukasz Kałużny: Tak, jest dużo takich detali i smaczków, które wynikają z tego. Sporo czytania, bo 13 stron, dość sporo tekstu wrzucone i trzeba chwilę się zastanowić nad tym co i jak to wygląda. Dość sporo detali pokazują takich pod spodem.
Szymon Warda: Taki faktyczny papier, czyli faktycznie publikacja taka quasi-naukowa, bym powiedział, więc dobry bardzo wpis. Dla osób, które korzystają z Aurory, zdecydowanie wydaje mi się, że obowiązkowy.
Łukasz Kałużny: Dobra, to jak jesteśmy przy bazach danych to chodźmy do SQLite’a.
Szymon Warda: Idźmy.
Łukasz Kałużny: Idźmy. Słuchajcie i co jest ciekawego? Team od SQLite’a zaczyna przygotowywać tool do replikacji SQLite’a. I teraz co będzie? Będzie pozwalało zrobić w locie snapshoty, które nie będą blokowały bazy i będą pozwalały na odczyty i zapisy w trakcie.
Szymon Warda: To jest ciekawe. To jest naprawdę ciekawe, bo to by umożliwiło dość ciekawe scenariusze, jeżeli chodzi o rozkład tej bazy i użycie SQLite’a jako bazy pamięciowej.
Łukasz Kałużny: Raczej tutaj zaczyna się robić ciekawie z tym jak sobie popatrzysz. W szczególności, że wydajność SQLite’a, jak to działa in process, jest coraz bardziej. No i fakt, oparli to… Widać co już będzie, są dwie rzeczy, bo po prostu będą wykorzystywać WAL-a do tego, write-ahead logging, które jest możliwe do skonfigurowania. Więc obie bazy będą musiały, które będziemy replikować, muszą używać właśnie WAL-a i ten sam rozmiar strony. Czyli pewnie bardzo mocno poszli low levelowo na page’ach i potem na scalaniu tego przy przenoszeniu snapshota, ale nadal jest to mega jak sobie popatrzysz.
Szymon Warda: Tak, ale jeszcze nie ma opublikowanej daty kiedy.
Łukasz Kałużny: Dopiero się to zaczęło, ale jest to ciekawy news. O tak.
Szymon Warda: Jestem bardzo ciekawy co ich skłoniło do tego ruchu, bo to się musiało skądś wziąć, w sensie jakieś konkretne użycie i coś się musiało zadziać po prostu. Ok, dobra informacja, ciekawa, jestem ciekaw gdzie to dalej pójdzie.
Łukasz Kałużny: Dobra i ciekawostka z Terraforma, ze świata terraformowego. Tego nienawidzę, czasem jak trafiam. Mówi się, że mamy unit testy i inne rzeczy i że ten cały kod powinniśmy trzymać dyscyplinę pisania i w ogóle. No i pojawił się taki fajny bug w providerze do Azure’a utrzymywany przez HashiCorpa. To jest provider trzymany nie przez Microsoft, tylko przez HashiCorpa, to jest ważne, ten Azure natywny, terraformowy. To przy upgradzie, teraz była taka duża wymiana terraforma w providerze właśnie azurowym na linii 3 na 4. I to jest przypadek też z życia, do 4.2 wszystko działa. I nagle pokazuje się w terraformie 4.3, nikt tego nie przetestował, pewna pierdoła, która mianowicie odpowiada za przepinanie w Azure subskrypcji pomiędzy management grupami. Czyli żeby ustawić automatycznie z kodu gdzieś w drzewku tą naszą subskrypcję i przypiąć ją w odpowiednią część organizacji, management grupę. I co się okazało? Tak zrobili update SDK, że leciał error parsing the subscription ID the number of segment didn’t match, czyli nie łykał w ogóle poprawnie po update’cie SDK, które zrobili pod spodem. Nikt tego nie testował i nie łykało w ogóle, nie zrobili migracji pod spodem automatycznej i nie łykało w ogóle właściwych formatów, ani starego, ani nowego.
Szymon Warda: No powiem, że grubo, bym powiedział, że jest plus, że już naprawiony, że zamknięty, może tak.
Łukasz Kałużny: Nie, wiesz co, będę testował, bo akurat dzisiaj sprawdzałem, czy muszę to wreszcie w jednym miejscu odblokować, auto podbijanie terraforma. Ale zaczęło się od 20 września, a merge poszedł… Gdzie tutaj jest merge’yk… Last month. Aż sobie zobaczę kiedy poleciał. Niby dwa tygodnie temu około.
Szymon Warda: Ciekawie to wygląda. Może Łukasz w takim razie Open Tofu?
Łukasz Kałużny: Ale tam jest ten sam provider.
Szymon Warda: Można potrollować, to można potrollować, to zawsze jest jakaś opcja.
Łukasz Kałużny: Strollował, ale zostawię to sobie na następnego shorta, trollowanie na temat terraforma.
Szymon Warda: Dobrze niech będzie. To co, kończymy chyba?
Łukasz Kałużny: Kończymy. Trzymajcie się.
Szymon Warda: Na razie.