Cloud Migration Strategy – Wszystko Co Musisz Wiedzieć, Aby Zmigrować Do Chmury z Sukcesem!

Przedstawiam Ci ten artykuł z punktu widzenia architektów i konsultantów firmy Chmurowisko. Wiedz, że nie ma jednego sposobu. Jest jednak zbyt mało praktycznej wiedzy na naszym wspaniałym, polskim rynku. Dzielę się więc z Tobą naszą praktyką, która działa. Co z tym zrobisz, zależy od Ciebie.

Zaczynajmy więc z Cloud Migration Strategy.

Firmy pod względem procesu migracji do chmury dzielą się na cztery grupy:

1. Firmy, które nie chcą używać niczego w chmurze i nie będą [R.I.P]
2. Firmy, które nie mogą używać niczego w chmurze
3. Firmy, które znajdują w usługach cloud rozwiązania pewnych problemów biznesowych
4. Firmy, które widzą w chmurze strategiczne miejsce i planują zmigrować tam “wszystko”

Pamiętajmy, że chmura nie rozwiązuje żadnego problemu, którego nie rozwiązalibyśmy w swoim Data Center, ale pozwala zrobić to taniej (czasami) i szybciej (prawie zawsze).

O tą szybkość właśnie chodzi. Zamiast skupiać się na pracach całkowicie nie związanych z przewagą biznesową naszej firmy, oddajemy ten element dla firm, które robią to najlepiej i mają miliony klientów: patrz dostarczenie energii, usługi pocztowe, usługi finansowe, usługi budowania infrastruktury, platformy, aplikacji.

Dziś skupimy się na grupie 4. Na firmach, które widzą w chmurze strategiczne miejsce. Często te firmy nie wiedzą jak dokładnie przejść przez proces migracji do chmury.

Dziś pokażemy, jak taki proces wykonać.

W ostatnich czasach pomagaliśmy kilku firmom w takim procesie i widzimy olbrzymi postęp. Na wyniki poczekamy jeszcze kilka lat, ale jestem przekonany, że ten proces jest dobrą rzeczą do skopiowania dla Twojej firmy.

Duży PROBLEM zanim zaczniemy

Zanim zaczniemy powiem Ci jaki jest największy PROBLEM wśród firm, które chcą migrować do chmury… BRAK WIEDZY. Brak wiedzy o tym po co chcemy migrować do chmury oraz o tym co chmura ma nam do zaoferowania. W samym AWS jest 98 usług, a w Azure 93. Nie mówimy tu też o usługach SaaS.

Specjalistom i managerom brakuje wiedzy. Brak tej wiedzy komplikuje potem wiele rzeczy. Np. utożsamiamy chmure z mailem i wirtualnymi maszynami. Firmy, które przechodzą przez proces pracy z nami MUSZĄ przejść przez obowiązkowe treningi. Bez nich dalsza praca nie ma sensu.

Wysokopoziomowy migracji do chmury

W tym artykule nie skupiamy się na nowych aplikacjach, ale na aplikacjach używanych już w firmie. Proces nie wyklucza używania chmury do nowych projektów!

Zaczynajmy!

Często dostawcy usług korzystają z dość standardowego modelu.

1. Badanie
2. Planowanie
3. Projektowanie
4. Implementowanie
5. Zarządzanie

Jest to jednak zbyt proste w sytuacji, gdy planujemy strategiczną migrację do chmury. W Chmurowisku korzytamy z takiej kolejności

1. Edukacja
2. Zabawa
3. Ustalenie kryteriów sukcesu
4. Stworzenie szablonu do badania aplikacji
5. Warsztat analizy aplikacji
6. Ustalenie strategii backup i disaster recovery
7. Ustalenie wymagań bezpieczeństwa
8. Wybór dostawców usług cloud computing
9. Policzenie kosztów dla 2-3 aplikacji z kategorii Start Here/Quick Wins
10. Stworzenie strategii migracji do chmury
11. Prezentacji strategii migracji do chmury dla właścicieli/zarządu
12. Stworzenie Cloud Center of Excellence
13. Ustalenie dokumentu i procesu wdrażania dobrych praktyk w chmurze
14. Ustalenie planów do PoC i warunków z kryteriów sukcesu
15. Zbudowanie PoC
16. Sprawdzenie rezultatów PoC z założeniami
17. Budowa minimum landing zone (enterprise cloud environment)
18. Wdrożenie II aplikacji z wykorzystaniem standardów
19. Wdrożenie standardów Disaster Recovery
20. Start migracji aplikacji z zakładki Quick Wins
21. Start migracji aplikacji z zakładki Start Here

1. Edukacja

Proszę. Proszę. Proszę.

Jeżeli planujesz dalszą migrację, a Azure kojarzy Ci się z Windowsem, Office z Wordem, a Amazon z księgarnią, to zdobądź wiedzę, zanim zaczniesz z migracją.

Potrzebny jest element edukacji, aby zrozumieć:

1. Jak się płaci za chmurę?
2. Jakie usługi dostawcy dostarczają?
3. Jak wygląda temat SLA w chmurze?
4. Jak wyglądają umowy z dostawcami?
5. Jak wygląda bezpieczeństwo w chmurze?
6. Jak zbudowani są dostawcy cloud computing?
7. Jak inni w Polsce i na świecie używają chmury?

Jest wiele opcji, aby zdobyć tą wiedzę.

1. Konferencje
2. Spotkania User Group (AWS, Azure, Public Cloud)
3. Szkolenia online, np. Pluralsight
4. Jednodniowe szkolenia pokazujące WSZYSTKO

2. Zabawa

Masz już wiedzę. Czas zacząć używać chmury. Warto sprawdzić różne scenariusz, potestować, zrozumieć. Każdy może to zrobić – manager, architekt, programista, administrator.

Wystarczy założyć konto Trial i GO.

Dostawcy udostępniają konta na 1, 3, 12 miesięcy do testów. Dodatkowo w internecie jest masa przykładów, które można wziąć na warsztat, np. Serverless Allergy Checker with Amazon Rekognition, Lex, Polly, DynamoDB, S3 and Lambda.

3. Ustalenie kryteriów sukcesu

Ekstremalnie ważne. Bez tego nie idźmy dalej. Szkoda czasu.

Musimy ustalić metryki, którymi pokażemy, że migracja do chmury udała się!

Oto przykłady:

1. Koszt (Capex) – 50% oszczędności w skali 2 lat na aplikacji X
2. Koszt (Opex) – Ilość aplikacji do zespołu 2x
3. Szybkość tworzenia – Czas uruchomienia 100 maszyn – 1000%
4. Time to market – 80% szybsze uruchamianie produktu
5. Niezawodność – 20% mniej zgłoszeń dotyczących aplikacji
6. Dostępność- 20% większa dostępność aplikacji X
7. Elastyczność – Programista może sam wybrać stos aplikacyjny
8. Nowe pomysły – 50% więcej „TAK” dla nowych pomysłów

Gdy mamy wybraną 1, max. 2 cechy, to lecimy dalej. Poświęćmy jednak wystarczająco dużo czasu na ten punkt.

Idealnie jak ustalimy coś w stylu:

1. 20% oszczędności po zmigrowaniu danej aplikacji do chmury – 2 miesiące od produkcyjnego uruchomienia powinniśmy widzieć koszt infrastruktury i licencji zmniejszony o 20%.

Nie przesadzajmy. Nie bądźmy za bardzo kreatywni. Chmura daje masę dodatkowych benefitów, które pojawiają się po czasie, na które trzeba poczekać. Znajdźmy to co pokaże sukces na liczbach.

4. Stworzenie szablonu do badania aplikacji

Dokument powinien zawierać następujące pola per aplikację:

1. Nazwa aplikacji
2. Właściciel biznesowy
3. Cel biznesowy
4. Architektura aplikacji (jeżeli nie mamy tego w innym systemie)
5. Połączenia z innymi aplikacjami (jeżeli nie mamy tego w innym systemie)
6. Koszt hardware i software per aplikację
7. Dostawca aplikacji
8. Koszt aplikacji
9. 10-15 parametrów pomiaru aplikacji w aspekcie migracji do chmury

Parametry są zawsze ustalane indywidualnie i przydzielana jest im wartość od 1 do 5.

Przykłady parametrów:

1. Zależność pomiędzy systemami – z iloma innymi systemami jest połączona
2. Krytyczność danych – co się stanie jak dane, gdy dane będą niedostępne
3. Dopasowanie do wymagań – czy aplikacja jest custom made do potrzeb biznesu
4. Platforma technologiczna –  czy hardware/software jest standardowy
5. Ilość komponentów w aplikacji – ile usług, serwerów, baz, etc. znajduje się w aplikacji

Te elementy są kluczowe, ponieważ pozwalają nam zbudować pełen obraz aplikacji w firmie.

5. Warsztat analizy aplikacji

W warsztacie muszą wziąć udział osoby z działu IT oraz właściciele biznesowi danych rozwiązań. To kluczowe, aby wspólnie zdecydować, co ma się dziać z daną aplikacją.

Do tego buduje się model migracyjny, który jest ustalany przez zespół na warsztacie.

Naszym celem jest podział każdej aplikacji na 4 grupy i potem na 5 grup:

1. Quick Wins – idealne pod względem celu i prostoty
2. Start Here – dobre pod względem spełniania kryteriów sukcesu
3. Long-Term Bets – aplikacje, które dobrze odnajdą się w chmurze, ale potrzeba czasu, wiedzy i doświadczenia
4. Pursue Later – aplikacje, o których warto zapomnieć przynajmniej na 18-36 miesięcy

Następnie musimy przypisać do aplikacji model migracji

Podział usług na 5 grup migracyjnych

1. Retain – aplikacja nie nadaje się do migracji do chmury. Niech żyje dalej w DC
2. Retire – aplikacja do uśmiercenia. Może warto pomyśleć o nowej na jej miejsce
3. Replace – aplikację należy zamienić na nową, najlepiej w modelu SaaS
4. Rehost – aplikacja do przeniesienia w modelu wirtualnych maszyn do chmury
5. Reenvision – aplikacja do przeprojektowania w całości lub częściowo, aby wykorzystywać platformy i API dostępne w chmurze

Ale jak wybrać?

Analizując każdą aplikację. Podczas przechodzenia przez pierwsze aplikacje zaczną nam się pojawiać zależności, np.

Jeżeli kryteria sukcesu mają związek z finansami, to wybranie drogich aplikacji, które nie mają krytycznych danych, mają minimalną ilość komponentów i są custom made, to idealny pomysł na:

1. Start Here
2. Reenvision

Jeżeli aplikacja jest bardzo tania w utrzymaniu, ma krytyczne dane i dodatkowo będzie za 2 lata zabijana, bo kończymy tą część biznesu, to idealny pomysł na:

1. Pursue Later
2. Retire

Powoli budujemy model i dobrze skonstruowany dokument Excel sam podpowie co trzeba zrobić z daną aplikacją, gdy będziemy wpisywać kolejne dane. Oczywiście wszystko powinno być zaakceptowane przez opiekuna technicznego i biznesowego.

6. Ustalenie strategii backup i disaster recovery

Mając już obraz co chcemy zrobić z każdą aplikacją skupmy się na politykach backupu i disaster recovery per aplikację. Tu jeszcze nie rozmawiamy o technologii, ale o zasadach panujących w naszej firmie.

Backup – pamiętamy o regule 3:2:1.

DRC – określamy parametry RPO i RTO per aplikację.

Ważne, jeżeli systemy pracują w parach lub w większych stadach i są zależne od siebie, to weźmy to pod uwagę. W naszych projektach zdarza się, że myślimy o wielu aplikacjach jako o jednym zbiorze, który musi być objęty jedną reguła DRC.

7. Ustalenie wymagań bezpieczeństwa

Jednym z mądrzejszych systemów jest posiadanie jednej polityki bezpieczeństwa, którą rozciągamy na usługi w chmurze. Czasami jednak musimy obecną politykę rozbudować o kolejne elementy. Warto podejść do tego w modelu całościowym oraz per aplikację.

Oto niektóre elementy, które należy opracować:

1. Uwierzytelnienie
2. Ochrona danych w przesyle
3. Ochrona danych w stanie spoczynku
4. Dostęp oparty o role
5. Dostęp dla osób spoza organizacji
6. Audytowalność
7. Certyfikaty
8. Monitoring bezpieczeństwa zasobów
9. Monitoring bezpieczeństwa systemu zarządzania
10. Narzędzia bezpieczeństwa
11. Ochrona systemu operacyjnego
12. Bezpieczeństwo w procesie aktualizacji
13. Ochrona dostępu do aplikacji
14. I tak dalej i tak dalej

Pamiętajmy, że w chmurze pewne elementy odpadają i powierzamy je dostawcy, podpisując z nimi odpowiednie umowy lub akceptując warunki:

1. Ochrona DC
2. Ochrona dostaw energii elektrycznej
3. Ochrona dostępu do DC
4. Ochrona infrastruktury sieciowej
5. Ochrona infrastruktury serwerowej
6. Ochrona infrastruktury do przechowywania danych
7. Ochrona warstwy wirtualizacyjnej
8. Ochrona systemu (rozwiązania PaaS)
9. Ochrona aplikacji (rozwiązania SaaS)

8. Wybór dostawców usług cloud computing

Na tym etapie powinniśmy już mieć wiedzę o tym jacy dostawcy per daną aplikację lub całościowo będą idealni. Jeżeli nadal nie wiemy czy wybrać AWS czy Azure czy Oracle Cloud, a może Salesforce niżeli Dynamics lub PipeDrive, należy poprosić kogoś o pomoc.

Przydają się analizy SWOT i analiza pod kątem mocnych i słabych stron zespołu, który będzie z daną chmurą pracował.

Jedna ważna rada. Im mniej dostawców, tym łatwiej. Nie przesadzaj zarówno w ilości sprawdzanych dostawców, jak i z wyborem. Dobrą praktyką jest zacząć od jednego dostawcy dla infrastruktury i platformy i z minimalną ilością usług SaaS.

9. Policzenie kosztów dla 2-3 aplikacji z kategorii Start Here/Quick Wins

Dopiero teraz zaczynamy liczenie. Koszta są zawsze ważnym elementem, szczególnie gdy wybraliśmy kwestię związaną z kosztami. Wiemy już jaki dostawca i w jakim modelu będzie nam świadczył usługi.

Dam Ci dobrą radę jak to zrobić.

1. Wybierz max. 3 aplikacje z kategorii Start Here/Quick Wins
2. Dobrze jakby te aplikacje były z kategorii Replace, Rehost, Reenvision
3. Dla opcji replace policz koszt licencji SaaS
4. Dla opcji rehost policz infrastrukturę w chmurze
5. Dla opcji reenvision siadamy z zespołem projektantów i programistów i bazując na wiedzy zdobytej w części “Edukacja” budujemy architekturę docelową aplikacji wykorzystując usługi PaaS.

Tu też warto coś założyć, bo liczenie wszystkiego co do $ zakończy się klapą. Zabiera to bardzo dużo czasu. Dlatego warto policzyć np. 3 aplikacje i potem w etapie walidacji, sprawdzić czy założenia były prawdziwe i dokonywać kolejnych obliczeń migrując kolejne zasoby do chmury. Im więcej doświadczenia, tym łatwiejszy i dokładniejszy to proces.

Warto też stosować przybliżenia. Szczególnie gdy znamy aktualny koszt. Z naszego doświadczenia zakładamy oszczędności dla hardware/software:

1. Rehost – 0% – 50%
2. Replace – 50% – 90%
3. Reenvision – 20 – 90%

Pozwala nam to zrobić pewne założenia najlepszych przypadków i najgorszych przypadków oraz poprzeć tezę dokładnymi wyliczeniami dla kilku systemów. Liczby będą inne dla każdej firmy, ale w trakcie procesu będziemy dochodzić do lepszych i bardziej szczegółowych zakresów.

Ważne.

Do tej kwot dojdzie jeszcze koszt po opcji ustalania MLZ (Minimum Landing Zone), ale warto mieć to jako koszt stały IT i nie rozbijać per projekt (na tym etapie)

10. Stworzenie strategii migracji do chmury

W tym celu budujemy dokument migracji do chmury. Pracujemy w zespole. Ważne, aby było to żywy dokument, który za chwile będzie rozwijany przez Cloud Center of Excellence.

Warto zawrzeć w nim następujące rzeczy:

1. STRESZCZENIE KIEROWNICZE
2. PODSUMOWANIE STRATEGII
3. ANALIZA OBSZARU MERYTORYCZNEGO
4. CELE BIZNESOWE
5. CECHY POZYTYWNE I NEGATYWNE MIGRACJI
6. ZESTAW USŁUG
7. DECYZJA O SPOSOBIE I MODELU MIGRACJI
8. USŁUGI PRZEZNACZONE DO MIGRACJI
9. ARCHITEKTURA APLIKACJI ORAZ INFRASTRUKTURY CLOUD COMPUTING
10. ANALIZA KOSZTOWA
11. ROAD-MAP

Road-mapa powinna być realistyczna i zakładać najpierw kroki poniżej i następnie migrowanie pozostałych aplikacji z zakresu Start Here i Quick Wins. Strategia powinna być na 18-36 miesięcy, bo w trakcie realizacji strategii dojdzie do wielu zmian i odkryć zalet chmury.

11. Prezentacji strategii migracji do chmury dla właścicieli/zarządu

Jedną cechą udanych migracji firm do chmury jest zebranie po stronie zwolenników migracji jak największej ilości osób:

1. Architekci i programiści muszą wiedzieć jak używać
2. Administratorzy muszą wiedzieć jak zarządzać
3. Dział bezpieczeństwa musi wiedzieć, że jest to bezpieczne
4. Management musi wiedzieć, że zwiększy produktywność i realizację KPI
5. Zarząd musi wiedzieć, że przybliży to firmę do wyznaczonego kierunku

Dlatego tak ważne jest przedstawienie wizji i wyników strategii w przejrzysty sposób oraz namówienie zarządu  do…

12. Stworzenie Cloud Center of Excellence

Cloud Center of Excellence to zespół 2-6 osób, którego celem jest:

1. Nauka na sukcesach i błędach projektów w chmurze
2. Zwiększenie ROI projektów w chmurze
3. Regularne przeglądy projektu i badanie niepowodzeń projektów
4. Dostarczanie informacji o projektach w chmurze
5. Zdobywanie wiedzy o nowościach i aktualizacjach
6. Dzielenie się tą wiedzą w organizacji
7. Śledzenie kosztów chmury
8. Budowanie społeczności praktyków
9. Trenowanie wewnętrznych zespołów
10. Polecanie zewnętrznych trenerów lub organizacji
11. Zbudowanie portalu dotyczącego zagadnień chmury
12. Znajdowanie słabych i mocnych stron organizacji w aspekcie chmury
13. Ulepszanie procesów migracji, utwardzania MLZ
14. Tworzenie warsztatów i hackathonów wykorzystujących najnowsze technologie: A.I., IoT, Data Lakes, etc.

Powinni też mieć dodatkowe bonusy, jak np. premię zależną od:

1. Ilość warsztatów i hackathonów dookoła chmury w organizacji
2. Optymalizacja kosztów w aktualnych projektach
3. Ilość aktualizacji w dokumentach strategii i dobrych praktyk
4. Ilość indywidualnych projektów w chmurze

Co jest dodatkowo istotne (i dlatego wymaga to wsparcia zarządu) to zbudowanie tego zespołu spośród ludzi z różnych działów. Warto dodać tu programistę, architekta, administratora, product manager, osobę od finansów i optymalnie kogoś z zarządu (pamiętaj – każda firma jest albo będzie firmą produkującą oprogramowanie lub opierającą swój biznes na oprogramowaniu)

13. Ustalenie dokumentu i procesu wdrażania dobrych praktyk w chmurze

Następny krok to zbudowanie dokumentu, który będzie zawierał szczegółowe elementy związane z migracją do chmury, jak i środowiska docelowego. Należy wziąć pod uwagę:

1. Limity
2. Narzędzia
3. Zarządzanie kosztami
4. Zarządzanie subskrypcjami
5. Zarządzanie grupami zasobów
6. Implementacja polityk bezpieczeństwa
7. Konfigurację sieciową
8. Zarządzanie tożsamością
9. Implementacją polityk backup
10. Implementacją polityk DRC
11. Procesy przechodzenia przez migracje rehost, reenvision, replace
12. Proces migracji danych
13. Proces migracji konfiguracji
14. Implementacji procesu CI/CD
15. Strategii na przełączenie
16. Odtwarzaniem niepowodzenia migracji
17. Sposobami badania poprawności migracji

Lista ta będzie zawierać inne elementy w każdej firmie i też będzie bardzo zależała od wybranych dostawców chmury.

14. Ustalenie planów do PoC i warunków z kryteriów sukcesu

W tym kroku, bazując na road-map, bierzemy pierwszą aplikację z kategorii Quick Wins i budujemy dla niej architekturę, upewniamy się w kosztach i liczymy jeszcze raz koszta w chmurze.

Może, ale nie musi, to być wdrożone w naszej docelowej subskrypcji. Ważne, aby jak najszybciej pokazać, że wyliczenia i założenia dotyczące kryteriów sukcesu można podeprzeć wynikami w chmurze.

EKSTREMALNIE ważne jest upewnienie się, czy jesteśmy w stanie zmierzyć kryteria sukcesu.

15. Zbudowanie PoC

W tej fazie budujemy rozwiązanie Proof of Concept (PoC). Ważne jest, aby nie robić tego samemu i zatrudnić do pomocy osoby, które:

1. Mają doświadczenie z chmurą
2. Posiadają doświadczenie przy podobnych projektach
3. Znają nasze aplikacje i wiedza dlaczego migrujemy do chmury
4. Przekazują wiedzę, która przyda się przy kolejnych projektach

16. Sprawdzenie rezultatów PoC z założeniami

Jeżeli dobrze ustaliliśmy kryteria sukcesu, np. sprawdzenie wyników odbędzie się 2 miesiące po przeniesieniu pierwszej aplikacji do chmury, to powinniśmy być gotowi.

Badanie pewnych elementów w chmurze jest łatwiejsze niż inne. Najłatwiej jest z kosztami, bo to możemy bezpośrednio wyczytać z bilingi otrzymanego raz w miesiącu.

Jeżeli natomiast naszym kryterium sukcesu jest przyśpieszenie Time To Market, to nie zawsze uda nam się to tak łatwo udowodnić.

Ważne więc jest, aby już na etapie projektowania PoC ustalić jakie narzędzia lub jakie procesy będą użyte do zbadania, czy migracja dała wyniki.

Jeżeli wyniki są nie do zaakceptowania, to robimy jedną z kilku opcji:

1. Zmieniamy kryteria sukcesu i powtarzamy proces od danego punktu
2. Powtarzamy PoC, jeżeli wiemy, że popełniliśmy błąd
3. Przerywamy process. Pamiętajmy, że głównym celem jest wsparcie firmy w osiąganiu pewnych celów. Jeżeli nie możemy ich osiągnąć, to przenieśmy nasz intelektualny kapitał w inne miejsce.

Decyzja jest łatwiejsza do podjęcia, gdy w CCoE mamy osoby z zarządu.

17. Budowa minimum landing zone (enterprise cloud environment)

W świecie idealnym każdy programista wywołuje polecenie “git push” i główny architektu lib główny programista robi “merge” kodu. Aplikacje tworzą się same i są dostępne przez 365 dni w roku.

W rzeczywistości tak nie jest i szybko nie będzie. Potrzebujemy części wspólnej, systemów współdzielonych, rozwiązań implementujących polityki bezpieczeństwa, rozwiązań implementujących procesy CI/CD.

Do tego ważne jest, aby stworzyć Minimum Landing Zone, czyli miejsce, gdzie dana aplikacja może wylądować i mieć pewność, że proces wdrożenia zakłada wszystkie szczegóły opisane w punkcie 13. Duża część tych elementów będzie wspólnym kosztem. To nad czym trzeba pomyśleć to:

1. Łącze z chmurą
2. Połączenia VPN
3. Rozwiązania firm trzecich do backup/DRC
4. Rozwiązania firm trzecich do migracji
5. Narzędzia do zarządzania kosztami
6. Rozwiązania bezpieczeństwa (WAF, IPS oraz inne elementy używane w firmie)
7. Infrastruktura AD/DNS
8. Narzędzia monitoringu
9. Narzędzia automatyzujące

Pamiętajmy, że jest to proces i warto wersjonować MLZ i (jeżeli mamy wiedzę i doświadczenie) traktować ją w jak największym stopniu jako kod (Infrastructure as a Code).

W tym miejscu powinniśmy mieć już gotowe środowisko na produkcyjnej subskrypcji do migracji pierwszych aplikacji.

18. Wdrożenie II aplikacji z wykorzystaniem standardów

Na tym etapie posiadamy już MLZ, posiadamy wiedzę, że migracja działa i spełnia ustalenia, mamy listę kolejnych aplikacji, które będzie łatwo migrować, mamy nową wiedzę.

Czas migrować i sprawdzić jak kolejna aplikacja zachowa się na produkcji

19. Wdrożenie standardów Disaster Recovery

Tu po wdrożeniu aplikacji (o ile polityka nie wymaga tego już w procesie pierwotnego wdrożenia) należy uruchomić proces Disaster Recovery. Chmury również mają swoje problemy, więc warto zapewnić ciągłość pracy biznesu.

20. Start migracji aplikacji z zakładki Quick Wins

Na tym etapie kolejne aplikacje lądują w chmurze. Zdobywamy kolejną wiedzą, mamy więcej danych. Nasza strategia ewoluuje, nasze polityki ewoluują, nasza MLZ ewoluuje.

21. Start migracji aplikacji z zakładki Start Here

Po zakończeniu migracji aplikacji Quick Wins bierzemy się za kolejne aplikacje. Na tym etapie w Twojej firmie pojawiają się nowe stanowiska pracy związane z chmurą, IaC, procesami, bezpieczeństwem. Ale o tym dowiesz się już sam, gdy będziesz w tym miejscu, czego bardzo Ci życzę!

Podsumowanie

Pamiętaj, że ten proces będzie inny dla Twojej firmy i wiele elementów zostało tutaj pominiętych, gdyż chciałem, aby ten dokument miał dużo wartości dla każdej z firm.

Jeżeli potrzebujesz wsparcia w procesie na dowolnym punkcie zarezerwuj 1h konsultacje ze mną, które dadzą Ci dużo szczegółowej wartości dotyczącej Twojego przypadku.