Chmura to nie on-premise
Inżynierowie tworząc architekturę i powołując nowe zasoby w chmurze w sposób niejawny podejmują decyzje zakupowe. Czasem wielokrotnie wciągu jednego dnia! Każda z nich ma wpływ na wielkość rachunku wystawionego na koniec miesiąca przez dostawcę chmury publicznej. Dla organizacji z długą historią jest to zupełnie nowa rzeczywistość. Działom finansowym trudno odnaleźć się w sytuacji, gdzie nie ma długofalowego planowania zakup sprzętu i licencji dla działów IT. W następstwie tego osoby kontrolujące wydatki ponoszone na IT stanęły przed nowym wyzwaniem, którego kiedyś po prostu nie było. W modelu on-premise nikt nie mógł przekroczyć budżetu po realizacji zamówienia. Bez względu na to jak używane były serwery ich koszt operacyjny był z góry znany i przede wszystkim stały.
Elastyczność chmury zmieniła zasady gry. Zakupy realizowane są w ciągu sekund, natomiast koszty zmieniają się w czasie rzeczywistym w odpowiedzi na bieżące użycie.
Za zmianą technologii podążają zmiany w praktykach
Budowa rozwiązań cloud-native uczyniła capacity planing przestarzałym, a zmiany w technologii spowodowały rozwój nowych praktyk zarówno na poziomie inżynierii rozwiązań jak i zarządczym.
Truizmem będzie stwierdzenie, że każdy problem w IT można rozwiązać na wiele sposobów. Architektura opisuje te rozwiązania. Każdy doświadczony architekt przyzna, że architektura to sztuka kompromisów. Jednak podobnie jak w przypadku bezpieczeństwa, tak w temacie kosztów ciężko zgodzić się na daleko idące ustępstwa.
Do tradycyjnej grupy wymagań niefunkcjonalnych, takich jak dostępność, wydajność i wspomniane już bezpieczeństwo (jest ich sporo więcej) należy koniecznie dodać koszty operacyjne rozwiązania. Systemy IT nie powinny być przeskalowane, a przez to nadmiernie kosztowne. W idealnej sytuacji koszty rozwiązania powinny rosnąć wolniej niż wolumen transakcji przez nie obsługiwanych. Świadczy to o doborze najlepszej architektury, która w elastyczny sposób, na naszą korzyść, wykorzystuje ekonomię skali, która stanowi jedno z fundamentalnych założeń chmury publicznej.
Jak poradzić sobie z nadmiernymi kosztami w chmurze?
Często na początku drogi, a szczególnie w sytuacji przekroczenia zaplanowanych budżetów na chmurę, pojawia się pokusa, aby dział finansowy sprawował pieczę nad doborem technologii i kontrolował kto, kiedy i jakie zasoby może tworzyć. O ile w pewnej mierze takie podejście ma sens,
Przykładowo, jeśli nie przeprowadzamy milionów symulacji pracując nad nowym lekiem, to naszej organizacji nie będą potrzebne bardzo drogie maszyny wirtualne wyposażone w karty graficzne, na których owe obliczenia mogą być przeprowadzane, zatem dostęp do takiej kategorii serwerów można “odgórnie” zablokować uniemożliwiając ich przypadkowe uruchomienie.
to niestety, daleko posunięte podejście ścisłej kontroli obarczone jest wieloma negatywnymi skutkami, z którymi kadra zarządcza musi się liczyć. Przede wszystkim blokuje większość benefitów używania chmury publicznej przez:
- ograniczenie dostępu do nowych usług i aktualizacji (które pojawiają się minimum, co kwartał i często powodują, że obecna „dobra” architektura staje się przestarzałą).
- uniemożliwienie szybkiej budowy PoC.
- zakaz eksperymentowania, a tym samym pozbawienie kadry IT możliwości rozwoju przez praktycznie poznawanie nowych rozwiązań.
Po drugie blokowanie IT jest źródłem konfliktów i buduje podziały na my kontra oni. Stawia programistów i inżynierów w pozycji osób do których organizacja nie ma zaufania i dlatego kontroluje ich finansowymi policjantami.
Ostatecznym, pragmatycznym powodem jest fakt, że nawet wstępnie zaakceptowane i sprawdzone usługi, mogą być skonfigurowane w sposób kosztowo nieoptymalny, powołane nadmiarowo lub najzwyczajniej w świecie zostać porzucone (ktoś ich kiedyś używał, potem przestał, ale zapomniał skasować – fachowo takie przypadki nazywamy waste).
Powyższe argumenty w moim przekonaniu są wystarczające, aby odradzać nadużywania władzy i nie wprowadzać żadnego daleko posuniętego gate keepingu.
Zatem co można zrobić, aby okiełznać rosnące koszty chmury?
Przed podjęciem działań, należy sobie uświadomić, że część z tych niezaplanowanych kosztów może być sensowna i właściwa, ponieważ przynosi korzyści dla organizacji. Wyzwaniem dla działu finansów będzie zrozumienie która! Trzeba się nauczyć odróżniać ziarno od plew i umiejetenie te koszty optymalizować.
Jak już napisałem, system zaprojektowany zgodnie ze sztuką będzie samoistnie dobierał ilość zasobów w chmurze, aby obsłużyć swoich użytkowników. W żargonie powiemy, że jest elastyczny. Zatem jeśli planowałeś, że średnio obsłużysz 10 tysięcy klientów miesięcznie i dla takiego wolumenu szacowałeś budżet, musisz uwzględnić czy przypadkiem ostatnia kampania marketingowa nie spowodowała wzmożonego popytu na produkty/usługi Twojej firmy, co spowodowało znaczący przyrost klientów i wyskalowało system, pociągając za sobą wzrost kosztów.
To oczywiście idealny przykład (i tylko takich Ci życzę) ukazujący ścisłą korelację między biznesem a technologią. Nie zawsze wyższe koszty to problem! Inne przykłady są trudniejsze do przeliczenia na pieniądze, bo po prostu trudno je wycenić:
- przeniesienie kopii zapasowych do chmury
- wzmożone testowanie aplikacji na serwerach w chmurze
- analizy Big Data i raportowanie
- oraz wiele innych.
Wszystkie mogły zostać wykonane w celu oszczędności czasu i zwiększenia bezpieczeństwa.
O ile takie niezaplanowane i niekontrolowane decyzje mogą zostać uzasadnione post-factum, szczególnie, że pokazują ekspertyzę i zaangażowanie personelu technicznego, to nie możemy pominąć faktu, że nie stanowią reguły i zawsze odpowiadają im nieuzasadnione koszty.
Rożne badania rynkowe zdają się być zgodne, iż średnio 20% kosztów chmury jest nadmiarowa. Niektórzy posuwają się w swoich szacunkach nawet do 35% (w co, osobiście jestem skłonny uwierzyć na podstawie swoich doświadczeń!). Już nawet dla małych i średnich przedsiębiorstw stanowi to wymierne sumy pieniędzy idące w dziesiątki lub setki tysięcy, a często miliony, dolarów rocznie.
To przede wszystkim w tym obszarze należy optymalizować koszty chmury, czyli szukać oszczędności i wyeliminować stratę!
Jak? Patrz punkt 3 w paragrafie poniżej.
Nowe wyzwania dla „finansów” w chmurze
Według mojej najlepszej wiedzy do odpowiedzialności CFO lub CIO w kontekście finansów chmury należy szeroko rozumiana budowa kultury FinOps, na którą składają się przede wszystkim następujące kwestie:
1. Alokacja kosztów – sposób przypisywania kosztów chmury do konkretnych systemów (projektów) lub jednostek organizacyjnych. Nietrywialne zadanie, którego celem jest stworzenie jasnych kryteriów zapewniających transparentność pomiarów kosztów. Czasem trudno odseparować koszty między projektami, przejrzyste zasady pomogą zespołom IT zrozumieć w jaki sposób są wewnętrznie rozliczne.
Jednym z pierwszych, kluczowych zadań w tym obszarze będzie zdefiniowanie strategii tagowania zasobów i wprowadzenie jej w życie.
Na wyższym poziomie dojrzałości będziesz musiał opowiedzieć się za wyborem jednego z modeli rozliczeń: chargeback lub showback. Umożliwi to przeniesienie jeszcze większej części odpowiedzialności za koszty rozwiązań w chmurze na krawędź organizacji – do zespołów za nie odpowiedzialnych.
2. Przewodzenie działaniom mającym na celu wypracowanie wewnętrznych praktyk i standardów ułatwiających zarzadzanie i optymalizacje kosztów chmury już na etapie projektowania. Działania te muszą być prowadzone z działami technicznymi i inżynierami. Próby narzucania reguł z książek i najlepszych praktyk z Internetu, rzadko kiedy odnoszą sukces z racji technologicznych i kulturowych ograniczeń.
Niechlubna prawda jest taka, że osoby techniczne nie znoszą krytyki rozwiązań, które stworzyły, a już zupełnie źle ją przyjmują od osób nietechnicznych. Stąd też zalecam budowę mechanizmów współpracy opartych o partnerstwo. Dużo lepszą receptą na sukces jest zaangażowanie działów IT przez pokazanie wspólnego celu jakim jest niski koszt operacyjny. Programiści i inżynierzy uwielbiają wyzwania, dlatego przedstawienie niskich kosztów (przy zachowaniu pozostałych parametrów niefunkcjonalnych) jako osiągnięcia technicznego (natury inżynieryjnej) będzie stukrotnie lepszym motywatorem niż jakiekolwiek przykazy i nakazy mające swe źródło w obcym dziale finansowym.
Warto też rozważyć bardziej wymierne motywatory, być może część zaoszczędzonych pieniędzy przez projekt może „wrócić” do jego budżetu i umożliwić zatrudnienie kolejnej osoby, która odciąży zespół?
3. Inicjowanie działań mających na celu optymalizację bieżących i przyszłych kosztów chmury. Jest to jedyna rzecz, która może przynieść natychmiastowe ograniczenie bieżących kosztów, szczególnie jeśli jest wykonana po raz pierwszy, gdyż zwykle dostarcza wachlarz prostych w realizacji optymalizacji kosztowych (low hanging fruits). W naszej ofercie istnieje dokładnie taka usługa i gorąco zachęcam z niej skorzystać.
Ale uwaga, to nie jest to panaceum (silver bullet) na wszystkie problemy kosztowe!
Jak najbardziej uzasadnione jest rozpoczęcie od tego kroku nawet gdy inne aspekty są dopiero na etapie planowania. Jednak warto wiedzieć, że to na liderze podejmującym decyzje spoczywa odpowiedzialność za zaplanowanie strategii budowy kultury FinOps w organizacji, tak aby całe działanie było również nastawione na wyciagnięcie wniosków, zmianę sposobu pracy i projektowania architektury. Tylko takie podejście może zaowocować oszczędnościami w przyszłości (cost avoidance). W przeciwnym wypadku optymalizacja kosztów chmury obniży chwilowo rachunek, ale nie rozwinie umiejętności kadry technicznej, co będzie skutkować powtórzeniem tych samych błędów i kolejnymi wysokimi rachunkami w przyszłości.
Redukcja kosztów w praktyce.
Trzy umowne kategorie optymalizacji
Optymalizacje kosztowe rozpoczynają się od analizy bieżących i historycznych rachunków oraz sprawdzenia, które usługi chmury AWS i w jaki sposób są używane przez organizację (lub konkretny system na koncie AWS – zależy od skali optymalizacji).
Na podstawie tych informacji i wglądu w architekturę wdrożonych rozwiązań, architekt specjalista ds. kosztów (ang. cloud economist) przygotowuje zestaw rekomendacji wraz z szacunkowymi wyliczeniami oszczędności, które zostaną osiągnięte po ich wprowadzeniu w życie. Rekomendacje są bardzo techniczne w swej naturze.
Z mojego doświadczenia, owe rekomendacje można skategoryzować na trzy grupy pod względem czasu i zasobów potrzebnych do ich realizacji:
- Szybkie i proste – w większości wypadków dotyczą źle skonfigurowanych lub zupełnie zbędnych zasobów, lecz nie wpływają na architekturę rozwiązania. Czas realizacji to dni, a czasem tylko godziny! Bardzo często już kolejnego dnia można zobaczyć efekt w postaci niższych kosztów.
- Średnie – tutaj mamy do czynienia z problemami, które wymagają większej dozy planowania. Często wymagana jest dodatkowa analiza potencjalnego wpływu na inne komponenty lub usługi organizacji. Jest to szczególnie ważne w przypadku nieodwracalnych operacji np. usuwania zasobów potencjalnie zbędnych, co do których wstępnie nie było pewności. Z tego powodu redukcji kosztów możemy oczekiwać w perspektywie dni lub tygodni.
- Skomplikowane – ta kategoria zawsze wymaga poważnych zmian w architekturze rozwiązania, które nigdy nie są ani szybkie, ani proste do wdrożenia. Stąd też należy liczyć się z wielotygodniowym okresem prac, zanim osiągniemy szacowane oszczędności.
Ta trzypoziomowa kategoryzacja w praktyce jest bardzo wygodna na etapie planowania prac naprawczych i ustalania kolejności działania.
Warto w tym miejscu wspomnieć, że nasza podświadomość zwodzi nas na manowce i nastawia na to, iż tylko Skomplikowane optymalizacje przyniosą duże (zauważalne) skutki na rachunku. Nic bardziej mylnego! Wszystko zależy od konkretnego projektu, użytych usługi, ich konfiguracji oraz wolumenu użycia.
Mamy w portfolio przykłady Szybkich i prostych optymalizacji, które przyniosły większe oszczędności niż te bardziej czasochłonne.
Optymalizacja kosztów chmury – przykłady success stories
U jednego z naszych klientów, przeprowadziliśmy analizę kosztową oraz wprowadziliśmy w życie zalecenia dotyczącą optymalizacji dysków w usłudze EBS (Amazon Elastic Block Storage). Szybka i prosta optymalizacja kosztowa przyniosła natychmiastowe skutki: oszczędności rzędu 20%. W skali roku klient zaoszczędził około 240 000 dolarów.
W innym przypadku, w kategorii Średniej, zidentyfikowaliśmy waste (niepotrzebne zasoby) generujący 68% kosztów całej usługi. W skali rocznej przełożyło się to na 4 730 dolarów oszczędności.
Działaniem, które wymagało od nas najwięcej pracy i czasu była zmiana architektury rozwiązania w taki sposób, aby zniwelować koszty związane z Elastic IP. Była to oczywiście Skomplikowana zmiana do przeprowadzenia. Przed rozpoczęciem działań naprawczych klient płacił blisko 30 000 dolarów za same adresy IP przypisane do tysięcy wirtualnych maszyn EC2. Po ponad roku prac, koszty zostały zmniejszone o 67% do mniej niż 10 000 dolarów miesięcznie. Rocznie dało to oszczędność powyżej 123 000 dolarów.
Remarkably, the conceptual work only initially required significant involvement of architects and engineers in the analysis and preparation of the new network architecture. Most of the practical work was done by less-skilled employees who performed the necessary steps on each EC2 server, thus saving the time of the most valuable specialists.
As you can see, real-world examples show that the savings achieved through cost optimization do not depend on the difficulty level and time-consuming implementation. Sometimes the most straightforward solutions yield the most significant savings, which doesn’t mean that the more challenging ones aren’t worth pursuing.
Of course, total savings (those in dollars) depend on the billing amount, but even the $4,730 saved per AWS service for this customer represented about 16% of total AWS costs and made a real difference.
Co dalej?
Wiem, że doskonale zdajesz sobie sprawę, że ustanowenie kultury FinOps, to zmiana organizacyjna, która może trwać latami.
W sytuacji, gdy niezbędne jest szybkie działanie, spowodowane na przykład przekroczeniem budżetu, rekomenduję przeprowadzenie szybkiej optymalizacji kosztowej w celu uzyskania wiarygodnych informacji na temat potencjalnych oszczędności i technicznych wytycznych prowadzących do ich osiągnięcia.
W najprostszej formie takie analizy trwają kilka dni. Zależy to oczywiście od zakresu, na który składa się ilość kont AWS oraz wykorzystanych zasobów i usług.
Szybkie i proste optymalizacje dadzą Ci realne, wręcz natychmiastowe oszczędności. Będą też Twoim własnym success story, które wybrukuje drogę Twojej organizacji do FinOps.
