Written by Aplikace bez serverů? Co je to zas za nový výkřik? Prozkoumejme o co jde a pohlédněme na cestu od roků k milisekundám. Proč mluvím o časových mírách? Čtěte dál.
Délka života aneb z roků k milisekundám
3 roky
Jaká byla životnost vašeho fyzického serveru od okamžiku, co byl nainstalován? Obvykle několik let. Nainstalovali jste operační systém, nějaké prostředí a aplikaci. Občas se něco aktualizovalo, ale přeinstalaci celého serveru jste většinou dělali až za pár let, kdy vás pokrok donutil aplikaci přesunout na výkonější platformu a tento starý server změnit na file share.
1 rok
Jak se změnila situace s nástupem virtualizace? Nijak dramaticky. Většina lidí se k VM chová jako k fyzickým serverům minulosti. Nainstaluje OS, prostředí, aplikaci a pak tento vnitřek oprašuje ve formě aktualizací. Z virtualizace si bere spíše možnosti snapshotů či přesunů spíše, než změnu ve způsobu nasazování a provozu aplikací. Možná je životnost VM přecijen o něco kratší, než byly fyzické servery v minulosti, ale často zůstává v kategorii let. Přesto jsou IT organizace, které s využitím širší automatizace jdou dál – uvidíte.
3 měsíce
Oprašování VM nevede k ideálním výsledkům – ruční zásahy kupí chyby a dlouhodobé špatně dokumentované a neopakovatelné změny vedou k vzniku prostředí, která jsou specifická, různorodá a jsme rádi, že to tak nějak běží (ostatně Franta, který už tu nepracuje, si s tím prý docela vyhrál, než to začalo fungovat a náš poslední pokus to nainstalovat jinam to potvrdil). Řada firem z toho důvodu využívá strategii, kdy při větším releasu VM (nebo ještě lépe celou příslušnou infrastrukturu) zlikvidují a vytvoří znova. Jasně – ručně by to nikdo nedělal (a navíc by to nemělo ten efekt), takže je to realitou spíše v automatizovaném světě. Začíná se základním image operačního systému a všechno ostatní (aplikační prostředí, samotná aplikace apod.) se instaluje automaticky (= opakovatelně) nástrojem typu Ansible, Chef, Puppet či HPE Server Automation. Změna verze komponent či prostředí = změna v předpisu, tedy VM nemusíme oprašovat, kdykoli si vytvoříme novou. Aby to celé fungovalo pořádně, je vhodné to spojit s šablonou a automatizací infrastruktury samotné – tedy IaaS jako je Helion OpenStack. V předpisu bude nejen vnitřek VM, ale i samotné VM a jejich image, síťová nastavení, storage prostředky, firewall a jeho prostupy, load-balancer nebo DNS záznamy. Kombinace OpenStack a configuration management nástroje vede k opakovatelnému a preciznímu vybudování infrastruktury vždy, když je potřeba provést nějakou změnu nebo spustit test. Neoprašujte, budujte opakovatelným způsobem.
2 týdny
Pokud praktikujete Continuous Integration a Continuous Delivery s DevOps principy, budete pravděpodobně i ve světě VM zkracovat životnost konkrétní mašiny někam k jednomu či dvěma týdnům. CI/CD pipeline si určitě bude sestavovat VM jen pro to, aby se na nich spustil test nového kódu aplikace – několikrát denně, vždy jen na pár desítek minut. Já ale mluvím o životnosti produkčního prostředí a tam lze očekávat release do produkce (a tím i sestavení nového prostředí – samozřejmě automaticky) řádově v týdnech. Pokud používáte VM, půjde dost možná o immutable servers, tedy v rámci vývoje se vybuduje i statický image s aktuální verzí aplikace (mrkněte na Packer). V případě kontejnerů to bude buď předpis pro vznik image kontejneru (třeba Dockerfile – takový Packer pro modernější svět) nebo ještě lépe manifest pro PaaS (kompletní předpis pro kompilaci aplikace, sestavení, vybudování kontejneru se všemi návaznostmi) jako je Cloud Foundry (třeba v distribuci HPE Helion).
5 minut
Kontejnery díky své lehkosti, malé velikosti, rychlému startu a vysoké úrovni automatizace mohou zkrátit životnost běžně k minutám. Mluvíme-li o DevOps a produkci, zmiňme pár konceptů, které k tomu přispívají – a ty platí jak pro VM, tak pro kontejnery (u těch je to ale podstatně rychlejší a obvyklejší). Continuous Deployment je trend ve vývoji software, kdy se po úspěšném otestování dostává release do produkce automaticky, třeba každý den nebo několikrát denně. Tyto release jsou obvykle v konceptu green/blue (nebo také canary release) – čili neaktualizuje se běžící VM či kontejner (a celé infrastrukturní prostředí, které označme za zelené), ale sestaví se kompletní nová infrastruktura (modrá). Jakmile je vše nahoře a jsme spokojeni, přepneme uživatele ze zelené do modré infrastruktury. Při dalším release pak naopak modrou necháme být a budujeme novou zelenou. Výsledkem je, že vlastní VM či kontejner je živý jen po dobu mezi release, třeba pár hodin. Přidejme ale A/B testing. Při něm nepřeklápíme ze zelené do modré v jednom kroku, ale postupně – nejdřív třeba jen jednotky uživatelů a zvolna přidáváme (a testujeme zpětnou vazbu). Jak přeléváme ze zelené do modré, v zelené likvidujeme “servery” (rozuměj VM či kontejnery) a v modré vytváříme nové a nové (dle předpisu pro tuto verzi). To ještě dál zkracuje životnost jednoho konkrétního “serveru”.
Vše se ještě zkrátí v případě cloud native aplikace, která je state-less a můžeme tak nasadit autoscaling. Požadavky uživatelů jsou rozkládány na několik běžících instancí, jejichž počet automaticky upravujeme podle reálné zátěže. VM či kontejner vznikne jen pro vykrytí špičky a pak je ihned nemilosrdně smazán. Pokud aplikujeme autoscaling přes VM (které dlouho startují a jsou celkově méně flexibilí), necháme tyto posily žít třeba hodinu. Ale v případě lehounkých kontejnerů, které startují za méně jak jednu vteřinu, může tento posílit výkon aplikace třeba jen na pár minut k překonání špičky. Životnost kontejneru od jeho kompletního vzniku až po zastřelení tak mohou být desítky vteřin či minuty.
100 milisekund a serverless computing
Serverless computing je to, co Amazon nabízí jako službu Lambda a Azure jako Functions. Vychází to ze dvou trendů. Velký zájem zažívají programovací jazyky, které jsou od základu zaměřeny na asynchronní myšlení – typicky Node.JS (řekněme serverový Javascript). Programují se tak, že řeknete funkci, že se má spustit v reakci na nějakou událost (třeba uživatel kliknul na tlačítko či přejel myší přes obrázek). Současně se stávají velmi populární kontejnery, které dokáží startovat v řádech desítek či stovek milisekund. Co to spojit?
Serverless je provokativní název, ale v zásadě je to pravda – o vaší aplikaci se nedá říct, že by někde “běžela”, že by byla “spuštěna”. Není žádná VM či kontejner s vaší aplikací, který by čekal spuštěný, až ho uživatel bude potřebovat. Vy poskytujete funkce, tedy kód co něco dělá, a definujete události, které mají vést k jeho spuštění. Těmi je například API volání (nějaký front end potřebuje vrátit zboží, které máte v košíku), časový kalendář (cron – chceme něco spustit každé 2 minuty, abychom si odečetli stav plynových měřáků), událost (například IoT zařízení poslalo údaje do nějaké message fronty) či nová data (například jakmile se v object store objeví nová fotografie, spustí se kód, který překonvertuje obrázek do různých velikostí pro různá zařízení a to uloží jako nové objekty).
