Strategie
Migracji
Systemów

Michał Bieroński 218324

Mateusz Burniak 218321

Agenda

  • Definicja
  • Etapy
  • Strategie
    • Refronting
    • Replacement
    • Rehosting
    • Rearchitecting
    • Interoperation
    • Retirement
    • Big Bang
  • Przykładowa technika
  • Podsumowanie

Definicja migracji

  • Konwersja lub przepisanie starego systemu
    na nowocześniejszy język programowania lub OS
  • Przepływ technologii ze starej na nową
  • Docelowo niższe koszty i lepsza współpraca
  • Zwiększa niezawodność

Etapy migracji

1. Audyt

  • dokumentacja zainstalowanych komponentów
  • przydatny jest
    • projekt systemu
    • kopie oprogramowania
  • jeśli brak - inwentaryzacja systemu

2. Analiza zasobów

  • na podstawie dokumentacji  z audytu
  • lista wycofanych elementów
  • uzupełnienie listy o następców dla wycofanych elementów

3. Strategia

  • przygotowanie scenariusza działań
  • ścisła współpraca z klientem
  • sprecyzowanie propozycji staretegii pod klienta
  • możliwość podziału na etapy
  • omówienie wszystkich alternatywnych rozwiązań

4. Wybór rozwiązania

  • porównanie proponowanych strategii
  • wyłonienie najlepszej strategii na potrzeby klienta

5. Migracja

  • dokonujemy migracji według ustalonego we wcześniejszych etapach planu

Strategie

Refronting

  • Zmiana interfejsu
  • Ta sama logika
  • Jeśli możliwe, dodanie
    interfejsu sieciowego

Refronting - zalety

  • Łatwość przeprowadzenia migracji
  • Mała ingerencja w kod aplikacji
  • Niski koszt

Refronting - wady

  • Konieczność nauki nowego interfejsu
    przez użytkowników

Replacement

  • Rozbicie aplikacji na funkcjonalne komponenty
    i zamiana fragmentów aplikacji
  • Zastąpienie kodem swoim lub innych firm
  • Commercial of-the-shelf (COTS)

Rehosting

  • Przeniesienie całej platformy z źródłowego środowiska bez zmian funkcjonalności
  • Nie zmienia aplikacji i architektury
  • Nowe możliwości zapewniane poprzez przeniesienie na nową platformę

Rehosting zalety

  • Zmniejszone ryzyko niskiego dewelopmentu
  • Szybki zwrot inwestycji
  • Nie ma potrzeby na nowo wdrażać użytkowników do systemu - brak zmian funkcjonalności, architektury
  • Dobre podejście by zmiejszyć koszty utrzymania i wsparcia systemu
  • Preferowany, gdy aktualna logika biznesowa pozostaje konkurencyjna na rynku i jest warta zachowania

 

 

Rehosting wady

  • Brak zmian w architekturze oprogramowania może oznaczać niemożliwość wykorzystania funkcjonalności oferowanych przez docelowe środowisko

 

Rearchitecting

  • Aplikacje tworzone są od zera na nowej platformie
  • Sugerowane dla aplikacji o słabej efektywności
  • Wykorzystuje nowe technologie, najnowsze wzorce i paradygmaty programowania

Rearchitecting zalety

  • Wykorzystanie najnowszych technologii
  • Łatwo osiągnąć kompatybilność z nowym środowiskiem
  • Łatwe wykorzystanie nowych funkcjonalności oferowanych przez nowe środowisko
  • Szansa na zwiększenie efektywności aplikacji oraz dodanie nowych funkcjonalności

 

 

Rearchitecting wady

  • Kosztowne
  • Czasochłonne
  • Wymaga ponownego wdrażania użytkowników, deweloperów oraz działu technicznego

 

 

Interoperation

  • Nie ruszamy bezpośrednio aplikacji
  • Otaczamy ją nową technologią, kiedy jest to wymagane
  • Konieczność możliwej interakcji starego oprogramowania z nowym

Interoperation zalety

  • Nie jest kosztochłonne
  • Nie jest czasochłonne
  • Wielu dostawców zapewnia technologie zapewniającą możliwość integracji starego oprogramowania z nowym

 

 

Interoperation wady

  • Ryzykowne
  • Może prowadzić do całkowitej bezużyteczności systemu - brak jego integralności z innymi modułami
  • Może prowadzić do braku wsparcia dla wycofanych już technologii
  • Możliwy brak oprogramowania integrującego stare wersje z nowymi

 

 

Retirement

  • Wycofanie funkcjonalności, gdy przestaje być potrzebna

Retirement - zalety

  • Mniej kodu do utrzymania

Retirement - wady

  • Usunięte funkcjonalności mogą okazać się potrzebne

Big Bang

  • Nagłe wprowadzenie nowego systemu
    i wyłączenie starego
  • Podobne do szybkiego odrywania plastra,
    może zaboleć, ale któtko

Big Bang - zalety

  • Niski koszt
  • Brak konieczności utrzymania dwóch systemów
  • Krótki czas wdrożenia
  • Szkolenia z nowej wersji systemu

Big Bang - wady

  • Wysokie ryzyko
  • Wiele rzeczy może pójść źle
  • Plany powrotu nie zawsze działają

Przykładowa technika

Branch by abstraction

Krok 0

Różne części systemu zależne są od dango modułu, biblioteki, frameworka, który chcemy wymienić

Krok 1

Tworzymy warstwę abstrakcji, przez którą "przepuszczana" jest cała interakcja z aktualnym dostawcą.

Modyfikujemy jedną z sekcji klienta, tak by odwoływał się do dostawcy poprzez tę wartswę.

Krok 2

Stopniowo wszystkie sekcje klienta powinny odwoływać się do dostawcy poprzez tę warstwę.

Krok 3

Budujemy nowego dostawcę, który implementuje jedną część kodu klienta,  wykorzystując zadaną warstwę abstrakcji.

 

Gdy jest już gotowy, przepinamy do niego obsługiwaną już sekcję klienta.

Krok 4

Stopniowo przepinamy sekcje klienta do nowego dostawcy, aż do momentu gdy wszystkie sekcje są przez niego obsługiwane.

 

W tym momencie możemy już pozbyć się starego modułu.

Podsumowanie

Źródła

  • https://medium.com/aws-enterprise-collection/6-strategies-for-migrating-applications-to-the-cloud-eb4e85c412b4
  • https://martinfowler.com/bliki/BranchByAbstraction.html
  • https://speakerdeck.com/s0enke/software-migration-strategies
  • http://www.mawos.com.pl/Files/MigracjaSystem%C3%B3wSterowania_INFO_PL.pdf
  • https://www.platformmodernization.org/transvive/Lists/ResearchPapers/Attachments/1/Transvive-MainframeMigrationStrategy-WP.pdf

Michał Bieroński 218324

Mateusz Burniak 218321

Made with Slides.com