Staré systémy mají dvě věci společné: fungují a každého znervózňují. Fungují, protože je roky reálného používání přizpůsobily skutečné firmě. Lidi znervózňují, protože se jich nikdo nechce dotknout, dokumentace je tenká a jeden z původních vývojářů odešel před třemi zaměstnáními.
Co se vlastně počítá jako "zastaralé"
Ne každý starý systém je zastaralý. Deset let stará aplikace běžící na podporovaných technologiích, dobře otestovaná, s aktivní údržbou, je prostě vyzrálá. Zastaralé obvykle znamená:
- Verze platformy nebo frameworku, které již nedostávají bezpečnostní aktualizace.
- Znalosti soustředěné v jednom či dvou lidech.
- Strach z provádění změn, protože malé změny rozbíjejí vzdálené funkce.
- Ruční nasazení, ruční testy, ruční všechno.
- Rostoucí propast mezi tím, co firma potřebuje, a tím, co systém umí.
Dva selhávající přístupy
- Nedělat nic. Riziko narůstá. Nakonec se něco kritického porouchá v nevhodnou chvíli.
- Přepsat od základu. Přepis stylem velkého třesku téměř vždy trvá déle, než se plánovalo, objeví skryté požadavky příliš pozdě a běží paralelně se starým systémem tak dlouho, že to tým vzdá.
Přístupy, které skutečně fungují, leží mezi těmito dvěma extrémy.
Strategie 1: Uškrťte starý systém
Nechte zastaralý systém běžet, ale postupně směrujte novou funkcionalitu přes novou vrstvu. Časem žije v novém systému stále více funkcí, starý se zmenšuje, dokud není nakonec vypnut.
Funguje to pro weby (přesouvejte stránku po stránce), interní nástroje (přesouvejte modul po modulu) a integrace (zaveďte novou API bránu a poté přesměrujte volající na ni).
Strategie 2: Modernizujte na místě
Někdy je architektura v pořádku, ale technologie jsou příliš staré. V tom případě aktualizujte jednu vrstvu po druhé: jazyk/runtime, pak knihovny, pak framework, pak nasazení. Postupně přidávejte automatizované testy, aby byl každý krok ověřitelný. Není to okázalé, ale velmi účinné.
Strategie 3: Rozdělte, poté modernizujte
Velké monolitické systémy se často snadněji modernizují kus po kuse, jakmile jsou hranice jasné. To znamená nejprve definovat hranice uvnitř stávajícího systému (moduly, ohraničené kontexty) a poté nezávisle nahrazovat moduly. Na hranicích záleží více než na volbě technologie.
Co udělat ještě před napsáním jakéhokoli kódu
- Zapište, co systém dnes skutečně dělá, ne co měl dělat.
- Identifikujte funkce, na kterých lidé denně závisejí, ty musejí během přechodu dál fungovat.
- Identifikujte mrtvé funkce, často tvoří významný podíl kódu a měly by být tiše vyřazeny.
- Proveďte inventuru dat, integrací, oprávnění a exportů. Právě zde se modernizační projekty obvykle dostávají do potíží.
- Rozhodněte, co "hotovo" znamená v měřitelných termínech.
Kontroly rizik, které dělají skutečný rozdíl
- Zálohy a ověřené obnovy, před jakoukoli změnou.
- Automatizované testy pro chování, na kterém vám záleží, zaváděné postupně.
- Feature flagy, aby bylo možné změny vrátit v produkci bez nasazení.
- Pozorovatelnost, logy, sledování chyb, klíčové obchodní metriky, abyste se rychle dozvěděli, že se něco zhoršilo.
- Postupné zavádění: nový kód běží nejprve pro interní uživatele, pak pro malé procento reálných uživatelů, pak pro všechny.
Vzor strangler fig. Místo rizikového přepisu stylem velkého třesku směrujete provoz přes tenkou fasádu, která postupně přeposílá stále více požadavků novým službám, zatímco zastaralý systém zpracovává zbytek, dokud není prázdný.
Příklad: minimální fasádní směrování
Malá brána může pro každou cestu rozhodnout, zda požadavek míří do zastaralého monolitu, nebo do nové služby. Napsáno způsobem nezávislým na frameworku:
app.use((req, res, next) => {
if (req.path.startsWith('/api/v2/invoices')) {
return proxy(req, res, NEW_SERVICE_URL);
}
return proxy(req, res, LEGACY_URL);
});Každý migrovaný modul přesune jeden prefix z LEGACY_URL do NEW_SERVICE_URL. Uživatelé nikdy nevidí přepnutí stylem velkého třesku, tým dodává malé, vratné kroky.
Běžná past: psát nový systém a starý tak, jako by musely být od prvního dne funkčně rovnocenné. Nemusejí. Začněte nejmenším kusem, který má skutečnou obchodní hodnotu, ověřte migrační cestu a poté opakujte.
Běžné chyby
- Dělat z modernizace otázku volby technologie. Efektní nové technologie nepomohou, pokud jsou datový model a integrace stále záhadou.
- Čekat na kompletní redesign, než opravíte viditelné problémy. Náklady nesou uživatelé, dynamika odumírá.
- Vypnout starý systém příliš brzy. Nechte oba běžet paralelně dost dlouho, abyste novému důvěřovali.
- Ztráta institucionálních znalostí. Spolupracujte s lidmi, kteří systém znají. Jejich znalosti jsou skutečným aktivem.
Realistický harmonogram
- Stabilizujte: zálohy, monitoring, bezpečnostní záplaty, minimální testy.
- Zmapujte: zdokumentujte, co existuje a co se skutečně používá.
- Prioritizujte: vyberte kus, který nyní bolí a je hodnotné ho modernizovat jako první.
- Nahraďte: postavte novou verzi té části vedle staré.
- Přepněte: směrujte provoz, monitorujte, opravujte problémy.
- Vyřaďte: vyřaďte starou část z provozu teprve poté, co byla nějakou dobu v klidu.
- Opakujte pro další část.
