Při posuzování ekonomických výhod a nevýhod je proto vždy důležité, aby se porovnávaly srovnatelné parametry – k tomu se nabízí srovnání kontrastu osobní a hromadné dopravy: ekonomické výhody hromadné dopravy jsou očividné, ale osobní doprava kromě čistě ekonomického hlediska přináší některé neekonomické přínosy, jako např. autonomie a osobní komfort, které můžou ekonomické nevýhody částečně vyrovnávat nebo i překonat. Budeme proto posuzovat hlediska čistě ekonomická s tím, že se budeme pohybovat v rámci právních a bezpečnostních požadavků, které jsme si vytyčili v předchozích částech našeho seriálu o cloudu. Velkým rozcestníkem je rozhodnutí, zda využít služeb veřejného nebo privátního cloudu. Právě tady nám zmíněná právní a bezpečnostní kritéria pomůžou v rozhodování. Nejdříve si vysvětlíme obecné ekonomické parametry pro cloud veřejný a pak se zaměříme na cloud privátní. Děláme to proto, že parametry veřejného cloudu jsou poměrně rigidně dány business modelem jeho dodavatele a jistý kompromis bude nutný, zatímco u privátního cloudu si tento můžeme do velké míry definovat sami dle svých potřeb a požadavků. Dle vlastních požadavků si vybíráme jednak typ cloudu, jednak jeho dodavatele. Hlavní otázkou je, zda se rámcové podmínky, vlastnosti a atributy služeb poskytovatele a jeho produkty kryjí s našimi požadavky, tj. požadavky zákazníka. Zejména je nutné brát v potaz:

• zralost procesů poskytovatele
• používanou technickou bázi
• hodnocení analytiků, reference.

V podstatě je potřebné provést jakýsi audit poskytovatele, zda je schopen splnit požadavky, které jsou na služby kladeny.

Ekonomické výhody veřejného cloudu

Malé počáteční investice - není třeba pořizovat hardware a zajímat se o nejnižší infrastrukturu. Jediné investiční výdaje jsou poplatky na licence pro klientský software, jestliže firma využívá placené programy. Mohou se však zvýšit výdaje za internetovou konektivitu kvůli zvýšení objemu přenesených dat nebo pořízení záložního připojení k internetu.

Nejsou zapotřebí opakované investice do infrastruktury - ve firmách obvykle dochází k výměně hardwaru hned po skončení servisní podpory od výrobce. Důvodem je zejména cena za servisní zásahy hrazené z vlastních prostředků a jejich rychlost. Mnohdy taková oprava hardwaru po záruční době vyjde draho a vyplatí se počítat s podporou, kterou nabízí výrobce (či distributor). Dnes je obvykle oprava zaručena do následujícího pracovního dne. U cloud computingu tyto starosti a výdaje spojené s obnovou odpadají. Nemusí se jednou za 3 až 5 let kupovat nové servery a ušetří se i čas potřebný pro instalaci a migraci dat.

Potlačení skrytých výdajů - pokud má firma vlastní hardware, je s ním spjato i mnoho výdajů mimo jejich pořizovací cenu, které nemusí mít jen finanční charakter. Například koupě náhradních součástek, časově náročná aktualizace nebo reinstalace softwaru, elektřina potřebná k provozu chladícího zařízení, nároky na prostory atd. To se v případě pořízení cloudu neprojeví. Zde platíte za službu a ta je vám dodána bez dalších nutných investic.

Méně nutně potřebných zaměstnanců - při provozování aplikací v cloudu není třeba zaměstnávat některé pracovníky v oddělení IT, kteří se starají o servery z hardwarového hlediska. Nejvíce se tento benefit projeví u firem menších rozměrů bez vlastního technického oddělení, které musejí na správu najímat specialisty z externích firem. U cloud computingu tyto výdaje odpadají. Rovněž odpadají zdroje na udržování kvalifikace odpovídajícího personálu.

Dynamická změna kapacity - pokud vznikne potřeba navýšení kapacity, v cloudu je možné v řádu několika minut takové změny zařídit za menší cenu, než by vyšlo pořídit nový server a doplnit vlastní infrastrukturu o nové prostředky. Pokud nastane opačný případ a je potřeba uvolnit kapacity, s cloudovým řešením se ušetří téměř okamžitě. Naproti tomu fyzický hardware firmě zůstává a najednou pro něj není využití až do dalšího případného nárůstu. Navíc, pokud je už z části využit, data na něm uložená musí migrovat jinam, nebo musí zůstat zapojený a neušetří se ani na energiích. Tuto výhodu ocení hlavně firmy se sezónním zatížením. Metodika migrace služeb Samotná metodika migrace služeb je jedním z nejdůležitějších faktorů definujících potřebné časové a lidské zdroje k tomu, aby migrace proběhla úspěšně a hladce. Na rozdíl od ušetřených nákladů na provoz se migrace služeb velmi těžko počítá, pokud nevíme, jaké kroky budeme muset podniknout. Bez definování metodiky se rovněž může stát, že se uprostřed procesu migrace octneme ve stavu, že kvůli nedostatečné analýze nebudeme bez vysokých a zejména nečekaných nákladů schopni v migraci pokračovat.

Migrace služeb se rozděluje do tří kroků:

• analýza služeb
• tvorba migračního plánu
• samotná migrace služeb podle migračního plánu.

Migrační plán popisuje postup při migraci každé jednotlivé služby a je součástí širšího, tzv. cestovního plánu (roadmap), ale z nákladového hlediska je nejvýznamnější. Poskytovatelé různých typů cloudů rovněž poskytují podporu při tvorbě migračního plánu, ale pro řádnou analýzu služeb se neobejdeme bez odborníků z vlastních či externích zdrojů. Cílem je, aby migrace proběhla hladce, tj. aby se funkční, výkonnostní ani bezpečnostní parametry business služeb po čas migrace nesnižovaly.

Analýza služeb

Analýza služeb má za cíl identifikaci, kategorizaci a dekompozici business služeb, tj. jejich rozklad na infrastrukturní služby. Jde doslova o rozložení služeb na šroubky. Analýza musí určit:

• identifikaci a popis služeb, které se budou migrovat včetně jejich vlastníků, poskytovatelů a uživatelů
• popis a kategorizaci datových aktiv, které služba používá, a stanovení parametrů služeb na základě hodnocení aktiv
• popis a kategorizaci síťových datových toků
• vazby businessových služeb na služby infrastrukturní a určení cloudové úrovně, na které budou provozovány (SaaS, PaaS, IaaS...)
• které služby je možné oddělit a které je nutné migrovat společně
• kdy je možné danou službu migrovat (v závislosti např. na přípravě infrastruktury, na určených servisních oknech, na vztahu k jiným službám a projektům)

Každá služba musí být analyzována z hlediska své funkčnosti, tj. jaké služby požaduje a jaké poskytuje (závislostní matice). Tyto závislosti se později promítnou do logické návaznosti migrace jednotlivých služeb v rámci migračního plánu. Analyzované parametry musí být definovány nejenom z hlediska kvalitativního (na kterých jiných službách je služba závislá a které poskytuje jako službu), ale i z hlediska kvantitativního. Parametry služeb musí zohledňovat i budoucí požadavky na služby (např. nárůst počtu spojení apod.). U služeb je z hlediska výkonu potřeba definovat minimální penzum nezbytných parametrů v oblasti dostupnosti a kapacity.

Parametry požadavků na výkon a kapacitu

Pod zátěží rozumíme nároky na výkon a kapacitu zdroje (systému) v čase. Zátěže je možné diferencovat podle typu a intenzity požadavků směřovaných na systém. Ne všechny typy zátěží běží efektivně v cloudovém prostředí.

Největší nároky na cloudové prostředí přestavují zátěže se striktně online zpracováním, charakterizované rychlými I/O transakcemi s malým objemem dat, náročnými na spolehlivost a dramatický kolísajícím množstvím uživatelů. Výpočetní výkon u takových typů zátěže je obvykle nízký, ale typicky vyžaduje složitou serializaci a uzamykání dat. Takový typ zátěže je pro cloudové prostředí nejméně vhodný a je zapotřebí počítat s větší rezervou.

Na druhé straně spektra jsou zátěže s asynchronním zpracováním a atomickými operacemi. Asynchronní procesy můžou být s výhodou rozkládány na různé části prostředí a jejich požadavky zpracovávány paralelně. Výkon a škálovatelnost jsou klíčovými vlastnostmi cloudových služeb, přičemž operační model cloudu dokáže zajistit maximální efektivnost.

V privátním cloudu jde méně o využití stávající infrastruktury (jelikož je dedikovaná), ale více o alokaci zdrojů, rezervy a škálovatelnost (možnost růstu). Nejnáročnější na virtuální výkon jsou aplikace, nejméně náročná je síťová komunikace (porty a šířka pásma). Nejspolehlivější metodou určení rezervního výkonu (viz dále) je výkonnostní aplikační testování na konkrétní infrastruktuře cloudu – benchmarking. Přitom je důležité diferencovat služby na vyžádání od služeb poskytovaných v dávkovém režimu. Absolutní převahu v službách má způsob poskytování dat na vyžádání.

Parametry požadavků na dostupnost

Hodiny dostupnosti služby - hodiny, ve kterých je služba standardně poskytována koncovému uživateli. Jedná se o interval, ve kterém se vyhodnocuje dostupnost služby. Do výpočtu dosažené dostupnosti se nepočítají pravidelné plánované odstávky systému. Režimem 24 x 7 je v rámci hodin dostupnosti služby myšlen nepřetržitý provoz 24 hodin denně, 7 dní v týdnu, 365 dní v roce. Příklad výpočtu celkového času u služby 7 x 24 (měsíční vyhodnocení): celkový čas = 31 x 24 - plánované odstávky [h]

Dostupnost služby – poměr doby, po kterou nejsou pro danou službu registrovány otevřené incidenty s vysokou prioritou, tj. služba je nedostupná jako celek, vůči celkově možné době dostupnosti v daném měsíci. Měřeným obdobím pro dostupnost služby je vždy kalendářní měsíc. Dostupnost se měří v rámci hodin dostupnosti služby. Vzorec pro výpočet dostupnosti v měsíci:

dostupnost = (celkový čas - downtime)/celkový čas × 100%

Lhůta pro vyřešení incidentu – čas do odstranění výpadku služby. Incident může být odstraněn i dočasným opatřením, které obnoví funkčnost služby. 

Parametry požadavků na kapacitu

Vzhledem k rozdílnému charakteru jednotlivých služeb je dle potřeby volena různá kombinace následujících parametrů, vyjadřující požadavky na kapacitu/výkon dané služby:

• Počet uživatelů služby – maximální počet všech uživatelů služby.
• Počet současně pracujících uživatelů služby – je uváděn ve dvou hodnotách, a to:
  • průměrný počet současně pracujících uživatelů při běžném provozu
  • průměrný počet současně pracujících uživatelů ve špičkách
• Počet transakcí za jednotku času – počet operací (transakcí) provedených za danou jednotku času. Jednotka času je vybrána tak, aby výsledný údaj byl relevantní, např. hodina, den nebo měsíc.
• Objem přenášených dat – množství dat, které je průměrně přenášeno danou službou přes její rozhraní za jednotku času. Jako jednotka času je používána hodina, den nebo měsíc. Místo množství dat se používá také podíl na kapacitě linky nebo úložiště. V případě úložiště je potřeba zahrnout do plánování kapacity rovněž potřebnou kapacitu pro ukládání záloh a konfigurací.

Specifika kapacitního plánování u privátního cloudu

U pravého privátního cloudu je nutné podrobněji kvantitativně plánovat současné a budoucí výkonové kapacity, protože na rozdíl od veřejného cloudu zahrnuje značné investice do HW a virtualizační infrastruktury. Cílem je dosáhnout vyšší průměrné utilizace a vyšší konsolidační poměr (pod konsolidací se rozumí snížení počtu jednotlivých serverů pomocí virtualizace). Konsolidační poměr serveru se dá s výhodou využít k vyhodnocení utilizace cloudu:

průměrná utilizace = průměrné využití zdrojů / kapacita

Maximální počet serverů s určitou zátěží, které jsou konsolidovatelné na cílovém reálném serveru virtualizační infrastruktury, závisí od variability jejich zátěží (využívání zdrojů v čase). Variabilita zátěží serverů tedy ovlivňuje konsolidační poměr. Při kombinaci zátěží serverů s variabilním využitím zdrojů (sdílením zdrojů pomocí virtualizace) se celková variabilita zátěže fyzického serveru virtualizační infrastruktury snižuje. Tudíž výkonnější fyzické servery virtualizační infrastruktury jsou schopny nejenom pojmout víc zátěže, ale rovněž běžet s vyšší utilizací než méně výkonné servery.

Variační koeficient pro jednotlivé servery je určen poměrem směrodatné odchylky (δ) k průměru:

V = (δ/průměrná utilizace) × 100%

Variační koeficient určuje míru variace zátěže, (tzv. variační rezervní kapacitu), kterou je zapotřebí přičíst k průměrné utilizaci pro odhad volných kapacit. Optimální kapacita by měla zohledňovat následující rezervy:

• variační rezervní kapacitu VRK
• rezervu pro nepředvídatelnou zátěž (provozní rezervní kapacita PRK)
• rezervu pro růst nároků na službu do nejbližšího období (růstová rezervní kapacita RRK).

Zbytek rezervní kapacity je pak možné považovat za volnou kapacitu využitelnou k jiným účelům (např. rozšiřování cloudu o nové služby):

celková rezervní kapacita = celková kapacita – průměrná utilizace – 3δ volná kapacita = celková rezervní kapacita – PRK – RRK

Tvorba migračního plánu

Migrační plán je klíčovým dokumentem, který bude popisovat posloupnost migračních kroků včetně testovacích scénářů. Migrační plán musí definovat:

• kdy a v jakém pořadí migrovat služby
• jak službu po migraci otestovat (akceptační kritéria a testovací scénáře) před předáním do produkce
• co dělat v případě neúspěchu migrace služby
• organizační opatření - součinnost mezi zákazníkem a poskytovatelem

Jako součást migračního plánu musí vzniknout ucelený set testovacích scénářů a testovacích protokolů. Testovací scénáře budou použity po dokončení migrace pro ověření správné funkčnosti služeb.

Závěr

Migrace businessových služeb do jakéhokoliv typu cloudu není triviální záležitostí. Pomoc poskytovatele (CSP), případně specializované firmy, situaci značně ulehčí, ale je důležité mít se na pozoru před nabízením „bezbolestné migrace“. Cílem je, aby bolest nepocítili zákazníci migrovaných služeb ve formě degradace funkcionality nebo bezpečnosti, ale pouze ti, kdo migraci připravují.

Již teď je jasné, že cloudová řešení jsou budoucností IT a málokdo se jim v střednědobém horizontu vyhne. Přinášejí zatím mnoho nejistot, nejasností a rozporů, ale zároveň otvírají dveře k novému způsobu fungování firemních i veřejných ICT. Kdo bude mít náskok, bude mít výhodu – kdo ale tento přechod uspěchá bez zvážení reálných výhod a rizik, ten může přijít o víc, než jenom o výhodu.

Milan Balážik Autor pracuje jako architekt technických řešení ve společnosti Corpus Solutions.