PKO Bank Polski: nasza droga to selektywna chmura

Z Arturem Kurcweilem, wiceprezesem PKO Banku Polskiego odpowiedzialnym za obszar technologii, rozmawiamy o roli banku w budowie ekosystemu chmur publicznych w Polsce; przecieraniu szlaków dla innych organizacji w Polsce; pionierskich, realizowanych projektach chmurowych; pierwszym systemie zmigrowanym z komputera mainframe na infrastrukturę chmury publicznej; a także o najważniejszych trendach na rynku usług cloud computing.

W październiku 2018 roku PKO BP i Polski Fundusz Rozwoju powołały do życia Operatora Chmury Krajowej. We wrześniu 2019 roku ogłoszono – wspólnie z Google – plan uruchomienia w Warszawie regionu Google Cloud Platform. Minęło kolejne 12 miesięcy i podobną konferencję OChK miał Microsoft w sprawie regionu Azure. Jak więc oceniają Państwo ostatnie 5 lat, jeśli chodzi o rozwój chmury obliczeniowej w Polsce i rolę PKO Banku Polskiego w tym procesie?

Jako bank byliśmy aktywatorem decyzji, które zapadały w centrali Google, a później Microsoft o umiejscowieniu centrów danych w Polsce. Ale za tymi decyzjami stało także to, że Polska ma niesamowity potencjał „informatyczny”. Mamy jednych z najlepszych specjalistów od IT na świecie. Wielokrotnie to udowadnialiśmy, zarówno w różnych konkursach, jak i tym, że Polacy zajmują coraz wyższe stanowiska w firmach technologicznych na świecie. Widać, że mamy potencjał i ekspercki, i menedżerski, aby nasz kraj w tym kierunku rozwijać.

Brakowało nam jednak lokalnego operatora chmurowego, co jest szczególnie istotne dla małych i średnich przedsiębiorstw, których nie stać na budowanie własnych data center. To oni najczęściej korzystają z chmury i są potencjalnymi klientami na usługi cloud computing. Młodzi ludzie w startupach tak naprawdę w życiu nie widzieli serwera na oczy. Nie mają szansy na korzystanie z rozwiązań, które są kojarzone z tradycyjnymi, dużymi centrami danych. Od razu, naturalnie, poszukują rozwiązań chmurowych.

Bazując na naszych doświadczeniach – i uważnej obserwacji rynku – zapadła decyzja, aby razem z Polskim Funduszem Rozwoju stworzyć Operatora Chmury Krajowej, który następnie zawarł partnerstwa strategiczne z Google i Microsoft. Ogłoszenie przez te dwie firmy inwestycji w Polsce stanowiło dodatkowy bodziec, by zapewnić zgodność z wymogami m.in. Komisji Nadzoru Finansowego. Wszystko zostało dostosowane do polskich uwarunkowań.

Pierwsze lata Operatora Chmury Krajowej naznaczone były pionierskimi działaniami i aplikacjami. W efekcie, OChK ma obecnie kilkudziesięciu klientów z całego świata, którym usługi dostarczane są z Polski przy wykorzystaniu regionów – na początku Google Cloud Platform, a od maja także Microsoft Azure.

W Polsce mamy do czynienia z dwucyfrowym wzrostem usług chmurowych. To jest oczywiście wynik niskiej bazy, ale też dostępności usług cloud computing lokalnie. Specjaliści od IT wiedzą, że kilku rzeczy nie da się „przeskoczyć”. Jedną z nich jest prędkość po światłowodzie i związane z tym opóźnienia w transmisji danych. Jeśli więc korzystamy z data center we Frankfurcie albo Londynie, to do pewnego rodzaju usług nie będą się one tak dobrze nadawać, jak te oferowane z centrum danych w Warszawie. To stanowiło kolejny impuls do rozwoju dla OChK i obu hyperscalerów.

Czy można było wówczas uznać PKO BP za pioniera, a dzisiaj za lidera w sektorze bankowym, jeśli chodzi o wykorzystanie usług chmurowych?

Mocno w to wierzę. Po pierwsze PKO Bank Polski, jako pierwszy bank – na pewno w Polsce – wdrożył strategię Road to Cloud. Jest to zaplanowana, dalekosiężna inicjatywa, która ma za zadanie migrować do chmury te usługi, które z naszego punktu widzenia mają sens.

Inne zastosowanie usług cloud computing to często eksperymentalne projekty, na potrzeby których wynajmujemy niezbędne zasoby, prowadzimy testy, a po kilku miesiącach, kiedy projekt niekoniecznie idzie zgodnie z planem, rezygnujemy z niego. Nie wyrzucamy jednak – jak to było kiedyś – zakupionych wcześniej fizycznych serwerów, tylko zmieniamy rodzaj subskrypcji usługi cloud computing na dużo niższy. W kolejnym kroku możemy wystartować z następnym eksperymentem na innej platformie.

Jeśli chodzi o bycie pionierem przez PKO BP, to w roku 2019 byłem w innej organizacji, choć również regulowanej przez KNF. Powiem szczerze, że wtedy miałem bardzo duże obawy, aby mając rekomendację D i pozostałe regulacje, uruchamiać usługi chmurowe. Tymczasem PKO Bank Polski bardzo odważnie poszedł do przodu i – moim zdaniem – przetarł szlaki.

Obecnie, po 4 latach działania usług chmurowych w banku, zgłoszenie do KNF kolejnego projektu nie wzbudza już w nas żadnych emocji. To zwykła formalność. Nasze odważne podejście otworzyło też drogę innym do zgłaszania swoich projektów chmurowych.

Czy były już pierwsze kontrole Komisji Nadzoru Finansowego? Ktoś, z sektora bankowego mówił rok temu, że jeszcze nikt w Polsce nie przeszedł tzw. pełnego cyklu migracji do cloud computing, czyli wyjęcia z własnego centrum danych istotnego fragmentu systemów bankowych wraz z danymi klientów; wyniesienia go do chmury w zgodzie z wymaganiami Komisji Nadzoru Finansowego; uruchomienia tam migrowanego rozwiązania; korzystania z niego przez co najmniej rok; a następnie pozytywnego audytu KNF…

Tak. My kontroli z KNF mamy bardzo dużo i to na różnych poziomach. W dużej części zahaczają one o usługi, które jakimś „kawałkiem” zmigrowały do chmury, a niektóre są wręcz w całości w chmurze. Absolutnie nie mamy z tym większego problemu.

Jakie jest obecnie podejście PKO BP do chmury? Nie ma od niej odwrotu?

Reprezentuję podejście selektywnego outsourcingu i selektywnego wykorzystania usług cloud computing, by dokonywać wyboru konkretnych, pasujących rozwiązań, na zasadzie dobierania „best-of-breed”. Są więc miejsca, w których chmura absolutnie idealnie się wpasowuje, np. tam, gdzie mamy do czynienia z nagłym wzrostem obciążenia.

Nie wszystko jednak da się „uchmurowić”. Są aplikacje – szczególnie stare, legacy – które najpierw należałoby przepisać, aby pasowały do technologii cloud computing. Oprzeć je na konteneryzacji i mikroserwisach. W ich przypadku jest to zazwyczaj nieopłacalne. Trzeba więc dać tym aplikacjom dożyć końca swoich dni w infrastrukturze on-premise.

Z drugiej strony mamy obszary, które wymagają skalowalności i dynamizmu, np. w przypadku środowisk umożliwiających szybszy rozwój aplikacji, tam gdzie zaangażowanych jest wiele zespołów programistycznych. To są idealne miejsca do zastosowania chmury. Żadnego z tego typu systemów nie cofnąłbym z powrotem do środowiska on-premise. Normalnie musielibyśmy kupić potężną farmę serwerów i zwymiarować ją pod szczyt obciążeń. Teraz wybrane aplikacje przenosimy do chmury, płacąc za infrastrukturę IT tylko wówczas, kiedy jest nam potrzebna.

Jakie, Pana zdaniem, są dziś najważniejsze trendy na rynku usług cloud computing?

Po pierwsze, obserwuję tendencję, aby z chmury kupować platformy (Platform as a Service – przyp. red.) albo oprogramowanie (Software as a Service). Tego typu podejście jest często wymuszane przez dostawców, którzy nie chcą już dostarczać licencji na on-premise’owe rozwiązania. Pozwalają zaś kupować bardzo elastycznie – skalując w górę i w dół – rozwiązania z chmury.

Drugi trend to konteneryzacja. To jest standard obowiązujący w każdej chmurze, czy to Microsoft Azure, Google Cloud Platform, Amazon Web Services czy Alibaba Cloud. Konteneryzacja jest obecna wszędzie. Każdy z hyperscalerów stosuje niekiedy inne narzędzia, ale pod spodem zawsze jest ten sam, dobry Kubernetes. Dzięki niemu powstają wysokoskalowane rozwiązania, które – przy odpowiedniej konfiguracji – mogą skalować się automatycznie bez udziału administratorów.

Przykładowo, jeśli mamy do czynienia z wysyceniem naszego serwisu, bo nagle ruszyła promocja, która cieszy się dużym zainteresowaniem klientów, dzięki autoskalowaniu wpisanemu w funkcjonalność Kubernetesa, powstają nowe zasoby. To pozwala obsługiwać piki obciążenia. Kiedy zaś ruch spada, np. o godzinie 19.00, gdy klienci wrócą do domu, następuje skalowanie w dół.

Czy Kubernetes daje też łatwość migracji pomiędzy chmurami?

Zdecydowanie tak. W PKO BP postawiliśmy na bycie Cloud Agnostic. Staramy się tworzyć rozwiązania niezależne od chmur. Nasze podejście do kubernetesowych systemów i aplikacji jest oparte właśnie na takim założeniu. Jeżeli będziemy chcieli, to – stosunkowo niewielkim nakładem sił i środków – jesteśmy w stanie przerzucać się pomiędzy OCHK, naszym centrum danych lub jedną z chmur publicznych.

To jest podstawowe założenie, które przyjmujemy przy rozwoju aplikacji. Ale nie wszystko jest takie różowe. Niektóre z rozwiązań są przypisane poszczególnym dostawcom usług chmurowych, np. Machine Learning. W tym przypadku zdecydowaliśmy się wykorzystać narzędzia dostępne w konkretnej chmurze, bo uważamy, że są najbardziej dojrzałe. Tutaj więc migracja pomiędzy różnymi chmurami nie jest już taka łatwa. Wszystko, co budujemy na bazie Machine Learning, modele oparte na algorytmach sztucznej inteligencji, działa w tej chwili na Google Cloud Platform.

Czy każda chmura ma coś, czym się wyróżnia na rynku?

Tak właśnie starają się dziś działać dostawcy. W ten sposób przywiązują do siebie klientów. Z jednej strony oferują wygodne rozwiązania, dostępne tylko w ich chmurze. Z drugiej zaś dają ergonomiczne i dostosowane do ich rozwiązań podstawowe usługi, takie jak narzędzia do zarządzania infrastrukturą i kontenerami. Każdy z hyperscalers próbuje dorobić własną nakładkę i narzędzia do Kubernetesa. Google Cloud Platform oferuje usługę Anthos, a Microsoft – Azure Stack. Każda z tych usług ma własny zestaw cech. Widać więc wyścig w oferowaniu jak największej wartości dodanej dla platform kontenerowych.

Wracając do sztucznej inteligencji. Czy wszystkie rozwiązania AI stosowane przez PKO BP działają w Google Cloud Platform?

Świadomie wybraliśmy Machine Learning oparty na GCP. Po uzyskaniu wszystkich, niezbędnych zgód, w tym regulacyjnych, „wpompowaliśmy” wybrane dane naszych klientów do chmury Google. Na to nakładamy narzędzia Machine Learning, które wykorzystujemy np. do oceny ryzyka kredytowego, oceny skłonności do zakupu naszych produktów albo do zaoferowania produktu najbardziej pasującego do konkretnego klienta.

Korzystamy już 40. gotowych modeli Machine Learning, które wspierają nasze działania . Jeden z najbardziej zaawansowanych modeli analizuje wiele różnych korelacji, wyciąga z nich wnioski, buduje na ich podstawie własne modele. Widzę w naszej organizacji ogromne uznanie dla tych narzędzi wśród Data Scientistów. Są niesamowicie podekscytowani, korzystając z nich. Wypracowywane modele ML oferują dużo większe możliwości i skalowalność niż stosowane wcześniej statyczne rozwiązania on-premise.

Kiedyś żeby sprawdzić rezultaty hipotezy i wynik działania modelu Machine Learning, musieliśmy czekać czasami 10 godzin. Data Scientist przychodził do pracy, budował i uruchamiał model i często dopiero następnego dnia rano otrzymywał wynik. Teraz uruchomienie takiego modelu zajmuje średnio 3 godziny. Dla naszych pracowników to ogromna korzyść, bo mogą dowolną tezę sprawdzić i otrzymać odpowiedź na zadane pytanie jeszcze tego samego dnia, decydując, czy iść tym „tropem”, czy nie.

Po sprawdzeniu tezy takie środowisko można od razu wygasić?

Tak. Ponadto dostawcy chmury oferują podejście, które zakłada, że jeżeli będziemy używali jakąś infrastrukturę na stałe – np. przez kolejne 3 lata – to dostaniemy pakiet, który pozwoli nam kupić ją 30-50% taniej. Natomiast ze skalowania w górę i w dół korzystamy w przypadku systemów, w których obciążenia bardzo dynamicznie się zmieniają. Rozwiązania te dają spore oszczędności, a w końcu „jak nie wiadomo o co chodzi, to chodzi o pieniądze” (śmiech).

Równie łatwo jak w górę, daje się skalować infrastrukturę również w dół?

Tak, i to jest właśnie fajne w usługach cloud computing. Nie tylko skalujemy infrastrukturę IT w dół, ale – kiedy przychodzi piątek – zamykamy środowiska IT i przestajemy za nie płacić. Dzięki daleko zakrojonej automatyzacji, możemy ustawić ich ponowny start w poniedziałek o 7 rano. Po kilkunastu minutach odtwarzają się do stanu z poprzedniego piątku.

W jaki sposób jest to rozliczane? Pamiętam, jak zmieniały się modele opłat operatorów telekomunikacyjnych. Ostatecznie zeszliśmy do sekundowego rozliczania połączeń…

Mamy w pionie IT specjalny zespół, który ma za zadanie kontrolować koszty usług cloud computing. Znamy przykłady wielu firm, które nie wyłączyły bardzo zasobożernego środowiska IT, albo niewłaściwie ustawiły „drogie” parametry środowiska cloud computing. Takie osoby – po weekendzie – dziwiły się, ile korporacyjna karta kredytowa jest w stanie „przyjąć”.

A bywają usługi chmurowe bardzo, bardzo drogie, np. związane z wynajmem mocy komputera kwantowego, które mogą generować w każdej minucie koszty rzędu dziesiątek czy setek dolarów. Dlatego mamy to – nie ukrywam, po pierwszych, bolesnych doświadczeniach – odpowiednio skalibrowane. Ustawiliśmy właściwe progi, po przekroczeniu których albo trzeba dostać akceptację na dalsze rozszerzanie środowiska IT, albo w tym momencie świadomie zamykamy projekt.

Czy wspomniany przez Pana zespół kontrolujący koszty podlega pod CFO?

Do mnie raportuje w zakresie odpowiedzialności za budżet pionu IT, ale raportuje również – matrycowo – do CFO. Jeśli więc popłyniemy z kosztami chmury, to na pewno się to wyda. Nie da się tego ukryć (śmiech).

Mam odpowiedzialność za budżet, więc w moim interesie jest to, aby go optymalizować. Stąd np. decyzja o wyłączaniu środowisk IT na weekend i automatycznym ich stawianiu na początku kolejnego tygodnia. Dzięki temu spore środki pozostają na naszym koncie. Można je np. wykorzystać na sfinansowanie innych eksperymentalnych projektów.

Poza analityką, jakie jeszcze obszary biznesowe w PKO BP korzystają z usług chmurowych?

Jak w przypadku wielu innych organizacji, komunikacja z klientem. To dziś niemalże standard. Ale do chmury przerzuciliśmy również operacje kartowe. To bardzo świeży projekt, z maja tego roku. Po 2 latach prac zmigrowaliśmy z komputera mainframe do infrastruktury chmury obliczeniowej system eBankart, który odpowiada za znaczną część procesu transakcji kartami debetowymi.

Chmura pozwala nam łatwiej skalować infrastrukturę na potrzeby tego systemu w okresach zwiększonej sprzedaży, np. przed świętami Bożego Narodzenia. Za chwilę podobny projekt obejmie system do obsługi kart kredytowych. Otwiera nam to również drogę do zaoferowania nowych, bardziej innowacyjnych produktów. Dotychczasowe rozwiązanie było ich blokerem.

Projektów chmurowych jest u nas bardzo dużo. Najwięcej tych biznesowych, związanych z analizą ryzyka, analizą chęci zakupu kolejnych produktów czy zachowań klientów. Zbieramy i przekazujemy codziennie do modeli Machine Learning ok. 2,5 mld zdarzeń. Bardzo duża część z nich jest związana z zachowaniami klienta, np. tym, co robią w aplikacji mobilnej. Na tej podstawie możemy blokować potencjalne fraudy. Do roku 2025 chcemy mieć wszystkie modele ryzyka w chmurze, ponieważ widzimy z tego niesamowity uzysk.

Na czym polega uzysk w przypadku stosowania – opartych na Machine Learning – modeli analizy ryzyka?

Dla każdego banku najważniejsze jest zarządzanie ryzykiem. Chodzi o to, aby mieć duży portfel kredytów, ale kredytów bezpiecznych, które nie przestaną być spłacane. W przeciwnym razie generują ogromny koszt, a cały zysk z pożyczonego kapitału jest „zjadany” m.in. przez procesy windykacyjne. Naszym zadaniem jest uważne dobieranie klientów, którym udzielamy finansowania, i dawanie bardzo dobrych warunków tym, którzy mają niski scoring ryzyka. Natomiast w przypadku bardziej ryzykownych – wprowadzanie dodatkowych zabezpieczeń, a nawet odmawianie przyznania kredytu.

Bazując na modelach Machine Learning, jesteśmy w stanie dostrzec po stronie klienta nadchodzące problemy. Spowolnienie w gospodarce przekłada się na spowolnienie po stronie finansów przedsiębiorców. My widzimy np. prognozowane opóźnienia w spłacaniu faktur czy inne problemy związane z płynnością. Ku radości naszych Data Scientistów, widzimy matematyczne zależności dotyczące tego, kiedy i z jakim prawdopodobieństwem wystąpią dane zdarzenia.

Co z taką wiedzą można zrobić?

Jeżeli widzimy, że koniunktura w jakimś sektorze gospodarki słabnie, a przychodzi do nas po kredyt firma z tej właśnie branży, to taki produkt może być obarczony zwiększonym ryzykiem. Istnieje zagrożenie, że firmie zmniejszą się przychody i wówczas przestanie ten kredyt spłacać. To jest wiedza, która pozwala nam utrzymać bezpieczny portfel kredytowy.

Wspominaliśmy już o kontrolowaniu wydatków na chmurę. Czy PKO BP dysponuje narzędziami, które wspierają ten proces?

Mamy nasze wewnętrzne narzędzia, które zbierają i integrują wszystkie dane, także te spływające od dostawców usług cloud computing. Tego typu rozwiązania są również dostępne w modelu chmury obliczeniowej. Podobne oferują też firmy doradcze. Stworzyły nawet specjalne linie konsultingu dla tych organizacji, które niezbyt „rozsądnie” wydawały pieniądze na chmurę. My już jakiś czas temu zainwestowaliśmy w narzędzia, które kontrolują ustalone limity i progi oraz ostrzegają o możliwości ich przekroczenia.

Na co, Państwa zdaniem, inne organizacje powinny zwrócić uwagę, planując migrację do chmury?

Moja pierwsza rada – też pochodząca z własnego, bolesnego doświadczenia – to nie wierzcie w projekty Lift & Shift. Nie da się dużej aplikacji bankowej, obarczonej długiem technologicznym, przerzucić tak po prostu do chmury. To nie zadziała. A jak zadziała, to stanie się bardzo kosztownym rozwiązaniem.

Aby aplikacje poprawnie zmigrowały do chmury, muszą być albo dobrze do tego przygotowane (to niestety często jest „skórka za wyprawkę”), albo  napisane np. w technologii mikroserwisów opartej o Kubernetesa. Natywnie możemy je wówczas migrować do chmury. Dzięki temu też łatwo się skalują.

Przeprowadziliśmy w banku jeden projekt Lift & Shift. Dotyczył migracji strony internetowej. Podobnego podejścia próbowaliśmy z intranetem. Okazało się jednak ostatecznie, że łatwiej byłoby je napisać od zera.

Czy bank wewnętrznie przygotowuje się do migracji kolejnych systemów, przebudowuje architekturę następnych aplikacji na mikroserwisy, wdraża w kolejnych miejscach Kubernetesa?

Absolutnie tak! Gdy budujemy aplikacje – nawet te „lądujące” w infrastrukturze on-premise – zaczynamy od tego, aby tworzyć je na bazie mikroserwisów. Robimy to po to, aby później – kiedy zapadnie taka decyzja – można było przenieść je do chmury. Nie jesteśmy też w stanie wszystkiego zrobić naraz. Liczba naszych zespołów ma określoną i w pewien sposób ograniczoną przepustowość. Kolejne projekty trzeba planować rozsądnie, krok po kroku.

Czy dostawcy systemów dla banków są już po drugiej stronie? Dostarczają kolejne, nowe wersje swoich rozwiązań oparte już na mikroserwisach? Czy wciąż mają Państwo do czynienia z rozwiązaniami monolitycznymi, pisanymi w Cobolu…

Są tacy, którzy nie umieją inaczej robić, jak tylko bazując na mikroserwisach. Ich ludzie nie napisali nawet jednej linijki kodu w Cobolu. Ale są też takie firmy, które cały czas tradycyjnie trzymają się rozwiązań on-premise.

Jakich obszarów PKO BP nie planuje przenieść do chmury? Czy są takie w ogóle?

Na pewno do momentu, kiedy będziemy korzystali z komputera mainframe i nasz core system będzie na nim pracował, to nie wyobrażamy sobie, aby można było przenieść do chmury nasz system transakcyjny. Niemniej – jak już wspomniałem – system kartowy, który właśnie zmigrowaliśmy do chmury, pracował na komputerze mainframe i był napisany w Cobolu. Przepisaliśmy i przenieśliśmy do chmury całą aplikację. Teraz – po okresie „chorób dziecięcych” – kiedy stworzone narzędzie stanie się stabilne, będziemy mogli korzystać ze wszystkich benefitów chmury.

Mówimy o chmurze, ale zwykle dzielimy ją na chmurę prywatną i publiczną. Czy wiadomo, jaki będzie podział pomiędzy tymi dwoma rozwiązaniami w Państwa banku?

Trudno odpowiedzieć na to pytanie. Do tej pory ograniczeniem była prędkość światła. Jeśli jakieś nasze rozwiązanie miało pracować w centrum danych Google Cloud Platform we Frankfurcie, Londynie albo w Irlandii, to był problem. Teraz kiedy regiony w Warszawie uruchomiły zarówno GCP, jak i Microsoft Azure, a dodatkowo działa OCHK, to dla nas tak naprawdę jest to wybór pomiędzy jednym z wielu data center. De facto niektóre z nich są bliżej niż nasze. Z tego punktu widzenia nie dostrzegam żadnych ograniczeń, aby zmigrować kolejne systemy do chmury. Dla nas jest to wybór pomiędzy jednym, drugim czy kolejnym centrum danych.