Z życia Protopii - gdzie hostować postgresa?

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.

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.

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.