Proč tvořit cloud native aplikace? V cloudu nic jiného ani nedává smysl
Developeři dnes umí vyvíjet aplikace přímo pro cloud. V praxi ale zákazníkovi obvykle nabídnou již hotové řešení, aby nemuseli aplikaci, která má být provozovaná v cloudu, přepisovat. Tím ale zvyšují provozní náklady aplikace a často snižují její výkon. V tomto článku si popíšeme, proč se vlastníkům aplikací, managerům a podobně vyplatí používat v cloudu pouze cloud native aplikace.
Zdeněk Soukup
Cloud native? Co to vůbec je?
Jde o soubor doporučení, jak stavět aplikaci, aby při provozování v cloudu využívala co nejvíce jeho výhod. Cloud native aplikace díky tomu šetří svým vlastníkům finanční prostředky. A v kombinaci s PaaS čeká operations méně práce s podporou, takže se může věnovat důležitějším úkolům.
Ukažme si efekt využívání cloud native aplikací na příkladu provozování webové aplikace na VM (skupině VM) a provozování Azure web app service s load balancerem (nebo lépe s application gateway s WAF).
Srovnání běžného a cloud native přístupu
V prvním případě potřebujeme jedno VM pro reverse proxy, která bude filtrovat požadavky, fungovat jako aplikační firewall, terminovat SSL a v neposlední řadě balancovat mezi backend servery. Na backend serverech „poběží“ nějaké IIS nebo jiný webserver. A všechno toto musíte záplatovat, monitorovat a v případě výkonnostních problémů nějak škálovat.
U web serverů přidáte instanci (pokud to webová aplikace umožňuje) a u reverse proxy budete pravděpodobně muset přidávat systémové prostředky nebo použít jinou technologii. A to nemluvím o případných výpadcích z důvodu údržby systémů.
Pokud ovšem použijete IaaS, nemusíte se o nic z toho starat. Při vhodně nastaveném auto-scallingu se vám bude škálovat jak web app service, tak application gateway. Dokonce i certifikát se vám může obnovit sám před koncem jeho platnosti.
Toto je pouze jednoduchý příklad, který ani naplno nevyužívá možností cloud native applikací. Je na něm ale vidět, že zvolením správného přístupu se dají v cloudu ušetřit finanční prostředky i lidská práce. Jak tedy cloud native aplikace tvořit?
Základní doporučení pro tvorbu cloud native apps
Jsme zvyklí stavět/psát/podporovat 2/3layer aplikace. Mají samozřejmě své výhody: například je všichni dovedou napsat, jejich výkon se dá snadno vertikálně škálovat a deployment probíhá typicky instalací nějakého balíčku na virtuální stroj/stroje.
Jejich schéma vypadá například takto:
Sečteno, podtrženo – nedivte se, jestliže vám najatý konzultant tvrdí, že aplikace není dobře napsaná a je potřeba ji přepsat 🙂
Jak na to? Dozvíte se stručně v tomto článku, nebo na stránkách Cloud native computing Foundations.
Microservices
Naproti tomu stojí aplikace navržená jako mikroslužby (microservices). Její jednotlivé funkce běží ve vlastních kontejnerech a komunikují spolu pomocí message brokeru. Taková architektura přináší mnoho výhod při developmentu i při provozování.
Jednodušší testování
Z pohledu developmentu oceníte možnost jednoduššího testování. Závislosti totiž řešíte pro každý kontejner zvlášť, a je tedy jednodušší provádět změny v kódu aplikace.
Provozní výhody
Z hlediska provozu oceníte možnost horizontálního škálování, odolnost proti chybám a rychlé a bezobslužné zotavení se z chyby.
Důsledkem uvedených výhod je, že se změní i váš přístup k provozování těchto aplikací. Hezky to popisuje například koncept mazlíčci vs. hospodářská zvířata.
Monolitické aplikace nebo i třeba on-premise servery jsou pro nás takoví mazlíčci – staráme se o ně, léčíme je a oni nám za to na oplátku něco dávají. Máme k nim až citovou vazbu. Když nám toho dávají málo, pořídíme si většího mazlíčka.
Naproti tomu microservices a jiné prostředky v cloudu představují „hospodářská zvířata“. Dokud nám dávají vejce a mléko – v pořádku. Jakmile přestanou, prostě je zabijeme a nahradíme.
Pokud jen dávají vajec a mléka málo, zvětšíme stádo krav nebo hejno slepic (přidáme instance) a naopak. Přidání/odebrání instancí probíhá při správném nastavení samozřejmě automaticky. Říká se tomu self-healing a auto-scalling.
Technologická oddělenost jednotlivých služeb
Služby patřící k jedné aplikaci mohou být psané v různých jazycích, mohou být udržované různými týmy a jejich komunikace pak probíhá pomocí API.
Nezřídka se pak stává, že je aplikace vystavěna z už existujících open-source projektů a je pouze vhodně provázána tak, abychom dostali kýžený výsledek. V takovém případě nám jsou většinou nápomocny různé DevOps tooly jako Azure DevOps, GitHub, Gitlab a podobně. Čímž samozřejmě šetříme na vývoji a urychlujeme ho.
Shrnutí výhod mikroslužeb
- Škálovatelnost
Díky nezávislému škálování jednotlivých mikroslužeb můžeme reagovat na růst uživatelského provozu efektivněji. Lze škálovat pouze ty mikroslužby, které vykazují zvýšenou zátěž. Důsledkem je úspora zdrojů a vyšší výkon aplikace. - Flexibilita
Díky samostatnosti jednotlivých mikroslužeb je možné provádět aktualizace, opravy a nasazení nových funkcí bez vlivu na ostatní části aplikace. To umožňuje rychlejší vývoj a nasazení aplikace. - Odolnost
Při výpadku nebo poruše jedné mikroslužby mohou být ostatní části aplikace provozovány normálně. Stačí jen nahradit danou instanci. To má za následek vyšší dostupnost a odolnost aplikace. - Technologická nezávislost
Každá mikroslužba může být vyvíjena a nasazována v různých technologiích nebo programovacích jazycích.
Vývoj cloud native aplikací podle 12-factor apps
Nejlépe asi popisuje vývoj cloud native applikací metodologie 12-factor apps, sada 12 pravidel pro vývoj cloudových aplikací definovaná v roce 2011 firmou Heroku. Její dodržování vám umožní rychlý vývoj, horizontální škálování aplikací dle potřeby a přidávání funkcionalit bez nutnosti přetestování celé aplikace.
- Codebase
Používejte jedno společné úložiště kódu pro všechna nasazení. Nasazení mohou používat různé verze kódu. - Závislosti
Nespoléhejte se na systémové knihovny nebo aplikace. Veškeré závislosti deklarujte explicitně a pro každou službu zvlášť. - Konfigurace
Konfigurace aplikace, přístupové údaje a jiné hodnoty, které se liší nasazení od nasazení, ukládejte mimo kód, ideálně do proměnných prostředí. - Backendové služby
Považujte backendové služby za připojené zdroje. V případě nutnosti změny zdroje změníte pouze handler a samotný kód aplikace zůstane stejný. - Build, release, run
Přísně oddělte fáze build, release a run. Nesmí být např. možné měnit kód za běhu aplikace. - Procesy
Aplikaci spusťte jako jeden nebo více bezstavových procesů. Proces musí být možné nahradit bez ztráty dat. Microservices – mrk, mrk… - Přiřazení portů
Vystavujte služby pomocí přiřazení portů. Pomocí přiřazení portu komunikují i jednotlivé součásti aplikace. - Paralelizace
Horizontálně škálujte jednotlivé procesy. - Odstranitelnost
Maximalizujte robustnost a škálovatelnost rychlým spuštěním a korektním vypnutím procesu. V ideálním případě by vykonání požadavku (spuštění, ukončení i samotná práce procesu) mělo být odbaveno do pár sekund. Minimalizujete tím nebezpečí pádu celé aplikace. - Shoda dev/prod
Udržujte vývojové, stagingové a produkční prostředí co nejpodobnější – ať už z pohledu kódu (jiná branch může být), použitých služeb nebo personálu. Nevhodné je i použití takzvaných odlehčených služeb v dev prostředí – i přes použití resource handlerů totiž může docházet k menším nekompatibilitám, které se projeví až v produkci. - Logy
Považujte logy za proudy událostí a směřujte je na STDOUT. Aplikace se nestará o zpracování logů, to zajišťuje běhové prostředí. V různém nasazení může logy zpracovávat jiný systém nezávislý na aplikaci, což nám umožní lepší portabilitu. - Administrativní procesy
Spouštějte správcovské úlohy jako jednorázové procesy, které budou taktéž splňovat 12-factor apps. Znamená to, že jejich kód je přítomen v codebase, mají striktně oddělené závislosti a tak dále.
Jistě jste si všimli, že použitím mikroslužeb většinu z těchto pravidel splňujete. Zbylá pravidla jsou spíše doporučení, jak nakládat s kódem a deploymentem. S čímž nám může pomoci DevOps.
DevOps
DevOps je aktuálně velmi skloňovaný způsob tvorby a podpory aplikací. Spojuje dva různé týmy do jednoho – developery a operations. A klade velký důraz na sdílení informací uvnitř a mezi týmy.
Touto synergií dosahujeme rychlejšího nasazení aplikací a větší kvality produktu.
Hlavní důvody, proč používat DevOps jsou:
- Rychlost a škálovatelnost
Cloudové prostředí poskytuje možnost rychlého nasazení aplikací a škálování infrastruktury dle aktuálních potřeb. DevOps procesy spolu s cloudem umožňují snadné a efektivní zavedení změn, což vede k rychlejšímu vývoji a nasazení aplikací. - Spolehlivost a stabilita
Díky automatizaci testování, nasazování a monitorování je možné dosáhnout vyšší kvality softwaru. S využitím cloudových služeb, které nabízejí škálovatelnost a redundanci, lze minimalizovat výpadky a zajistit vysokou dostupnost aplikací. - Efektivita a spolupráce
DevOps v cloudu podporuje silnou spolupráci mezi vývojovým a provozním týmem. Automatizované procesy, sdílení nástrojů a transparentní komunikace umožňují efektivní využití zdrojů a dosažení cílů s minimálním počtem chyb. - Flexibilita a agilita
Cloudové prostředí poskytuje flexibilitu vývojového týmu pro rychlé nasazení nových funkcí a experimentování. Infrastruktura jako kód (Infrastructure as Code) umožňuje automatizaci správy infrastruktury a rychlou replikaci prostředí. - Monitorování a zpětná vazba
Cloudové služby poskytují nástroje pro monitorování výkonu aplikací a sběr dat. To umožňuje rychlou reakci na případné problémy a získávání užitečných zpětných vazeb pro vylepšování aplikace.
Podrobněji se tématu DevOps věnujeme v samostatném článku Encyklopedie cloudu Když v cloudu, tak DevOps. Proč?.
Vytvářejte cloud native aplikace
Na příkladu se zvířátky jsme si ukázali, co nám může přinést využívání a vytváření cloud native aplikací. Pokud provozujete aplikaci psanou postaru a nemáte s ní problémy, musíte si dobře spočítat, zda se vám vyplatí takovouto aplikaci přepisovat.
Pokud ovšem píšete aplikaci novou nebo vaše aplikace dospěla do bodu, že je stejně nutné jí přepsat od základů, nedává smysl nepoužívat cloud native přístup. Vyžadujte ho po svých dodavatelích a podřízených, vyplatí se vám.
