Modernizacja aplikacji legacy nie oznacza przepisania całego oprogramowania naraz. Dla wielu firm lepsze pierwsze pytanie brzmi: która funkcja musi się zmienić, co może na razie działać dalej i jak zachować poprawność zamówienia podczas przejścia? DAXS przeanalizowałby więc istniejącą aplikację Windows lub Linux pod kątem danych, interfejsów i zgód producenta przed wyborem nowego interfejsu użytkownika, API czy platformy.
Przeniesienie istniejącej VM może rozdzielić system operacyjny i sprzęt, ale nie modernizuje jeszcze samej aplikacji. Odbiór migracji VMware/Proxmox stanowi osobny etap. Tutaj chodzi o długoterminową zmianę funkcji i integracji podczas normalnej działalności firmy.
Najpierw opisać stan, potem wyznaczyć granicę
Inwentaryzacja wymaga więcej niż listy nazw serwerów. Karta każdej usługi obejmuje właściciela, grupy użytkowników, wersję Windows lub Linuksa, bazę i sterowniki, zadania wsadowe, udziały plikowe, drukarki, źródło tożsamości, interfejsy wejściowe i wyjściowe oraz umowy utrzymania i licencji. Szczególnie istotne są mało widoczne ścieżki: nocny eksport CSV do księgowości, konto usługi z wygasającym hasłem albo klient stanowiskowy, którego wersja zależy od serwera.
W oprogramowaniu zamkniętym producent określa wspierane systemy gościa, wersje baz, sterowniki i środowiska wirtualizacji. Bezpośredni zapis w jego bazie może wyglądać na prostą integrację, ale naruszać reguły biznesowe, warunki gwarancji i późniejsze aktualizacje. DAXS sprawdziłby najpierw udokumentowane API, zatwierdzony eksport lub SDK producenta. Gdy nie ma żadnego wspieranego punktu integracji, stopniowa wymiana może być technicznie lub umownie niewłaściwa; potrzebna jest wtedy inna decyzja z dostawcą.
Przykład: nowy status zamówień, dotychczasowy rdzeń
Załóżmy, że wewnętrzny system zamówień ma usługę aplikacyjną Windows, bazę SQL i nocny eksport. Klienci często pytają o status, a stary rdzeń niezawodnie obsługuje zamówienia i faktury. Pierwszą nową funkcją może być widok tylko do odczytu zasilany przez zatwierdzony interfejs. Rdzeń zamówień i jego baza początkowo pozostają źródłem nadrzędnym.
Warstwa integracji tłumaczy stare identyfikatory i statusy na nowy, udokumentowany model. To wzorzec adaptera lub Anti-Corruption Layer. Nie jest magicznym API przed niekontrolowaną bazą: trzeba ponownie sprawdzić prawa do zamówień, uwierzytelnianie, walidację wejścia, limity żądań, logowanie i czasy odpowiedzi. OWASP zalicza autoryzację na poziomie obiektu i uwierzytelnianie do głównych ryzyk API. Nawet odczyt statusu nie może ujawniać cudzych zamówień.
Dopiero po ustabilizowaniu odczytu może nastąpić ograniczony proces zapisu, np. wprowadzanie jednego typu zamówienia. Kluczowa staje się odpowiedzialność za dane: dopóki stary rdzeń jest nadrzędny, nowy interfejs nie może po cichu tworzyć drugiej niezależnej prawdy. Dla każdego rekordu należy określić system uprawniony do zapisu, jednoznaczne rozpoznawanie żądań oraz rozliczanie nieudanych prób, spóźnionych wiadomości i korekt. Jednoczesny zapis obu systemów bez biznesowego modelu konfliktów nie jest planem przejścia.
Cztery etapy z mierzalnym punktem zatrzymania
| Etap | Zmiana | Dowód wymagany przed następnym etapem |
|---|---|---|
| 1. Zabezpieczyć stan obecny | Zarejestrować zależności, umowy, przepływy danych i odtwarzalne kopie | Odtworzyć aplikację i bazę w sieci testowej; uzgodnić przykładowe zamówienie z działem biznesowym |
| 2. Oddzielić odczyt | Użyć zatwierdzonego eksportu/API dla nowego widoku statusu | Zmierzyć status, prawa wglądu, opóźnienie aktualizacji i obciążenie względem starego systemu |
| 3. Przenieść jeden przypadek zapisu | Obsłużyć jeden typ zamówienia nowym interfejsem; ustalić odpowiedzialność za dane | Zaksięgować każde zamówienie dokładnie raz, uzgodnić dokumenty i korekty, przećwiczyć powrót |
| 4. Wycofać starą część | Wyłączyć dopiero po udowodnionym przejęciu funkcji i danych | Brak nierozpoznanych wywołań, zaległych obowiązków eksportu/przechowywania i zależności od producenta |
Stopniowa wymiana funkcji przypomina wzorzec Strangler Fig. Nie pasuje wszędzie: gdy żądań nie da się przekierować, dostawca blokuje wszystkie interfejsy albo mały system łatwo wymienić w całości, adapter może wymagać więcej pracy, niż daje korzyści. Warstwa przejściowa sama potrzebuje monitoringu, zasobów i operatora; nie może stać się nowym pojedynczym punktem awarii.
Powrót ustalić przed pierwszym zapisem produkcyjnym
Przy widoku tylko do odczytu powrót bywa prosty: wyłączyć nowy widok, nadal używać rdzenia i zbadać przyczynę. Po pierwszym zapisie do nowej bazy samo przełączenie proxy z powrotem nie wystarczy. Nowe zamówienia, anulowania i dokumenty trzeba przenieść do starego stanu lub uzgodnić biznesowo. Każda zmiana wymaga więc ostatniego uzgodnionego stanu danych, wyraźnego zatrzymania zapisu, procedur eksportu/importu, odpowiedzialnych osób i próby. Microsoft wyraźnie ostrzega, że rollback staje się trudniejszy po usunięciu starych obiektów danych.
Nie wolno też zapominać o starym środowisku podczas pracy równoległej. Jeśli system lub aplikacja nie otrzymuje aktualizacji bezpieczeństwa, odpowiednie usługi, ścieżki sieciowe i dostępy należy ograniczyć, monitorować i objąć datą wyjścia. Nowe API przed aplikacją nie usuwa luki w starym rdzeniu. Wystarczalność izolacji zależy od konkretnego ryzyka i dostępnych środków producenta.
Uczciwie ocenić nakład i ograniczenia
Porównanie trzy- lub pięcioletnie obejmuje co najmniej analizę stanu, uzgodnienia producenta i licencji, rozwój adaptera, mapowanie danych, kontrolę bezpieczeństwa, dane testowe, odbiór biznesowy, pracę równoległą, monitoring i późniejsze wycofanie. Mogą dojść licencje systemu lub bazy i szkolenia osób tymczasowo obsługujących oba środowiska. Praca równoległa jest świadomym kosztem, nie darmowym etapem. Stopniowa modernizacja opłaca się dopiero wtedy, gdy uniknięte ryzyka i nowe funkcje uzasadniają rzeczywisty nakład; nie wynika z niej uniwersalny procent oszczędności.
DAXS wybrałby z działem biznesowym małą, widoczną pierwszą granicę, np. podgląd statusu z przykładu, i odebrał ją pod kątem poprawności danych, czasu odpowiedzi, możliwości wsparcia i odtwarzania. Następnie ustalono by, która kolejna funkcja rzeczywiście wymaga osobnej usługi. Dla podstaw technicznych istniejącej VM artykuł Proxmox w firmie przedstawia ramy infrastruktury; przewidywalna obsługa dostępów API uzupełnia późniejszą obsługę interfejsów. Aby przygotować konkretną kartę aplikacji, można skontaktować się z DAXS przez Kontakt.
Źródła: Microsoft Azure Architecture Center: wzorzec Strangler Fig · Microsoft: wzorzec Anti-Corruption Layer · OWASP: API Security Top 10.
