Z życia Protopii - gdzie hostować postgresa?

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.

Żeby klient nie manipulował, a może nawet my też nie manipulowali. I potem do tych kryteriów była ocena każdej z usługi i potem była suma ważona, która usługa wygrywa. I to wyszło. Czemu? No operujmy na liczbach tam, gdzie możemy i tak dalej. Spędrogą jest odcinek, kiedy Łukasz mi się nie wcina co za sukces. Znaczy, wiesz, tutaj nie mam co się... inaczej. Zauważ, że jak dyskutowaliśmy, sam ci powiedziałem, że trzeba rozborować Cloud Native PG mocno. Tak, jest dobre. Znaczy, odrzuciliśmy w ogóle, jest drugi operator od... Boże, z Zalando wywróciliśmy. Od Zalando, tak. Zalando, no niestety, Cloud Native PG przebiło, tak. Inaczej, osoby, które były u mnie na szkoleniach, to jest istotna rzecz, bądź słuchały starych odcinków,