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
Copy of Strategie migracji
By Mateusz Burniak
Copy of Strategie migracji
- 288