Finanční instituce může přesunout stovky aplikací do cloudu, a přesto dál vydávat změny jednou za čtvrtletí, čekat dny na nové prostředí a platit více než před migrací. Samotný cloud totiž neodstraňuje technologický dluh ani manuální řízení provozu. Hodnota vzniká teprve tehdy, když se spolu s infrastrukturou změní architektura, automatizace, odpovědnost týmů a způsob měření výsledků. Cloud-native přitom neznamená rozdělit každou aplikaci na mikroslužby, ale umět ji bezpečně, opakovatelně a ekonomicky měnit.

Migrace dokončena, změna trvá tři měsíce

Finanční instituce může úspěšně přesunout významnou část infrastruktury do cloudu, a přesto dál vydávat nové funkce jednou za několik měsíců.

Znáte to. Vývojář čeká na prostředí, změna putuje přes několik schvalovacích front, nasazení vyžaduje manuální zásah a po incidentu se teprve hledá, kdo službu skutečně vlastní. K tomu může přijít účet vyšší než před migrací, protože trvale běžící virtuální servery byly pouze přeneseny z vlastního datového centra do dražšího modelu placeného podle spotřeby.

To není selhání cloudu. Instituce změnila místo provozu aplikace, nikoli způsob, jakým je aplikace navržena, vyvíjena a provozována. Právě zde leží rozdíl mezi migrací infrastruktury a transformací technologické schopnosti.

„Konkurenční výhodu nepřináší cloudový účet. Přináší ji schopnost provádět bezpečné změny častěji, obnovit službu rychleji, propojit nový produkt přes rozhraní API a znát náklady na konkrétní transakci, “ říká Radek Teichmann, CTO MoroSystems

Čtyři různé úrovně změny

Rehosting, známý jako lift-and-shift, přesune aplikaci bez zásadní změny kódu či architektury.

Replatforming už část provozní zátěže předává spravované platformě, například databázi jako službě, ale aplikaci zásadně nepřepisuje.

Refactoring mění kód a architekturu tak, aby bylo možné využít automatické škálování, spravované služby nebo nezávislé nasazování komponent.

Cloud-native model jde ještě dál: propojuje vhodnou architekturu s automatizovaným vývojem, bezpečností, provozem a odpovědností produktových týmů. Toto rozlišení odpovídá běžně používaným migračním strategiím, ale žádná z nich není univerzálně správná pro celé portfolio.

Lift-and-shift typicky zachová monolitické závislosti, dlouhé vydávací cykly, ruční schvalování, slabou pozorovatelnost provozu i oddělení vývoje od provozu. Technologický dluh se pouze přestěhuje. Přibude navíc nový problém: variabilní cloudové náklady bez jasného vlastníka.

Přesto může být rehosting racionální. Pokud končí smlouva na datové centrum, probíhá rychlá konsolidace po akvizici nebo je nutné splnit pevný termín, minimalizuje změny během samotného přesunu. Musí však mít pojmenovanou druhou fázi, vlastníka a rozpočet. Bez nich se z přechodového řešení stane cílový stav.

Definice CNCF popisuje cloud-native systémy jako volně propojené, bezpečné, odolné, řiditelné a pozorovatelné, provozované programově a opakovatelně. Výslovně uvádí, že konkrétní technologie tvoří pouze různé kombinace, nikoli povinný seznam. To je důležitá korekce rozšířeného omylu, že cloud-native automaticky znamená mikroslužby a kontejnery všude.

Podrobněji jsme principy modularity, API-first přístupu a cloud-native systémů rozebrali také v článku MACH architektura: Budoucí standard? na blogu MoroSystems. I zde platí, že smyslem není zavádět konkrétní technologický vzor za každou cenu, ale vytvořit architekturu, kterou lze rozvíjet bez rostoucího počtu vzájemných závislostí.

Hodnota vzniká ve schopnosti měnit službu

Prvním zdrojem hodnoty je vhodně zvolená modularita. Mikroslužby dávají smysl tam, kde jednotlivé obchodní domény potřebují nezávisle škálovat, často se měnit a mít jasného vlastníka. Například scoring, notifikace nebo zpracování plateb mohou mít odlišný rytmus změn i nároky na výkon.

„U stabilní aplikace s jedním týmem však distribuovaná architektura přidá síťovou komunikaci, složitější testování, observabilitu a více provozních bodů selhání. Modularizovaný monolit nebo spravovaná platforma může být rychlejší, levnější a bezpečnější volbou. Cílem není maximalizovat počet služeb, ale minimalizovat závislosti, které brzdí změnu, „ doplňuje Teichmann.

Přístup API-first odděluje schopnosti banky od konkrétního uživatelského rozhraní. Zkracuje integraci fintechového partnera, nového distribučního kanálu nebo interní aplikace.

Událostmi řízená architektura má hodnotu tam, kde více systémů potřebuje rychle reagovat na vznik transakce, změnu limitu či podezření na podvod. Není však náhradou za všechny synchronní procesy. Bez řízení schémat, idempotence a dohledatelnosti událostí pouze vymění jednu sadu závislostí za jinou.

Druhým zdrojem hodnoty je automatizovaná cesta změny do produkce. CI/CD, automatické testy, Infrastructure as Code a bezpečnostní kontroly v pipeline zkracují lead time a současně vytvářejí auditní stopu. Stejná konfigurace se neopisuje do formuláře, ale opakovatelně vzniká z verzovaného kódu.

DevSecOps tím nepřesouvá odpovědnost za riziko na vývojáře. Přenáší kontrolu co nejblíže okamžiku, kdy změna vzniká, a umožňuje blokovat porušení pravidel ještě před nasazením.

Třetím zdrojem hodnoty je platform engineering. Centrální tým nemá být další schvalovací bránou. Má nabídnout bezpečné stavební bloky, například připravené pipeline, správu tajemství, logování, šablony infrastruktury a standardní síťové vzory. Produktový tým pak využije předem schválenou cestu bez zakládání tiketů.

DORA 2024 upozorňuje, že interní vývojová platforma může zlepšit produktivitu a výkonnost organizace, ale špatně zavedená může zhoršit stabilitu a průchodnost změn. Platforma tedy musí snižovat kognitivní zátěž, nikoli pouze centralizovat nástroje.

Čtvrtým zdrojem je vlastnictví výsledku. Tým odpovědný za produkt sleduje frekvenci nasazování, dobu od změny k produkci, podíl neúspěšných změn a dobu obnovy. K tomu přidává dostupnost služby, obchodní konverzi, jednotkové náklady a zákaznický dopad.

„Observabilita zde není sběr co největšího množství logů. Je to schopnost propojit technický incident s konkrétní službou, klientem a obchodním procesem, “ říká Jiří Bartoš, Head of Operations, MoroSystems

Stejnou disciplínu potřebují náklady. FinOps přiděluje spotřebu týmům a převádí účet za cloud na jednotkovou ekonomiku, například náklady na platbu, pojistnou smlouvu nebo aktivního klienta.

Úspora infrastruktury je jen jedna část. Vyšší účet může být obhajitelný, pokud instituce výrazně zkrátí uvedení produktu na trh nebo sníží dopad výpadků. Neobhajitelný je účet, jehož vlastník neumí vysvětlit, jakou schopnost či výnos financuje.

Pět otázek pro management každé finanční instituce

1. Jaký obchodní výsledek má modernizace IT přinést?

Výchozí metriky musí zahrnout lead time, dostupnost, dobu obnovy, náklad na změnu a jednotkový náklad produktu, jednotkové provozní náklady v čase, ne pouze počet serverů.

2. Má každá aplikace zdůvodněnou cílovou strategii?

U každé položky portfolia se rozhoduje mezi vyřazením, zachováním, nákupem služby, rehostingem, replatformingem a refactoringem.

3. Dostanou týmy zodpovědné za jednotlivé aplikace pravomoc nasadit ji do produkce?

Společná platforma má poskytovat pipeline, identity, logování, šablony infrastruktury a automatizované kontrolní důkazy.

4. Kdo vlastní službu po nasazení?

Produktový tým musí mít pravomoc i odpovědnost za změnu, provozní spolehlivost, bezpečnostní nápravy a spotřebu cloudu.

5. Měříme technologický výstup, nebo obchodní schopnost?

Jak rychle dostaneme novou funkci k zákazníkům, jak rychle naintegrujeme nového partnera, jak rychle dokážeme reagovat na novou regulaci, zákaznický dopad incidentu a náklad na transakci, průměrné náklady na novou funkci atd., atd.

Transformace začíná rozhodnutím, co neměnit

Dobrá cloudová strategie nezačíná cílem – migrovat 80 procent serverů. Začíná pojmenováním problému a definicí byznysových cílů. Vše ostatní následuje.

„Klíčová je role managementu. Ten by neměl požadovat jen procento migrovaných serverů. Měl by chtít důkaz, že instituce zkracuje cestu změny do produkce, zvyšuje odolnost, zná jednotkovou ekonomiku a zachovává kontrolu nad riziky. Teprve tehdy se z migrace stává transformace, “ říká Tomáš Páral, CEO MoroSystems.

Některé aplikace je vhodné vyřadit, jiné koupit jako službu, další replatformovat a jen ty s dostatečnou změnovostí či strategickou hodnotou refaktorovat. Tím se modernizace vyhne dvěma extrémům: drahému přestěhování všeho beze změny a stejně drahému přepisování všeho do mikroslužeb

Úspěch se následně měří na úrovni služby a produktu. Kolik trvá bezpečná změna sazby nebo limitu? Jak rychle se obnoví platební služba? Kolik stojí zpracování jedné transakce včetně sdílené platformy? Lze doložit, kdo schválil konfiguraci a která verze byla nasazena? A dokáže tým reagovat na regulatorní změnu bez několikaměsíčního programu závislostí?

Konkurenční výhodou není vlastnit cloudový účet ani provozovat aplikaci u hyperscaleru.

Konkurenční výhodou je schopnost bezpečně, opakovatelně a rychle měnit finanční služby dle byznysových potřeb finančních institucí.