FinOps: optymalizacja kosztów chmury publicznej AWS i Azure

Koszty chmury: nielimitowane możliwości kontra faktura

Nierzadko biznes, zachwycony elastycznością infrastruktury chmurowej, podchodzi do zarządzania kosztami zbyt swobodnie - w szczególności zaraz po wstępnym przeniesieniu serwerowni w skali 1:1, czyli modelu techniki Lift and Shift. Efektem są niekiedy dość szokujące, narastające kwoty spływające od gigantów na wystawianych comiesięcznie rachunkach z wektorów dla kosztów uruchomieniowych (Compute EC2), powalających stawek eksportu pasma w chmurze (Bandwidth Out) czy choćby niewymiarowych opłat za relacyjne silniki w archiwach pod tworzony rygorystyczny Snapshot dla baz danych.

Określenie tak zwanego Całkowitego Kosztu Posiadania i procesu samego kosztu migracji do chmury (TCO) wyznaczane przez same podmioty handlowo-biznesowe (zarządy i asystentów), bardzo mocno polega wyłącznie na zderzeniu rynkowym modeli wydawania pieniędzy w tzw "rozliczeniu na rzecz posiadania lub wynajęcia" - gdzie w pierwszym ujęciu serwer on-prem amortizuje gwałtownym opadem wydatków model zakupów (CAPEX), by wynajem i utylizacja skrawków dysku i potępionych na sekundy usług przez ułamki czasu na korzyść rozproszenia na planecie operacyjnej przełożyć w tzw raty operacyjne bez konieczności zakupowej jako (OPEX). Często jednak poleganie na internetowych kalendarzach u twórców do wycen estymowanych usług o chmurę w bezwzględnym zderzeniu i bez doświadczonego inżyniera architektury po stronie podmiotu do zderzeń na pokładzie wykazuje mocno naciągane na "zaniżenia kwot do OPEXu" na papierze. Niestety brak optymalizacji to potężne pęczniejące portfele na rachunku (np gdy maszyna pod firmą staje po nieudolnym zakotwiczeniu obciążona w weekend z braku uśpienia środowisk), a firma poszukuje w panicznym biegu możliwości natychmiastowego opanowania procedur do rewaluowania audytów o optymalizacji kosztów środowiska chmurowej.

Złote zasady FinOps na ratunek inwestorom

Działania opiewające na procesie z kategorii jaką jawi Optymalizacja kosztów chmury (FinOps) w skali korporacyjnej u głównych Cloud Providerów, do tak wdrożonego organizmu od strony eksperckich inżynierów certyfikowanych w ramach m.in np Architektów AWS od PSLAB przynoszą wymierne oddziaływania już po wstępnych analizach wyliczeń z usług do logowań audytowanych u producentów z rachunku (np Cost Management Platform z AWS z CloudTrail).

Tak ukierunkowany rzut wykwalifikowanej załogi u inżynierów sprawnie zdejmuje i zrzuca nadwagi kosztorysów od kwot ~10 a wielokrotnie i wyżej poza granicami 28-35% przez zaprzęgnięcie podstawowej standaryzacji o higienę:

1. Right-sizing (racjonalny dobór wielkości i ułożenia instancji) - sytuacje po migracjach bywają naznaczone zjawiskami kupowaniu mocy pod mityczny zapas - maszyny klasy Dev stają w 90% niezagospodarowane z przepalonym obciążaniem rachunków pod CPU leżącego "do góry brzuchami" całą noc w niedzielę. Nasi audytorzy sprawnie lokalizują uśpione przestery z tzw: brakiem aktywności "idle", usypiają i redukują ich wymiary.
2. Wyciszanie nadprogramowych tworów (Zombie resources) - niedopięte do balanserów IP ze strefą po zapomnianych testach z brakiem powiadomień, lub martwe obciążone strefy na dyskach po wycofanym kodzie po programistach. Przepalając te pieniądze miesiącami płacisz gigantom. Proces wprowadzania tzw "Tagowania resourców" w zespole z oznaczaniem portfela zapobiega masowym wypływom gotówki z firmy!
3. Wykorzystywanie i negocjowanie rabatów (Reserved / Savings Plan AWS) - Gdy usługa twojej firmy na instancji produkcyjnej gwarantuje ci potrzebę płaskiej nieprzerwalnej funkcji pod wymóg systemu (np do uruchamiania bazy SQL) obiektywnie można przy założeniach odblokować tzw roczne do ~3 letniego przyrzeczenia by zmniejszyć zadeklarowane zasoby kosztorysowe o wywindowane ułamki rzędu na zjawisku nawet do 70% redukcji kwot subskrypcyjnych.

Modernizacja i głęboki refaktoring architektoniczny chmury

Błędnym przekonaniem okazuje się przełożenie serwera maszyny tzw MS Windows jeden-do-jednego za on-prem rzucając architekturę systemem po maszynach na wycięciach stref Vm w celu minimalizowaniu kwot i redukcji kosztów ze wstycznym mianem Lift&Shift bez dalszych zabiegów ubezpieczenia.

Zabiegami po wejściowych rzutach do usług ujęte działania u audytorów to w m.in ewaluacje u projektów deweloperskich wprowadzanie po zaawansowanej metodyce z udziałem (Refactoring Architecture) przy dziedzinie rozwijania skalowanych mikrousług na oprogramowaniach korporacyjnych. Zabiegi wprowadzają logikę bez serwera pod rzutami u usługi zwane Serverless (np AWS Lambdy na obciążeniem fakturowych dopiero od zdarzeń z akcją powołaną od mikro-sekund bez opłat na nasłuch). Do kolejnych genialnych zabiegów używa się instancji chmurowych operujących potężnymi obciążeniami pod logikach dla wozów klastrów orkiestrujących (np do środowisk Kubernetes) osadzonych i balansowanych natywnymi usługami ze zdolnościami giełdowymi rynku AWS tj Spot Instances. Kosztują o ~90% progu mniej, stąd zaprzęgnięte np po system CI/CD do budowy aplikacji od devops tną kwoty diametralnie rzędu groszy dziennie w potęgach przeliczeniowych a zarząd cieszy się odblokowanym budżetem.