Application assessment: jak dostat aplikace do cloudu?

V tomto článku vám představím základní kroky a možnosti, jak jednoduše a efektivně převedete své aplikace do cloudového prostředí. A na co vám to bude dobré? S důkladnou analýzou a na ní postaveném návrhu architektury můžete v cloudu dosáhnout úspory nákladů, modernizaci aplikací, vyšší dostupnosti, lepšího zabezpečení a větší flexibility aplikací.

Ve většině společností, kde se přemýšlí o přechodu do cloudu, se začíná nejprve manažerskou prezentací na vrcholové úrovni. V prezentaci mám na druhém snímku diagram s aplikacemi u sebe v serverovně. Pak následuje 3. a 4. snímek, kde jsou již aplikace zmigrovány v cloudu, což komentuji slovy: „To přece stačí jenom zkopírovat a pustit.“ Na 5. a 6. slidu představuji rovnou návrh multi-cloud strategie, přičemž aplikace přesouvám mezi Azure a Amazonem s poznámkou: „Přece nebudu závislý na jednom providerovi.“

Ale tak jednoduché to není. Bez řádné přípravy a plánu končí migrace většinou roztrpčenými uživateli, překročeným rozpočtem a rollbackem aplikace zpět. Ukažme si krok za krokem, jak správně provést application assesment.

Application assessment

Application assessment lze zjednodušeně chápat jako proces posuzování stávajícího prostředí a stávajících aplikací. Je založen na systematickém a dokumentovaném shromažďování informací o stávajícím prostředí a na jejich hodnocení s ohledem na transformaci do cloudového prostředí.

Na začátku tohoto procesu stojí high level analýza aplikací, při které identifikujeme všechny podmínky pro převod do cloudu.

High level analýza

V jaké fázi životního cyklu se jednotlivé aplikace nacházejí, jak jsou licencované a jaké využívají technologie? V rámci high level analýzy aplikace roztřídíme podle společných vlastností, obvykle do tří hlavních skupin:

• Legacy = starší aplikace, které budou pravděpodobně vyžadovat refactoring zdrojového kódu, což bývá často dražší než aplikaci znovu vyvinout moderním způsobem.
• Cloud ready = aplikace lze většinou přesunout bez větších úprav do IaaS/PaaS služeb.
• Cloud native = aplikace vyvíjené architekturně jako microservices (Openshift, Kubernetes).

Další třídění aplikací

Základní údaje o aplikačních celcích máme z high level analýzy. Nyní je dobré se na všechny aplikace a jejich prostředí podívat z architekturní perspektivy. Zjistíme například, že kvůli použitým technologiím nebo hardwarovému klíči některé aplikace migrovat nepůjdou.

Je důležité nezapomenout, že každá aplikace je provozována na více prostředíchv závislosti na tom, jestli ji vyvíjím sám, dodavatelsky nebo se jedná o krabicové řešení. Typické bývá produkční a testovací prostředí, v případě vlastního vývoje i DEV prostředí, případně UAT. Každé prostředí má jinou kritičnost a jinou potřebu dostupnosti.

Další roztřídění můžeme provést podle těchto pravidel:

• Co půjde migrovat jednoduše (jednoduchá migrace) = typicky malé aplikace na cloudem podporovaných technologiích.
• Co bude složitější (složitější migrace) = větší aplikace s mnoha integracemi a závislostmi.
• Co nepůjde migrovat vůbec (migrace, které nelze provést) = z důvodu nepodporovaných technologií, nebo třeba blížícího se konce životního cyklu.

Na aplikace je vhodné se dívat jako na aplikační celky, které mají propojená data a integrovaná rozhraní. Obvykle tyto celky migrujeme společně a nelze je infrastrukturně oddělovat. Jeden showstopper blokuje celý aplikační celek.

Po základním rozřazení aplikací do přehledu musíme každou aplikaci detailně analyzovat, abychom následně správně navrhli design a novou architekturu aplikace v cloudovém prostředí.

Detailní analýza aplikace

Detailní analýza aplikace je nezbytná pro budoucí architekturní návrhy v cloudovém prostředí. Nejprve potřebujeme identifikovat všechny aplikační a technologické komponenty a jejich sizing. Na co nesmíme zapomenout?

• Detailní architektura aplikace – přesný popis a sizing jednotlivých komponent a prostředí.
•  Integrace a jejich datové toky mezi jednotlivými aplikačními komponentami i ostatními aplikacemi (například odlévání dat do datového skladu je z pohledu přenosů náročná operace).
• Autentizace – jakým způsobem se ověřuje přístup uživatelů do aplikace, přistupují k ní z vnitřní sítě, nebo „zvenku“?
• Je aplikace stavěna jako vysoce dostupná, tj. vše redundantně, a jaké musí splňovat SLA?
• Je aplikace součástí DR strategie?
• Obecné požadavky na security a compliance, splnění norem ISO27001 nebo implementace vlastních klíčů na šifrování dat apod.
• Licencování aplikace a jejích komponent – ověřit, jak je licencovaná vlastní aplikace, v cloudu to může být často jinak. U operačních systémů a databází obecně platí, že když mám aktivní smlouvu a platím software assurance, můžu licenci využít i v cloudu. V případě MS Azure se tato služba nazývá Azure Hybrid benefit u Microsoft licencí. Na jiných cloud platformách se používá termín BYOL (Bring your own licence).
• TCO – ceny běhu služeb, licencí, podpory a ceny konzumace hardwarových zdrojů.

Věcí, které je potřeba analyzovat, může být výrazně více podle složitosti migrované aplikace a velikosti společnosti. Třeba v bankovním prostředí jsou kladeny vysoké nároky na compliance a security část. Výhodu mají ti, kdo řeší architekturu prostředí a mají dokumentaci stávajícího stavu.

Po aplikační analýze přecházíme k návrhu cílové architektury, kde navrhneme více možných scénářů, které následně je vyhodnotíme.

Aplikační architektura

Design a architekturu aplikace navrhujeme s ohledem na využití cloudových služeb. Často se vyplatí podívat, zda aplikace neexistuje jako SaaS, tedy vše formou služby. V základním rozdělení pak rozlišujeme tyto varianty přechodu:

• Lift and shift – přesouvám vše, jak je. Většinou jako IaaS – tento způsob je pro migraci aplikace nejrychlejší, ale často nejméně vhodný z pohledu ceny a nepřináší žádné inovace.
• Replatform – v cloudu vyměním Windows za Linux, MS SQL za PostgreSQL apod. dle podporovaných možností aplikace. Dále můžeme zvažovat využití platformních služeb, hlavně u databází aplikací, které potřebují vyšší garantovanou dostupnost a robustnost.
• Rearchitecture – redesign aplikace s využitím platformních služeb jako třeba Redis Cache nebo nahrazení message queingu pomocí Azure Service Bus. Moderní aplikace, které jsou kontejnerizovány a vyvíjeny (např. Microservices architektura), můžeme nasadit do AKS nebo do Azure web application services.

Při plánování soustředíme komponenty, které spolu intenzivně komunikují, na jednu lokalitu, aby přes VPN linky neteklo velké množství dat (hlavně směrem z cloudu ven). Obecně platí, že do cloudu kopíruji data zadarmo, kopírování ven je zpoplatněno.

Vedle objemu dat může být problém i s latencí při velkém počtu operací. Roli hraje každá milisekunda navíc, kvůli které může dojít k výraznému zpomalení reakce aplikace.

Ve výsledném návrhu aplikační architektury většinou posuzujeme více variant dle stanovených kritérií (včetně cen) a přecházíme k výpočtu TCO.

TCO: co mě to bude vlastně v cloudu stát?

TCO vychází ze zvolené architekturní varianty. Obecně platí, že: „Když to nechám tak, jak to je (lift and shift), bude to dražší, ale rychlejší na migraci a bez nutnosti velkých úprav.“

Finančně lépe už pak vycházejí varianty s použitím platformních služeb, které mohou mít vysokou dostupnost a umožňují vertikální i horizontální škálování za chodu. Zde můžeme lépe pracovat s případnými peaky, nebo naopak s hluchým obdobím, tedy aplikaci přizpůsobovat provoznímu zatížení dle aktuální potřeby. Obecně dosahujeme lepšího cenového poměru, než když stavíme vysoce dostupné služby sami na vlastním HW a SW.

Další možností je rezervace prostředků většinou na 1–3 roky, kdy může být cena méně než poloviční oproti standardnímu využití PAYG (pay-as-you-go). Standardně se používá kombinace rezervací a PAYG dle typu workloadu a délky běhu služby v měsíci.

Výpočetní úlohy, které nepotřebují okamžitě dostupný hardware, můžeme umístit do low priority tieru. Takový hardware pak nemá garanci okamžitého spuštění, ale jeho cena může být až o dalších 50 % nižší.

V případě porovnávání se stávajícím provozem je potřeba na straně vlastní serverovny přičíst náklady na elektrickou energii, UPS, diesel agregáty, technologii chlazení, hašení, zabezpečení apod. dle velikosti organizace.

Po vyhodnocení TCO a zvážení všech pro a proti, pokračujeme samotnou migrací aplikace.

Migrace aplikace

Po analýze aplikace, zvolení cílové architektury, vypočteném TCO a vyhodnocení, že to všechno dává smysl (z pohledu všech nastavených kritérií), následuje plánování migrace aplikace.

Většinou se začíná TEST nebo DEV prostředím. Po testovací migraci probíhá vyhodnocení a testovaní, ať už samotnými uživateli nebo pomocí automatických testů, které kontrolují správnou funkčnost nebo generují zátěž (load testy). V případě přechodu na jiný typ služby a nasazení ve vysoké dostupnosti (HA) nebo při škálování za provozu bude testování náročnější.

Zde je možné použít nějaký produkt pro nasazení prostředí formou IaaC, tedy celé prostředí mám popsané v kódu (Github, Jenkins, DevOps). Nebo použiju nástroj na řízení testování, vykonávání testovacích scénářů a jejích vyhodnocení (DevOps).

Tento cyklus opakujeme a vyhodnocujeme až po migraci všech prostředí dle plánu. Pak následuje předání produkčního prostředí do provozu (Operations).

Na závěr bych rád řekl

Migrace aplikací do cloudového prostředí je trend poslední doby a vyplatí se s ní cílit na platformní služby, které mají přidanou hodnotu v podobě vysoké dostupnosti a škálování za provozu dle různých parametrů.

Největší výhodu mají moderní aplikace, které už byly vyvinuty (jako např. Microservices architecture), velmi dobře fungují třeba v Kubernetes clusteru, kde jejich komponenty umí běžet spuštěné současně vedle sebe.

Další přínosy cloudu jsou okamžitá dostupnost HW v případě potřeby rozšířit službu nebo dostupnost HW s grafickou akcelerací průmyslových karet (kterých je na trhu velký nedostatek kvůli těžbě kryptoměn).

Přidanou hodnotu vidíme i u podpory nejrůznějších standardů a norem, kde může být jednodušší splnit různé security, compliance a governance požadavky.

Z pohledu financí bude zajímavější přechod z nákupu majetku k nákupu služeb, tedy namísto CAPEX přesun do OPEX.

Než se však pustíte do migrační fáze, je potřeba věnovat pozornost připravenosti cloudového prostředí, aby splňovalo všechny security, compliance governance parametry. Ale to už je téma na další článek.