Přechod do cloudu má svoje úskalí, která nemusejí být jen technického charakteru. Jan Mlynár ze společnosti Stratox vysvětluje, jak a kdy rozbít větší celky, přistoupit k agilnímu vývoji, nasadit mikroslužby, ale hlavně jak provést úvodní analýzu byznysové aplikace zákazníka. Stratox pro ni nabízí vlastní metodiku, kterou nazývá Health Check Assessment.
Pokud se zákazník rozhodne přejít se svým IT do cloudu, jaká jsou úskalí?
Když má firma nějaký zakázkový software, který běží typicky na jeho serverech v datovém centru a uvažuje o jeho migraci a provozu do cloudu, pak aby byl jeho provoz efektivní, je potřeba splnit určité předpoklady. Přenést nějakou aplikaci do cloudu není až tak velký technický problém. Ten typicky nastává, když se zjistí, jaké jsou na její provoz náklady, které vystřelí nahoru i ve srovnání s cenou provozu on-premise, tj. v jeho datovém centru.
Proč se tomu tak děje?
Tento problém spočívá v přílišné „hrubozrnnosti“ aplikací, které nevyužívají správně zdroje, s nimiž pracují. Typický k tomu dochází, když je aplikace příliš monolitická, nasazená komponenta je příliš veliká a má příliš velikou režii ohledně nasazení a spotřebovávaných zdrojů u některých instancí, tj. procesorů, paměti apod. Když se takovou aplikaci snažíte nasadit do virtuálního stroje nebo clusteru v prostředí Kubernetes u poskytovatele cloudu, začnete se potýkat s fragmentací zdrojů. Když máte určitou velikost clusteru a jedna instance vám zabere příliš mnoho místa, pak je velice těžké řídit zdroje efektivně, je těžké nasadit další komponentu, nasazení dlouho trvá když je to veliké apod.
Jak tomu lze zabránit? Existuje nějaké lepší řešení?
Řešení spočívá v rozdělení aplikace na menší celky, komponenty, které jsou samostatně nasaditelné. Jejich nasazení se lépe provádí, je to rychlejší a zabírají méně místa a zdrojů, je lze lépe poskládat do určitého prostoru zdrojů, které má cluster k dispozici. Zároveň nevyužívá zdroje rovnoměrně. Některé moduly využívají zdroje s intenzivněji, jiné méně. Když aplikaci rozdělíte na komponenty, dokážete ji škálovat mnohem výše. Z kritické komponenty si tak můžete vyrobit třeba deset instancí, aby kapacita zpracování byla odpovídající kapacitě celého řetězce, u jiné komponenty vám zase bude stačit jen jedna instance, protože je u ní byznysová logika mnohem jednodušší.
Což znamená, že je zapotřebí analýza původního celku?
Ano, určitě je zapotřebí se podívat, jaký je vlastně účel aplikace, jaké jsou funkční, ale i nefunkční požadavky, například ohledně bezpečnosti, dostupnosti; s tím se také často potkáváme. Proto pak není efektivní zabezpečovat perimetr celé aplikace, ale lze se soustředit na nějakou menší část, nebo řešit dostupnost jen určité kritické části aplikace a zbytek může mít méně přísnou SLA na provoz.
Jak přistupujete k s popsanými metodami k zákazníkovi vy, musíte přece také provést analýzu jeho prostředí a dané byznysové aplikace?
Ve Stratoxu máme propracovanou metodiku, kterou nazýváme Health Check Assessment, kde se v průběhu přibližně dvou týdnů podíváme na prostředí klienta, většinou v konkrétní oblasti s konkrétním zadáním. Tím může být rychlost dodávky softwaru, škálovatelností, nebo si nejsou jisti, zda je jejich aplikace připravená pro běh v cloudu. Podíváme se na byznysové požadavky pro danou oblast, aplikaci nebo aplikace, jakým způsobem je postavená současná aplikační architektura, jak daná společnost nebo její dodavatel řeší způsob dodávky softwaru a jak mají vyřešenou architekturu infrastruktury. V každé z těchto oblastí se podíváme, jak současný stav ve vztahu k byznysovým požadavkům ať už funkčním nebo nefunkčním, kde jsou nějaká problematická místa. V souladu s touto metodikou probíhá třeba standardní prověření připravenosti nativní přechodu do cloudu (Cloud Native Maturity Assessment), kde se díváme na mnoho hledisek; kulturu v organizaci, jakým způsobem navrhují změny, jak provádějí inovace, jak spolupracují týmy, jak mají v organizaci nastavené procesy pro dodávku softwaru, využívání dané funkčnosti, jak je navržená architektura, na jakých principech ji navrhují, jak řeší údržbu softwaru, nasazování změn, podporu provozu, podporu infrastrukturní vrstvy. Výsledkem této dvoutýdenní aktivity je soubor zjištění a závěrů, a to pro každou vrstvu zvlášť. Každý z těchto závěrů pak má řekněme samostatnou kartu nebo detail, na kterém je vidět jeho popis daného závěru, jaké má dopady problém, který jsme identifikovali. Jaká je jeho závažnost, míra rizika která s sebou nese a potřebná opatření pro zlepšení situace. Samozřejmě, že ne všechny závěry mají stejnou váhu, pracnost, takže nakonec klientovi navrhneme nějakou z našeho pohledu optimální cestu k řešení jeho problémů. Samozřejmě i v závislosti na tom, jaké jsou jeho požadavky, co a jak rychle je potřeba vyřešit. Kolik má k řešení prostředků, kolik může poskytnout k nápravě lidí, nebo kolik je ochoten věnovat financí externím zdrojům.
Vaše analýza Health Check Assessment je tedy prvním krokem k fragmentaci větší aplikace do mikroslužeb?
Přestože tomu tak velice často bývá, avšak rozbití monolitické aplikace nemusí vždy být řešením problému. Někdy je vhodné zachovat nějaké monolitické jádro, které může být velmi komplexního charakteru, s vysokými nároky na výkonnost. V tom okamžiku může být vhodné jeho zachování. Typicky však dochází k fragmentaci celého řešení, zejména když ona společnost cílí na provoz daného řešení v cloudu.
Která bývají nejchoulostivější místa ohledně funkčnosti aplikace?
Ta se typicky týkají dvou záležitostí. Za prvé, firmy nejsou příliš spokojené s tím, jak rychle jsou schopné aplikaci implementovat a/nebo provádět v ní úpravy. Za druhé jsou to nefunkční požadavky v tom smyslu, že firmy často mívají požadavky na škálovatelnost řešení, a pokud je toto řešení stavěné jako monolit, pak je jeho škálovatelnost velmi omezená. Pro obě tyto oblasti dnes už existuje poměrně osvědčená metoda architektury mikroslužeb. Je zapotřebí se podívat na zadání aplikace a jak současná architektura těmto požadavkům odpovídá. V mnoha případech je třeba změnit nejen její architekturu, ale zároveň je nutné upravit třeba procesy, jakými daná společnost, případně její dodavatel, software dodává. Znamená to opravdu přejít k agilnímu vývoji. Nelze udělat jen první půlkrok a zavést nějaké agilní ceremonie, formální stránku. Pokud tomu neodpovídá aplikační architektura, změna přístupu k analýze, testování softwaru, pak se sice mohou tvářit, že mají agilní týmy, stand-upy, sprinty atd., ale nakonec to vypadá tak, že udělají analýzu pro hrozně veliký rozsah až do detailů, a pak jdou všechno implementovat místo toho, aby i ta fáze analýzy byla opravdu agilního formátu. Agilní přístup je skutečně nutné začlenit do celé organizace.
Na jednu věc je však třeba dát pozor, a tou je Convayův zákon, který říká, že po určité době architektura systému odpovídá organizační struktuře společnosti. V okamžiku, kdy začnete používat mikroslužby, se to mnohonásobně zrychlí a tato doba zkrátí. Proto je při revizi architektury přizpůsobit i organizační strukturu. Proto je nutné, aby byla v souladu struktura týmů. Ideálně je dobré definovat si ve společnosti hodnotové řetězce a podle nich organizovat týmy i aplikační komponenty a mikroslužby nejen z pohledu Convayova zákona, ale i z pohledu toho, že jednotlivé týmy by měly být přímo zodpovědné za dodávku konkrétní hodnoty pro danou organizaci. Pro nás je „antipattern“, odstrašující příklad, takové to klasické rozčlenění na úrovni technologií. Například tým pro front-end, back-end, databáze atd. V tomto případě je velmi snadné přehazovat si problém jako horký brambor tam a zpátky aniž by ho někdo vyřešil. Oproti tomu v okamžiku, že máte průřezový tým pro určitou část řešení, který obsahuje více specializací, a jako takový je dedikovaný, takový musí cítit zodpovědnost za dodávku hodnoty pro danou organizaci, a v tento moment pak může vše opravdu fungovat.
Jan Mlynár, Stratox
Může ale i tam docházet k přehazování horkého bramboru z jednoho člena týmu na druhého?
To sice může, ale nevyřčeným předpokladem je, že dedikovaný tým s více specializacemi úzce spolupracuje, potkávají se na denní bázi, až několikrát denně, čímž se riziko zmenšuje. Máte také menší perimetr k nalezení nějakého problému. Když máte třeba deset lidí, dá se to zvládnout podstatně snáze. Když ale zatáhnete do problému tři týmy, každý o deseti lidech, perimetr pro hledání problému už má třicet lidí.
Existují nějaké nástroje, které takový přístup usnadňují a podporují?
Určitě, existují a na více úrovních. Ve Stratoxu používáme obecnou a technologicky nezávislou metodiku nazývanou Team Topology, která říká, jakým způsobem týmy nastavit, jejich rozsah, interakce, závislosti tak, aby byly co nejslabší. Náš nástroj CodeNOW pak funguje jako automatizační platforma, která významně zvyšuje efektivitu vývojářů a provoz takovýchto aplikací, postavených na mikroservisní architektuře. Team Topology stojí jako organizace dodávající software nad tím a jednotlivé týmy využívají CodeNOW, aby byly schopné efektivně dodat software, za který jsou zodpovědné.
