W technologiach stosujemy zasady: buy over build, adopt not adapt

Z Łukaszem Strzelcem, Global Tribe Lead – Global Platforms Enablement & Engineering w ING Hubs Poland, Head of Site Reliability Engineering I&E rozmawiamy o modernizacji infrastruktury IT w Grupie ING w kierunku rozwiązań cloud-ready; strategii migracji do chmury i budowie dojrzałej kultury inżynieryjnej, m.in. poprzez regularnie organizowane wydarzenia propagujące odpowiedni mindset takie, jak hackathony czy TechDays.

 

Jaki był cel ostatniego, globalnego hackathonu ING i innych, regularnie przez Was organizowanych?

Mamy hackathony lokalne, globalne i ostatni – przeprowadzony w marcu – hiperglobalny. Uczestniczyli w nim pracownicy Grupy ING z całego świata, nawet z Australii, reprezentujący różne domeny. Łącznie wzięło w nim udział ponad 2500 osób.

Cel hackathonów związany jest z budowaniem środowiska, które pozwala nam z jednej strony eksplorować i pozyskiwać ciekawe pomysły naszych inżynierów, z drugiej zaś budować kulturę inżynieryjną. W trakcie hackathonu pracownicy mogą kreować różne kategorie rozwiązań dotyczących zaproponowanego problemu, albo po prostu pobawić się technologiami. Oderwać się od rzeczywistości. Choć jest to tylko jedna z możliwości, aby osiągnąć ten cel.

Warto pamiętać, że ING Hubs Poland to nie tylko inżynierowie. Jesteśmy firmą z sektora finansowego. Mamy więc też specjalistów z innych dziedzin, np. anty-fraudu. Dajemy szansę wszystkim pracownikom na udział w hackathonach lub innych wydarzeniach wspomagających innowacje i kreatywność w naszej organizacji. Dzięki tzw. cross-departamentowym zespołom, tworzymy idealne środowisko do dzielenia się wiedzą, pomysłami czy doświadczeniem w danej dziedzinie.

Dwie z kategorii hackathonu były Tobie szczególnie bliskie. Mam na myśli Move to Public Cloud i Move to ICHP, czyli Waszej strategii odnoszącej się do takich nurtów, jak cloud-ready, cloud-native, a także odpowiedniego zarządzania długiem technologicznym. Mógłbyś krótko rozwinąć ten wątek? Czy dostrzegłeś jakieś wyróżniające się projekty?

Obie kategorie powiązane są z naszą strategią skupioną na migracji w kierunku usług cloud computing dostarczanych przez największych graczy na rynku. Mówi ona jasno, że chcemy jak najszybciej przejść do chmury publicznej, tworząc środowisko silnie odzwierciedlające standardy rynku IT. Pozwoli nam to znacząco obniżyć jego złożoność, a także kontrolować dług technologiczny.

Oczywiście, jak wszystko, wymaga to od nas dobrego przygotowania i inwestycji, nie tylko w technologie, ale również w odpowiednie umiejętności czy zachowania naszych inżynierów. Dotyczy to także kadry zarządzającej. Przyświeca nam kilka, ważnych zasad. Wspomnę o dwóch, najważniejszych: „Buy over build” oraz „Adopt not Adapt”. Obie wymagają zmian nie tylko w nas samych, ale także w podejściu do zarządzania technologią w całej Grupie ING.

Bardzo dobrym przykładem jest tutaj dość wczesna inwestycja w konteneryzację naszych aplikacji. Jako tzw. early-adopter zainwestowaliśmy w rozwiązanie znane u nas jako ING Container Hosting Platform. Oparte jest o rozwiązanie OpenShift i zgodne z natywnym standardem K8S. Nazwijmy je środowiskiem cloud-ready. Dzięki takim decyzjom przybliżamy się do realizacji naszej strategii – migracji do chmury publicznej i cieszenia się rozwiązaniami rozpoznawanymi pod magiczną już nazwą cloud-native.

Wspomniane przeze mnie zmiany w nas samych, staramy się wzmacniać poprzez różnego typu inicjatywy, nie tylko lokalne, ale przede wszystkim globalne. Nasza transformacja obejmuje całą Grupę ING. Ostatni, hiperglobalny hackathon, pozwala na szlifowanie oraz pozyskanie nowych umiejętności, aby jak najrzetelniej przygotować się do migracji do chmury publicznej.

Tym samym promujemy w organizacji zasady dotyczące tego, jak należy się zachowywać w „nowym świecie”, aby było to jak najbardziej efektywne dla całej Grupy ING. Kreujemy w ten sposób odpowiedni zestaw umiejętności i sposób myślenia pracowników. Pamiętajmy, że w chmurze publicznej działa się inaczej niż w prywatnej czy w lokalnym centrum danych. Często powtarzam, że każde, pojedyncze „kliknięcie” w public cloud już kosztuje.

Zwrot w kierunku chmury publicznej z pewnością nie jest łatwym procesem, szczególnie w organizacji, która ma tak bardzo mocne korzenie, jeśli chodzi o własne środowisko on-premise. Mówię o wewnętrznym centrum danych, w które – przez wiele lat – inwestowaliśmy. Oczywistym jest, że w związku z tym posiadamy dług technologiczny, a proces jego zaadresowania nie będzie zadaniem na rok. To jeden z czynników, jaki trzeba wziąć pod uwagę przy planowaniu migracji do chmury. Do tego dochodzi również koszt oraz czas związany z jego optymalizacją.

Strategia hybrid cloud ma na celu optymalizację kosztów, ułatwienie adopcji nowych technologii, skrócenie czasu ich dostarczenia, zwiększenie elastyczności działania, a co najważniejsze przyspieszenie tzw. roll-out’u usług w różnych regionach na świecie. Globalny zasięg to jeden z wielu benefitów jakimi można się cieszyć. To jest chyba najważniejszy punkt bycia w chmurze.

Czy na hackathonie były projekty, które zostaną przez Was wykorzystane?

Było ich wiele. Skupiały się głównie na optymalizacji pracy w chmurze publicznej tak, aby zredukować koszty utrzymania w niej środowisk IT przy jednoczesnym zagwarantowaniu możliwości automatycznego ich skalowania. Wykorzystamy na pewno kilka z nich. Wyboru dokonamy z listy zwycięzców wyróżnionych w naszej, lokalnej dogrywce.

Jaka jest różnica pomiędzy byciem cloud-ready a cloud-native?

Zakładam, że pojęcie cloud-native jest powszechnie znane. Abstrahując od jego definicji, według nas jest to takie działanie, które – po migracji do public cloud – pozwoli nam skorzystać z natywnych rozwiązań danego dostawcy chmury. Chcemy cieszyć się z możliwości jakie daje nam bycie w chmurze, np. automatycznego skalowania naszych środowisk. Jednocześnie chcemy mieć pewność, że nasze rozwiązanie pasuje do chmury w myśl naszej, złotej zasady „adoptuj, nie adaptuj”.

Jeśli migrację przeprowadzimy w nieodpowiedni sposób, automatycznie podniesie to nasze koszty. Efektem będzie tzw. u-turn (znany w środowisku IT „powrót” z chmury – przyp. red.), który powoduje, że firmy zawracają z obranej drogi do chmury i ponownie inwestują we własne centrum danych.

Powodem u-turn często jest wykonanie migracji np. w modelu Lift & Shift. Nie zalecam nikomu tego podejścia. Wcześniej warto dokonać refaktoringu środowiska IT, jego odpowiedniej walidacji oraz przygotowania realnego planu działania. Co ważne, można ten proces wpisać już na etapie zarządzania cyklem życia aplikacji. W znaczący sposób ułatwi to przyszłą migrację.

Naszą przygodę z chmurą zaczęliśmy jakiś czas temu. Nadal skupiamy się na budowie rozwiązań cloud-ready, a więc jak najlepiej wystandaryzowanych. Takie podejście determinuje też, które elementy środowiska IT przenosimy do chmury publicznej, a dla których być może wystarczy nasza chmura prywatna. Jest ona idealnym miejscem np. dla maszyn wirtualnych, które – według mojej opinii – nie powinny gościć w chmurze. W public cloud celujemy w rozwiązania Software as a Service i Function as a Service.

Już teraz mogę stwierdzić że, podejście hybrid-cloud z pewnością zostanie z nami dłużej.

Jakimi zasadami kierujecie się wybierając pomiędzy chmurą prywatną, a chmurą publiczną?

Po pierwsze, uważamy, że nigdy nie pokonamy rynku. W chmurze nowe technologie rozwijają się bardzo szybko. Każdego roku pojawiają się setki, jeśli nie tysiące nowych projektów. One szybciej staną się dostępne w chmurze publicznej niż my będziemy w stanie stworzyć je sami.

Po drugie, chmura publiczna znacznie skraca czas wprowadzenia produktu na rynek, tzw. Time-to-Market. Tego też nie przebijemy, choćbyśmy nawet starali się maksymalnie rozbudować wewnętrzne zespoły inżynierskie. Wiele środków i czasu kosztowałoby nas np. stworzenie własnego środowiska IT na potrzeby oddziału Grupy ING, który chcemy otworzyć w nowym kraju. W chmurze publicznej wybieramy po prostu – najlepszy dla danej lokalizacji – region z oferty danego dostawcy. Dzięki temu od razu jesteśmy w stanie uruchomić core-services naszego banku. Niemalże natychmiast możemy budować biznes na nowym rynku.

Po trzecie, najważniejszą zaletą chmury publicznej jest jej elastyczność. Wszyscy powtarzają, że public cloud jest droższy. Tymczasem nie jest on droższy, tylko efektywniejszy. Wyższy koszt wynika zaś z tego, że nie do końca rozumiemy, jak chcemy tym środowiskiem zarządzać, wykorzystywać natywne mechanizmy oraz jak umiejętnie sterować długiem technologicznym.

W środowisku lokalnym zawsze bierzemy to, co najlepsze i najwięcej jak się da, bo taki mamy plan na konsumpcję infrastruktury IT. Tymczasem nie zawsze jest to adekwatne do potrzeb. Z kolei w chmurze publicznej można bardzo łatwo zwymiarować rozwiązanie dostosowane do wymagań w danym czasie. W efekcie będzie ono dużo mniejsze niż infrastruktura w lokalnym data center. Pozwoli także sporo zaoszczędzić w przypadku tzw. sezonowych akcji. Idealny przykład to Black Friday, gdzie platforma musi sprostać wyższej utylizacji zasobów poprzez natężenie świątecznych zakupów, tudzież promocji w danym okresie.

Oczywiście nie można zapomnieć o bardzo ważnym aspekcie jakim jest tzw. exit plan. Jasna strategia wyjściaz chmury jest krytycznym ćwiczeniem i nie należy go pomijać. Całość powinna zawierać wytyczne odnośnie do dostępnych scenariuszy. Co ważniejsze, znaleźć się tam powinny rekomendacje dotyczące tego, gdzie będziemy stawiać nasze kolejne kroki i czy powinniśmy się skupiać na powrocie do lokalnego DC, czy raczej wybrać kolejnego dostawcę chmury publicznej.

Mam to szczęście, że jestem odpowiedzialny zarówno za część inżynieryjną, jak i infrastrukturalną. Rozwijam również fundamenty chmury publicznej, kontrybuując do globalnej strategii Grupy. Mogę z czystym sumieniem stwierdzić, że jesteśmy dobrze przygotowani do konsumpcji rozwiązań chmurowych.

W jakiej perspektywie czasowej chcecie zakończyć proces migracji do chmury?

Przez co najmniej 5 lat będziemy funkcjonować w środowisku hybrydowym. Co nie znaczy, że ten okres nie może potrwać dłużej lub krócej. Przez ostatnie lata skupialiśmy się na rozwoju chmury prywatnej. Dziś jej adopcja jest na poziomie 70%.

Teraz koncentrujemy się na rozwoju usług chmury publicznej, które obecnie pokrywają ok. 5-10% naszych środowisk IT. Chcemy sukcesywnie zwiększać ten udział, w dużej mierze dzięki redukcji naszego długu technologicznego, co znacznie przyspieszyłoby proces adopcji chmury.

Mówiłeś, że Infrastructure-as-a-Service nie do końca opłaca się w chmurze publicznej. Chcecie korzystać z Software as a Service i Function as a Service. Czym są usługi FaaS?

Jest to cała gama rozwiązań tzw. bezserwerowych (serverless – przyp. red.). W ich przypadku skupiamy się na samej funkcjonalności, bez zbędnego zaangażowania w warstwę fizyczną. Tworzymy kod, który opisuje oczekiwane przez nas zachowanie. Nie jesteśmy zaś – z punktu widzenia konsumowanej usługi – w żaden sposób uzależnieni od konkretnego rozwiązania sprzętowego. O całość zadbał już dostawca. Natomiast dla nas, jako konsumenta rozwiązania, jest to całkowicie transparentne.

Rozwiązania FaaS bardzo mocno różnią się od tego, z czym mamy do czynienia na co dzień. Warstwa funkcjonalna jest bowiem konsumowana wyżej. To dostawca usługi „martwi się” o aspekty bezpieczeństwa czy wydajności dostarczanej infrastruktury, platformy czy usługi oferowanej w modelu FaaS. Naszym zadaniem jest zapewnienie bezpiecznego kodu.

W 2022 roku mówiliście o waszej chmurze prywatnej (IPC), platformie hostującej kontenery (ICHP) oraz o tym, że zaczęliście przygotowywać odpowiednie rozwiązania dla Microsoft Azure i Google Cloud Platform. Jak to wygląda obecnie?

Nasza chmura prywatna – jak każda chmura – składa się z wielu elementów. Przez lata rozwijaliśmy to środowisko by uzyskać jak najwyższy poziom standaryzacji naszych aplikacji, a także funkcji wspierających. Dzięki tej inwestycji jesteśmy o krok bliżej w procesie realizacji tej strategii. Uzyskaliśmy pewien poziom automatyzacji oraz „higieny”. Pozwala nam to myśleć o następnych etapach naszego rozwoju i prześledzić możliwości dostępne na rynku, wracając do jednej z naszych zasad, czyli „buy over build”.

W ramach ćwiczenia, jakie można wykonać, aby zobrazować naszą platformę hybrydową w przyszłości, rozważamy np. czy w ramach naszej strategii hybrydowej nie warto zainwestować w lokalną instancję dostawcy chmury, którą wstawimy do własnego centrum danych. Jest kilka tego typu rozwiązań na rynku, m.in. AWS Outpost, Azure Stack, Google Distributed Cloud czy Oracle Distributed Cloud Services.

Może to stanowić dla nas dużą oszczędność czasu i kosztów związanych z integracją z chmurą publiczną. Daje to szansę funkcjonowania w ramach standardów rynkowych. A jest to dla nas bardzo ważne, ponieważ pozwala przyciągać do pracy najlepsze talenty. Gwarantuje bowiem naszym inżynierom poprawne doświadczenie w pracy z rozwiązaniami chmury publicznej, rozwój ich kariery, a także rozpoznawalność na rynku pracy.

Osoby wchodzące na rynek pracy IT nie chcą rozwijać „starej” infrastruktury. Chcą raczej czerpać garściami z nowych rozwiązań i rozwijać się w najnowszych technologiach. My, jako ING Hubs Poland, dajemy im takie możliwości.

Jakie jest Wasze podejście do wykorzystania najnowszych technologii?

Mamy trzy zasady. Pierwsza to wspomniane „buy over build”. Zanim zaczniemy coś budować, robimy analizę rynku i kupujemy najlepsze, dostępne rozwiązanie. No chyba, że naprawdę nic nie pasuje do naszej organizacji. Wówczas tworzymy rozwiązanie wewnętrznymi zasobami.

Po drugie, o czym też już mówiłem – i to jest dosłownie słowo klucz – działamy z zgodnie z zasadą „adopt not adapt”. Nie dostosowujemy rozwiązania rynkowego do podejścia Grupy ING. Nie chcemy tworzyć tzw. snow-flake’ów, które przynoszą wzrost złożoności naszego ekosystemu IT. Powodują też zwiększenie samego wysiłku związanego z zarządzaniem nim.

Adoptujemy technologię zgodnie ze standardem rynkowym. Dzięki temu możemy rozwijać się wraz z postępem technologii, trendami, dostępnymi rozwiązaniami przynoszącymi dodatkową wartość w sektorze finansowym i nie tylko. Nasi obecni, jak i przyszli pracownicy mogą zaś żyć w symbiozie z tym, co się dzieje w nowych technologiach.

Po trzecie, zawsze staramy się wykorzystywać natywne rozwiązania danego dostawcy chmury. Decyzja o wykorzystaniu specyficznego dostawcy, powinna opierać się na walidacji danej potrzeby oraz szacowaniu ryzyka wpływu na strategię opuszczenia danej platformowy w przyszłości.

Często dostawcy chmury publicznej oferują rozwiązania dostępne wyłącznie w ich chmurze.

Oczywiście. Obecne trendy rynkowe, w szczególności związane z Generative AI, bardzo mocno szeregują dostawców chmury pod względem rozwiązań dostępnych w ich ofercie. Wyścig ruszył i każdy z nich chce być tym jedynym, najlepszym w tej dziedzinie.

Odniosę się do przykładu z portfolio Google Cloud w zakresie rozwiązań AI. Dedykowane rozwiązanie takie jak np. Vertex AI jest idealnym przykładem świadomej decyzji wykorzystania serwisu, dostępnego tylko u jednego dostawcy. Przy okazji platforma należąca do Google, posiada łatkę chmury agregującej produkty wspierające analizę danych.

Jednak, jak wspomniałem, wyścig trwa i pozostali gracze nie odstają. Całość rozegra się o lepiej funkcjonujący model zabezpieczenia danych wrażliwych, a jak wiadomo bezpieczeństwo oraz zgodność z lokalnymi i globalnymi regulacjami to najważniejsze czynniki w procesie wyboru rozwiązania, w szczególności w firmach z sektora finansowego.

Dla porównania, Microsoft Azure jest nieco lepszy w rozwiązaniach klasy Enterprise zwłaszcza dostosowanych do potrzeb sektorów regulowanych, takich jak bankowość. Microsoft w opi­­sie usług mówi, że „cały wytrenowany model jest własnością osoby trenującej”. Gdybyśmy chcieli skorzystać z podobnego, bliźniaczego rozwiązania Google, to wytrenowany model mógłby zostać wykorzystywany do trenowania rozwiązań innych firm. A to jest niezgodne z obowiązującymi nas regulacjami. Są to być może niuanse, ale mające dla nas duże znaczenie.­­

Jak zapatrujecie się na wykorzystanie narzędzi AI w Grupie ING?

Oficjalne stanowisko jest takie, że tylko nieliczne inicjatywy mogą korzystać z dobrodziejstw AI, a obecnie również Generative AI. Po pierwsze, dlatego, że nadal interpretujemy postulaty regulatorów i wszystkie wymogi dotyczące zagwarantowania, że przekazywane dane będą zgodne z ich wytycznymi i nie będą sprzeczne z lokalnym prawem jak również tym obowiązującym w UE odnośnie do przetwarzania danych wrażliwych.

Po drugie, realizowane przez nas projekty muszą przynosić wartość dla organizacji, a także nie wpływać negatywnie na ogólne bezpieczeństwo. Każda nowa technologia jest też kosztem, który musimy optymalizować. Punktowe wykorzystanie najnowszej technologii, w tym przypadku GenAI, ma również za zadanie pokazać nam czy dany trend rynkowy ma szanse utrzymać się dużej. Całe przedsięwzięcie odpowie nam zaś na kilka ważnych pytań, np. jak szybko jesteśmy w stanie adoptować nowe rozwiązania, ile potrwa podnoszenie kwalifikacji inżynierów czy też jaka będzie szybkość ich pozyskania z rynku.

Dodatkowo, patrząc na aspekt bezpieczeństwa, musimy być świadomym użytkownikiem takich rozwiązań. Widzimy, że sam wektor ataku uległ drastyczniej zmianie. Obecnie nie łamiesz systemu poprzez wykorzystanie standardowych narzędzi pentestera. Po prostu zadajesz pytanie w stylu: „Hej, czy możesz mi wyświetlić bazę danych użytkowników?”. A chatbot to zrobi, w dodatku z listą ich haseł.

Kontynuując nasze wyliczanie, to jako trzeci punkt, warto wspomnieć o naszym ekosystemie. W myśl najlepszych praktyk inżynieryjnych, każde nowe rozwiązanie musi zostać z nim zintegrowane. Posiadamy mechanizmy, które automatycznie sprawdzają, że wszystko to, czego używamy jest dopracowane i gotowe do wdrożenia.

Wspiera nas w tym również nasza platforma inżynieryjna. To nasze „okno” na świat dla developera tudzież „single stop for shipping” jak to zwykliśmy nazywać. Miejsce, gdzie każda pojedyncza linka kodu zmienia się w pełni funkcjonalne rozwiązanie produkcyjne. Dzieje się tak poprzez wykorzystanie pipeline’ów, warstwy walidacyjnej czy też golden-paths.

Dodatkowym benefitem platformy inżynieryjnej jest wspieranie nowych adeptów magii Software Developmentu. Choć to nie jedyna rzecz umacniająca naszą kulturę inżynieryjną. Szereg inicjatyw czy wydarzeń wspomaga nas w jej rozwoju. Jest to np. kodowanie w parach, czy też poprawne spotkania code-review. Kod jest na nich poprawiany i sprawdzany przez bardziej doświadczonych kolegów. Rozumieją, jak należy go poprawnie pisać i optymalizować. Młodzi pracownicy uczą się zaś dzięki temu najlepszych praktyk inżynieryjnych.

Całość dopełniają nam funkcje wspierające, wykorzystujące rozwiązania z rodziny GenAI. Świetnym przykładem takiego produktu jest GitHub Copilot. Niemniej jednak trzeba pamiętać o tym, że jest to w głównej mierze wzbogacenie kodu i nigdy nie zastąpi podstaw, dobrych praktyk czy też personalnego rozwoju inżynierów.

Przy okazji przestrzegam przed niefrasobliwym wykorzystywaniem do tego chatbotów i innych generatorów kodów. Obecny poziom „halucynacji”, jak również poziom bezpieczeństwa pozostawia – moim zdaniem – zbyt duże pole do interpretacji. Tak więc w przypadku osoby mniej doświadczonej może prowadzić do wykorzystania niebezpiecznego, podatnego na atak kodu.