Kontejnerizace nebo virtuální servery?

Zahájení nové interní aplikace se v mnoha společnostech nezasekne na vývoji. Aplikace je hotová, ale pak se objeví otázky: na který server ji umístit, jak bude zálohována, kdo ji aktualizuje, co se stane v případě chyby a jak ji lze později rozšířit? otázka kontejnerizace nebo virtuálních serverů proto není jen otázkou výběru infrastruktury. Určuje, jak předvídatelně bude fungovat obchodně kritický systém a kolik pozornosti bude vyžadovat od IT týmu.

Dobré rozhodnutí nezačíná tím, která technologie je modernější. Nejdříve je třeba pochopit, jaký obchodní proces aplikace podporuje, jakou ztrátu by způsobila chyba, jak rychle se systém mění a zda má skutečného provozního správce.

Nejprve nevybírejme server, ale zhodnoťme riziko

Vezměme si běžnou situaci. Objednávky z e-shopu se prostřednictvím speciální integrace dostávají do systému řízení zásob, pak do fakturačního systému a systému kurýrní služby. Při několika stovkách objednávek denně už tato propojující aplikace není zanedbatelným technickým prvkem. Pokud se zastaví, sklad neví, co má připravit, a zákaznický servis nevidí skutečný stav objednávky.

V této situaci není podstatné, zda program běží na virtuálním stroji nebo v kontejneru. Podstatné je, zda je obnovitelný, monitorovaný, zda jsou chyby izolovány, zda je jeho provoz zdokumentován a kdo může zasáhnout, i když původní vývojář není k dispozici.

Pro rozhodnutí obvykle pět otázek poskytuje užitečný rámec:

• Jedná se o jedinou aplikaci, nebo o více služeb, které se mění společně?
• Jak často se vydává nová verze nebo oprava?
• Je třeba v krátké době rozšířit kapacitu?
• Existuje interně dostatečná provozní znalost a odpovědnost?
• Kolik stojí hodina výpadku při zpracování objednávek, výrobě nebo zákaznickém servisu?

Odpovědi na tyto otázky často řeknou více než dlouhé technologické srovnání.

Co nabízí virtuální server?

Virtuální server je prostředí oddělené na fyzickém stroji s vlastním operačním systémem. Lze s ním zacházet jako s tradičním serverem: má vlastní úložiště, síťová nastavení, uživatelská oprávnění a systémové aktualizace. Pro společnost je to často dobře pochopitelný, osvědčený provozní model.

Může být zvláště odůvodněné, pokud starší obchodní aplikace funguje pouze s určitým operačním systémem, speciálními komponenty nebo podle specifikací výrobce. Totéž může platit pro systém podpory výroby, starou databázi nebo software podporovaný externím poskytovatelem, který stanoví přesné instalační podmínky.

Výhodou virtuálního serveru je relativně jasná hranice. Aplikace může mít vlastní stroj, který lze zálohovat, monitorovat a v případě potřeby obnovit. To může znamenat jednodušší provoz pro menší nebo zřídka se měnící systémy.

Tato jednoduchost má však svou cenu. Každý virtuální server vyžaduje vlastní operační systém, který je třeba aktualizovat, chránit a monitorovat. Pokud se v průběhu let pro každou novou potřebu vytvoří nový server, brzy se objeví hromadění serverů: nikdo si není zcela jistý, co na nich běží, zda jsou stále potřebné a jaký obchodní proces může aktualizace ovlivnit.

Virtuální server tedy není zastaralé řešení. Je vhodný, pokud je aplikace stabilní, dobře definovaná, změny jsou vzácné a je třeba oddělení na úrovni operačního systému.

Co řeší kontejnerizace?

Při kontejnerizaci aplikace a komponenty potřebné pro její běh běží v regulovaném, přenosném balíčku. Kontejner není plnohodnotný virtuální server: obvykle využívá zdroje hostitelského systému a zároveň udržuje aplikaci v odděleném prostředí.

Z obchodního hlediska je nejdůležitější výhodou opakovatelnost. Pokud je vývojové, testovací a produkční prostředí postaveno ze stejného definovaného balíčku, je menší pravděpodobnost známého problému, že „v testovacím prostředí to ještě fungovalo“. Nasazení neprobíhá na základě dlouhého, částečně ručně prováděného popisu, ale je opakovatelně kontrolovatelné.

To je zvláště užitečné pro systémy, které se často mění. Například v integraci e-shopu se objeví nová kurýrní služba, nový způsob platby nebo nové skladové pravidlo. Pokud jsou vývoje pravidelné, kontejnerový provoz může podpořit rychlejší a předvídatelnější proces vydávání.

Kontejnery se také dobře hodí, když obchodní funkce sestává z několika samostatných služeb. Jeden komponent přijímá objednávky, druhý synchronizuje zásoby, třetí vytváří dokumenty, čtvrtý odesílá oznámení. Tyto komponenty nemusí nutně vyžadovat samostatný virtuální server, ale mohou být samostatně verzovány, monitorovány a v případě potřeby samostatně rozšiřovány.

Kontejnerizace však není automaticky jednodušší. Pro správný provoz je třeba regulované správy image, správy oprávnění, logování, síťového návrhu, správy tajemství, zálohovací strategie a monitorování. Koordinovaný provoz více kontejnerů již vyžaduje zvláštní provozní disciplínu. Pokud to chybí, společnost nezíská méně, ale jen jiný druh složitosti.

Kontejner nenahrazuje architekturu

Častým nedorozuměním je, že kontejnery samy o sobě vytvářejí vysokou dostupnost. Nevytvářejí. Špatně spravovaná databáze, integrace představující jediný bod selhání nebo nedokumentovaná externí závislost zůstávají obchodním rizikem i v kontejneru.

Dostupnost je otázkou návrhu. Je třeba určit, co se stane v případě selhání serveru, síťové chyby, chybného vydání nebo ztráty dat. Je třeba automatické restartování? Jak rychlé obnovení je přijatelné? Zálohujeme pouze data, nebo také pravidelně kontrolujeme, zda je provoz skutečně obnovitelný ze zálohy?

Kontejnerizace nebo virtuální servery: kdy je která rozumná?

U stabilní, staré aplikace, do které se zasahuje několikrát ročně, je virtuální server často disciplinovanější a přiměřenější volbou. Není vhodné budovat složitou kontejnerovou platformu jen proto, že je to technologicky možné.

U aplikace, která se pravidelně vyvíjí, zpracovává více integrací nebo běží v několika prostředích, může kontejnerizace poskytnout významnou provozní výhodu. Opravy chyb mohou být vydávány rychleji, bude sledovatelnější, co běží v produkci, a menší je pravděpodobnost chyb způsobených rozdíly v prostředí.

V mnoha případech není správná odpověď buď-anebo. Kontejnery mohou běžet i na virtuálních serverech. To je častá a odůvodněná přechodná nebo trvalá architektura: virtuální stroj zajišťuje oddělení na úrovni infrastruktury a kontejnery zajišťují regulované nasazení aplikací. Není tedy třeba provádět velký technologický skok a přetvářet všechny systémy najednou.

Je vhodné také odděleně zpracovávat povahu dat. Aplikační servery, integrační služby a zpracovatelské procesy jsou obvykle snadněji kontejnerizovatelné. U velké, obchodně kritické databáze však mají požadavky na zálohování, výkon, ukládání a obnovu přednost před módními trendy v nasazení.

Skryté náklady jsou v provozní nejistotě

Při rozhodování o infrastruktuře se často porovnává pouze měsíční náklad na server. Větší položkou je však často nepředvídatelná práce: když chybu může vyřešit jen jeden člověk, když neexistuje aktuální dokumentace nebo když před aktualizací nikdo neví jistě, co se zastaví.

Technická volba by proto měla podporovat transparentnost. Mělo by být známo, která aplikace slouží jakému obchodnímu procesu, kde jsou její data, s jakými systémy komunikuje, kdo za ni odpovídá a za jakých podmínek ji lze změnit. To není administrativní zátěž, ale základ pro kontinuitu podnikání.

Dobrá infrastruktura není cenná tím, že nese moderní označení. Je cenná tím, že nový vrchol objednávek, aktualizace systému nebo nepřítomnost klíčové osoby nezastaví každodenní provoz. Pokud se před volbou tato provozní představa vyjasní, technologie již nebude nejistým rizikem, ale kontrolovatelným nástrojem.