A legacy alkalmazások korszerűsítése nem jelenti a teljes szoftver egyszerre történő újraírását. Sok vállalatnál jobb első kérdés, hogy melyik funkciónak kell változnia, mi működhet egyelőre tovább, és hogyan marad helyes egy rendelés az átmenet alatt. A DAXS ezért egy meglévő Windows- vagy Linux-alkalmazás adatait, interfészeit és gyártói jóváhagyásait tárná fel, mielőtt új felületről, API-ról vagy platformról döntene.
A meglévő VM áthelyezése elválaszthatja az operációs rendszert a hardvertől, de magát az alkalmazást még nem korszerűsíti. A VMware/Proxmox-migráció átvétele külön lépés. Itt a funkciók és integrációk hosszabb távú változtatásáról van szó, működő üzletmenet mellett.
Először a meglévő állapotot kell leírni, aztán határt húzni
A felméréshez több kell a szervernevek listájánál. Minden szolgáltatás alkalmazáskártyájára felkerül a gazda, a felhasználói csoportok, a Windows- vagy Linux-verzió, az adatbázis és illesztők, kötegelt feladatok, fájlmegosztások, nyomtatók, identitásforrás, bejövő és kimenő interfészek, valamint karbantartási és licencszerződés. Különösen fontosak a kevésbé látható utak: éjszakai CSV-export a könyvelésnek, lejáró jelszavú szolgáltatásfiók vagy a szerververzióhoz kötött munkaállomás-kliens.
Zárt forrású szoftvernél a gyártó határozza meg a támogatott vendégrendszereket, adatbázis-verziókat, illesztőket és virtualizációs környezeteket. Az adatbázisába közvetlenül írni egyszerű integrációnak tűnhet, de sértheti az üzleti szabályokat, garanciális feltételeket és későbbi frissítéseket. A DAXS először dokumentált API-t, jóváhagyott exportot vagy gyártói SDK-t vizsgálna. Ha semmilyen támogatott integrációs pont nincs, a fokozatos csere műszakilag vagy szerződésesen alkalmatlan lehet; ekkor más döntés szükséges a szállítóval.
Példa: új rendelési állapotnézet, megmaradó rendelési mag
Tegyük fel, hogy egy belső rendeléskezelőnek Windows-alkalmazásszolgáltatása, SQL-adatbázisa és éjszakai exportja van. Az ügyfelek gyakran kérdezik a rendelés állapotát, a régi mag viszont megbízhatóan kezeli a rendeléseket és számlákat. Az első új funkció lehetne egy csak olvasható állapotnézet, amely egy jóváhagyott interfészen kap adatokat. A rendelési mag és adatbázisa egyelőre a hiteles forrás marad.
Az integrációs réteg a régi azonosítókat és állapotokat egy dokumentált új modellre fordítja. Az elv adapterként vagy Anti-Corruption Layerként ismert. Nem varázslatos API egy ellenőrizetlen adatbázis előtt: a rendelésenkénti jogokat, hitelesítést, bemenetellenőrzést, híváskorlátokat, naplózást és válaszidőt újra kell vizsgálni. Az OWASP az objektumszintű jogosultságkezelést és a hitelesítést a fő API-kockázatok közé sorolja. Egy csak olvasó állapotlekérdezés sem fedheti fel mások rendeléseit.
Csak a stabil olvasás után következhet egy körülhatárolt írási folyamat, például egyetlen rendeléstípus felvétele. Az adatgazdai szerep ekkor kritikus: amíg a régi mag a hiteles forrás, az új felület nem hozhat létre észrevétlenül második, független igazságot. Minden rekordnál egyértelművé kell tenni, melyik rendszer írhat, hogyan azonosítjuk egyedileg a kéréseket, és hogyan egyeztetjük a sikertelen próbálkozásokat, késő üzeneteket és korrekciókat. A két rendszer egyidejű írása üzleti konfliktusmodell nélkül nem átállási terv.
Négy szakasz mérhető megállási ponttal
| Szakasz | Változás | Bizonyíték a következő szakasz előtt |
|---|---|---|
| 1. Meglévő állapot biztosítása | Függőségek, szerződések, adatfolyamok és visszaállítható mentések felmérése | Alkalmazás és adatbázis visszaállítása teszthálózaton; mintarendelés üzleti egyeztetése |
| 2. Olvasás leválasztása | Jóváhagyott export/API használata az új állapotnézethez | Állapot, láthatósági jogok, frissítési késés és terhelés mérése a régi rendszerhez képest |
| 3. Egy írási eset áthelyezése | Csak egy rendeléstípus kezelése az új interfészen; adatgazda meghatározása | Minden rendelés pontosan egyszeri könyvelése, bizonylatok és javítások egyeztetése, visszaút gyakorlása |
| 4. Régi rész kivezetése | Leállítás csak a funkció- és adatátvétel igazolása után | Nincs tisztázatlan rejtett hívó, export-/megőrzési kötelezettség vagy gyártói függőség |
A funkciók fokozatos kiváltása a Strangler Fig mintához hasonló. Nem mindenhol illik: ha a kérések nem irányíthatók át, a szállító minden interfészt lezár, vagy a teljes kis rendszer könnyen cserélhető, az adapter több munkát okozhat, mint amennyi értéket ad. Az átmeneti réteg maga is felügyeletet, kapacitást és üzemeltetőt igényel; nem válhat új egyetlen hibaponttá.
A visszautat az első éles írás előtt kell meghatározni
Egy csak olvasható állapotnézetnél a visszaút gyakran egyszerű: az új nézet kikapcsolása, a rendelési mag további használata és az ok kivizsgálása. Az új adatbázisba történő első írás után a proxy visszakapcsolása már nem elég. Az új rendeléseket, sztornókat és bizonylatokat vissza kell vezetni a régi állapotba vagy üzletileg rendezni. Minden váltáshoz kell ezért utolsó egyeztetett adatállapot, egyértelmű írásstop, export-/importeljárás, felelős és próba. A Microsoft kifejezetten figyelmeztet, hogy a régi adatobjektumok eltávolítása után a rollback nehezebbé válik.
A régi környezetet a párhuzamos időszakban sem szabad elfelejteni. Ha az operációs rendszer vagy alkalmazás már nem kap biztonsági frissítést, az érintett szolgáltatásokat, hálózati utakat és hozzáféréseket célzottan korlátozni, figyelni és kivezetési dátummal ellátni kell. Egy elé tett új API nem szünteti meg a régi mag sérülékenységét. Az izoláció elégségessége a konkrét kockázattól és a gyártó rendelkezésre álló intézkedéseitől függ.
A ráfordítás és korlátok őszinte értékelése
A három- vagy ötéves összehasonlítás legalább a felmérést, gyártói és licencegyeztetést, adapterfejlesztést, adatleképezést, biztonsági vizsgálatot, tesztadatokat, üzleti átvételt, párhuzamos üzemet, felügyeletet és későbbi kivezetést tartalmazza. Ehhez új rendszer- vagy adatbázislicencek és a két környezetet átmenetileg kezelő emberek képzése is társulhat. A párhuzamos üzem tudatos költségtétel, nem ingyenes köztes szakasz. A fokozatos megoldás csak akkor éri meg, ha az elkerült kockázatok és új funkciók indokolják a tényleges ráfordítást; általános megtakarítási százalék ebből nem vezethető le.
A DAXS az üzleti területtel kis, látható első határt választana, például az állapotlekérdezést, és helyes adatok, válaszidő, támogathatóság és visszaállítás alapján venné át. Ezután dőlne el, melyik következő funkciónak kell valóban saját szolgáltatás. A meglévő VM műszaki alapjaihoz a Proxmox a vállalatnál írja le az infrastruktúra keretét; API-hozzáférések tervezhető üzemeltetése pedig a későbbi interfészüzemeltetést egészíti ki. Konkrét alkalmazáskártya készítéséhez a DAXS elérhető itt: Kapcsolat.
Források: Microsoft Azure Architecture Center: Strangler Fig minta · Microsoft: Anti-Corruption Layer minta · OWASP: API Security Top 10.
