Rok ten był głównie pod znakiem ślepych zaułków ucinanych przez Cost-Explorera, gdybym tylko długość reki mnie do niego dopuścili…., a to kilka najciekawszych wniosków z podróży po nich:
Stack Thanosa – bardzo spodobała mi się jego architektura i możliwości skalowania każdego najmniejszego elementu* – oprócz procesu kompresji i downsampling(no akurat to co najważniejsze). A największą motywacją do przejścia na thanosa była dla mnie możliwość integracji z S3 i operowaniu na nim.
Niestety i ostatecznie, przejście z prometheusza na thanosa było do nie zaakceptowania przez koszty, bo te samo przetwarzanie metryk wychodziło kilka krotnie drożej w thanosie, a główny kosztem który pogrążał thanosa była ilość generowanych zapytań do S3(long storage). Niech żyje Promethuesz!
Migracja Docker swarm do EKS – historia podobna jak z thanosiem, bo ostatecznie misja rozbiła sie o koszt utrzymania. Zmiana orkiestratora z swarma na k8s zwiększała koszty utrzymania tego samego o ponad trzy razy i karpenter nie był tutaj rozwiązaniem. Więc po co zmieniać znanego wroga(orkiestratora), wychowanego na własnej krwi i pocie, jeszcze za tyle monet. Ostatecznie w temacie nie zapadła klamka bo zostało mi do sprawdzenia konfiguracja z prefix mode, o której dopiero niedawno się dowiedziałem, możliwe ze dostosowanie tego zmieni ten czarny scenariusz z eks.
EKS vs self-hosted k8s – po postawieniu k8s samemu człowiek zaczyna rozumieć, że koszt tego jaki jest ukryty w usłudze serverless EKS nie jest aż tak duży do ilości prac jakie trzeba wykonać samemu. Jedynym sensownym wytłumaczeniem jakie widzę na ten moment do utrzymywania tego samego jest ominięcie wymuszonych aktualizacji klastra eks lub ogólnej pogardy do rzeczy związanych aws cni.
Teleport vs AWS SSM – Teleport używa fajnych funkcji TLS o którym nie byłem świadomy do tej pory, robi to samo co ssm, ale za to ładniej wygląda i przyjemniej sie tym zarządza jako klaster i klastry, a i najważniejsze, omija koszt z ssm poza AWS. Ale niestety odbiłem sie od ściany przy stabilnym utrzymaniu tego co chce przez ALB używając haku „Connection: Upgrade”, a logi jego były mało pomocne, gorsze od staków javy. No więć kolejna piękna perełka, która czeka na dojrzenie w moim archiwum X 🙂
Terraform nadal w 2024 moim najlepszym przyjacielem – próbowałem go zastąpić pulumi w go, ale nadal struktura kodu terraforma jest dla mnie bardziej czytelna i przekonująca. Za to bardzo ciekawie rozwija się ostatnio cloudformation, mam nadzieję ze hashicorp pójdzie tą samą ścieżką i zrobi podobny output/front przy apply.
Budowania cache w kodzie mikroserwisu – to podstawa i powinno być 11 przykazaniem. Ciągłe odpytywanie o te same rzeczy przez ALB prowadzi tylko do dużego rachunku lub niekończącym dorzucaniu dolarów do usług serverlessowych niewspółmiernym z zwiększaniu skali przedsięwzięcia.
Dbaj o swojego Postgres jak o żonę swoją – może już oklepane, ale dobrze dobrane parametry postgresa potrafią zdziałać cuda i nawet zlikwidować 95% zapisu – 2Gb/s. Diabeł tkwi szczegółach, a nie w zasobach zfs.
Incydenty miedzy 15:00 – 15:30 to zawsze były problemy u klienta, najczęściej była to szybka aktualizacja firewall do poprawienie dobrego samopoczucia przed pójściem do domu i malowania obrazów.
EOT
Szczęśliwego nowego roku 🙂
Niech 2025 przyniesie nam więcej bezawaryjnych dyżurów, logów bez błędów i aby obfitował jeszcze więcej wyzwań!