Je zcela zřejmé, že většina organizací dnes ve svých informačních strategiích zvažuje nasazení IT infrastruktury ve formě privátního cloudu (někdy také nazývaného jako interní cloud). Je však otázkou, jak bude využíván a jaký efekt jeho zavedení přinese. V našich analýzách pracujeme s celou řadou scénářů – některé z nich jsou více, jiné méně pravděpodobné, další existují pouze v myšlenkách zcela mimo realitu. Výsledkem takových úvah je naše předpověď toho, jakým způsobem budou privátní cloudy v budoucnosti skutečně využívány.
V našich úvahách vycházíme z předpokladu, že jen málokterá existující společnost provede radikální krok přechodu do privátního cloudu se svým kompletním aplikačním portfoliem. Důvody této opatrnosti jsou následující:
1. Klíčovým manažerským principem, kterým se dnes řídí drtivá většina CIO, je „nevrtej se v ničem, co uspokojivě funguje“. Tento přístup má samozřejmě své limity – například v situaci, kdy jsou na danou infrastrukturu vysoké náklady nebo pokud dosud nebyla virtualizována.
2. Většina existujících aplikací nedokáže přinést valné přínosy pouze na základě toho, že ji přesunete do prostředí cloudu. Vinu na tom nese skutečnost, že většina soudobých produkčních aplikací si nese na bedrech statickou topologii a nutnost manuální administrace.
3. Zavedení cloud computingu je nákladné a může na čas přerušit hladký chod organizace. Velmi často se setkáváme s podceněním těchto skutečností.
Kvůli výše uvedeným faktům směřuje většina společností své primární snahy v oblasti privátního cloudu do vzniku prostředí vhodného pro vývojáře. Těm se totiž obvykle věnuje pouze nedostatečná pozornost – vytvoření sebeobslužného prostředí tak výrazně pomůže jejich produktivitě a dokáže zamezit celé řadě problémů, které se objevují při prvotním nasazení produkčních privátních cloudů, jako je například otázka integrace těžkotonážních procesů (například ITIL) s agilním sebeobslužným prostředím. A co více, vývojáři nejsou právě nejlevnější pracovní silou, takže pokud dokážete zvýšit jejich efektivitu, projeví se to i na vašich nákladech.
Pokud je optimálním prvním krokem při získávání zkušeností s privátním cloudem jeho nasazení pro potřeby vývojářů, nabízí se otázka, s čím by měly organizace následně pokračovat. Přinášíme trojici nejčastějších příkladů použití a důsledky plynoucí z jejich nasazení.
Scénář první: Agilní vývoj, statický provoz
V tomto scénáři mají softwaroví inženýři k dispozici cloud pro potřeby vývoje, ale v oblasti produkčních systémů jsou aplikace provozovány podle existujících procesů (které byly vytvořeny pro statickou topologii a neelastické aplikace provozované v prostředí těžkopádného prostředí stavícího na principech ITIL).
Máme za to, že spokojenost s touto strategií bude do značné míry závislá na tom, jaká část nově vyvíjených aplikací bude využívat elasticitu a automatické procesy spjaté s cloud computingem. Volba tohoto přístupu může záviset na individuálních požadavcích organizace v oblasti elasticity aplikací. Pokud je poměr aplikací vyžadujících elasticitu spíše nízký, může být tento scénář výbornou volbou. Pro většinu aplikací totiž bude statické prostředí zcela dostačující. A pro menšinu aplikací, které vyžadují elasticitu, by mohly být přijaty výjimky, aby bylo dosaženo potřebné agility.
Výzva spojená s tímto scénářem spočívá v tom, že se dostává do konfliktu s tím, co bude stále běžnější u budoucích aplikací. Povaha aplikací se totiž mění a spolu s ní se objevují požadavky na variabilitu zátěže, mnohem vyšší škálovatelnost a komplexnější topologii nasazení.
Scénář druhý: Agilní vývoj, poloagilní provoz
V rámci tohoto scénáře jsou v provozu použity nové aplikace, které mohou podporovat elasticitu, komplexní technologie a automatizovanou administraci, zatímco starší aplikace i nadále pracují ve statickém prostředí. Jde v zásadě o vybudování určitého přídavku, který pracuje podle svých vlastních pravidel, k existujícím datovým centrům.
Dalo by se říci, že tento scénář je ve shodě s historickým vývojem v oblasti počítačů. Nové platformy nikdy nárazově nevytlačí ty, které již nějakou dobu existují, nýbrž se k nim svým způsobem přimknou a rozvíjejí se společně. Obvykle se stane to, že většina nových aplikací je nasazena na nových platformách, zatímco existující platformy přicházejí spíše s updaty současných aplikací. A samozřejmě postupem času nová platforma získává převahu a je pro ni vyvíjena většina vznikajících aplikací. Tento scénář je atraktivní, neboť redukuje problematické oblasti na minimum, a poskytuje tak dobré prostředí pro nasazení aplikací navržených a využívaných v rámci cloudu.
Zároveň si však musíte uvědomit dvě zásadní věci:
V první řadě jde o zneklidňující způsob, jakým se aplikace dostávají z fáze vývoje do provozu – zde totiž chybí jakýkoliv oficiální krok, který by toto stanovil. V provozu se tak mohou ocitnout aplikace, u nichž není zcela zřejmé, kam směřují, ale zároveň ke svému běhu vyžadují agilní infrastrukturu. Část IT oddělení zodpovědná za provoz se tak může dostat do situace, kdy by měla poskytnout elastické prostředí pro nasazení takových aplikací, aniž by to mohla náležitě naplánovat. Taková situace nemůže vést k ničemu jinému než k problémům.
Za druhé je velmi snadné podcenit změny nutné k tomu, aby mohla být provozována agilní infrastruktura. Skutečná automatizace totiž vyžaduje více než pouze instalaci softwaru potřebného pro běh cloudu, který se následně prohlásí za „připravený k nasazení pro byznys“. Podobně jako se nové platformy tradičně přimykají k těm starým, dochází obvykle také k tomu, že se nové technologie přeceňují a naopak se podceňuje význam kvalifikované pracovní síly a procesů. Výsledkem je situace, kdy se organizace učí vše související s automatizací a elastičností provozu aplikací takříkajíc za pochodu.
Scénář třetí: Agilní vývoj, přemostěné nasazení do provozu
V rámci tohoto scénáře se vývojáři snaží využívat privátní cloud, ale z různých důvodů jim takové prostředí nevyhovuje, a tak se rozhodnou vyvíjet a nasazovat aplikace v prostředí veřejného cloudu. Jako příklad můžeme použít jeden případ, s nímž jsme se nedávno setkali. Při diskuzi na téma cloud computingu s jedním ze správců IT infrastruktury jsme zmínili potřebu samoobslužného přidělování zdrojů uživatelům. Správce souhlasil s tím, že jde o perfektní způsob posílení agility, ale zároveň důrazně prosazoval názor, že požadavek na přidělení zdrojů musí být posvěcen příslušným administrátorem, který ho vyhodnotí a teprve následně pošle žadateli povolení k čerpání požadovaných zdrojů. Ve skutečnosti vůbec nepochopil rozdíl mezi skutečně samoobslužným prostředím a posíláním žádostí o zdroje e-mailem.
Pokud technologie přinášejí skutečně inovativní postupy, organizace s tím mají často problémy a snaží se je zaškatulkovat do existujících regulí a zasadit je do prostředí původních procesů – většinou neúspěšně.
V rámci tohoto scénáře začínají vývojáři využívat privátní cloud, ale když uvidí komplikace na straně podpory sebeobslužného přidělování zdrojů, začnou být nespokojeni a zvolí raději alternativní řešení. Tím může být nasazení aplikací mimo interní datová centra nebo, a to je horší varianta, obrátí svou pozornost k prostředí veřejného cloudu.
Jedním z klíčových bodů při zavádění privátního cloudu je tedy fakt, aby uživatelé neměli zbytečné problémy s pořizováním výpočetních zdrojů a odbouraly se nekonečné řady souvisejících e-mailů, telefonátů, mítinků a dalších zcela nesmyslných mezičlánků.
Shrnutí
Organizace, které chtějí nasadit privátní cloud, by měly vědět, k čemu se tím upisují. Jeho nasazení pro vývoj nových aplikací představuje jednoznačně vhodný začátek, ale v dlouhodobém horizontu jde samozřejmě o nedostatečné řešení. Je nevyhnutelné, že dříve nebo později bude organizace muset učinit i další kroky vedoucí k implementaci provozního řešení, které bude podporovat sebeobslužné přidělování zdrojů a nabídne potřebnou elasticitu a agilitu – jedině tak může být naplněn smysl a poslání cloud computingu.
PŘEDPLATNÉ
ČLÁNKY DO MAILU