Wszystko, co chcielibyście wiedzieć o… chmurzeProjekt Go2Cloud

Prawie pięć lat minęło w okamgnieniu, odkąd podjęliśmy decyzję o migracji aplikacji do chmur publicznych i uruchomiliśmy w naszym banku projekt Go2Cloud. Oczywiście w tak dużych przedsięwzięciach nie da się tylko wyznaczyć kierunku, w którym zmierzamy, a potem już wszystko zacznie dziać się samo…

Oto historia projektu Go2Cloud od kuchni – jego złożoność, wpływ na naszą instytucję, ale także nowy model operacyjny IT, który wdrożyliśmy, i co z niego wynika w naszej pracy. I najważniejsze – jakie benefity może przynosić naszemu biznesowi w dłuższej perspektywie. Wszystko to okraszone ciekawostkami i analizami trendów IT, które – chcąc nie chcąc – dotykają nas w każdym aspekcie życia zawodowego i prywatnego. 

Dobre IT zaczyna się od strategii…

Dla naszego banku „chmury” to nie nowość. Pierwszą dużą inicjatywę realizowaną od 2015 roku nazwaliśmy Zero Touch. Miała ona na celu wybudowanie własnej infrastruktury IT, która będzie zestandaryzowana, skalowalna, bezpieczna, optymalna kosztowo i co najważniejsze – czas dostarczenia środowisk (TTM – Time to Market) dla aplikacji będzie bardzo krótki. Tu jestem Wam winien kilka wyjaśnień i definicji, bo… chmura chmurze nierówna. 

Pojęcie „bank z głową w chmurach” to już nie nowość, to trend, który rewolucjonizuje sektor bankowy, umożliwiając szybsze wprowadzenie innowacji, większą skalowalność i lepszą obsługę klienta, ale także codzienne pragmatyczne podejście, które powinniśmy traktować jak stałą ewolucję usług IT.

Czym jest „magiczna” infrastruktura IT

Dlaczego jedną infrastrukturę IT nazywamy „chmurą”, a drugą  serwerami postawionymi w Data Center? Wiecie, że do roku 2017 nie mieliśmy jednoznacznych definicji?! Dopiero tzw. Komunikat Chmurowy UKNF w drugiej wersji wprowadził definicję chmury i podzielił ją na trzy grupy: chmury prywatne, społecznościowe oraz publiczne, wskazując także na możliwość hybrydowości, czyli mieszania lub łączenia takich środowisk. 
To było dla nas bardzo ważne w tym okresie, ponieważ limitowało sposób wykorzystania tej infrastruktury i przetwarzania danych, porządkowało rynek dostawców i narzucało na instytucje regulowane z jednej strony obowiązki, z drugiej zaś skłaniało do dobrej analizy ryzyka. Komunikat KNF już niestety nie obowiązuje i jego zapisy przejęły inne regulacje lokalne i europejskie, ale instytucje, które kiedyś się do niego przystosowały procesowo i spełniały jego wymagania, są dobrze przygotowane na przyszłość. 

Wracając do definicji chmury…

Chmura obliczeniowa to pula współdzielonych, dostępnych „na żądanie” przez sieci teleinformatyczne, konfigurowalnych zasobów obliczeniowych (np. sieci, serwerów, pamięci masowych, aplikacji, usług), które mogą być dynamicznie dostarczane lub zwalniane przy minimalnych nakładach pracy zarządczej i minimalnym udziale ich dostawcy – tak brzmi definicja techniczna chmury.
Z tej „archiwalnej” (w rozumieniu regulacji), ale cały czas aktualnej technicznie definicji jednoznacznie widzimy, że Chmurę charakteryzuje współdzielenie i dynamiczne dostarczanie lub zwalnianie zasobów i minimalizacja pracy zarządczej, czyli w przełożeniu na nasz język – maksymalna automatyzacja tam, gdzie to tylko jest możliwe.  

W czym więc był problem i wyzwanie?

Ktoś mógłby powiedzieć: jak już mieliśmy własną chmurę prywatną, wystarczyło przenieść to, co tam mamy, do chmury publicznej, zachowując wymogi bezpieczeństwa, i sukces murowany. 

W chmurach publicznych powinniśmy do maksimum wykorzystać idee płacenia tylko za faktycznie wykorzystywane zasoby, to tzw. zasada pay-as-you-go.

Sprawa na pierwszy rzut oka wydaje się prosta, jednak aby to się opłacało, w chmurach publicznych powinniśmy do maksimum wykorzystać idee płacenia tylko za faktycznie wykorzystywane zasoby, to tzw. zasada pay-as-you-go. W praktyce oznacza to, że aplikacja w zależności od obciążenia ilością pracy (np. transakcjami klientów) potrafi samodzielnie się powiększać lub zmniejszać – my to w IT nazywamy dynamicznym skalowaniem zasobów aplikacji. Dzięki takiemu podejściu potrafimy także zadbać o wydajność i odporność w tzw. godzinach szczytu, gdyż aplikacja automatycznie dostosuje swój rozmiar do potrzeb wynikających z liczby transakcji czy przetwarzanych danych. 

Pryncypium chmurowe? Konteneryzacja! 

Takie możliwości skalowania dają nam tylko aplikacje, które przygotowaliśmy w bardzo konkretny sposób. Polega on na tym, że każdą z funkcji aplikacji wydzieliliśmy w postaci tzw.  kontenera, który w zależności od potrzeb może być powielony (skalowany) tyle razy, ile w danej chwili potrzebujemy. To powielanie kontenerów jest bardzo szybkie oraz automatyczne i im lepiej dostosowaliśmy parametry takiego kontenera do funkcji, którą realizuje, tym bardziej jest to optymalne z punktu widzenia wydajności aplikacji czy kosztów.
Jak widzicie, takie przygotowanie aplikacji (ich konteneryzacja) to jedno z wyzwań projektu, a jednocześnie pryncypium architektoniczne i element strategii chmurowej.

Różne możliwości przechowywania i udostępniania

Kolejnym elementem aplikacji, który musieliśmy uwzględnić w modelowych architekturach, są dane, które aplikacja przetwarza. Dostawcy chmur publicznych dają nam różne możliwości ich przechowywania i udostępniania oraz różne technologie – od baz danych dostosowanych do wolumenów i szybkości przetwarzania po tzw. wiaderka na dane plikowe/obiektowe.

Nie przenosimy aplikacji 1:1, tylko robimy refaktoryzację i optymalizujemy ich działanie.

Głównymi parametrami, które charakteryzują dane, są szybkość dostępu do nich oraz retencja (czas życia), poziom kompresji (upakowania) przekładający się na zajmowane miejsce, czyli koszty, no i oczywiście format ich przechowywania. Technologie także mają tu znaczenie, bo część z nich jest unikalna i dostępna tylko u konkretnych dostawców, czyli ich przenoszenie między chmurami nie jest możliwe, a część technologii jest uznawana jako standard tzw. multicloud i może być używana niezależnie od dostawcy. 

„Wiaderka na dane” i czas „chomikowania”

Naszym zadaniem w projekcie było przede wszystkim wybranie takich rozwiązań technologicznych, które są uniwersalne i ich użycie będzie możliwe w każdej chmurze. Dodatkowo patrząc na architektury i sposób pracy aplikacji z danymi, za każdym razem zastanawiamy się wspólnie z programistami, czy dana technologia jest optymalna w tym zastosowaniu, czyli czy dane muszą być bardzo szybko dostępne dla aplikacji (wtedy używamy wybranej „szybkiej” bazy danych), czy mogą one być trochę wolniej dostępne i wówczas używamy wspomnianych wcześniej „wiaderek na dane”. 

Koszt danych różnego typu w dłuższej perspektywie jest największym kosztem w chmurach.

Oczywiście kolejnym kryterium jest czas przechowywania, tzw. retencji danych – w tym wypadku najlepiej, gdy działają automaty, które dbają o to, by dane już niepotrzebne były z zachowaniem wszystkich procedur bezpiecznie usuwane. Dla instytucji takich jak nasz bank koszt danych różnego typu w dłuższej perspektywie jest największym kosztem w chmurach i w każdej strategii powinien być uwzględniany i dobrze zarządzany. 

Milisekundy mają znaczenie

Budując nowe chmurowe rozwiązanie, nie mogliśmy zapomnieć także o tym, że będziemy rozciągali komunikację aplikacji między różnymi ośrodkami przetwarzania danych. Nie jest to duży problem, jeżeli uwzględnimy prędkość światła 😉. Może się to wydawać zabawne, ale wynika z podstawowych zasad fizyki i opóźnień komunikacji adekwatnej do odległości geograficznej, a tak naprawdę długości linii światłowodowych i urządzeń, które są na poszczególnych węzłach komunikacyjnych dostawców. 

Im bardziej skrócimy czas „rozmowy” między poszczególnymi komponentami naszych aplikacji, tym lepiej.

Ktoś mógłby zapytać: czy 5, 10, 20 ms (milisekund) ma znaczenie? Oj tak, zdecydowanie ma i im bardziej skrócimy czas „rozmowy” między poszczególnymi komponentami naszych aplikacji, a na koniec między urządzeniem naszego klienta (telefonem/laptopem) i naszymi Data Center, tym lepiej.

Cloud SecOps na straży bezpieczeństwa

Jak skrócić czas „rozmowy”? Przede wszystkim tak grupując aplikacje i ich moduły, aby sieciowo były blisko siebie. A tam gdzie komunikacja (zależność od czasu) ma mniejsze znaczenie, możemy pozwolić sobie na jej rozciągnięcie geograficzne. To także jest jedno z kryteriów, które bierzemy pod uwagę, układając harmonogram migracji, i na które bardzo zwracamy uwagę architektom. 
Musimy także pamiętać, że o ile dostawcy chmur publicznych bardzo chętnie i bez dodatkowych kosztów przyjmują komunikację przychodzącą do chmur, o tyle w drugą stronę, czyli z chmur do lokalnych centrów danych, sprawa wygląda już zupełnie inaczej i tu płacimy za liczbę przesyłanych danych.   

Dobre zabezpieczenie infrastruktury i uodpornienie jej na wszelkiego rodzaju ataki to rola Cloud SecOpsa.

Mówiąc o sieciach komputerowych, nie możemy zapominać, że chmury publiczne z założenia „stoją” w internecie i to właśnie internet jest podstawowym medium dostępowym z i do chmur. Krytyczne w takiej sytuacji staje się dobre zabezpieczenie takiej infrastruktury i uodpornienie jej na wszelkiego rodzaju ataki. To rola Cloud SecOpsa, czyli specjalisty na styku bezpieczeństwa infrastruktury chmurowej i aplikacji. 

Najtrudniejszy element? Kryptografia

Elementy zabezpieczenia używanych serwisów, ciągłego ich monitorowania oraz nadzoru konfiguracji to potężna wiedza i wiele technologii, dla których musieliśmy wspólnie przygotować architekturę, wdrożyć ją i ciągle rozwijać oraz udoskonalać. Użycie bezpiecznej kryptografii zapewniającej adekwatne poziomy szyfrowania danych i zgodnej z wymogami regulatorów to chyba koncepcyjnie najtrudniejszy element, nad którym pracowaliśmy bardzo długo – wszystko po to, by być pewnym, że dane naszych klientów są bezpieczne.

Elementy zabezpieczenia używanych serwisów, ciągłego ich monitorowania oraz nadzoru konfiguracji to potężna wiedza i wiele technologii.

Wszystkie te ustalenia, o których napisałem wyżej, dotyczące z jednej strony zaleceń architektonicznych, a z drugiej opisu wykorzystywanych serwisów, ich typów i parametrów zebraliśmy w dokumencie, który jest swego rodzaju katalogiem lub ofertą dla naszych programistów i architektów i jego modyfikacje odbywają się w ramach prac Komitetu Architektury IT.

Przepis na dobrą aplikację i wdrożenie

Czasami żartuję, że nasze serwisy chmurowe bardzo przypominają klocki Lego, z których każdy architekt lub programista może złożyć infrastrukturę dla swojej aplikacji. Każdy z tych „klocków” jest opisany pod względem jego parametrów i zalecanej konfiguracji, ale także tego, co wszyscy znamy jako BIA lub CIA, czyli jaki maksymalny poziom bezpieczeństwa zapewnia nam dany serwis (C – Confidentiality), czy mamy wsparcie dla sprawdzania integralności danych (I – Integrity) oraz jaki maksymalny poziom dostępności gwarantuje dostawca chmurowy tego serwisu lub jego przyjęte parametry (A – Availability). 

Nasze serwisy chmurowe bardzo przypominają klocki Lego.

Wszystko to złożone w przykładowe architektury referencyjne stanowi przepis na dobrą aplikację i wdrożenie w chmurze.

Trzymamy rękę na pulsie

Powinniście wiedzieć, że z każdym nowym wdrożeniem aplikacji realizujemy specjalnie dla potrzeb tego projektu spotkania warsztatowe, które nazywamy DeepDive’em architektonicznym. Polegają one na tym, że po zgłoszeniu aplikacji do migracji architekt za nią odpowiedzialny wraz z programistami prezentuje jej aktualną architekturę i wspólnie z całym zespołem specjalistów, technologów i architektów analizujemy, co należy zmienić lub uwzględnić podczas migracji do chmury. 
Spotkania te są podstawą do rozpoczęcia prac i z racji doświadczenia, które zdobyliśmy przez ostatnie lata, wiemy, na co zwracać szczególną uwagę. Taka check lista pozwala nam także ocenić, z jaką pracochłonnością przy tych modyfikacjach aplikacji będziemy mieli do czynienia i czy wraz z nowym wdrożeniem pojawia się potrzeba nowego serwisu w chmurze.

Gdy już mamy strategię i pryncypia architektoniczne, to co dalej?

Kolejnym elementem był model operacyjny utrzymania infrastruktury w chmurze, który pozwoliłby nam maksymalnie wykorzystać z jednej strony dynamikę powoływania zasobów, a z drugiej zapewniłby powtarzalność działań i konfiguracji, zgodność z procesami utrzymania, zarządzania zmianą, pojemnością, ale także dostarczy dowodów dla procesów kontrolnych.

Pryncypium  jest maksymalna automatyzacja działań polegająca na tym, że całą infrastrukturę w chmurze zapiszemy jako „kod aplikacji” (IaC – Infrastructure as Code).

Pryncypium, które tu przyjęliśmy, jest maksymalna automatyzacja działań polegająca na tym, że całą infrastrukturę w chmurze zapiszemy jako „kod aplikacji” (IaC – Infrastructure as Code), a następnie ten kod „przekazujemy” do chmury z wykorzystaniem jej mechanizmów (API), by ta infrastruktura tam powstała. Takie podejście gwarantuje nam, że zawsze wiemy o wszystkich zmianach, bo tylko tą drogą możemy je robić, posiadamy cały czas spójną konfigurację całego środowiska i – co najważniejsze – kod ten jest podzielony na moduły, które można utrzymywać niezależnie w ramach zespołów technologicznych. 

Stworzyliśmy rolę Cloud DevOpsa… 

I tu płynnie z modelu operacyjnego przechodzimy do modelu organizacji pracy IT, gdzie stworzyliśmy rolę Cloud DevOpsa, czyli specjalisty będącego na styku programistów utrzymujących aplikację i infrastrukturę. 
To jest bardzo ważna rola, wymagająca szerokiej wiedzy – zarówno aplikacyjnej związanej z funkcjami biznesowymi i ich wzajemnymi zależnościami, programistycznej, która powinna obejmować świadomość np. wykorzystywanych bibliotek czy optymalizacji kodu, jak i infrastrukturalnej, bo bez tego wdrożenie aplikacji może nie być optymalne. 
To DevOps w odsłonie aplikacyjnej odpowiada za całość wdrożenia i jego powodzenie w pierwszych godzinach po migracji, a potem o utrzymanie i optymalizację w czasie, ale pamiętajmy, że nie jest sam i ma cały czas wsparcie realizowane przez zespół centralny (DevOps Cloud Team) i zespoły DevOps Technologiczne, które współpracują ze sobą.

To DevOps w odsłonie aplikacyjnej odpowiada za całość wdrożenia i jego powodzenie w pierwszych godzinach po migracji.

Ten model pracy biegnący na wskroś struktury organizacyjnej pionu CIO jest oparty przede wszystkim na optymalnym wykorzystaniu kompetencji i przypomina metodologią Chapter Cloud DevOpsowy, ale z racji tego, że praca operacyjna w ramach migracji oraz zadania R&D (Research and Development) wymagają cały czas dyscypliny planowania zadań w ramach QBR i sprintów, ma on bardziej formalny charakter, w którym prowadzimy swój backlog i wspólne planowania kolejnych działań.

Domknięciem całości jest tzw. warsztat powdrożeniowy

Nie możemy także zapominać, że cały proces przeniesienia aplikacji do chmury nie kończy się tylko w dniu wdrożenia. Domknięciem całości jest tzw. warsztat powdrożeniowy, który odbywa się najczęściej kilka tygodni po przejściu aplikacji do nowego środowiska. Na tym warsztacie sprawdzamy z zespołem migracyjnym, czy wszystkie parametry pracy aplikacji przez ostatnie tygodnie (mimo jej poprawnego działania) są optymalne, zalecamy ewentualne poprawki i staramy się wyciągać wnioski, co jeszcze można zoptymalizować w środowisku na przykładzie tych wdrożeń na przyszłość. 

Cały proces przeniesienia aplikacji do chmury nie kończy się w dniu wdrożenia.

Podstawą we wszystkich tych działaniach jest dzielenie się wiedzą, doświadczeniami i pomysłami. Specjalne spotkania, które nazwaliśmy Ask The Experts, to forum, gdzie nie ma złych pytań. Tu każdy zainteresowany tematem chmury może być jednocześnie ekspertem, bo ma już doświadczenie wdrożeniowe, i może także zapytać innych kolegów i koleżanki, jak coś zrobić, wskazać pomysły optymalizacyjne czy zmiany w serwisach na przyszłość.  Frekwencja na tych spotkaniach i interakcje potwierdzają, że potrzebujemy takiej przestrzeni i ta inicjatywa była strzałem w dziesiątkę.  

Kto to taki ten FinOps? 

To DevOps, który specjalizuje się w optymalizacji kosztowej serwisów chmurowych, ale nie tylko. Pracuje on z danymi finansowymi i księgowymi, które generują automatycznie dostawcy chmury jako cząstkowe wydatki użycia zasobów i serwisów. 

Od początku projektu położyliśmy także bardzo duży nacisk na rolę FinOpsa. 

Jest to bardzo duży zbiór danych, który dobrze zarządzany i opisany modelem naszej organizacji (struktury tribe’ów i aplikacji), pozwala z jednej strony bardzo szybko wskazać obszary największych kosztów, podzielić je na technologie, przypisać do aplikacji lub modułów i z dokładnością do 1 centa wskazać nam z dnia na dzień, czy zmiany w środowisku idą w dobrym kierunku, ile kosztuje nas aplikacja, ile jej składniki, co możemy zoptymalizować oraz co wymaga działań na poziomie całej organizacji. 

Model FinOps wyróżnia nas w skali światowej i niezależni audytorzy, którzy badali pod względem finansowym naszą chmurę, podkreślali dojrzałość tego procesu i pomysłu na niego.

To wszystko ubrane w świetną wizualizację typu drill down robi tak unikalne wrażenie, że śmiało mogę powiedzieć, że model FinOps nas wyróżnia w skali światowej i niezależni audytorzy, którzy badali pod względem finansowym naszą chmurę, podkreślali dojrzałość tego procesu i pomysłu na niego. To dzięki tym narzędziom zaprezentowaliśmy w zeszłym roku szereg inicjatyw w ramach ESG, z których część – jak optymalizacja logów aplikacji lub zmiana struktury klastrów (GKE) – już przynosi efekty w postaci mniejszych kosztów, a opiekunowie aplikacji na tej podstawie organizują swoje budżety i ich predykcję na przyszłość. 
Tu cały czas jest coś do poprawy, więc podobnie jak inne procesy utrzymaniowe FinOps ma znaczącą rolę, która w wielu raportach firm analitycznych jest wskazywana jako coś, o czym zapomniano przy wdrożeniu, a potem naprawa tego procesu jest bardzo trudna – my nie zapomnieliśmy 😉, więc jest się czym chwalić.

Benefity, które dają chmury publiczne

Na koniec wrócę do benefitów, które dają nam chmury publiczne. Trzy lata temu nie byłem tego jeszcze pewny, ale teraz wiem, że najważniejszymi zaletami, które dają nam chmury publiczne, są: mnogość skalowalnych serwisów, rozproszenie geograficzne oraz bardzo duża możliwość dostosowania i optymalizacji kosztowej. 
Wymaga to jednak zmian w organizacji i modelu wdrożeniowego zarządzania ryzykiem adekwatnie do jego poziomu. I co najważniejsze – stałego rozwoju kompetencji. Dynamika zmian i nowych funkcji, serwisów i usług w chmurach jest tak duża, że nie dziwię się, dlaczego dostawcy wymagają odnawiania certyfikatów inżynierskich i architektonicznych naszych specjalistów w cyklach rocznych lub dwuletnich.

Koszty utrzymania w chmurach dla dobrze przygotowanych aplikacji mogą być niższe, ale wymaga to ciągłej dyscypliny.

Już wiemy, że koszty utrzymania w chmurach dla dobrze przygotowanych aplikacji mogą być niższe, ale wymaga to ciągłej dyscypliny, dbania o wyłączanie czy reskalowanie zasobów, kiedy ich nie używamy.
No i na koniec to, co najważniejsze – stabilna i bezpieczna praca naszych aplikacji to mniej przerw w ich działaniu wynikających z awarii, a co za tym idzie, większe zadowolenie naszych klientów, a dla nas, utrzymujących tę infrastrukturę, odpowiednio mniej stresu i możliwość skupienia się na rozwoju i optymalizacji.

Podsumowując korzyści, chmury publiczne to:

• Szybkość i elastyczność
• Innowacyjność
• Efektywność kosztowa
• Bezpieczeństwo i odporność

Zapraszamy do kontaktu

Mam nadzieję, że tym krótkim artykułem zainteresowałem Was chmurami i ich wykorzystaniem w naszym banku. Jeżeli macie pytania lub chcecie dowiedzieć się więcej na ten temat, to zapraszam do kontaktu. Wspólnie z całym naszym zespołem chętnie na nie odpowiemy.

Michał Jurga
IT Area Lead, DevOps Cloud Team