Chmura miała uwolnić firmy od kupowania infrastruktury na zapas. W wielu organizacjach przyniosła jednak rachunek, którego wysokość trudno przewidzieć i powiązać z wynikami biznesowymi.

Problem nie polega na tym, że chmura jest z natury droga. Pojawia się wtedy, gdy zużycie zasobów rośnie szybciej niż wartość, którą dzięki nim tworzy firma. Dopóki CFO widzi rosnącą fakturę, a CIO rosnące potrzeby infrastruktury, żadna ze stron nie wie, czy wzrost kosztów jest uzasadniony.

Chmura gwarantuje elastyczność, nie oszczędności

Tradycyjna infrastruktura wymagała zakupu serwerów i licencji z wyprzedzeniem. Chmura zastąpiła ten model zasobami uruchamianymi na żądanie i rozliczanymi według wykorzystania.

Nie oznacza to jednak, że zawsze jest tańsza. Jej główną wartością są szybkość, dostęp do technologii i możliwość reagowania na zmieniający się popyt. Oszczędności pojawiają się dopiero wtedy, gdy firma potrafi dopasować zużycie do rzeczywistych potrzeb.

Ekonomika chmury wygląda najlepiej przy obciążeniach sezonowych, szybko rosnących lub trudnych do przewidzenia. Jest mniej oczywista w przypadku systemów, które przez całą dobę wykorzystują podobną moc obliczeniową. Firma może wówczas płacić za elastyczność, z której niemal nie korzysta.

Dlatego właściwe pytanie nie brzmi: „Czy chmura jest tańsza?”, lecz: „Które aplikacje uzasadniają cenę jej elastyczności?”.

Koszt jest projektowany razem z architekturą

Rachunek za chmurę rzadko ogranicza się do maszyn wirtualnych. Obejmuje także bazy danych, pamięć masową, kopie zapasowe, monitoring, bezpieczeństwo, licencje, wsparcie oraz transfer danych.

To właśnie usługi dodatkowe często odpowiadają za różnicę między kalkulacją przygotowaną przed migracją a rzeczywistą fakturą. W AWS koszty mogą zależeć od kierunku przepływu danych, regionu, strefy dostępności oraz wykorzystywanych elementów sieciowych. Źle zaprojektowana komunikacja między częściami jednej aplikacji może więc generować stałe opłaty, mimo że sama moc obliczeniowa została dobrze zoptymalizowana.

Dla biznesu oznacza to, że koszt nie powstaje dopiero pod koniec miesiąca. Jest wpisywany w usługę już podczas wyboru architektury, poziomu redundancji, sposobu replikacji danych i długości przechowywania logów.

Szczególnie kosztowne bywa przenoszenie istniejących systemów bez zmiany sposobu ich działania. Jeżeli aplikacja była przewymiarowana w lokalnym centrum danych, po migracji nadal może wykorzystywać zbyt duże zasoby. Różnica polega na tym, że każda niewykorzystana jednostka staje się teraz widocznym kosztem operacyjnym.

Chmura nie naprawia więc automatycznie nieefektywnej infrastruktury. Może jedynie zmienić sposób, w jaki firma za tę nieefektywność płaci.

Wysoka faktura nie zawsze oznacza problem

Najczęstszym błędem jest ocenianie efektywności chmury wyłącznie na podstawie całkowitego wydatku. Wzrost rachunku o 20 proc. może oznaczać brak kontroli nad zasobami. Może jednak również wynikać z obsłużenia o 50 proc. większej liczby klientów.

Sam koszt nie pozwala odróżnić tych sytuacji.

Dlatego kluczowe staje się mierzenie kosztu obsłużenia klienta, transakcji, zamówienia, zapytania API lub innego wyniku biznesowego. FinOps Foundation wskazuje, że ekonomika jednostkowa tworzy wspólny język dla finansów, technologii i zespołów produktowych. Koszty można mierzyć między innymi na klienta, transakcję, usługę, rozwiązany przypadek lub uzyskany przychód.

Jeżeli całkowity rachunek rośnie, ale koszt jednej transakcji spada, firma prawdopodobnie korzysta z efektu skali. Jeżeli natomiast klientów przybywa, a koszt ich obsłużenia również wzrasta, infrastruktura staje się coraz mniej efektywna.

To właśnie pogorszenie kosztu jednostkowego, a nie przekroczenie określonej kwoty na fakturze, pokazuje moment, w którym chmura przestaje poprawiać ekonomikę firmy.

FinOps nie może zaczynać się od faktury

Firmy dostrzegają problem, ale nadal mają trudności z jego rozwiązaniem. Według Flexera 63 proc. badanych organizacji ma już zespół FinOps, a mimo to szacowany udział marnowanych wydatków chmurowych wzrósł do 29 proc. Zarządzanie kosztami pozostaje głównym wyzwaniem chmurowym dla 85 proc. respondentów.

Pokazuje to, że sam dashboard, raport lub centralny zespół nie wystarcza. FinOps jest nieskuteczny, jeżeli pojawia się dopiero po zamknięciu miesiąca i sprowadza do wyszukiwania niewykorzystywanych zasobów.

Największy wpływ ma wcześniej: podczas projektowania aplikacji, wyboru baz danych, określania wymaganego poziomu dostępności i planowania skalowania. Wydatki chmurowe powstają bowiem w kodzie, konfiguracji infrastruktury i decyzjach produktowych, a nie w dziale finansowym.

CFO i CIO potrzebują wspólnej miary

CFO wnosi do rozmowy budżet, cele marżowe, prognozy sprzedaży i ocenę ryzyka wieloletnich zobowiązań. CIO zna wykorzystanie zasobów, wymagania bezpieczeństwa, charakterystykę aplikacji oraz techniczne konsekwencje ograniczania kosztów.

Dopiero połączenie tych perspektyw pozwala stwierdzić, czy konkretny wydatek jest marnotrawstwem, czy ceną za wartość. Redundancja podnosi rachunek, ale ogranicza skutki awarii. Monitoring kosztuje, lecz skraca czas wykrywania problemów. Środowiska testowe nie generują bezpośrednio przychodu, ale zmniejszają ryzyko błędów produkcyjnych.

Celem nie jest więc najniższy możliwy rachunek. Jest nim najlepsza relacja między kosztem, wartością i ryzykiem.

Rozmowa CFO i CIO powinna koncentrować się na tym, czy koszt na klienta spada, które produkty generują największe wydatki, kto odpowiada za ich ekonomikę i czy płatne zasoby rzeczywiście wspierają sprzedaż, jakość lub bezpieczeństwo.

W ten sposób pytanie „dlaczego faktura znowu wzrosła?” zostaje zastąpione znacznie ważniejszym: „czy dodatkowy wydatek poprawił wynik produktu?”.

Nie każda aplikacja należy do publicznej chmury

Czasem optymalizacja oznacza przeniesienie stabilnego, intensywnie wykorzystywanego systemu do infrastruktury prywatnej lub modelu hybrydowego. Nie świadczy to o porażce całej strategii chmurowej.

Uptime Institute wskazuje, że wysokie koszty są głównym powodem przenoszenia części obciążeń z public cloud, ale skala odwrotu od chmury jest często wyolbrzymiana. Firmy pozostają przy środowiskach hybrydowych i selektywnie umieszczają aplikacje tam, gdzie ich charakterystyka najlepiej odpowiada modelowi kosztowemu.

Chmura zachowuje przewagę tam, gdzie liczy się szybkie skalowanie, eksperymentowanie i dostęp do zaawansowanych usług. Infrastruktura prywatna może lepiej odpowiadać stabilnym systemom o dużym i przewidywalnym wykorzystaniu. Decyzja nie powinna więc dotyczyć całej organizacji, lecz konkretnego obciążenia.

Rachunek powinien rosnąć wolniej niż wartość

Wzrost wydatków nie jest problemem, jeżeli infrastruktura obsługuje proporcjonalnie większą sprzedaż, liczbę klientów lub skalę działania. Sygnał ostrzegawczy pojawia się dopiero wtedy, gdy koszt obsłużenia jednej jednostki biznesowej zaczyna rosnąć.

Dojrzałe zarządzanie chmurą nie polega na minimalizowaniu każdej pozycji faktury. Polega na sprawdzaniu, czy dodatkowy wydatek przekłada się na większą skalę, lepszy produkt, niższe ryzyko lub szybsze wejście na rynek.

Chmura przestaje obniżać koszty, gdy jej zużycie rośnie szybciej niż wartość biznesowa. CFO i CIO powinni więc wspólnie kontrolować koszt klienta, transakcji lub usługi, zamiast oceniać strategię chmurową wyłącznie na podstawie wysokości miesięcznego rachunku.