Modernizovat starší aplikace neznamená přepsat veškerý software najednou. Pro řadu firem je lepší první otázkou, která funkce se musí změnit, co může zatím fungovat dál a jak zůstane objednávka během přechodu správná. DAXS by proto nejprve rozebral stávající aplikaci Windows nebo Linux podle dat, rozhraní a schválení výrobce, než by rozhodl o nové uživatelské vrstvě, API či platformě.
Přesun stávající VM může oddělit operační systém od hardwaru, ale samotnou aplikaci ještě nemodernizuje. Přejímka migrace VMware/Proxmox je samostatný krok. Zde jde o dlouhodobější změnu funkcí a integrací za běžícího firemního provozu.
Nejprve popsat stav, potom vymezit hranici
Inventura vyžaduje více než seznam názvů serverů. Karta každé služby zahrnuje vlastníka, skupiny uživatelů, verzi Windows nebo Linuxu, databázi a ovladače, dávkové úlohy, sdílené soubory, tiskárny, zdroj identit, vstupní a výstupní rozhraní i smlouvy o údržbě a licencích. Zvlášť důležité jsou málo viditelné cesty: noční export CSV do účetnictví, servisní účet s končícím heslem nebo klient navázaný svou verzí na server.
U proprietárního softwaru výrobce určuje podporované hostované systémy, verze databází, ovladače a virtualizační prostředí. Přímý zápis do jeho databáze může působit jako snadná integrace, ale porušit obchodní pravidla, záruční podmínky a budoucí aktualizace. DAXS by nejprve prověřil dokumentované API, schválený export nebo SDK výrobce. Pokud chybí jakýkoli podporovaný integrační bod, postupná náhrada může být technicky či smluvně nevhodná; je pak třeba jiné rozhodnutí s dodavatelem.
Příklad: nový stav objednávek, původní jádro zůstává
Předpokládejme, že interní správa objednávek má aplikační službu Windows, databázi SQL a noční export. Zákazníci se často ptají na stav objednávek, zatímco staré jádro spolehlivě zpracovává objednávky a faktury. První novou funkcí může být přehled stavu pouze pro čtení, zásobovaný přes schválené rozhraní. Jádro objednávek a jeho databáze zatím zůstávají hlavním zdrojem pravdy.
Integrační vrstva převádí staré identifikátory a stavy do nového dokumentovaného modelu. Princip je známý jako adaptér nebo Anti-Corruption Layer. Nejde o kouzelné API před nekontrolovanou databází: oprávnění pro jednotlivé objednávky, autentizaci, ověření vstupů, limity požadavků, protokolování i dobu odezvy je nutné nově posoudit. OWASP řadí oprávnění na úrovni objektů a autentizaci mezi hlavní rizika API. Ani dotaz na stav pouze pro čtení nesmí zpřístupnit cizí objednávky.
Až po stabilizaci čtení může následovat vymezený zápisový proces, například zadání jediného typu objednávky. Rozhodující je nyní odpovědnost za data: dokud je staré jádro hlavním zdrojem, nové rozhraní nesmí potají vytvářet druhou nezávislou pravdu. Pro každý záznam musí být jasné, který systém smí zapisovat, jak jednoznačně rozpoznat požadavky a jak vypořádat neúspěšné pokusy, opožděné zprávy a opravy. Souběžný zápis obou systémů bez obchodního modelu konfliktů není přechodový plán.
Čtyři etapy s měřitelným bodem zastavení
| Etapa | Změna | Důkaz před další etapou |
|---|---|---|
| 1. Zajistit stávající stav | Zachytit závislosti, smlouvy, datové toky a obnovitelné zálohy | Obnovit aplikaci a databázi v testovací síti; věcně ověřit vzorovou objednávku |
| 2. Oddělit čtení | Použít schválený export/API pro nový přehled stavu | Měřit stav, práva zobrazení, zpoždění aktualizace a zátěž vůči starému systému |
| 3. Přesunout jeden případ zápisu | Vést jediný typ objednávky novým rozhraním; určit odpovědnost za data | Zaúčtovat každou objednávku právě jednou, porovnat doklady a opravy, nacvičit návrat |
| 4. Odstranit starou část | Vypnout až po prokázaném převzetí funkcí a dat | Žádní skrytí volající, nevyřešené exportní/archivační povinnosti či závislosti na výrobci |
Postupná náhrada jednotlivých funkcí připomíná vzor Strangler Fig. Nehodí se všude: pokud nelze požadavky přesměrovat, dodavatel blokuje všechna rozhraní nebo lze malý systém snadno nahradit celý, adaptér může přinést více práce než užitku. Přechodová vrstva sama potřebuje monitoring, kapacitu a provozovatele; nesmí se stát novým jediným bodem selhání.
Návrat stanovit před prvním produkčním zápisem
U přehledu stavu pouze pro čtení bývá návrat jednoduchý: vypnout nový přehled, dál používat jádro a vyšetřit příčinu. Po prvním zápisu do nové databáze již přepnutí proxy zpět nestačí. Nové objednávky, storna a doklady se musí vrátit do starého stavu nebo věcně vypořádat. Každá změna proto potřebuje poslední sjednocený stav dat, jasné zastavení zápisu, exportní/importní postupy, odpovědné osoby a cvičení. Dokumentace Microsoftu výslovně upozorňuje na obtížnější návrat po odstranění starých datových objektů.
Ani za souběžného provozu se nesmí zapomenout na staré prostředí. Pokud systém nebo aplikace již nedostává bezpečnostní aktualizace, je třeba cíleně omezit a sledovat dotčené služby, síťové cesty a přístupy a určit datum ukončení. Nové API před aplikací neodstraní zranitelnost starého jádra. Zda izolace v daném případě stačí, závisí na riziku a dostupných opatřeních výrobce.
Poctivě vyčíslit náročnost a meze
Tříleté či pětileté porovnání zahrnuje nejméně analýzu stavu, vyjasnění podmínek výrobce a licencí, vývoj adaptéru, mapování dat, bezpečnostní posouzení, testovací data, přejímku oddělením, souběžný provoz, monitoring a pozdější odstranění. Přibýt mohou licence systému či databáze a školení lidí, kteří přechodně spravují oba světy. Souběžný provoz je záměrná nákladová položka, nikoli bezplatná mezifáze. Postupná cesta se vyplatí jen tehdy, když snížená provozní rizika a nové funkce odůvodní skutečnou náročnost; obecné procento úspory z toho odvodit nelze.
DAXS by s příslušným oddělením vybral malou viditelnou první hranici, třeba dotaz na stav z příkladu, a převzal ji podle správnosti dat, odezvy, podporovatelnosti a obnovy. Pak by rozhodl, která další funkce skutečně potřebuje vlastní službu. Pro technický základ stávající VM Proxmox ve firmě popisuje infrastrukturní rámec; plánovatelný provoz API přístupů doplňuje následnou správu rozhraní. Kdo chce vytvořit konkrétní aplikační kartu, může DAXS oslovit přes Kontakt.
Zdroje: Microsoft Azure Architecture Center: vzor Strangler Fig · Microsoft: vzor Anti-Corruption Layer · OWASP: API Security Top 10.
