Na otázku, proč selhává pouhé převedení starých aplikací do cloudu, a proč může být tento přechod dražší než jejich provoz doma on-premise, a jak se tomu vyvarovat, odpovídá Patrik Horný, partner společnosti Stratox.
V posledních několika letech se zrychlil přechod firem do cloudu. O jaké firmy jde nejvíce a jakých finančních výhod mohou přechodem do cloudu dosáhnout?
Trend spojený s cloudem trvá už možná více než deset let. Vše začalo představou, že vezmu systémy z mých vlastních datacenter, dám je do takzvaného cloudu na infrastrukturu, kterou de facto nevidím a o kterou se mi někdo stará, a že na tom ušetřím peníze, protože tato služba bude levnější. Vycházelo se z předpokladu, že to, co fungovalo v datacentru, bude stejně fungovat v cloudu. Tato očekávání se však nenaplňují a vidíme, že spíše než přestěhovat co jsem měl kdysi, je lepší až nutné přestěhovat obnovenou aplikaci. Jedině tehdy pak mohu dosáhnout nějakých úspor na provoz aplikací, možná více než padesát procent. Ze světa je ale známá skutečnost, že při pouhém přenosu staré aplikace do cloudu jsou náklady vyšší než byly předtím. Tím se teď ve Stratoxu s CodeNOW zaobíráme, aby se popsanému překvapení zamezilo. Naopak, abychom na tento přechod firmy připravili a nepřenášeli jen staré do nového, ale migrovat tak, že se aplikace novému prostředí přizpůsobí. Nebo je rozebereme na menší části, ale už nově postavené, a přesouváme je do cloudu jednu po druhé. Pozor, důležitý detail: cloudové prostředí je možné postavit i “on premise” – cloud totiž není “jiné” datacentrum, jedná se hlavně o funkcionalitu škálování a možnosti bezodstávkového rozvoje a údržby aplikací – a to ne nativní cloud.
Co přechod do cloudu může urychlit?
Když se přechod do cloudu dělá správně a aplikaci rozdělíme na menší části, rozdrobíme zároveň větší problém na řadu menších, a při takovémto správném dělení lze do cloudu přecházet velmi hladce. Pomáhají přitom mnohé nové, k tomu přizpůsobené nástroje, které umožňují, aby šlo celý přechod uskutečnit a orchestrovat (řídit). Také ale aby bylo možno následný chod aplikace bezpečně ustát a monitorovat, co se s aplikací v cloudu děje. Zde se rovněž objevuje kámen úrazu, a sice že tyto nástroje někdy dokonce mohou stát víc, než samotná infrastruktura v cloudu.
Co ale nakonec přechod do cloudu zpomaluje?
Rozhodně nefunguje, když tlačím do cloudu to staré. Pak se totiž klienti trápí, protože jejich systémy mnohdy v cloudu prostě nefungují technicky, a když ano, je to mnohdy dražší než v původním prostředí. Následné debaty, jak na to, jak to zase dát do pořádku, trvají dlouho. Zkrátka se podceňuje přípravná fáze s dekompozicí na menší části a problémy, s případným zavedením úplně nových přístupů. Zejména mikroservisního (mikroslužby, microservices), cloud-nativního, jen tehdy může být migrace do cloudu zrychlená.
Patrik Horný, partner společnosti Stratox
To znamená, že přechod do cloudu málokterá organizace sama těžko zvládne, jak ale vybrat vhodného poskytovatele cloudu a implementačního partnera?
S tím, že se vybírá hlavně “poskytovatel cloudu”, se potkáváme často. My ale říkáme, že když chceš do cloudu, nejdřív vyzkoušejte, jak funkcionalita, kterou chcete přestěhovat, může v novém prostředí vypadat, jak ji nově postavit? Většinou se ukazuje, že starou věc musíte kompletně předělat. To se nedělá výběrem cloudového providera a že si řeknete, že jdete do Azure od Microsoftu, do AWS od Amazonu nebo někam jinam. Místo toho musíte vyzkoušet nová zadání, nově je naprogramovat, případně migrovat je po částech do jednotlivých cloudů. Zde ale pozor, musíte si také vybrat nástrojové prostředí, které vám toto i provoz nové aplikace umožní. Pak teprve uvidíte, jestli cenový model, který tyto nástroje nabízí, funguje s tím, co vlastně chcete. Uvedu příklad; koupíte si v cloudu stejnou kapacitu, jakou jste měl dosud ve vlastním datacentru. Potřebujete ale k tomu ještě monitoring, a ten může být ve výsledku až desetkrát dražší, než ona nakoupená cloudová kapacita na provoz. Jak velkou kapacitu na monitoring potřebujete, zase zjistíte jen na základě reálného testu ,, když vidíte kousek toho softwaru, který v cloudu provozujete. Pak se teprve můžete rozhodnout, jaký nástroj pro monitoring vezmete a jak ho nastavit. Nemůžete se upínat na jednotlivé cloudové providery, ale naopak sledovat, které nástroje a u kterého poskytovatele jsou vhodné pro můj software v bilanci levnější. Nakonec můžete fungovat v multihybridním prostředí a mít více cloudových providerů, protože pro kousek vaší funkcionality funguje nejlépe prostředí Amazon AWS, pro jiné Microsoft Azure, a kousek si můžete nechat ve vašem datacentru, i ten však musíte přizpůsobit cloudovému způsobu provozu.
Jak toho lze dosáhnout? Jak starou aplikaci transformovat a rozdrobit ji na menší díly? Jak ji provozovat dál? Jaké existují nástroje, které změnu v IT a přechod do cloudu usnadňují?
Už ve vaší otázce jste nabídnul část řešení. Nesmíte do cloudu tlačit staré velké celky, ale rozdrobit je na menší, to je základ. Dělá se to tak, že se aplikace rozdělí na jednotlivé funkční celky, například podle zážitků klienta, eventů (událostí). Kolem těchto eventů pak vznikají mikroslužby, a když mohu rozdrobit starý funkční celek na malé mikroslužby, pak vzniká mikroservisní architektura, která mi umožňuje krok za krokem vypínat staré a zapínat nové už v cloudu. Pro jednotlivé kostičky mikroslužeb dokonce můžete vybírat jednotlivého poskytovatele cloudu.
Abychom takovou migraci umožnili, abychom umožnili dekompozici velkých částí na malé, pomohli klientům zvyšující se komplexnost ustát, uřídit, vytvořili jsme platformu CodeNOW, která celý proces vývoje softwaru až po neustálé změnové řízení a provoz bez odstávek systému umožňuje. Náš CodeNOW je platforma, která vývojářům automatizuje mnohé jednotlivé činnosti, nemusí se zaobírat jak nastavit jednotlivé specifické cloudové procesy, monitoruje a automatizuje za něj vytváření celku z mikroslužeb atd. Jejich správa je náročná, jako celá už je proveditelná jen přes některé nástroje které ji automatizují, a to je právě CodeNOW. Některé, už manuálně nezvládnutelné úkony, je totiž v cloudu nutné dělat automaticky.