Proces stałej optymalizacji chmury: doświadczenia RASP

Historia chmury obliczeniowej w Grupie Ringier Axel Springer Polska rozpoczyna się od budowy dwóch, własnych ośrodków obliczeniowych w Krakowie. W pewnym momencie doszło do powstania w obrębie własnej serwerowni chmury prywatnej, kompatybilnej z infrastrukturą jednego z dostawców chmury publicznej.

Ewolucja środowiska rozpoczęła się ponad dekadę temu. Budowa chmury prywatnej wniosła do organizacji nowy mindset, podejście dzięki czemu mogliśmy płynnie przejść do korzystania z chmury publicznej. Jednym z ważnych elementów był ciągły proces porównanie trendów kosztu realizacji usług w chmurze publicznej i kosztu samodzielnego ich rozwoju. W pewnym momencie przewidzieliśmy przecięcie się linii obu trendów. Od tej chwili zdaliśmy sobie sprawę, że nie mogliśmy dłużej z chmurą publiczną konkurować. Dostawcy publiczni rozwijali się w innym tempie, a w perspektywie 3 lat mogli być od nas tańsi. W 2017 dostaliśmy zgodę na migrację, którą rozpoczęliśmy w następnym roku, a w 2022 r. zakończyła się ostatecznie migracja do chmury publicznej. Obecnie w chmurze publicznej – w ramach dwóch, europejskich regionów – działa cały biznes mediowy Grupy RASP.

Proces pomiaru efektywności i optymalizacji chmury narodził się wraz z pierwszymi instancjami chmurowymi. Kiedy tylko zaczęliśmy rozważać migrację chmurową, dokonaliśmy wyboru wskaźników finansowych, które obiektywnie uzasadnią decyzję. W oparciu o nie zaprojektowaliśmy ROI dla przedsięwzięcia. Czas osiągnięcia dodatniego bilansu zaplanowaliśmy na 4 lata i rzeczywiście udało się go dotrzymać.

Plan finansowy i czasowy, był bardzo precyzyjny i dlatego od początku migracji towarzyszył proces optymalizacji. Ważnym uwarunkowaniem dla tego procesu był wybrany model migracji. Zaplanowaliśmy od początku przechodzenie na usługi wyższe, a nie proste przenoszenie do chmury istniejących instancji. Daje to bez porównania większe pole manewru, jeśli chodzi o zarządzanie efektywnością w trakcie samej migracji i po uruchomieniu usług w chmurze. Nie wspominając o tym, że samo w sobie podejście Lift and Shift podnosi koszt utrzymania.

Wielość wariacji wykorzystania chmury, konieczność zapewnienia elastyczności, powodują, że proces optymalizacji środowiska chmurowego jest interesującym wyzwaniem. Trudno udawać, że zarządzanie budżetami IT było wcześniej zajęciem porywającym. Była to żmudna, menedżerska praca. To się diametralnie zmieniło w chmurze. Najlepiej ilustrują to efekty, jakie uzyskujemy. Kiedy dostaje się fakturę za usługę, zaczyna to przemawiać do wyobraźni i rozumu. Proces odnosi się do kilku wymiarów, w tym podstawowych – procesu, ludzi i narzędzi.

Już na etapie budowy budżetu rocznego IT przyjmuje założenia dotyczące optymalizacji. Z reguły przyjmujemy na siebie ryzyko optymalizacji ok 10%. To zasadnicza zmiana w stosunku do świata on-premise. Takich założeń, celów w on-premise nie mogliśmy sobie stawiać. Realizowaliśmy co prawda działania w nurcie Green IT, jak wyłączanie serwerów itp., ale z dzisiejszej perspektywy to przedsięwzięcia, które skalą można porównać dziś do ekscytacji z jazdy na nartach na oślej łączce; dzisiaj przypinamy sobie szerokie narty, aby wyjść wysoko, cieszyć się wysiłkiem i wyzwaniem a potem swobodną jazdą po własnym szlaku, bez tłoczenia się przy wyciągach.

Działanie w ramach publicznej chmury pozwala uniknąć pułapki, która bywa udziałem firm pozostających w on-premise, szczególnie dużych, na giełdzie. Najważniejsze z finansowego punktu widzenia są dla nich kwestie amortyzacji wydatków na utrzymanie i rozbudowę aktywów kapitałowych. W kontekście wydatków na IT prowadzi to do stosowania rozwiązań, jak np. kapitalizowane wydatków operacyjnych, które – na własny użytek – nazywam COPEX’em w celu uzyskania jak najwyższego wyniku EBITDA. Ich stosowanie utrudnia ocenę rzeczywistego stanu finansów przedsiębiorstwa.

Najważniejszym wskaźnikiem przedsiębiorstwa jest płynność/cashflow. Dlatego podczas budowy Business Case dla migracji chmurowej, oparliśmy o niego kalkulację. To jedyny sposób, aby wykazać, że chmura może być kosztowo porównywalna ze światem on-premise, gdzie wydatki się amortyzuje, rozpisuje na różne okresy. Chmura jest usługą, gdzie faktura od dostawcy jest równie nieuchronna, jak podatki. Dlatego jeśli znamy wykonanie, wykorzystanie chmury na bieżąco, to na bieżąco kontrolujemy budżet chmurowy.

„W sytuacji, kiedy dostawcy przesyłają biling z jednodniowym opóźnieniem, odpowiednie narzędzia pozwalają na bieżąco kontrolować nie samą fakturę, tylko nasze usługi, produkty i kontrolować ich koszt. Taka informacja staje się elementem codziennego spotkania statusowego zespołu produktowego, staje się czynnikiem, na który można odpowiednio reagować. To jest ogromna zmiana. Na czym polega jej istota? Wymiar finansowy jest przyswajany przez osoby z IT odpowiedzialne za stronę technologiczną usługi.

Wszyscy, jako CxO, zdajemy sobie sprawę – ba, pewnie wielu z nas tego doświadczyło kiedyś na sobie, w praktyce – że inżynierowie uwielbiają działać szybko i wydajnie. Uzewnętrzniało się to przecież przez lata, np. podczas prezentowania osiąganych wskaźników uptime czy szybkości odpowiedzi aplikacji. Ten rodzaj wyścigu o jak najwyższy uptime lub wydajność, dzisiaj możemy rozciągnąć także na współzawodnictwo w tym, jak zbudować aplikacje taniej. I to świetnie działa. Zmienia to inżynierów – i po części architektów – w przedsiębiorców, deklarujących np. 10% optymalizacji a następnie realizujących ten cel.

Czy sam proces kryje w sobie tajemną recepturę? Budżetowanie odbywa się centralnie na poziomie ogólnym. Natomiast w szczegółach przychodzi do rozłożenia odpowiedzialności pomiędzy zespoły i ich poszczególnych członków. Są odpowiedzialni za swój „odcinek”, fragment infrastruktury aplikacji czy usługi i odpowiadają za niego na bieżąco.

Ciekawą kwestią wydaje się skalowalność tego procesu. Musi on mierzyć się z kwestiami dynamiki środowiska chmurowego – powodowanej potrzebami biznesu, potrzebami związanymi z utrzymaniem środowiska, ale też zmianami w samym ekosystemie, które wprowadza operator. Czy podoła rosnącej złożoności, zmienności? A może nieodpowiednio konserwowany proces stanie się niewydolny, sam w sobie zacznie generować koszty przekraczające efekty jakie ma dostarczać.

Staramy się kontrolować całość kosztów, czyli oprócz faktury za chmurę analizować, ile kosztuje praca inżynierów ponoszona na optymalizację. Z drugiej strony staramy się zapewnić w środowisku pewną elastyczność, aby uwzględniać specyficzne potrzeby jakiejś aplikacji biznesowej i dobrać do niej odpowiednią usługę w chmurze.

Należy jednak pamiętać, że ‘szaleństwo optymalizacyjne’ może doprowadzić do rozpraszania się i pogoni za ‘coraz lepszymi kosztowo’ usługami i znienacka można mieć w portfelu 10, różnych, superoptymalnych kosztowo i technologicznie baz danych, ale brakuje kompetencji do ich utrzymania. Budowa tych kompetencji to przecież koszt, który często jest dużo wyższy niż oszczędność z optymalizacji. Dlatego nie zapominamy o zdrowym rozsądku, o pryncypiach, standardach architektonicznych i procesach utrzymania. One obowiązują, a ich utrzymanie jest często trudniejsze niż w środowisku on premise bo dostawcy ciągle dostarczając coraz to nowe technologie a naszym obowiązkiem jest aby utrzymać odpowiedni chmurowy governance.

Wojciech Ehrenfeld, Head of IT Solutions w Ringier Axel Springer

Notował Szymon Augustyniak