Marcin Mazurek, wiceprezes ds. technologii w Grupie Allegro podczas spotkania CXO HUB podzielił się doświadczeniami optymalizacji chmury obliczeniowej w swojej firmie. W Grupie Allegro odpowiada bowiem za cały obszar technologii, polityki zarządzania i środowiska pracy dla programistów, w tym dostarczanie elementów technologicznych kompatybilnych ze schematem zarządzania i bezpieczeństwa, zgodność z regulacjami, zarządzanie zasobami materialnymi i niematerialnymi oraz narzędzia do monitorowania wydajności w wielu wymiarach, w tym finansowym, dla CFO. „Jesteśmy w Grupie sklepem technologiczno-procesowym” – mówi o roli swojego obszaru.
Czy „sklep technologiczno-procesowy” w Allegro posiada w ofercie także produkt „proces optymalizacji kosztowej cloud”?
Marcin Mazurek: Oczywiście tak.
Rozumiem perspektywę CFO, ponieważ jestem z wykształcenia magistrem ekonomii. Pomimo że od lat jestem w obszarze technologii i inżynierii, wiem po prostu, że nic nie jest za darmo. Tutaj dygresja: sądzę, że świadomość ograniczeń – rozumienie obszaru finansowego, zarządzania usługami i obszaru technicznego – pozwoliły mi znaleźć się tu gdzie dziś jestem.
Dołączyłem do Allegro, kiedy była to nieduża firma na szybkiej ścieżce wzrostu. Jedynym celem dla obszaru technologii było wówczas umożliwienie utrzymania tempa wzrostu. Mieliśmy wolną rękę w rozbudowywaniu sprzętu, infrastruktury – byle nadążyć za biznesem. W momencie, gdy ten wzrost się ustabilizował, mogliśmy zacząć wprowadzać pomysły na zwiększanie efektywności wykorzystania technologii.
Zaczęliśmy budować modele rozliczania usług technicznych – całościowy, świetny framework powstał już 8 lat temu. Byliśmy w stanie określić, ile kosztuje pojedyncza usługa lub dany element infrastruktury. Jako organizacja musieliśmy jednak dojrzeć do tego, by te informacje przełożyły się na działania także w innych działach. Oczywiście wynikało to z charakteru rozliczeń – dokonywały się one w wewnętrznej walucie, tzw. allegro-dolarach. Nawet rozumiem, że dla biznesu operującego na „prawdziwych” budżetach, te wewnętrzne rozliczenia mogły wydawać się umowne aż poza granice abstrakcji.
Ale z pomocą przyszły wydarzenia zewnętrzne – zmiana właściciela Allegro i pandemia COVID-19, która przełożyła się na kolejny skokowy wzrost liczby użytkowników platformy.
To fakt – zmianę motywowała sprzedaż firmy w 2017 roku, późniejsze wejście na giełdę, ale to przede wszystkim wybuch pandemii spowodował błyskawiczne odkurzenie pomysłów optymalizacyjnych.
Wróciliśmy do istniejących założeń modelu rozliczeń finansowych, pewne rzeczy trzeba było odbudować, inne przebudować. Zaczęliśmy m.in. bardzo blisko pracować z kontrolingiem.
To była wówczas nowość?
Wcześniej istniała już nieduża komórka kontrolingu w dziale IT, delegowana z tego działu do nas.
Obecnie jest ona jednak znacznie większa i podlega bezpośrednio CFO. Jej pracownicy są przypisani do obszaru technologii i wspólnie z nimi budujemy modele finansowe. Jestem dzięki temu w stanie uzyskać i pokazać informacje o każdej usłudze, która jest częścią każdej z platform Allegro: ile kosztuje, ile i jakiej wymaga infrastruktury, jaki jest poziom amortyzacji, czy to środowisko chmury publicznej czy prywatnej…
W kontekście środowisk chmury publicznej, o której tu przede wszystkim rozmawiamy, to bardzo ważne.
Bardzo łatwo uruchomić w chmurze usługę, trudniej dobrze skonfigurować. Dlatego często zdarza się, że firmy wydatkują w krótkim czasie poważne budżety chmurowe, często bez świadomości tego faktu.
Kiedy kilka lat temu budowaliśmy pierwsze business case’y, żeby określić w czym chmura publiczna ma przewagę w stosunku do usług, które świadczyliśmy z wykorzystaniem zasobów wewnętrznych, bardzo ważnym elementem był governance – schemat zarządzania środowiskiem. Wiedzieliśmy, że próbując włączyć chmurę publiczną do naszego systemu, musimy móc nią zarządzać, utrzymać kontrolę nad tym, co się w niej dzieje. To się udało doskonale.
W jaki sposób?
W chmurowym business case testowaliśmy trzy obszary: po pierwsze przechowywanie i analityka danych; po drugie – przetwarzanie, które dla platformy realizuje ponad tysiąc serwerów oraz wreszcie – obszar usług bardzo złożonych i skomplikowanych. Badaliśmy, które z nich możemy przenieść do infrastruktury chmurowej.
Podjęliśmy wówczas obowiązującą do dziś decyzję, że cała analityka danych znajdzie się w chmurze publicznej. Z perspektywy finansowej doskonale orientowaliśmy się, że będzie to zmiana na droższy model. Ale jasno też wynikało z analizy sytuacji, że nie jesteśmy w stanie, ani tym bardziej w przyszłości – nie będziemy, ścigać się z dostawcami chmury pod względem szybkości, skalowalności przetwarzania, gromadzenia danych, zapewnienia do tego odpowiedniej infrastruktury.
Chyba nie była to łatwa decyzja, ponieważ Allegro rozwijało przez lata własną infrastrukturę, w tym z myślą o Big Data.
Mieliśmy jeden z większych klastrów Hadoop’owych w Polsce. Pamiętam jednak doskonale, kiedy na którymś ze spotkań kwartalnych z jego zespołem dowiedziałem się, że 70% czasu poświęcają na utrzymanie. Uznałem, że to niedopuszczalne. To był jeden z powodów, dla których przenieśliśmy się z analityką danych do chmury – bardzo świadomi tego, czego się możemy tam spodziewać.
Może to dobry moment, aby na przykładzie tego obszaru opisać, na co właściwie – i jak – się przygotowaliście.
Governance – schemat zarządzania – rozliczania danych opiera się na narzędziach, które śledzą wykorzystanie chmury w kontekście usług. Każda z nich jest powiązana z własnym, małym budżetem. Jego wysokość określa w procesie budżetowania każdy zespół, który chce skorzystać z chmury publicznej.
Monitorowanie dokonuje się w ujęciu niedoszacowania albo przeszacowania tego budżetu. Kiedy zużycie przebiega szybciej niż planowaliśmy, na bieżąco staramy się wyjaśnić przyczynę: czy to jest potrzeba biznesowa, czy kwestia konfiguracji, czy możemy coś usprawnić? Robimy to bardzo metodycznie i automatycznie.
Jak zbudowaliście aparat do monitorowania? Samodzielnie, czy w oparciu o narzędzia od dostawców chmury?
Zbudowaliśmy bardzo dużo narzędzi w oparciu o to, co znajdujemy na bardzo szybko rosnącym rynku takich rozwiązań. Zapotrzebowanie jest ogromne, stało się powszechnie jasne, że migracja do chmury może być bolesna – powstał więc dynamiczny rynek start-upów.
Jak bolesna?
Firmy, które weszły bez przygotowania do chmury, często obudziły się z fakturami wielokrotnie wyższymi niż dotychczasowe koszty realizacji danych usług. Rozmawiałem z bardzo dużymi firmami e-commerce ze Stanów Zjednoczonych, m.in. o przypadku 10-krotnego wzrostu kosztów utrzymania technologii, co nie było wyjątkiem.
Nam udało się tego uniknąć dzięki stopniowemu wchodzeniu do chmury, przenoszeniu tam obszarów co do których jesteśmy pewni, że to ma sens, niesie wartość, albo kiedy pojawiają się nowe potrzeby. Dla tych potrzeb stawiamy prognozy i na tej podstawie podejmujemy decyzje.
Tomasz Rychter: Jak trafne są te prognozy i czy z czasem ich dokładność rośnie? Z czego wynikają błędy i w jaki sposób je naprawialiście?
Początkowo błąd w prognozach sięgał 15-20%. Uważam, że to zupełnie przyzwoity wynik, biorąc pod uwagę rozmiary, wielkość zasobów i rozległość zastosowań.
W naszym wypadku wejście do chmury poprzedzają też negocjacje z dostawcą – negocjowanie, prognozowanie zużycia w oparciu, o które uzyskujemy cenę w perspektywie roku, 3 i 5 lat. Z perspektywy dostawców kontrakt chmurowy to normalne kupowanie infrastruktury – a chmura to narzędzie do zarządzania nią.
Ale wracając do pytania: do negocjowania i podpisywania kontraktu na chmurę przystępujemy po przeanalizowaniu całego obszaru produktowo-inżynierskiego, po odpytaniu o zapotrzebowanie. Suma tych ważonych prognoz dawała łączną wartość prognozy. Niezależnie od tego, realizacja kontraktu podlega wspomnianemu monitoringowi wykorzystania zasobów chmurowych. Każda usługa znajduje się w katalogu, z przypisanym właścicielem technicznym, produktowym. Otrzymują oni regularnie informację o zużyciu budżetu, modelu użytkowania, różnicach względem prognozy.
Zarządzanie tą sferą leży w zakresie odpowiedzialności osobnego menedżera, który także utrzymuje komunikację z użytkownikami, reagując na potrzeby szkoleń, braku wiedzy czy doświadczenia w użytkowaniu, bądź zmianę uwarunkowań.
W obieg informacyjny, który dokonuje się kanałami Slack, włączony jest też CFO. Odbywamy z nim regularne spotkania poświęcone kosztom chmury, wyjaśniając przebieg realizacji prognoz.
Polecam taką otwartość, budowanie zaufania do naszego schematu i systemu zarządzania środowiskami chmurowymi. Na koniec roku nie szykujemy się dzięki temu na trudne rozmowy.
Czy cele optymalizacji finansowej budżetu chmurowego są w gestii zespołów? Czy ich zadaniem jest szukać takich sposobów?
Zespoły nie mają celów finansowych jako takich. Uzgadniamy jaki budżet potrzebują na realizację zadań w danym okresie i nie dociekamy, nie kwestionujemy jaką kwotę oszacowali – ponieważ posługują się narzędziami oraz informacjami, których sami im dostarczyliśmy.
Wspieramy ich jednak w realizacji budżetu, przypominając o swoistej higienie korzystania z chmury – edukujemy, żeby pracowali w zgodzie z takimi zasadami. W efekcie, nie mamy problemów z przekazywaniem do chmurowych systemów analitycznych zbędnych, nieprzemyślanych zapytań. Użytkownikom uświadomiliśmy na przykładach, że nie jest to trudne – tak, jak nie jest trudne wydać koszmarne kwoty na niepotrzebne zapytania. Pomocne są małe, podręczne narzędzia, takie „bezpieczniki”: przykładem jest zainstalowany przez nas zwykły plug-in do przeglądarki, który pokazuje, ile dane zapytanie będzie kosztowało w GCP czy Azure.
Celów optymalizacyjnych nie mamy, mamy budżet, mamy prognozy i monitoring. Budżet to są koszty, ale i przychody. Jeśli przypisane są do konkretnych produktów, to produkty muszą je utrzymywać. Ale ponieważ produkty także mają swój cykl życia, schodzą ze sceny, tracą klientów i wówczas mamy jasne przesłanki, aby dany produkt zamknąć.
Maciej Dzięcielak, Chief Architect, Veolia: czy w jakiś sposób optymalizujecie także waszą pracę? Chmura często obiecuje odzyskanie czasu pracy dla zadań rozwojowych, dotąd blokowanych przez konieczność utrzymania…
Wydajność zespołów IT to oczywiście Święty Graal, szczególnie w czasie trudniejszym ekonomicznie. Regularnie mam takie rozmowy z CFO, ale i całym zarządem.
Tematem szczególnie wdzięcznym jest utrzymanie. Podam przykład zespołu platformy technicznej. Kiedy zaczynaliśmy go budować, utrzymanie zajmowało mu średnio 25% czasu. Staraliśmy się ten współczynnik obniżyć przy zachowaniu stabilności związanej z ciągłością działania – osiągnęliśmy 15% i myślę, że to rozsądna wartość. Z rozmów z konsultantami McKinseya wynika, że do przyjęcia jest w firmach wartość od 12% do 30% w zależności od tego jaka jest to branża i etap rozwoju.
Ale to nie wszystko. Istnieją metryki, które zresztą stosujemy od dawna, a obecnie stały się buzzwordami: developer experience i platform engineering. Obejmują wiele miar obrazujących, co się dzieje na platformie: liczbę bibliotek, które są przestarzałe; serwerów, które mają jakiś problem; serwerów, które nie były od dawna aktualizowane czy restartowane. Przy naszej skali powyżej 1000 urządzeń zaczyna to mieć znaczenie dla ogólnego poziomu utrzymania. Liczymy, ile usług przypada na zespół deweloperski, co z kolei pokazuje ewentualne przeciążenie informacją i wiedzą, tzw. cognitive load. Przeciążenie zespołu skutkuje oczywiście obniżeniem jakości pracy, brakiem zrozumienia itd. Nazywamy to „testem zdrowia” (health check), mierzymy ten wskaźnik wskroś całej technologii w zespołach i w odniesieniu do pojedynczego członka zespołu, a poziom tej miary włączyliśmy do oceny rocznej i półrocznej.
Bartosz Stachowiak, Cloud Center of Excellence Manager, mBank: czy budżety na usługi chmurowe i aplikacje są w gestii Twojej, IT – czy w biznesu?
Zarządzam całym budżetem – między innymi ze względu na to, że zarządzam także kontraktem z dostawcami. Natomiast menedżer odpowiedzialny za chmurę do rozmowy z dostawcą włącza użytkownika – żeby sygnalizować np. jego potrzeby szkoleń, kredytów na usługi czy choćby udziału w konferencji o trendach.
Czyli rezerwacje zasobów pod aplikacje są centralnie zarządzane?
Mamy dosyć elastyczną platformę, użytkownicy sami sobie rezerwują zasoby. Zbudowaliśmy konsole ekosystemów chmurowych i każdy zespół może sobie „wyklikać” infrastrukturę. Skonfigurowana usługa automatycznie przypisuje właścicielstwo biznesowe, techniczne, jest powiązane z kontem zespołu.
Nie będziemy ingerować, jaką zespół rezerwuje w związku z tym liczbę rdzeni czy pamięci. To odpowiedzialność menedżera i lidera zespołu, bo on dostanie od nas później refakturę wewnętrzną. Naturalnie dostaną zwrotną informację, jeśli z zamówionych 500 rdzeni będą wykorzystywać np. 20.
Są także mechanizmy autoskalowania. Ostrożnie ich używamy, bo czasami nie są sobie w stanie poradzić z nagłymi zdarzeniami, do których dochodzi w naszej działalności.
Tomasz Socik, Software Asset Management Team Leader w mBank S.A: jeśli za infrastrukturę odpowiadają właściciele danego biznesu, to czy to na nich spoczywa odpowiedzialność za projektowanie danego rozwiązania?
Dostarczamy infrastrukturę obudowaną różnymi warstwami abstrakcji, konsolę pozwalającą konfigurować podstawowe parametry. Zespoły dobierają sobie usługi, z których dane rozwiązanie ma się składać i widzą, ile mogą kosztować.
Czyli jest jeszcze ciało, które weryfikuje, że to optymalnie wymyślone rozwiązanie pod względem architektonicznym.
Nie, to jest ich odpowiedzialność.
Częściowo ciężar odpowiedzialności przekładamy również na inżynierów senior i principal. Oni mają prawo do całościowej oceny – od doboru rozwiązań, po w ogóle sens jego budowy, od strony technicznej i logicznej.
Więc poniekąd dajecie wolną rękę, a później koszty pokazują, czy to jest optymalne?
Czasami robimy przeglądy, żeby wychwycić usługi, które są nieużywane, kontaktujemy się z właścicielami, staramy się negocjować, zrozumieć. Staramy się jednak pomagać, a nie blokować – bardzo się tego wystrzegam. Dlatego, że nadrzędną albo równie istotną wartością jest wspomniane developer experience. Raczej poszukujemy równowagi pomiędzy szybkością developmentu a kontrolą kursu i jakości.
Michał Marzewski, Benefit Systems International (M.M): chciałem zapytać o budowanie procesu, budowanie dojrzałości i odpowiedzialności – współodpowiedzialności za chmurę. Na początku podałeś, że dopuściliście błąd oszacowania budżetu do 20%. Czy korelujecie estymacje biznesu z ich finalnymi ocenami, na przykład rocznymi? Czy to może motywować? A jeśli nie – to może podasz inne sposoby?
Biznes to u nas zespół komercyjny, w Allegro technologia to produkt i IT, w takim klasycznym rozumieniu. Komercyjny zespół wypracowuje z menedżerami produktu potrzeby i pomysły. Menedżerowie produktu przekładają to na rozwój produktu i z inżynierami pracujemy nad architekturą. Nie oczekujemy od zespołu komercyjnego, żeby się znał na architekturze lub na budowaniu produktu. Od tego są wspomniani menedżerowie.
Jesteśmy podzieleni na działy biznesowe, ja odpowiadam za technologię, są też działy Data and AI, Consumer, Merchant. Każdy z tych działów ma swojego odpowiednika po stronie komercyjnej. To dwóch najbliżej współpracujących menedżerów w każdym z takich układów. Z takiej dwójkowej współpracy ma wynikać efekt.
Michał Marzewski: I taki dualizm jest najlepszy. A ile ten proces dojrzewał?
Zajęło nam to dobrych kilka lat. Stopniowo utarło się, że to nie jest walka pomiędzy dwoma funkcjami i obszarami, ale wspólne przygotowywanie do przedstawienia pomysłu osobom decyzyjnym w firmie, na zasadzie: takie środki będą potrzebne na architekturę, takie na infrastrukturę, na rozwiązanie techniczne, to potrzeby marketingu, a taki chcemy mieć rezultat komercyjny…
Marek Andrzejuk, Deutsche Telecom: Jak wygląda obsługa sytuacji trudnych do przewidzenia? Jak wówczas robi się te predykcje i uzgadnia współdziałanie marketingu?
Trochę pomaga nam skala Allegro, a jeszcze bardziej – doświadczenie i przygotowanie. Znamy specyfikę naszej działalności, to są bardzo szczególne uwarunkowania i zjawiska. Przygotowujemy się po prostu robiąc wiele testów obciążeniowych – solidnie, regularnie powtarzanych – to żadne rocket science.
Zespół doświadczonych inżynierów, którzy zajmują się wydajnością serwisu i ciągłością działania, przygotowuje testy i je wykonuje, bada jakie obciążenie wytrzymają zaplanowane zasoby. Potem jest jeszcze kalibrująca rozmowa z biznesem, aby przygotować platformę na wymagające okoliczności, takie jak np. sprzedaż biletów na warszawski koncert Taylor Swift i obsługa licznych zapytań klientów z całej Europy. Odpukać, tak to było przygotowane i wyskalowane, że mieliśmy jeszcze sporo zapasu.
Mamy w podobny sposób rozpracowany dokładnie kalendarz z wydarzeniami cyklicznymi, z miesięcznymi, dziennymi, wszelkie akcje marketingowe Black Week, pre- Black Week, czy premiera nowego telefonu… To ostatnie akurat jest nauczką po takim wydarzeniu, które nas kiedyś pokonało. Ale przekuwamy wszelkie doświadczenia na dobre.
Na koniec chciałbym zapytać, czy ten przygotowany i sprawdzony, optymalizujący się proces chmurowy może czekać jakaś większa przebudowa? Czy jakieś zjawiska technologiczne, biznesowe mogą zmienić ten paradygmat, wymusić nowe podejście? A może sam aparat do obsługi procesu stanie się zbyt drogi i takiego nowego podejścia trzeba będzie poszukać?
Organicznie nie lubię zmian. Kiedy czytam artykuły o potężnej migracji do chmury publicznej, okraszone deklaracjami o oszczędnościach rzędu 100 – 500 czy nawet 1000%, to na usta cisną mi się jedynie słowa: potworny musieli mieć… bałagan, skoro zaoszczędzili tyle pieniędzy.
Jakbyśmy nie liczyli po naszej stronie, w naszej infrastrukturze, to w życiu byśmy nie osiągnęli oszczędności z migracji do chmury publicznej. To niewykonalne. A zrobiliśmy business case’y ze wszystkimi dostawcami – i nie byli w stanie nam wyliczyć oszczędności. Inne wartości – jak najbardziej: łatwiejszy dostęp do usług, technologii, skali, owszem. Wniosek jest taki, że do chmury nie idzie się po oszczędności.
Dostrzegam dziś otrzeźwienie, że firmy migrują do chmury faktycznie to, co jest potrzebne oraz rzeczy nowe, żeby samemu nie budować zbędnej infrastruktury. Zdrowy rozsądek w końcu zwycięża – zaczynamy korzystać z chmury kierując się wartością. Trzeba umieć powiedzieć, po co wchodzimy do chmury i to nie może być odpowiedź: „bo chcemy być nowoczesną firmą”.
W tej chwili nie widzę natomiast jakichś przełomowych inicjatyw, które mogłyby ten stan rzeczy zmienić. Spodziewam się, że nadejdą, oczywiście ze strony AI, ML, ale na razie tego przełomu jeszcze nie widać. Wszyscy oczywiście obserwujemy to, co się dzieje. Ja z równym zachwytem, co przerażeniem. Fascynuje mnie to, trochę się boję, ale myślę, że ludzkość sobie poradzi.
