Ile firm, tyle powodów migracji do chmury - część organizacji decyduje się na nią z chęci modernizacji stosu technologicznego, inne opracowują nowe modele biznesowe, niemożliwe do realizacji bez odpowiednich, nowoczesnych rozwiązań, jeszcze inne szukają oszczędności. Niezależnie od motywacji, na samym początku migracji należy precyzyjnie zidentyfikować swoje potrzeby biznesowe oraz - w wypadku braku kompetencji - poszukać odpowiedniego partnera. To niektóre z wniosków płynących z 8. sesji strategicznej programu CIONET Cloud Excellence.

Za nami ósma z kolei, a pierwsza w 2024 r., sesja programu CIONET Cloud Excellence. W trakcie sesji z prelekcjami wystąpili Zuzanna Dylęgowska, Cloud Engineering Director w Procter & Gamble; przedstawiciele Europa Ubezpieczenia – Grzegorz Pawlicki, członek zarządu odpowiedzialny za IT i operacje i Łukasz Zięba, Cloud Architect; Dariusz Kazimierski (dyrektor Departamentu Innowacji Technologicznych) i Jakub Kusztelak (kierownik IT) z PKO BP Faktoring oraz Robert Skica, manager Działu Koordynacji Wdrożeń i Rozwoju Usług IT w Credit Agricole Bank Polska.

Chmura w firmach różnej wielkości

Zuzanna Dylęgowska na bazie własnych doświadczeń i obserwacji opisała różnice w sposobie używania chmury między firmami enterprise, a małymi i średnimi przedsiębiorstwami.

W aspekcie operacyjnym różnica polega na zakresie, w jakim organizacje wykorzystują cloud. W dużych przedsiębiorstwach funkcjonuje bardzo dużo różnych przepływów pracy, które chmura musi być w stanie obsługiwać. Dlatego firmy takie szukają chmur z największym wachlarzem narzędzi, które mogą być wykorzystywane do różnych procesów biznesowych – od pozyskania danych dla po zaawansowane AI/ML.

Zazwyczaj kością niezgody między przedsiębiorstwami enterprise, a dostawcami chmurowymi, jest umowa Service Level Agreement, która określa przewidywalność oraz możliwość oceny potencjalnej niedostępności usług, a w konsekwencji strat biznesowych (dostawcy chmury zwykle zapewniają o szybkim reagowaniu na problemy, lecz nie zawsze informują, jak długo potrwa ich rozwiązywanie, co zwykle jest źródłem nieporozumień).

Firmy z sektora MŚP są natomiast skupione na swoim głównym biznesie i są w związku z tym dużo bardziej zwinne i precyzyjne.

Dla odmiany, w wymiarze organizacyjnym w firmach mniejszej wielkości można zauważyć dużo szerszą ekspertyzę – z racji ograniczonych zasobów ludzkich. Firmy, nie mogąc sobie pozwolić na luksus zatrudniania specjalistów zajmujących się tylko aplikacjami czy infrastrukturą, niejako naturalnie i organicznie rozwijają podejście DevOps. Infrastruktura jest zaś budowana tak, aby jej obsługa była możliwie jak najbardziej bezproblemowa czy nieangażująca – bo po prostu nie ma komu tego robić.

W przypadku dużych przedsiębiorstw często i naturalnie występują wewnętrzne struktury takie jak „community of practise”, centra doskonałości czy inżynierii niezawodności. Znów – wynika to ze skali. Przy tysiącach aplikacji trzeba dokładnie pilnować spójnej implementacji różnych architektur, szczególnie jeżeli firma ma oddziały rozsiane po różnych lokalizacjach. Niezwykle istotne jest też posiadanie umiejętności w zakresie automatyzacji.

Jeżeli chodzi o zarządzanie kosztami chmury, to, zdaniem Zuzanny Dylęgowskiej, w MŚP niejako naturalnie wykształca się podejście FinOps.

Z moich dotychczasowych doświadczeń współpracy z różnymi firmami wynika, że kluczowym aspektem było ocenianie kosztów chmurowych już na etapie planowania architektury oraz ciągła kontrola i weryfikacja tych kosztów – mówiła.

W dużych firmach kwestia kosztów w chmurze jest bardziej złożona. Przykładowo, na początku migracji chmurowej w Procter&Gamble ustalono, że motywacja oparta jedynie na redukcji kosztów nie jest wystarczającym powodem do przeprowadzenia migracji. Koszty nie ograniczają się bowiem jedynie do infrastruktury – uwzględniają one całkowity koszt posiadania (TCO), czyli zarówno zarządzanie, jak i obsługę infrastruktury.

Ponadto w dużej firmie istnieje wyzwanie związane z kontrolą kosztów, ponieważ często brakuje poczucia indywidualnej odpowiedzialności za ich nadmierną generację. Choć podejście do FinOps może być ustalone z dostawcami, to różnorodność aplikacji i procesów w takiej skali skutkuje nieuniknionymi różnicami w kosztach, których nie ma w przypadku MŚP. W kontekście tysięcy aplikacji i dziesiątek tysięcy osób korzystających z infrastruktury, kluczowe jest ustalenie, kto jest odpowiedzialny za generowane koszty poszczególnych aplikacji.

Istotne różnice między MŚP, a enterprise zachodzą też w obszarze bezpieczeństwa. U tych pierwszych bezpieczeństwo i zgodność z przepisami wydają się być ostatnimi na liście kwestii do poruszenia (mniejsze organizacje opierają się na założeniu, że te elementy są wbudowane w chmurę).

Natomiast w dużych przedsiębiorstwach bezpieczeństwo zawsze stoi na pierwszym miejscu. Istnieją rozbudowane wewnętrzne struktury ds. bezpieczeństwa informacji, które pilnują najlepszych praktyk i ustalają standardy.

W dużych firmach jesteśmy bardziej świadomi ryzyka, często spotykamy się z rzeczywistymi próbami ataków hakerskich – w przeciwieństwie do MŚP, gdzie profil ryzyka jest znacznie niższy – podkreślała przedstawicielka Procter & Gamble.

Jeśli jednak porównać oczekiwaną wartość ataku, uwzględniając prawdopodobieństwo i ewentualną stratę zysków, okazuje się, że ryzyka i w enterprise, i MŚP są porównywalne. Duże przedsiębiorstwo może szybciej zareagować i minimalizować szkody, ponieważ atak nie dotknie wszystkich obszarów biznesowych. Natomiast w MŚP atak może dotknąć wszystkich procesów. Dlatego warto, aby MŚP uczyły się na podstawie doświadczeń dużych przedsiębiorstw, które już miały styczność z takimi ryzykami.

Jak chmura pomaga rozwijać nowe modele biznesowe

Europa Ubezpieczenia w 2022 r. podjęła decyzję o strategicznej transformacji cyfrowej. Cel? Konkurencyjność firmy takiej jak ten ubezpieczyciel, skoncentrowanej na partnerstwach, leży w zwinnych procesach wspieranych przez prostą, łatwo modernizowaną i skalowalną technologię. Decyzja ta była spustem, którego wciśnięcie uwolniło jednocześnie potencjał na partnerstwa pan-europejskie w modelu embedded insurance, które Europa Ubezpieczenia rozwija od 2023 r. pod marką HDI Embedded. To nowy model oferowania ubezpieczeń wbudowanych w usługi partnerów, gdzie kluczowa jest zdolność ubezpieczyciela do integracji z różnorodną infrastrukturą partnerów.

Zgodnie z założeniem, że embedded insurance nie jest możliwe do zrealizowania w infrastrukturze on-premise, rozpoczęto poszukiwania dostawcy chmurowego - zaczynając od oszacowania kosztów chmury.

Następnie, w oparciu o opracowane przypadki użycia rozpoczęto warsztaty z głównymi dostawcami chmurowymi.

Mieliśmy 4-5 use-case'ów, które postanowiliśmy odtworzyć w każdej z chmur i sprawdzić, jak łatwo będzie się je wdrażało i ile będą kosztować. Od samego początku zależało nam na wielochmurowości, więc patrzyliśmy na dostawców pod tym kątem.– wspominał Łukasz Zięba.

Jednym z głównych założeń platformy była możliwość szybkiego podłączenia partnerów. Dlatego też priorytetem było zapewnienie interfejsów API oraz funkcji „white label”. Kolejnym istotnym elementem były dane.

Informacje dotyczące sprzedaży, klientów są potrzebne do analizy ryzyka, dopasowania oferty do procesu zakupu podstawowej usługi albo produktu, które kupują klienci naszych partnerów oraz obsługi klientów i roszczeń. W związku z tym platforma została zaprojektowana tak, aby oferować kompleksową paletę usług. Dodatkowo, w naszej strategii zdefiniowaliśmy, że platforma powinna być wielochmurowa – mówił Grzegorz Pawlicki.

Początkowo część infrastruktury firmy była on-premise, obejmując podstawowy system ubezpieczeń, narzędzia wspierające, hurtownię danych, konektory do systemów partnerów oraz systemy zewnętrzne. Jednak zgodnie z nową strategią wszystkie nowe aplikacje wspierające procesy biznesowe miały być rozwijane w chmurze.

Dlatego też, jako centrum dla usług embedded insurance, w tym także dla API oraz całego stosu technologicznego, postanowiliśmy na wstępie wykorzystać rozwiązania oferowane przez Google – podkreślił Grzegorz Pawlicki.

Obecnie firma korzysta też już z narzędzi oferowanych przez Microsoft Azure.

Plany na przyszłość obejmują przeniesienie do chmury systemu likwidacji szkód do chmury, i stopniową dekompozycję pozostałych elementów infrastruktury on-premise.

W kwestii architektury nie wynajdywaliśmy koła na nowo, tylko skupiliśmy się na tym, jak dostosować to, co znamy, do naszych wymagań. Nie traktujemy chmury jako data center – unikamy maszyn wirtualnych tak bardzo, jak możemy, a naszą docelową architekturą jest budowa platformy aplikacyjnej – podsumował Łukasz Zięba.

Chmura i co dalej?

W PKO Faktoring, po wydzieleniu się kilka lat temu jako odrębna spółka w strukturach grupy PKO BP, również przyszedł czas na decyzję – co dalej z infrastrukturą (firma przez pewien czas korzystała z infrastruktury grupowej).

PKO Faktoring, będąc na początkowym etapie działalności jako osobna jednostka, musiała bardzo uważnie zarządzać finansami. Duży nacisk był kładziony na optymalizację i kontrolę kosztów. Dodatkowo, jako część grupy PKO BP, spółka musiała sprostać wysokim standardom dotyczącym cyberbezpieczeństwa, obowiązujących w grupie. Nowa infrastruktura musiała być i stabilna i bezpieczna.

Byliśmy w punkcie, w którym musieliśmy zdecydować, czy pozostać przy dotychczasowej infrastrukturze on-premise czy przenieść się do chmury. Na początku chmura nie była dla nas oczywistym wyborem. Jednakże na etapie szczegółowej analizy możliwych wariantów okazałoo się, że przeniesienie do chmury jest dla nas korzystne – wspominał Dariusz Kazimierski.

Projektowi migracji towarzyszyły jednak dwa warunki brzegowe: nieprzekraczalny budżet (nawet kosztem czasu realizacji projektu) oraz utrzymanie dynamiki rozwoju firmy.

Analiza kosztów wykazała, że przeniesienie do chmury nie będzie droższe od utrzymania infrastruktury on-premise. Co więcej, biorąc pod uwagę szybki wzrost firmy, decyzja o migracji do chmury okazała się bardzo trafna ze względu na możliwość skalowania. Uznano za to, że w kontekście skali działalności firmy nie ma potrzeby stosowania kilku chmur różnych dostawców.

Jedna z lekcji, jakie wynieśliśmy z projektu, jest taka, że wsparcie doświadczonego partnera jest nieocenione. Oprócz dostępu do szerokiej wiedzy można również polegać na jego rozwiązaniach w zakresie bezpieczeństwa. W procesie migracji kluczową rolę odgrywała też komunikacja. Zapewniliśmy, że zarząd i pracownicy byli świadomi postępów i potencjalnych problemów, co pozwoliło nam szybko reagować i podejmować działania korygujące - podkreślał Jakub Kusztelak.

Lekcja trzecia: niezbędnym elementem każdego projektu migracyjnego jest plan awaryjny, ponieważ migracja może powodować niezaplanowane wyzwania technologiczne.

Myśleliśmy, że przejście do chmury będzie szybkie, jednak okazało się, że proces ten wymaga refaktoringu i dostosowania infrastruktury do nowych warunków – przyznał Jakub Kusztelak.

Wnioski wyciągnięte z doświadczeń PKO Faktoring wskazują, że migracja do chmury metodą lift&shift może być korzystna w wypadku firm potrzebujących szybkiego rozwiązania, które nie planują natychmiastowego przejścia na rozwiązania Platform as a Service. Jednakże w przypadku obrania długoterminowej strategii chmurowej bardziej uzasadnionym rozwiązaniem może być refaktoring usług i aplikacji. W PKO Faktoring W przypadku PKO Faktoring najbardziej optymalne okazało się budowanie infrastruktury w oparciu o IaC.

Istotnym składnikiem całego procesu było zapewnienie rozwoju zespołowi IT równolegle z rozwojem całej organizacji. Pozostanie przy infrastrukturze on-premise ograniczałoby ten rozwój, uniemożliwiając zespołowi dostęp do nowych technologii i rozwiązań, które firma chciała wprowadzić – tłumaczyli przedstawiciele PKO Faktoring.

Projekt został zakończony w grudniu 2023 r. Obecnie PKO Faktoring jest pierwszą spółką z grupy PKO BP, która działa całkowicie w chmurze oraz pierwszym faktorem bankowym na polskim rynku, który ma tę migrację za sobą.

Najpierw potrzeba, potem technologia

Jak mówił Robert Skica, FinOps w Dziale Koordynacji Wdrożeń i Rozwoju Usług IT w Credit Agricole Bank Polska zaczął się od jednej faktury za usługi chmurowe, którą było trudno rozliczyć.

Chociaż jesteśmy organizacją enterprise, działamy globalnie, a grupa pomaga nam z dostawcami cloudowymi, to jednak dotykamy problemów typowo operacyjnych, czyli kosztów. W ramach kontraktu, jako departament z naszą dywizją, dostaliśmy jedną kwotę z miesięcznym zużyciem i pozycją globalną. Nie wiedzieliśmy, jak to podzielić na żadne formaty. Zastanawialiśmy się, jak zaprezentować dane i wpadliśmy na pomysł, żeby użyć do tego PowerBI - wspominał.

Na potrzeby odpowiedniego rozdzielenia kosztów organizacja musiała znać dokładny podział usług po subskrypcjach. Wymagało to należytego oznaczania zasobów (tagowania). Z kolei do odpowiedniego tagowania konieczne było wprowadzenie odpowiednich polityk. Pojawiła się zatem potrzeba organizacyjna.

Pomoc w projekcie zaoferowały zespoły infrastruktury. Powstał zespół zwinny (formalnie w strukturze organizacyjnej banku nie ma zespołu FinOps) na poziomie którego ustalono zakresy odpowiedzialności. A na koniec cały proces zdecentralizowano.

Realizacja projektu doprowadziła do sytuacji, w której po wpłynięciu faktury kosztowej można ją przeanalizować w formie zestawienia z podziałem według hierarchii tagów na miejsca powstawania kosztów, czyli numery księgowe, a następnie weryfikować wszystkie środowiska. W ten sposób każdy dział może natomiast samodzielnie wyklikać, za co płaci.

Cloud Excellence – o programie

Program Cloud Excellence to inicjatywa poświęcona zagadnieniom związanym z wdrażaniem technologii chmurowych w organizacjach, powołana przez CIONET w 2022 r. Uczestnicy programu spotykają się na cyklicznych sesjach strategicznych oraz warsztatach. Partnerami programu są AWS, Cloudware, HP Enterprise, IBM, Red Hat, PwC i Tameshi.

Więcej informacji o zbliżającej się sesji strategicznej: https://www.cionet.com/cloudexcellence/9sesja

Więcej informacji o programie: https://www.cionet.com/pl-pl/cloudexcellence

LINKEDIN: https://www.linkedin.com/showcase/cloudexcellencepl/