Potřeba být pro dnešní rychlý a zákaznicky orientovaný svět vybaven „modulárním systémem“ je jasná. A to nejen z pohledu samotné technické architektury, ale i struktury business procesů a produktů. Je to nemalá výzva, podobná snaze vyměnit polovinu součástek letadla za letu, kdy si nemůžete dovolit ani zpomalit, natož přistát, protože konkurence kolem vás se snaží zrychlovat.
Arbes Technologies již delší dobu úspěšně u klientů aplikuje své modulární řešení Arbes Digital Platform (ADP). Jeho hlavním posláním je poskytnout komplexní a současně s tím flexibilní přístup pro dekompozici monolitických systémů. Ty se vyvíjely řadu let a díky tomu získaly jak na robustnosti, tak na šíři funkcionalit, které jsou schopné pokrýt. Zároveň tím většinou ztratily na přehlednosti, flexibilitě a narostla cena jejich údržby.
Modularizace integračních vrstev a business logiky se tak ukazuje jako nezbytná cesta pro inovace jak zákaznických řešení, tak vlastního portfolia služeb a informačních systémů.
Jaké jsou reálné zkušenosti na této „dekompoziční“ cestě a které oblasti je třeba pohlídat?
V současné době je na straně zákazníků jedním z klíčových témat vhodná volba postupu dekompozice monolitických systémů, které stále v řadě organizací představují naprostý základ jejich informačního systému. Jako první se nabízí zdánlivě přímočarý a na první pohled jednoduchý přechod na mikroservisní služby, které jsou schopné vyřešit veškeré problémy, které se nahromadily za řadu let vývoje a zpracování funkcionalit. Ty často představují unikátní firemní know-how. Je nutné si ale uvědomit, že právě tento „generační“ skok, který je často prováděn na základě dílčích znalostí nebo nedostatečného ověření dalších postupů např. formou PoC nebo pouze pomocí vlastních IT kapacit, pak může vést k zastavení či významnému zdržení rozvoje nových služeb. Snaha o generační skok se pak lehce stane spíše „generačním šokem“.
Jak na dekompozici monolitu za pomoci ADP
Při implementaci ADP platformy, resp. jejího core modulu, který je jakýmsi „podvozkem“ pro budoucí samostatné mikroservisní moduly, jsme již získali řadu poznatků a prošli si také slepými uličkami. Jako první krok před zahájením samotné dekompozice je třeba mít jasně pojmenované stávající funkčnosti monolitické aplikace (s využitím frameworků, jako je BIAN či IBM IFW) a ty poté rozdělovat do samostatných modulů, které řeší danou oblast, nebo dekomponovaný systém rozdělit dle business domén či funkčností. Tento krok představuje základ pro vznik mikroslužeb, které mohou být poté postupně budovány.
Při vývoji mikroslužeb je třeba mít na paměti:
- způsob uložení a práce se specifickými údaji pro každou mikroslužbu
- změna v jedné mikroslužbě vyžaduje nasazení dalších služeb
- mnoho služeb sdílí stejné zdroje (např. databázi)
- mikroslužby spoléhají na komunikaci s nízkou latencí
Kritickým krokem je poté vyřešení způsobu komunikace koncových zákaznických aplikací se stávající monolitickou aplikací a současně s novými mikroslužbami tak, aby bylo možné kontinuálně ověřovat, že nová služba vrací stejné výsledky. Tento problém je třeba řešit vhodným návrhem komunikačních vrstev směrem od monolitu (za pomoci tzv. facade/services layers v kombinaci se Service Mediation Layer) k uživatelským aplikacím nebo kanálům, které tyto služby konzumují.
Dalším krokem je volba vhodného způsobu přesměrování komunikace do nových služeb tak, aby se v případě zjištění problémů bylo možné vrátit zpět ke službám poskytovaným původní monolitickou aplikací. Teprve poté lze začít s postupným převáděním stávajících monolitických služeb do nového mikroservisního prostředí. Typickým problémem, se kterým se setkáváme při nevhodném návrhu či nedodržení správných postupů, je vznik tzv. distribuovaného monolitu, což je vlastně systém, který se podobá architektuře mikroslužeb, ale je stále pevně svázán s monolitickou aplikací.
ADP platforma jako business driver
ADP a její core platforma neslouží pouze pro převod stávajících služeb monolitických aplikací do nových prostředí, ale lze ji též využít pro vývoj a provoz nových business modulů. Tyto mikroservisně orientované moduly se v řadě případů nemusí vytvářet od začátku, protože v rámci kontinuálního vývoje platformy již byly vyvinuty (např. modul pro onboarding klientů). Dále lze použít různá předpřipravená řešení zejména na úrovni front-endu, který lze v krátké době upravit pro specifickou potřebu zákazníka. Vhodnou kombinací mikroservisních modulů provozovaných na ADP platformě spolu se správně nastavenou customer journey se v řadě případů dá efektivně a v krátkém čase naimplementovat nová služba pokrývající E2E požadavky zákazníka. To významně snižuje čas nutný k uvedení takovéto služby do reálného provozu, než jak by tomu bylo v případě klasického vývoje řešení na míru nebo použití low-code vývojových platforem, jejichž výsledný efekt je v provozním prostředí často rozporuplný.
Evoluce, nebo revoluce?
Potřeba být pro dnešní rychlý a zákaznicky orientovaný svět vybaven „modulárním systémem“ je jasná. A to nejen z pohledu samotné technické architektury, ale i struktury business procesů a produktů (tzv. „composable business“ přístup). Mnohem pragmatičtější otázkou je, jak toto realizovat.
Je to nemalá výzva, podobná snaze vyměnit polovinu součástek letadla za letu, kdy si nemůžete dovolit ani zpomalit, natož přistát, protože konkurence kolem vás se snaží zrychlovat.
Věříme, že postupná evoluce je přístup správný a díky platformám a řešením, jako je ADP, i možný.
Pro říjnové číslo časopisu Bankovnictví David Kopřiva, ředitel divize Digital.