Z życia Protopii - gdzie hostować postgresa?

Jakbyś nadał temu w ogóle cały kontekst całej sytuacji. Jasne. Powiedzmy sobie, to jest temat, który się dział połowa zeszłego roku. To jest dość ważne jeżeli chodzi o też decyzje jakie były i też pochwaląc się jak słuszne decyzje podjęliśmy. Ale zobaczycie o co chodzi. Jak jest kontekst? Mówimy o dużym kliencie. Nie będziemy tu go nazywali. Który rozważał naprawdę dużą, taką bardzo znaczą skalę dla przechowywania danych. Mówimy tutaj o dziesiątkach terabajtów. Wcześniej rozmawialiśmy z tym klientem, jak to w ogóle na poziomie architektury rozwiązać, jak na poziomie hostowania, a potem nasz temat, ok, skoro już wiemy, że będziemy to trzymali w postgresie, wiemy więc, jak to będzie wyglądało, jak to podzielimy, jak będziemy obsługiwali skalę i tak dalej, to w takim razie, gdzie to w ogóle trzymać?

Będą ważne i zarządzanie kosztami. Musimy to być tanie, ale musimy umieć zarządzać kosztami, bo będziemy trzymać dane relatywnie długo. No nie, a nawet gdyby nie, no to terabajty. Dalej. Więc jak mówimy o kosztach, to bardzo prosta opcja, bo mowa o postgresie. Table Spaces. Możliwość przechowywania różnej świeżości bazy danych, bo akurat usługa jest tak zbudowana, że dane starsze są dużo rzadziej odpytywane. Więc zależałoby, żeby mieć dane świeże na dyskach lepszych, a potem idziemy degradacja jakości, czy też może wolniejsze dyski im dalej jesteśmy w czasie. Jak najbardziej tutaj sprawdzałoby się super. Wysoka dostępność, dlatego że w czasie, kiedy usługa jest potrzebna, jest naprawdę realnie potrzebna. To tutaj nie ma dyskusji, ona po prostu musi w pewnych momentach dnia działać, koniec, kropka. Kolejna opcja to jest to, co tam wyszło, ciekawa właśnie rzecz tam wyszła, w kontekście rozmowy z osobami, które by to utrzymywały, prowadziły dowódcami, że OAuth jest bardzo dla nich ważny, bo zarządzanie hasłami, dostępami w tej ilości serwisów jest...

Już obecnie z morą. To nie było początkowo zwerbalizowane kompletnie, ale okazało się, że OAuth jest kluczowym tu elementem. Co było ważne w momencie, jak to robiliśmy, wtedy jeszcze postgres nie wspierał w pełni. I ostatnie, które nam wyszło, które było naszym rekomendacjom bardzo mocno, to jest replikacja wieloregionowa albo możliwość generalnie odtworzenia się w wielu regionach potencjalnie, no bo duże dane, jeszcze moc obliczeniowe, tutaj element jakby region pat albo co były czkawka, no to nie zatrzymałem biznesu. Tak, lecz ostatnim elementem, z racji na niewielki zbiór zespołu, była coś monitorowania. Po prostu, żeby z tym się żyło prosto. To nie jest firma, która kręci się wokół bazy danych, firma, która robi biznes na czymś zupełnie innym. Dobra. I mamy taki zestaw. Też go prezentujemy, jak to wygląda, mówimy, co będziemy oceniali.

Klient mówi, tak, zgadza się, czasami się zaskoczą. No to co? Idziemy przez to, co w ogóle omawialiśmy. Łukasza rozbawiłem. Wiem, co będziesz omawiał, więc dobra. Tak, wiem, co będziesz omawiał. Pierwsza rzecz, która w ogóle poszła przy tej skali i to jest nasz element, gdzie się ucieszyliśmy, że generalnie nie, to oczywiście jest Cosmos Digi for Postgres. A czemu się ucieszyliśmy? Bo jak tą analizę pisaliśmy, to on był jeszcze okej. Teraz już jest usługą wycofywaną. Na papierze ta usługa wygląda świetnie pod ten problem, ale tylko na papierze, jak się wchodzi w detal, to to partycenowanie, które jest narzucone i tak dalej, tak dalej, tak dalej, nie do końca i brak wsparcia do Table Spaces, totalnie tego nie miało sensu. Kosztowo?

Jak mamy takie usługi właśnie, gdzie mamy replikację, możemy z punktu widzenia postgresa zrobić, na przykład, do innej usługi, do innego postgresa, tam też tego nie ma. Sam sharding fajnie, kosztowo średnio i możliwość, też granularność zasobów, które można było dobierać, średnio to wyglądało bardzo mocno. Dlatego kompletnie nie. Najlepszym konkurentem w tym momencie chmurowym wchodził Flexible Server for Postgres. Tam kilka rzeczy naprawdę było fajnych. Przede wszystkim zarządzana usługa, małe opsy. To było to, że... Jeszcze, jak to rozważaliśmy, nie było oAufa, który miał się pojawić w wersji 18, więc to bardzo fajne. Skalowanie, które miało być tam near zero downtime, czyli poniżej 30 sekund, fajnie.

I można było konfigurować logiczną replikację pomiędzy nawet różnymi bazami, przez poziom postgresa jako takiego. Więc tam było kilka elementów, które były fajne. Z bardzo dużych minusów, no to brak table spaces. Sorry, kosztowo, długofalowo, niekoniecznie. Tam jeszcze są ograniczenia odnośnie tego, co możemy włączyć, komponenty, pluginy i tak dalej, ale do przeżycia. Lista pluginów jest inaczej. W tym przypadku była sobie do przeżycia. Ona jest imponująca i cały czas wszystkim rosła. To było bardzo ważne i widać było, że Microsoft to rozszerza, rozszerza, rozszerza. Więc tam było tego dużo. Przy tej skali trzeba sobie powiedzieć znowu, backupy Realne, prawdziwe, inaczej, bo teraz powiedzmy sobie, jeżeli masz disaster recovery, to być może chciałbyś się odtworzyć poza tą chmurą i wyciągnąć te backupy.

Zaczył klient, korzystał już generalnie, miał wydarzony jakąś próbę z Cloud Native PG na AKS-ie. No i jak to teraz tam wyglądało? Bo kilka elementów było fajnych. Po pierwsze, table spaces, czyli możemy sobie rozłożyć, czemu doskonale wiemy. Elastyczność? Spoko. Możemy też mieć granularność, jeżeli chodzi o zasoby, compute, tak dalej, tak dalej. Jeszcze wróćmy na chwilę do Flexible Server. Tam była niezła ta granularność, można było całkiem fajne rzeczy wybierać, jednak znowu granularność na poziomie dysków mogłaby być trochę lepsza, że tak powiem, no nie? Nie było to super, zdecydowanie sam AKS siebie daje dużo, dużo więcej. Tak, jeżeli chodzi o narzut utrzymywania na Cloud ATV PG, on wbrew pozorom nie wyszedł tak bardzo dużo większy. Dużo ta usługa robi sama z siebie, jeżeli chodzi o monitorowanie.

Inaczej, teraz trzeba sobie tylko jeden element powiedzieć, żeby inaczej, w porównaniu do tych scenariuszy te Cloud Native PG, inaczej, tak jest zajebiste, to trzeba bez dwóch zdań. Przy tej skali jest i tak narzut operacyjny, który jest duży na przykład z upgradami. To będzie, i to jest chyba największy ból tyłka tego całego rozwiązania. Jest, chociaż nad tymi upgrade'ami też pracują, one też się zmieniają, bo faktycznie on umie robić te rolling update'y i tak dalej. Tam faktycznie zmieniło się dość dużo i widać, że nakład na to jest. Więc też był nakład. Największy minus też to było to, wersja, którą rozważaliśmy, niewspierany był postgres 18, więc przez to opcji na OAuth nie było jeszcze, a miał być, że tak powiem. Więc finalnie, na czym się w ogóle skończyło?

Skończyło się właśnie na operatorze. Zdecydowanie przy tej skali opcje wyjścia koszty operacyjne niewiele wyższe. Jak policzyliśmy to kosztowo, powiedzmy, bo jak to wytwarzaliśmy? Tu i teraz co robić? Co robić za trzy do sześciu miesięcy? I skala na rok, bo to są zupełnie inne skale jak to będzie wyglądało. No po wszystkim, bo to co mówiliśmy nawet w wielu odcinkach, budujemy kompetencje, czyli to co wybieramy na trzy do sześciu miesięcy to jest okno, kiedy budujemy kompetencje, możemy coś zmienić, przygotowujemy się do zmiany i potem długofalowy na to z czym my docelowo chcemy żyć. I wyszło, że w ogóle bez myślenia. Cloud Native PG jako długofalowy to jest ten wybór słuszny. Kosztowo się spina i tutaj nawet daje miejsce na kilka etatów. Krótkofalowo, flexible server może, ale jak już klient ruszył z Client FPG, nie było to sensu, więc został na Client FPG, tylko tam jeszcze z sugestiami, jak to zrobić właśnie w kontekście disaster recovery, w kontekście HA i takie drobne zmiany, jeżeli chodzi właśnie o jak sobie poradzić z poaufem do czasu wyjścia wersji 18 i tak dalej i tak dalej.