W jaki sposób mBank podchodzi do rozliczania kosztów chmury FinOps

Aleksander Gawroński, który odpowiada za szeroko rozumianą infrastrukturę IT w mBanku był gościem spotkania CXO HUB „W stronę FinOps2”. Jak przyznaje, chmura obliczeniowa zaistniała w strategii banku w 2020 roku. Równocześnie powstało Cloud Center of Excellence, w ramach którego istotną rolę od początku odgrywa komórka FinOps. Obecnie strategia mBank zakłada budowę hybrydowego środowiska, w ramach którego odpowiednią architekturę dobiera się w toku osobnego procesu.  

Na jakim etapie wyłonił się proces, który pozwala weryfikować, czy projekt ma iść chmurowo, czy nie, proces, który pozwala brać pod uwagę architekturę chmurową?

Aleksander Gawroński: mBank jako instytucja finansowa, a więc regulowana, dzielił oczywiście historię całego sektora finansowego w zakresie podejścia do chmury. Musiało upłynąć kilka lat, żebyśmy przeszli, we współpracy z KNF, przez komunikaty chmurowe, ustalenia, i uzgodnienia.
Można więc powiedzieć, że w stosunku do innych segmentów rynku mamy kilka lat opóźnienia, jeśli chodzi o doświadczenia z chmurą publiczną. Z drugiej strony obecne regulacje są w moim przekonaniu bardzo sensowne i w jasny sposób określają, jak możemy z nich korzystać.
Impulsem do odważniejszego skorzystania z tych możliwości stały się uwarunkowania okresu pandemii COVID-19. W roku 2020 stworzyliśmy zespół Cloud Center of Excellence (CCoE), centrum doskonałości chmurowej, który stanowił zaczyn rozwoju. Uprzedzając dalszą historię – uważam, że jest to podstawowy czynnik powodzenia wdrożenia chmury. Od stworzenia takiego zespołu warto zacząć przygodę chmurową.

W jakich uwarunkowaniach powstało centrum doskonałości chmurowej mBanku?

Najważniejsze cechy banku, które determinują kierunki i możliwości przedsięwzięcia chmurowego, to w moim przekonaniu: duża liczba transakcji, duże legacy, duże data canter. Organizacja taka jak nasza nie jest z pewnością cloud native – wyjątek mogą stanowić banki budowane od zera.
Wobec tego, że brak jest kompetencji, procesów, doświadczenia, trudno sobie wyobrazić, żeby nie budować podejścia do chmury od podstaw.

Pomówmy zatem o zadaniach i działaniach CCoE w mBanku.

Zespół Cloud Center of Excellence z założenia miał „rozprowadzać” tematy chmurowe w organizacji. Podejście FinOps było zaś od początku częścią tego zespołu i całego procesu budowania dojrzałego wdrażania chmury obliczeniowej.

Wejście do chmury i budowa CCoE wiązały się też z przyswojeniem dużej dawki wiedzy o standardach, praktykach, zagrożeniach i wartości z chmury od firm analitycznych i doradczych. Zrobiliśmy to z pełną świadomością, że brak wiedzy oznacza ryzyko spalenia tematu chmury u zarania – chcieliśmy tego uniknąć. Wydaje mi się, że przygotowaliśmy się zgodnie ze sztuką.

Czy poza tymi zewnętrznymi referencjami, CCoE i w ogóle chmura w mBanku bazowały na własnych doświadczeniach, np. ze współpracy IT z kontrolingiem, czy szerzej – z finansami banku? Czy były jakieś praktyki, które można było wykorzystać?

Od samego początku w obszarze IT mieliśmy wyspecjalizowaną jednostkę kontrolingową, która nadal funkcjonuje. Obecnie współdzielimy odpowiedzialność pomiędzy dział kontrolingu IT oraz zespół CCoE.
Mamy przygotowane kokpity do rozliczeń na Azure i GCP, pełną, transparentną wiedzę na temat każdego systemu. W różnych przekrojach możemy obserwować, ile i w jaki sposób każdy system zużywa zasoby na pasmo, na landing zone, w podziale technicznym i dziedzinowym, a w zasadzie – w ujęciu produktowym. Wszystkie te wnioski stanowią wsad do centralnego planowania w obszarze IT.

Czy zatem budżet chmurowy w całości pozostaje w dyspozycji IT?

Budżet IT jest w IT, biznes nie zarządza tym budżetem, podobnie, jak miało to miejsce w przypadku „starego” świata data center, gdzie koszty serwerów, kabli, chłodzenia – wszystko to było niewidoczne dla biznesu.
W przypadku chmury taki model zmienia się jedynie o tyle, że zaczynamy udostępniać biznesowi informację o kosztach i użytkowaniu rozwiązań SaaS, natomiast „chmura centralna”, w IaaS, w landing zones – pozostaje w naszej działce. My planujemy i rozliczamy jej użycie, my alertujemy, sprawdzamy, itd. To kompetencja, która pozostaje w domenie IT, gdzie została zbudowana od samego początku.

Odsłania nam się powoli budowa – składowe CCoE. Silnym elementem wydaje się governance…

Powiedziałbym nawet, że zbudowanie i wdrożenie governance okazało się w wielu miejscach szybsze niż zakładaliśmy. Bywa, że jesteśmy z tym działaniem krok przed samą migracją, która z kolei postępuje wolniej niż planowaliśmy. Governance regulacyjny jest u nas faktycznie silnym elementem, poniekąd ze względu na dobrze określone wymagania KNF.

Drugi element to zespół techniczny, ten który zajmuje się landing zone’ami oraz wspieraniem i utrzymaniem całej infrastruktury chmurowej. Do jego zadań należy także współpraca z całym szeroko rozumianym światem aplikacyjnym, przykładowo, przy przenoszeniu produktów.

Zespół CCoE pilnuje całości procesu. Przede wszystkim musi powstać dokument HLD w zakresie przeniesienia do chmury, który podsumowuje wnioski z analizy czy dany system nadaje się do chmury, a także czy migracja go do chmury publicznej ma sens operacyjny, finansowy. Czasy hurraoptymistycznych migracji do chmury minęły, ale też szczęśliwie nie byliśmy częścią tego zjawiska.

Dobrze, że można dziś otwarcie mówić, że pewne rzeczy bardziej się opłaca utrzymywać w data center albo na wirtualizacji…

Być może przewrót, jaki dokonuje w obszarze wirtualizacji firma Broadcom po przejęciu Vmware, przyśpieszy migrację chmurową. Przyjmując jednak dotychczasowe koszty wirtualizacji w tej technologii, nie ulegało wątpliwości, że wiele systemów taniej jest utrzymywać we własnej serwerowni.

Natomiast kwestia pójścia do chmury publicznej to niewątpliwie także kwestia kosztów. Podzielę się jeszcze jedną obserwacją: z naszej strony kwestia finansowa nigdy nie stała za decyzją o przejściu do chmury. W tej architekturze wcale nie jest bowiem taniej, a bywa drożej. Koszty nie spadają, a jeśli – to nieznacznie, ponieważ nadal musimy płacić za prąd, ludzi, kolokację czy rozwiązania, które utrzymujemy on-premise. Przeniesienie dwóch albo trzech systemów do chmury nie spowoduje, że wyraźnie obniżymy wydatki.

Co jest więc z perspektywy mBanku przesłanką przejścia do chmury?

Taką przesłanką jest pozyskanie nowych kompetencji albo nawet szerzej – skorzystanie z przepustki do świata nowych, szybciej rozwijających się rozwiązań, niedostępnych w „starym” świecie data center. Wiadomo, że pewne narzędzia i rozwiązania będą tylko w chmurze. Bez ogródek sprawę stawiają zresztą dostawcy, promując model subskrypcyjny. W dłuższej perspektywie pozostawanie wyłącznie w realiach własnego centrum danych może prowadzić do zahamowania rozwoju i stworzenia bardzo wysokiej bariery wzrostu kosztów, kiedy już dojdzie do takiej konieczności.

Przejście na chmurę ma także wymiar unowocześnienia zestawu kompetencji i umiejętności, którymi posługują się ludzie w organizacji. Chcemy stworzyć okazję i szansę oderwania się od tradycyjnych zagadnień aktualizacji systemów operacyjnych albo wgrywania poprawek do kodu, nawet w tej nowoczesnej formule DevOps. Zależy nam też na tym, aby chociaż trochę ukierunkować naszych inżynierów od środowisk sprzętowych na zagadnienia sterowania infrastrukturą przez kod. To jest strategiczna korzyść, która ma pojawić się w nieco dłuższej perspektywie. Będzie to możliwe, ponieważ infrastruktura powoływana docelowo z kodu, będzie podlegać automatycznemu zarządzaniu, aktualizacji, itd., niezależnie od tego, czy zostanie zbudowana w chmurze publicznej, prywatnej – pozostającej w naszym data center. Dlatego CCOE tak pilnuje realizacji założeń governance, postępowania według dokumentów HLD także dlatego, aby wspierać zmianę struktury naszych systemów na korzyść tych nowoczesnych, obsługiwanych automatycznie.

Wracając do tematu spotkania: co z FinOps?

FinOps od początku jest częścią tej zmiany. Budując kompetencje zespołu CCoE wiedzieliśmy od początku, że musi być tam miejsce dla FinOps, które narzuci rygor i pragmatyzm tym zmianom. Oczywiście jesteśmy na początku drogi – w naszym przypadku część aplikacji trafiła do chmury prywatnej, do chmury publicznej zaś około 20 aplikacji, i to nie z kategorii superciężkiej.

Dotychczas nie przestrzeliliśmy prognozy kosztowej w żadnym przypadku. Posługujemy się w planowaniu ostrożnymi założeniami, więc i budżety chmurowe mamy relatywnie duże w stosunku do potrzeb. Przede wszystkim nie chcemy ich przekraczać.

Pomocny jest tu fakt, że biznes bankowy jest przewidywalny. Posiada oczywiście „piki” aktywności, ale bardzo powtarzalne i przewidywalne.

A gdyby wykroczyć nieco poza temat kosztowej optymalizacji – co z wydajnością pracy? Czy podejście chmurowe staje się rozsadnikiem nowego podejścia do efektywności?

Możemy się pochwalić wieloma przykładami dobrego policzenia wydajności IT, ale też programowo nie dążymy do oszacowania wszystkiego. Do niektórych obszarów przykładamy miary makro. Korzyści z przejścia do chmury publicznej są w pewnych miejscach są niewymierne, ale w założeniach strategicznych uznaliśmy, że docelowo, w łącznym bilansie kosztów ludzkich, procesów i utrzymania, nowoczesny świat będzie kosztował mniej od dotychczasowego.

Istnieje tu tzw. magia dużych liczb. Koszty zaczną się wyraźniej obniżać gdy 70% naszego IT przejdzie do nowego świata chmurowego. Z tego powodu pewnych elementów nie mierzymy punktowo, np. ile by dana aplikacja zużyła prądu w data center. Mamy policzone licencje, przypisanie serwerów, główne aspekty i kategorie kosztowe.

Czy ta kalkulacja uwzględnia także wspomnianą efektywność procesów pracy? Korzyść z wprowadzenia platform inżynierskich, aparatu obsługi i automatyzacji?

W mBanku ponad 90% rozwiązań aplikacyjnych wytwarzamy wewnętrznie. Bardzo mało kupujemy na zewnątrz.
Te proporcje zaczyna zmieniać otwarcie na rozwiązania SaaS, jest to jednak zmiana o małej dynamice. Tym niemniej po stronie developmentu pojawiła się duża chęć, żeby się nauczyć nowego podejścia, więc skorzystaliśmy z „krzywej innowatorów”.

Dodatkowo jednak, z naszej perspektywy bardzo istotne jest bezpieczeństwo. Dużo czasu zajęło więc ułożenie spraw z dostawcami i architektami chmurowymi. Nasze landing zone’y mają pewne, konieczne ograniczenia, ale dzięki temu zachowujemy wysoki poziom bezpieczeństwa.

Moim zdaniem o efektywności pracy w pewnym stopniu decyduje kolejność zanurzania w świat chmurowy. W naszym przypadku, w pierwszej kolejności zaadaptowali się ludzie i zespoły, którzy chcieli i byli bardzo chętni, gotowi na taką zmianę. Teraz z kolei budujemy pewną masę krytyczną, w oparciu o tych, którzy dopuszczają zmianę, a podległe im systemy zakwalifikowaliśmy jako nadające się do chmury. Na końcu zostanie trudniejsza część, ciężkie, duże systemy.

Bardzo ciekawe jest włączenie wymiaru bezpieczeństwa osobowo czy kompetencyjnie w strukturę CCoE.
Niespecjalnie mamy wybór. Jako bank musimy to robić ze zdwojoną starannością, tolerancja błędu jest przecież mniejsza niż w innych sektorach.

Stąd właśnie tak mocny governance przechodzenia do chmury i weryfikowania aplikacji. Podnosi to poprzeczkę i skalę wyzwań, ale przyjęliśmy, że jest obowiązkowym i wartym poniesienia kosztem dojścia do założeń całej migracji – tj. osiągnięcia poziomu nowoczesnego, szeroko korzystającego z nowych rozwiązań podmiotu. Te korzyści zresztą zaczynają się już pojawiać, skoro tenże governance pozwala nam akceptować i uruchamiać chmurowe projekty np. z obszaru rozwiązań GenAI.

Krzysztof Wykręt, VINCI: Powiedziałeś, że dążycie do tego, aby do chmury przenieść około 70% aplikacji. Czy przewidujesz, że koszty związane z bezpieczeństwem tych rozwiązań wzrosną, spadną, czy nie zmienią się? A może przeniesiecie je w gestię innego budżetu?

Doprecyzuję, że w myśl aktualnej strategii 70% obciążeń chcemy przenieść do chmury prywatnej i publicznej. Istotną częścią zmiany jest w naszym przypadku chmura prywatna. Podział na to, co idzie do chmury prywatnej, a co do publicznej oparty jest na kryterium kosztowym.

Bezpieczeństwo jest częścią naszej inwestycji w zespół chmurowy, więc wchodzi w skład CCoE, choć funkcjonalnie jest w departamencie bezpieczeństwa. Chodzi bardziej o logiczne przypisanie takich specjalistów do centrum, z którego wykonują centralne funkcje bezpieczeństwa.

Tyle schemat, natomiast uczciwie muszę powiedzieć, że pozyskanie kompetencji bezpieczeństwa chmury jest szalenie trudne i kosztowne. To rząd wielkości więcej w stosunku do kosztów kompetencji skupionych wokół tradycyjnej infrastruktury. Chmurowi „bezpiecznicy” to najdrożsi i najtrudniej dostępni specjaliści na rynku. Zakładam, że z czasem ta pula wzrośnie, bo specjaliści bezpieczeństwa przekwalifikowują się, także z naszą pomocą, na obszar chmury.

Natomiast, podobnie jak w przypadku kosztów infrastruktury, tak w przypadku kompetencji bezpieczeństwa wiemy dziś, że model hybrydowy, który jest dla nas jedyną opcją, będzie droższy.

Adam Wojtaszek, Sourceful IT Services: Jak trudne jest porównywanie kosztów w sytuacji, kiedy część z nich jest trudno mierzalna albo podlega jakimś strategicznym albo emocjonalnym wytycznym? Gdzie umieścić linię ostatecznego bilansu przedsięwzięcia?

Znam odpowiedź, tylko że dla mojej organizacji jest ona specyficzna i trudna do przełożenia wprost na inne firmy.

Bardziej uniwersalna jest otoczka tej decyzji. A składa się na nią w zasadniczej mierze zaufanie ze strony zarządu do planów chmurowej migracji, które przedstawiliśmy. Umówiliśmy się na strategiczne liczby, a nie na walkę o detale w rodzaju koszt energii do zasilenia urządzenia czy aplikacji w wybranym okresie. Strategia chmurowa została zaakceptowana przez zarząd i – choć oczywiście mamy ograniczenia finansowe – to zarząd ma zrozumienie tematu i wie, że w pewnych wymiarach finansowych będzie drożej, natomiast całościowo zyskamy elementy, które przyniosą nam zysk z tej zmiany. Z tego zaufania wynika też scedowanie na IT zarządzania zmianą, prowadzenie w szczegółach tej podróży, aby w zakładanym czasie znaleźć się w zakładanym miejscu, nie nadkładając drogi.

Cieszę się, że pracuję w firmie, gdzie dominuje nastawienie probiznesowe, patrzenie na IT przez pryzmat całego portfela projektów i przedsięwzięć, podobnie jak na wydatki infrastrukturalne, co sprawia, że towarzyszy temu tolerancja błędów przy projektach. W mBanku raz na 4 lata przeprowadzamy benchmarki porównujące się do rynku, stąd wiemy które obszary wymagają dofinansowania, a które są przepłacone. Na podstawie tego dokonujemy poprawek.

Zdaję sobie sprawę, że taka odpowiedź może być trudniejsza do zastosowania w niektórych organizacjach o pionowej hierarchii, z silosowym podejściem. Ale zapewne tam można inaczej uzasadniać zmianę chmurową.

Marcin Kaczmarek, Senior Cloud Engineer, Bayer: Czy próbowaliście łączyć koszty infrastruktury chmurowej ze stałymi biznesowymi? Moje doświadczenia z poprzedniej pracy w instytucji finansowej są takie, że kiedy porównywaliśmy koszt infrastruktury, która obsługiwała na przykład przelewy, to mogliśmy wykazać, że choć całościowy koszt był wyższy, to koszt pojedynczy obsługi transakcji był niższy.

W pierwszej fazie, wybieraliśmy do chmury rozwiązania, których migracja przynosiła nawet oszczędności. Natomiast z perspektywy całościowego budżetu organizacja taka jak moja, gdzie do utrzymania środowiska hybrydowego niezbędne jest utrzymanie własnej infrastruktury i odpowiednich kompetencji, nie uzyska natychmiastowego zejścia z kosztów.

Taki scenariusz warunkuje nam potrzeba utrzymania znacznego udziału systemów legacy, więc korzyści z chmury publicznej nie są oczywiste i namacalne. Całościowo koszt infrastruktury nie będzie niższy. Nie wierzę w skokowe oszczędności z wejścia w chmurę w dojrzałej i dobrze „ustawionej” pod względem technologii firmie.
Ale zarazem nie można pomijać wartości biznesowej, która pojawia się wraz z opcją chmurową, jak na przykład czynnik time to market. Należy nastawić się na te korzyści w dłuższej perspektywie – zakładam, że beneficjentami zainicjowanej zmiany będą zarządzający bankiem za kilka lat.

Tomek Rychter: Czy rozpatrując korzyści z wdrożenia architektury chmurowej braliście pod uwagę także kwestie geopolityczne, budowę rozwiązania mającego znamiona ambasady danych – że posłużę się analogią z administracji?

To dosyć wrażliwy temat. Nie wchodząc w szczegóły – jak wszyscy zapewne na rynku – dokładnie analizowaliśmy przypadek ukraińskiego Privat Banku. Tam było bardzo dużo wirtualizacji, która została bardzo szybko przeniesiona do chmury publicznej. W ten sposób bankowi udało się podtrzymać i uratować działanie.
Natomiast weźmy pod uwagę inny aspekt: regulator zobowiązuje nas do tego abyśmy mieli ścieżkę wyjścia z chmury. W kontekście geopolitycznym i w kontekście vendor-lock także trzeba szukać alternatywy. Obecnie chmury publiczne zdominowane są jednak przez podmioty amerykańskie i hybrydowe podejście jest jedyną opcją zamienną. Europa nie była w stanie i nic nie wskazuje, aby się na to zdobyła, wytworzyć własne ekosystemy chmurowe o takiej skali.

 Ostatnie pytanie niech więc dotyczy przyszłości. Czy po dobrym starcie rozpatrywany jest jakiś scenariusz przyspieszenia na drodze do chmury – na przykład inspirowanego potrzebami biznesu?

Jesteśmy na dobrej trajektorii i nie chcemy tego zmieniać. Na pewno będziemy większy nacisk kłaść na edukację biznesu, żeby więcej wnosił do realizacji strategii.

Nie chcemy, aby doszło do sytuacji, w której za bardzo zawłaszczymy chmurę. W organizacjach zmierzających ku chmurze, nie tylko w mBanku, rośnie znaczenie edukacji biznesu. To jest jedyna możliwość, aby pojawił się powód do przyspieszenia. Inna opcja zmiany dynamiki wdrażania strategii chmurowej może być powodowana tylko geopolityką.

Zamykając klamrą temat finansowy – musimy dbać o koszty i równowagę. Budżety, które są planowane od 2025 roku zmuszają nas do myślenia o redukcji kosztów własnych data center. Balansowanie kosztami będzie tematem przewodnim obsługi środowisk chmurowych. W tym kontekście proces FinOps-owy i kompetencje, które w nim powstają, mają znaczenie trudne do przecenienia.