Abstrakt Modernizace IBM enterprise stacku patří k nejnáročnějším projektům v podnikové IT. Aplikace na AIX, DB2 a WebSphere často běží desetiletí bez výrazných výpadků, jejich licenční náklady jsou však vysoké a expertíza ubývá. Článek vychází ze zkušeností s migrací desítek kritických systémů ve finančních a státních organizacích a popisuje pragmatický postup od zhodnocení stavu přes migrační vlny po provozní optimalizaci v kontejnerizovaném prostředí.
1. Kdy se pevnost IBM stává klecí
Typická enterprise instalace IBM stacku zahrnuje AIX 7.x na hardware Power9 nebo Power10, DB2 verze 11.5 a vyšší, WebSphere Application Server Network Deployment 9.x, IBM HTTP Server jako frontend, ITCAM pro monitoring a produkty Tivoli pro správu. Charakteristické rysy zahrnují jednotné přihlašování přes TAM nebo ISAM, rozsáhlé Java EE aplikace s dědictvím EJB 2, uložené procedury v DB2 s logikou v PL/SQL a ručně laděné JVM s 64GB haldami.
Vázanost na IBM má tři roviny. Technická spočívá v proprietárních souborových systémech typu JFS2, knihovnách specifických pro AIX a deployment deskriptorech WebSphere. Komerční vyplývá z objemových licenčních smluv, podpory a investic do certifikací. Kulturní souvisí s konzervativní enterprise kulturou a specializovanými dovednostmi.
Reálné motivace pro modernizaci přicházejí typicky ze čtyř směrů. Licenční náklady přesahují dva miliony dolarů ročně. Poslední administrátoři AIX odcházejí do důchodu a nábor nových je nemožný. Cyklus nasazení trvá šest měsíců, což blokuje obchodní iniciativy. Regulatorní audity zpochybňují legacy infrastrukturu.
2. Fáze posouzení: poznat to, co máme
Automatizované nástroje typu IBM Application Discovery and Analysis dokážou analyzovat miliony řádků Java EE kódu, mapovat databázové závislosti a katalogizovat rozhraní. Doplňují je vlastní skripty pro profilaci AIX systémů, které zjišťují počet procesorů, paměť, konfiguraci úložiště a sítí.
Hodnocení složitosti aplikací probíhá ve třech kategoriích. Zelená skupina zahrnuje standardní Java EE aplikace s minimem vlastního kódu. Žlutá obsahuje vlastní EJB a střední vazbu na databázi. Červená je tvořena aplikacemi s těžkým využitím IBM specifických API a komplexními transakcemi.
V jedné středně velké bance proběhla inventarizace následovně: 47 Java EE aplikací, 234 DB2 databází, 1847 uložených procedur, 89 LDAP integrací a 156 závislostí na souborový systém. Tato čísla ukazují, proč se modernizace nedá zvládnout v měsících.
3. Třívrstvý přístup k migraci
Modernizace IBM stacku se osvědčuje rozdělit do tří vrstev, které lze postupně kombinovat. Vrstva infrastruktury zahrnuje přechod z AIX na RHEL, z PowerPC na x86_64 a z fyzických strojů na virtualizaci či kontejnery. Vrstva platformy obsahuje migraci z WebSphere Traditional na Liberty, případně náhradu DB2 za PostgreSQL a přípravu na rozdělení monolitického nasazení. Vrstva aplikací znamená přepis z Java EE na Spring Boot či Quarkus, přesun logiky z uložených procedur do aplikační vrstvy a transformaci na událostmi řízenou architekturu.
Migrační vlny typicky probíhají ve čtyřech fázích. Nultá vlna prvních tří měsíců slouží jako proof of concept na jednoduchých aplikacích a pro vybudování dovedností. První vlna pokrývá zhruba dvacet procent portfolia se středně složitými aplikacemi a paralelním provozem s produkcí. Další vlny probíhají hromadně s aplikací získaných ponaučení a plánováním vyřazení původního prostředí.
4. WebSphere: od Traditional k Liberty
WebSphere Traditional představuje instalaci o velikosti 500 MB s komplexní konfigurací. Liberty má 50 MB a využívá konvenci nad konfigurací. Tradiční konfigurační XML soubory se zkracují na server.xml o pár desítkách řádků. IBM Migration Toolkit for Application Binaries pomáhá identifikovat nekompatibilní místa, zejména přechod z EJB 2.1 na EJB 3 a aktualizace bezpečnostního API.
Kontejnerizace v Dockeru je přímočará: základní obraz websphere-liberty:kernel, kopie konfigurace a WAR souboru, aktivace potřebných funkcí. V OpenShiftu pak Liberty běží v podech s definovanými limity paměti a procesoru, externalizovanou konfigurací databáze a monitoringem přes standardní endpointy.
Výkonnostní rozdíly jsou výrazné. Doba startu Traditional WAS činí tři až osm minut, Liberty deset až třicet sekund, Spring Boot patnáct až čtyřicet pět sekund. Paměťová stopa základní instance klesá z 512 MB až 2 GB na 64 MB až 256 MB. V jedné bance přepis core banking modulu z WAS ND clusteru s 8 GB haldami na Liberty kontejnery s 2 GB haldami snížil paměťové nároky o šedesát procent a zrychlil restart desetinásobně.
5. Modernizace DB2
Rozhodování mezi zachováním DB2 a přechodem na PostgreSQL musí vycházet z reálných charakteristik. DB2 zůstává volbou při komplexních uložených procedurách nad tisíc řádek PL/SQL, vysokorychlostních OLTP zátěžích, existující odbornosti DBA a regulatorních požadavcích. PostgreSQL přichází v úvahu při tlaku na náklady, omezené odbornosti DB2, cíli na cloud-native architekturu a převážně standardním SQL.
Migrace DB2 z AIX na Linux řeší především otázku endianness. Architektura PowerPC pracuje v big endian režimu, x86 v little endian, což vynucuje export a import dat, znovu vytvoření indexů a konverzi vlastních binárních formátů. Praktický postup zahrnuje export schématu nástrojem db2look, export dat příkazem db2 export, instalaci DB2 11.5 na RHEL 8, obnovu schématu, import dat a sběr statistik.
Migrace na PostgreSQL naráží na rozdíly v syntaxi. Konstrukty WITH UR nebo FETCH FIRST nemají přímou náhradu. Sekvence se volají jinak, kurzory mají odlišné chování, výjimky se zpracovávají jinou syntaxí. AWS Schema Conversion Tool dosahuje úspěšnosti automatické konverze kolem sedmdesáti procent, vlastní skripty obvykle devadesát procent, ale s vyšším úsilím.
6. Z AIX na Linux
Technické rozdíly mezi AIX a Linuxem jsou hluboké. Souborové systémy JFS2 přecházejí na ext4 nebo xfs, správa svazků se mění z AIX LVM na Linux LVM s odlišnou syntaxí, mount pointy mají jiné konvence. Síťová konfigurace přechází ze SMIT na NetworkManager, firewall z IP filtering na iptables nebo nftables. Bezpečnostní model AIX RBAC se nahrazuje SELinux politikami.
Ekonomika hardware je výrazně ve prospěch x86. Skutečná migrace ukazuje následující čísla. Původní platforma se dvěma servery Power9 stála 450 tisíc dolarů s roční údržbou 85 tisíc, spotřebou 12 kW a obsazením osmi rackových jednotek. Náhrada čtyřmi servery Dell R750 stála 180 tisíc s údržbou 25 tisíc, 6 kW a čtyřmi U. Tříletá totální náklady na vlastnictví klesly z 705 na 255 tisíc dolarů, tedy o 64 procent.
Výkonnostní rozdíly jsou diferencovanější. Moderní x86 procesory jsou v jednovláknovém výkonu konkurenceschopné, paměťová propustnost zůstává historicky lepší u Power. V reálné OLTP bankovní zátěži klesl počet transakcí za sekundu o 15 procent, doba odezvy se zvýšila o osm milisekund, využití procesoru vzrostlo o 25 procent, paměť však klesla o 20 procent díky nižší režii Linuxu.
7. OpenShift jako cílová platforma
OpenShift se osvědčuje jako cílová platforma pro IBM modernizaci díky vestavěné bezpečnosti, pokročilé správě sítě, perzistentním svazkům, integrovanému Prometheu a Grafaně a nativní CI/CD. Tradiční IBM aplikace však očekávají lokální souborový systém, předvídatelná hostname, statické IP adresy a sdílenou paměť, takže přizpůsobení vyžaduje práci.
Pro stavové aplikace se používá StatefulSet s perzistentními svazky a stabilními síťovými identitami. Postupné přijetí cloud-native principů prochází třemi fázemi. První znamená pouhou kontejnerizaci se zachováním architektury. Druhá zavádí externalizovanou konfiguraci, health checky a standardizaci logování. Třetí přináší rozdělení na mikroslužby, událostmi řízenou architekturu a API-first přístup.
8. Případová studie: regionální banka
Výchozí stav v roce 2021 zahrnoval 34 kritických aplikací na AIX 7.2 a Power8, DB2 10.5, WebSphere 8.5.5 ND a roční IBM licence ve výši 3,2 milionu dolarů. Migrace probíhala v patnácti měsících. První tři měsíce zahrnovaly průzkum, mapování závislostí, návrh cílové architektury a školení. Další tři měsíce příprava infrastruktury OpenShift, sítě, bezpečnostních politik a CI/CD. Zbývajících devět měsíců probíhala migrace ve třech vlnách od šesti jednoduchých přes dvanáct středně složitých až po šestnáct vysoce složitých aplikací včetně core bankingu.
Mezi nejčastější výzvy patřilo odlišné chování JVM od IBM oproti OpenJDK, zejména v ladění garbage collectoru. Connection pooling se přesunul z aplikačního serveru na úroveň aplikace s nutností přizpůsobit velikost pro kontejnerové prostředí. Externí integrace přes IBM CTG na mainframe a IBM MQ vyžadovaly úpravy.
Výsledky po osmnácti měsících: 32 z 34 aplikací úspěšně migrováno, 2 vyřazeny místo migrace, roční licence klesly z 3,2 milionu na 800 tisíc dolarů, doba nasazení ze šesti týdnů na dva dny, vývojová rychlost vzrostla o 200 procent.
9. Závěr
Modernizace IBM stacku není projektem, ale programem. Trvá roky a vyžaduje kombinaci technické exekuce, řízení změn a investic do lidí. Pět zásad úspěchu: postupný vývoj místo revoluce, lidé na prvním místě, zaměření na obchodní hodnotu, konkrétní řízení rizik a dlouhodobá vize, kde migrace je začátkem, nikoliv koncem.
Praktická doporučení pro organizace, které stojí před rozhodnutím: začít s nekritickými aplikacemi pro získání zkušeností, investovat do školení existujícího týmu, počítat s realistickým časovým rámcem dvojnásobně až trojnásobně delším oproti původnímu odhadu, plánovat hybridní období v řádu let a měřit obchodní dopad, nikoliv jen technické metriky.
IBM stack není špatný, je konzervativní. To bylo správné v minulém desetiletí, dnes se však konzervativní přístup k technologiím stává existenčním rizikem. Úspěšná modernizace není výměnou platformy, ale obnovou schopnosti organizace inovovat.
Užitečné odkazy:
- IBM Application Modernization Field Guide
- Red Hat OpenShift Application Migration
- WebSphere Liberty Migration Guide
- DB2 to PostgreSQL Migration Guide
- AIX to Linux Migration Best Practices
- IBM Cloud Pak for Applications
