Jak bez problemów przejść do chmury?

Wojciech Struski, Chief IT Architect w Ringier Axel Springer Polska odpowiadał za strategię chmurową i przeniesienie zasobów firmy do chmury AWS. Wcześniej firma korzystała z własnej chmury. Dlaczego więc taki krok? Pytamy, co robić, a czego unikać podczas transformacji do chmury.

Computerworld: Niedawno Onet ogłosił przeniesienie wszystkich swoich zasobów do chmury AWS. Porozmawiajmy więc o strategii chmurowej. Co zadecydowało o całkowitym przejściu do chmury? Czy także usługa poczty Onet została przeniesiona do tej chmury?

Wojciech Struski Chief IT Architect, Ringier Axel Springer Polska: Powiedziałbym, że o ile 100% obszaru medialnego Ringier Axel Springer Polska jest w chmurze, to dla całego biznesu to 90%. Poczta Onetu to jedyny obszar, który cały czas jest utrzymywany on-premise. Natomiast mamy z tyłu głowy, że i ten temat trzeba będzie podjąć. Choćby po to, żeby sprawdzić, czy się da. Czy i w jakich warunkach, ten produkt po migracji do chmury publicznej mógłby realizować swój model biznesowy. Poczta jest specyficzna, bo potrzebuje bardzo dużej przestrzeni na przechowywanie danych: na ogromną liczbę maili, czy zapytań. Chmury nie zawsze udostępniają tego rodzaju storage o specyficznych parametrach. Trzeba dobrze przemyśleć sposób migracji, żeby spełniło to nasze oczekiwania.

Zobacz również:

  • Migracja do chmury - jak wygląda i jak się do niej przygotować?
  • Cyberbezpieczeństwo coraz ważniejsze dla branży logistycznej

Jak opisałby pan zmiany, przez które wasza organizacja przeszła np. w ostatnich 5 lat i jak one wpłynęły na podstawową działalność spółki i cały ekosystem?

Mniej więcej 13 lat temu podjęliśmy decyzję o budowie własnego środowiska technologicznego, które byłoby podobne do publicznej chmury prywatnej. Nasza chmura prywatna miała pewne założenia, które są podobne do tych przyjętych w rozwiązaniach chmur publicznych: jak wirtualizacja i jednocześnie separacja od kolejnej warstwy, którą jest platforma usług technologicznych. Mamy wtedy następujące warstwy: infrastrukturę, platformę technologiczną jako usługę i usługi wyższego poziomu, zawierające konkretne funkcjonalności produktowe. Dopiero na tym budowaliśmy nasze produkty i rozwiązania, które są powszechnie używane w firmie. Było to podejście unikalne w polskiej skali. W założeniach, dokładnie takie samo, jak wyglądają dzisiaj chmury publiczne. W pewnym momencie zorientowaliśmy się jednak, że dokładanie kolejnych usług kosztuje nas coraz więcej. Biznes wymaga nowych rozwiązań technologicznych, a my nie byliśmy w stanie w odpowiednim tempie ich dostarczyć, bez zwiększania zasobów i zespołu. Kiedy ceny chmur publicznych bardzo zbliżyły się do naszych kosztów wewnętrznych, to było około 2017-18 roku, a tempo przyrostu nowych funkcjonalności w tych platformach okazało się nieporównywalne z tym, co moglibyśmy zrealizować własnymi siłami, decyzja zapadła szybko. Nasz biznes jest z natury bardzo innowacyjny i wymaga od działu IT ogromnej elastyczności. Chmura umożliwia nam włączenie pewnych usług, przetestowanie ich, potem wyłączenie, rozpędzenie zasobów na czas jakiegoś projektu, potem ich usunięcie. Nie wspominając o cyklach dobowych, bo przecież ruch użytkowników na naszych stronach jest w dzień zupełnie inny niż w nocy, czy w weekendy. Od dawna byliśmy gotowi do migracji do chmury zewnętrznej, jedyną przeszkodą były wówczas koszty. W 2018 roku podpisaliśmy długoterminową umowę z AWS. Migracja trwała do końca 2022 roku.

Doprawdy? Czy Państwa droga do chmury była aż tak gładka? Czy Pański zespół nie napotkał na żadną trudność?

Jak już mówiłem, “mentalnie” byliśmy już w chmurze. Przynajmniej po stronie działu TECH – jako twórcy zwirtualizowanego środowiska z usługami dostępnymi w dużej mierze w trybie self-service. Korzystali z niego nasi deweloperzy, wykorzystując sporo automatyki do budowy i wdrażania aplikacji oraz utrzymania usług persystencji i manipulacji danymi, na przykład relacyjnych baz danych, ale nie tylko. Tak więc, po naszej stronie ten krok nie był aż tak trudny. Jest szansa, że strona biznesowa nie zdawała sobie do końca sprawy, co dla nich oznacza zrobienie tego kroku, więc odpowiedzialność za przeprowadzenie udanej transformacji IT wzięło na siebie. Nigdy by się to jednak nie wydarzyło, gdyby migracja nie była projektem strategicznym dla zarządu, bowiem transformacja w kierunku chmury tak dużej części biznesu - w zasadzie 90% - wymaga innego spojrzenia na planowanie infrastruktury. Jeśli chodzi o wydatki zewnętrzne, zmienia się drastycznie sposób finansowania, z dużej części CAPEXu w prawie sam OPEX. W trakcie procesu migracji przenieśliśmy dziesiątki usług technologicznych, niekiedy brało w niej udział 60 pracowników w tym samym czasie, z 300 osobowego zespołu technologicznego, migrując wszystkie kluczowe obszary działania firmy jak: platforma wydawnicza, cały stack big data z przetwarzaniem i analityką danych, całe środowisko deweloperskie, wszystkie mikroserwisy. Trzeba było mieć techniczny pomysł, jak to zrobić oraz zapewnione wsparcie biznes ownerów i zarządu, żeby priorytet migracji w ogóle był wzięty pod uwagę. W innym przypadku bowiem, bieżące potrzeby i plany strategiczne biznesu zawsze wypierałyby te migracyjne, konkurujące o tych samych ludzi te same zasoby. Musieliśmy przekonać firmę, że nie można rozpocząć tego projektu bez jego skończenia, bo inaczej koszty będą tylko rosły. Oczywiście to tak nie działa, że coś zmigrujemy i pstryk, nie ma kosztów, bo przecież są, np. utrzymywane wewnętrznie kompetencje, być może niezamortyzowany sprzęt, jakieś kontrakty podpisane na dłużej. To wszystko razem stanowi duże wyzwanie. Rola zarządu jest więc dla tej transformacji strategiczna.

Wspomniał Pan o kompetencjach, czyli ludziach. W tym roku zetknęliśmy się z niespotykaną dotąd falą zwolnień w sektorze technologicznym. Zatrudnienie ograniczają najwięksi: Google, Microsoft, Amazon i wiele innych firm. Jak transformacja do chmury Państwa firmy przełożyła się na kwestie zasobów ludzkich?

Migracja do chmury nie spowodowała u nas redukcji zatrudnienia. Wykorzystując naturalną rotację w zespołach IT, przesuwaliśmy ludzi do innych zadań. Przeszkoliliśmy też 200 inżynierów i wsparliśmy wielu z nich w certyfikacji. Stan osobowy zespołu technologicznego delikatnie się nawet zwiększył w czasie czteroletniego procesu migracyjnego. Wynikało to z potrzeb biznesowych, a przyspieszony proces iteracyjnego wytwarzania oprogramowania, dawał przedstawicielom biznesu pole do podejmowania szybszych decyzji o otwieraniu nowych produktów.

Jesteśmy ciągle otwarci na nowe projekty i utalentowanych pracowników. To prawda, że w obecnej chwili biznes nie rozwija się tak szybko jak w zeszłym roku, ale nie mamy też sygnałów z ryku o kryzysie na tyle poważnym, który by prowadził do redukcji w naszym obszarze IT. Wydaje mi się że przyczyną redukcji zatrudnienia w największych światowych firmach są: wzrost inflacji, problem z potencjalną recesją w Stanach Zjednoczonych, bo ona się jeszcze nie zmaterializowała, oraz spodziewane gorsze wyniki raportowane w tych największych spółkach w następnych kwartałach. Na cenę akcji big techów bardzo mocno wpływa wynik, który raportują z kwartału na kwartał. Moim zdaniem, obecne duże zwolnienia to ruchy wyprzedzające. Sądzę, że gdy sytuacja gospodarcza zacznie się poprawiać, te wszystkie firmy zaczną znowu „wysysać” z rynku informatyków. To jest bardziej makroekonomia niż złe decyzje, czasem można odnieść takie wrażenie z wypowiedzi szefów spółek, że przyznają, że przeinwestowali w czasie pandemicznym.

Przenieśliście swoje zasoby do chmury AWS. Czy nie boicie się tzw. vendorlock-in?

Nie mamy obaw związanych z przeniesieniem zasobów do chmury AWS. Myślę, że vendorlock-in jest złym pojęciem. To słowo-klucz, wytrych dla firm pośredniczących, chcących sprzedać rozwiązanie, teoretycznie ułatwiające arbitraż pomiędzy innymi vendorami, jednocześnie samemu stając się vendorlockiem. Przykładowo, jeśli mamy dwóch dostawców chmur i ja rozdzielę swoje zasoby pomiędzy tych dwóch dostawców, to zmniejszyłem czy zwiększyłem swoje problemy? A jeśli rozwiązania tych dostawców nie będą kompatybilne? Za „ubezpieczenie” możliwości przerzucenia się pomiędzy dwoma dostawcami płacę co najmniej kilkadziesiąt procent więcej rocznego rachunku. Po naszych doświadczeniach, mógłbym dzisiaj się założyć, że w razie potrzeby, nasza firma zmigrowałaby się do innego dostawcy w ciągu roku.

Jakich rad udzieliłby Pan firmom, które dopiero rozważają przejście do chmury? W Polsce zrobiło to zaledwie kilkanaście procent.

U nas, w odróżnieniu od świata zachodniego, największe organizacje działają w sektorach regulowanych, są to często banki czy firmy ubezpieczeniowe. Oczywiście, na rynku jest i Allegro, i Ringier Axel Springer Polska, i Wirtualna Polska, ale relatywnie mało mamy w Polsce takich niezależnych wielkich firm cyfrowych. Jeśli miałbym coś radzić, to radziłbym działać. Jeżeli macie w organizacji problem technologiczny do rozwiązania, to zacznijcie robić jakiś projekt. Jeśli nie macie jeszcze niczego w chmurze, to proponuję wskazać jeden projekt, który będzie w całości możliwy do wyniesienia do chmury publicznej. W działaniu nauczycie się najwięcej i sami zobaczycie, czy to jest właściwa ścieżka.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200