Jak o 48% obniżyliśmy koszt migracji klienta do chmury Azure?

Migracja do chmury ponad 200 maszyn wirtualnych

Nasz klient to średniej wielkości Software House, zatrudniający prawie 250 osób i — na moment przed migracją — dysponujący ponad 200 maszynami wirtualnymi w on-premise. Co warto zaznaczyć, środowisko IT klienta cechuje bardzo duża złożoność. Podzielone jest na wiele małych projektów i dedykowanych infrastruktur, pomiędzy którymi nie zachodzi żadna integracja. Taki też model miał pozostać zachowany bez zmian, nawet po wymianie i modernizacji infrastruktury IT.   

Jednak to nie skomplikowane środowisko, a przestarzała infrastruktura była największym problemem klienta. Wiele z jego rozwiązań było już w dużej mierze pozbawione wsparcia i całość nie nadążała za potrzebami biznesowymi rozwijającej się firmy. Stąd decyzja o całkowitej wymianie sprzętu lub przejściu na zupełnie nową technologię i wykorzystaniu usług chmurowych.

Nowa infrastruktura IT – migracja do chmury czy on-premise?

Na samym początku współpracy klient poprosił nas o wycenę trzech różnych scenariuszy przejścia na nową infrastrukturę IT:

1. Pozostanie w on-premise, ale przy zakupie całego sprzętu od podstaw (elementy sieciowe, macierze dyskowe, serwery i rozwiązanie backupowe);
2. Skorzystanie z usług firmy zewnętrznej i wzięcie w leasing wyżej wymienionego sprzętu;
3. Pełna migracja infrastruktury do chmury Azure.

Przystąpiliśmy do analizy kosztów dla każdego scenariusza w okresie 3 lat, uwzględniając przy tym takie elementy jak choćby zmienne ceny prądu i serwerowni czy koszt wymiany urządzeń. Oczywiście w przypadku scenariusza Azure były to koszty wynikające z subskrypcji i ruchu na chmurze (przy czym pierwotnie ruch obliczony został jeszcze na starej infrastrukturze — będzie to poruszone w dalszej części tekstu). Wyceniliśmy także pracochłonność projektu w mendejach*, uwzględniając pracę ludzką potrzebną do przeprowadzenia migracji w każdym z trzech scenariuszy.  

Po przedstawieniu pełnego kosztorysu zakupu nowej infrastruktury IT w trzech wariantach klient zdecydował się przejść do chmury Azure, wykorzystując w tym celu wsparcie naszego zespołu.

Jak wycenić chmurę w stosunku do on-premise?

Wyceniając tak różne scenariusze migracji, trzeba pamiętać, żeby porównywać jabłka z jabłkami, a nie np. gruszki z jabłkami. Świadomie nie uwzględnialiśmy w wycenie np. najnowszych feature’ów Azurowych, które wychodziły poza określone wymagania. 

Przykładowo, jeżeli infrastruktura klienta w on-premise (na fizycznym hardware) miała być zamknięta do jednej lokalizacji i backupu, to samo wycenialiśmy w chmurze. W innym wariancie wyceniliśmy również przełączanie się między dwoma lokalizacjami. Naszym zadaniem nie było forsowanie decyzji klienta z nastawieniem na chmurę Azure i jej dodatkowe rozwiązania. Klient jasno przekazał wymagania odnośnie do funkcjonalności SLA w on-premise, co uszanowaliśmy i 1:1 wyceniliśmy w chmurze.

Co jeszcze przed wyceną? Nowa architektura i prace optymalizacyjne

Zatrzymajmy się jeszcze na chwilę przy wycenie scenariuszy przejścia. Zanim przedstawiliśmy klientowi ostateczne kosztorysy, wykonaliśmy ważny krok, a mianowicie przeprowadziliśmy analizę wykorzystania maszyn. Wiedzieliśmy, że kilkunastoletnia infrastruktura kryje wiele niepotrzebnych zasobów i — prawdopodobnie — przestarzałą architekturę. Chcieliśmy się dowiedzieć, w jaki sposób klient wykorzystuje środowisko, aby trochę w nim posprzątać przed rozpoczęciem prac migracyjnych.  

Nasze działania przyniosły wymierne efekty: zoptymalizowaliśmy ponad 50 maszyn, które były używane w niewielkim stopniu, a nawet wcale. Tym samym ich funkcjonalności można było przenieść na pozostałe środowiska, a klient mógł zakupić aż o ¼ mniej sprzętu (oczywiście wpłynęło to też na kosztorys migracji do chmury). Po udanych porządkach zabraliśmy się za zaprojektowanie architektury docelowego środowiska od nowa, uwzględniając nie tylko duże zmiany w architekturze sieci, ale też w architekturze serwerów. Dopiero na tej podstawie dokonaliśmy wyceny każdego z trzech scenariuszy przejścia.

Przestarzała wersja VMware’a

W scenariuszach migracji musieliśmy uwzględniać również aspekty charakterystyczne tylko dla jednego czy dwóch wariantów. Tak było w przypadku pierwszego i drugiego scenariusza, w których to wyceniliśmy migrację do najnowszej wersji VMware’a. Obecny VMware nie miał już wsparcia, a bez supportu automatyczna migracja do chmury nie mogła mieć miejsca. Dlatego, jeżeli klient wybrałby któryś z nieazurowych scenariuszy, musielibyśmy migrować wszystko w 100% ręcznie, co zostało uwzględnione.

Nowa architektura a ISO 27 001

Kolejnym aspektem prac przed migracyjnych był fakt, że klient był właśnie w trakcie spełniania wymogów związanych z certyfikatem ISO 27 001. Musieliśmy uwzględnić ten aspekt i zaaplikować do nowej architektury wszystkie niezbędne wytyczne. Między innymi była to całkowita separacja środowisk produkcyjnych od nieprodukcyjnych, a także projektowych między sobą. Opracowaliśmy to w taki sposób, aby projekty na poziomie sieciowym nie widziały się wzajemnie, a separacja uprawnień zapewniała odpowiednie bezpieczeństwo. Wcześniej projekty były widoczne dla każdego z dostępem do sieci.

Obniżamy koszty migracji do chmury: najpierw 48%, potem kolejne 20%

Tak jak wspomnieliśmy na początku tekstu, klient przyszedł do nas ze wstępną wyceną migracji do Azure, używając w tym celu prostego kalkulatora: wpisał liczbę maszyn o sprecyzowanych parametrach i otrzymał kwotę. Nasze działania, związane z wyżej opisaną optymalizacją maszyn i zmianami w architekturze, pozwoliły zmniejszyć wyliczoną kwotę o 48% już na samym starcie działań. Natomiast kolejna obniżka wiązała się z ruchem sieciowym.  

W chmurze płacimy za maszyny wirtualne, czyli de facto za CPU, RAM i STORAGE, ale częstym błędem jest zapominanie o elemencie, który zabiera dużo energii, a tym samym pieniędzy: o ruchu sieciowym. Przed migracją ruch wyceniliśmy na podstawie miesięcznego skanu, dokonanego jeszcze na starej infrastrukturze klienta. Na tym etapie nowa architektura była tylko rozrysowanym planem, więc musieliśmy przyjąć jakiś sensowny punkt wyjścia i założyć, że ruch nie ulegnie zmianie. W praktyce jednak zmiany architektoniczne obniżyły ruch sieciowy i w ten sposób zyskaliśmy jeszcze 20% optymalizacji kosztów już po migracji.

Nowe scenariusze działania środowisk klienta

Standardem wśród wielu firm jest myślenie, że korzystają ze swoich środowisk 24h na dobę, siedem dni w tygodniu. W praktyce jednak część środowisk pracuje wyłącznie w nocy (przetwarzanie nocne), a część żyje tylko w momencie pracy developerów, czyli średnio między 7:00 a 18:00 i poza tym okienkiem dokonuje się wyłącznie backup. W ramach naszych działań dokonaliśmy analizy, w jaki sposób klient rzeczywiście korzysta ze swoich środowisk i zaproponowaliśmy nowe scenariusze ich działania.  

Zależało nam, aby pokazać, w jakich godzinach, które środowisko powinno być uruchomione, a w jakich można je spokojnie wyłączyć i niepotrzebnie nie płacić. Albo przynajmniej zmniejszyć koszty, bo niestety wyłączona maszyna też generuje pewne opłaty, o czym niżej.

Optymalizujemy STORAGE, żeby zmniejszyć koszty

Gdy maszyna wirtualna w chmurze jest wyłączona, nie płacimy za CPU czy za RAM, ale wciąż płacimy za STORAGE. Dlatego ważnym punktem w naszej optymalizacji była optymalizacja wykorzystania właśnie tych zasobów i oczyszczenie wszystkiego, co zbędne (a co nagromadziło się przez lata). Zmienialiśmy struktury związane z przechowywaniem dokumentów i plików, odcinając wiele przestarzałych elementów. Porządki w STORAGE to niezbędny krok każdej przemyślanej migracji, bo — chcąc nie chcąc — jest to tak naprawdę jedyny zasób, za który płacimy 24 godz. na dobę. 

Wsparcie i utrzymanie już po migracji do chmury Azure

Klient świadomie wybrał migrację do chmury, nie mając w firmie kompetencji w tym zakresie. Nie tylko związanych z samym wdrożeniem i migracją do Azure, ale również utrzymaniem i analizą zużycia. Po swojej stronie zapewniliśmy wsparcie, dzięki czemu nie został na żadnym etapie ani w żadnej warstwie kompetencji pozostawiony sam sobie. Na sam koniec założyliśmy odpowiednie alerty i uczyliśmy klienta, jak doglądać nową infrastrukturę, żeby nie było strachu o koszty, nad którymi nie ma kontroli. 

Mimo przekazanej wiedzy (którą w naszej ocenie zespół utrzymaniowy klienta przyswoił i na bieżąco wykorzystuje do obserwowania zużycia), klient zdecydował się na dalszą współpracę. W ten sposób weszliśmy niejako w rolę wielkiego brata i w trybie codziennym, analizujemy koszty oraz przekazujemy informacje, czy wszystko idzie zgodnie z założonym planem. Warto także pamiętać, że platforma Azure stale się rozwija, zachodzą zmiany w architekturze i pojawiają się kolejne udogodnienia. Będąc w stałej współpracy z klientem możemy reagować real-time i kiedy tylko pojawia się nowy, ciekawy feature, proponujemy zmiany, które podnoszą bezpieczeństwo infrastruktury i obniżają jej koszty.

Ile trwa taka migracja?

Na analizę, zaproponowanie prac optymalizacyjnych i zaprojektowanie nowej architektury potrzebowaliśmy mniej więcej kwartał. W momencie, w którym klient otrzymał kosztorysy i wybrał kierunek, narzucił nam jeden warunek: chciał przeznaczyć na migrację rok, nawet jeżeli moglibyśmy przyspieszyć prace. Podobną migrację można wykonać nawet w 2-3 miesiące, ale tutaj na specjalne życzenie pracowaliśmy dłużej, za to nasze działania w żadnym stopniu nie wpływały na rozwój biznesu i prace projektowe. Migracja została przeprowadzona niezauważalnie dla developerów i reszty zespołu klienta.