Růst výpočetního výkonu a rozvoj technologií virtualizace platformy x86 na jedné straně a šíření IT outsourcingu na straně druhé vedly k myšlence utility computing (IT jako veřejná služba). Proč nezaplatit za IT stejně jako za vodu nebo elektřinu – přesně tolik a přesně tehdy, když to potřebujete, a nic víc.
V tuto chvíli vznikla myšlenka cloud computingu – využívání IT služeb z "oblačnosti", t.j. z externího zdroje zdrojů, aniž bychom se starali o to, jak a odkud tyto zdroje pocházejí. Stejně jako se nestaráme o infrastrukturu vodárenských čerpacích stanic. V této době byla také vypracována další strana koncepce – a to pojem IT služeb a jak je řídit v rámci ITIL / ITSM.
Byl vyvinut celá řada definic oblaků (cloud computingu), avšak neměli bychom je považovat za pravdu v poslední instanci – je to pouze způsob, jak formalizovat metody poskytování utility computing.
- "Cloud computing je technologie distribuovaného zpracování dat, ve které jsou počítačové zdroje a výkon poskytovány uživateli jako internetová služba" Wikipedia.
- "Cloud computing představuje model pro zajištění snadného síťového přístupu ke společnému fondu konfigurovatelných výpočetních zdrojů (například sítí, serverů, systémů pro ukládání dat, aplikací a služeb) podle potřeby, které lze rychle přidělit a poskytovat s minimálním úsilím nebo minimálním zásahem ze strany poskytovatele služeb" NIST.
- "Cloud computing je paradigmata, která zajišťuje síťový přístup k škálovatelnému a flexibilnímu fondu distribuovaných fyzických nebo virtuálních zdrojů, které jsou poskytovány v režimu samoobsluhy a spravovány na požádání" ISO/IEC 17788:2014. Informační technologie – Cloud computing – Přehled a slovník.
Podle NIST existují tři základní typy oblaků:
- IaaS – Infrastructure as a Service — Infrastruktura jako služba
- PaaS – Platform as a Service — Platforma jako služba
- SaaS — Software as a Service — Software jako služba
Pro zcela zjednodušené pochopení rozdílu si pojďme představit model Pizza-as-a-Service:
NIST definuje následující nezbytné rysy IT služby, které ji umožňují považovat za cloudovou.
- Univerzální síťový přístup (broad network access) – služba by měla mít univerzální síťové rozhraní, které umožňuje připojení a používání služby prakticky kýmkoliv s minimálními požadavky. Příklad – pro použití elektrické sítě 220V stačí se připojit k jakékoli zásuvce se standardním univerzálním rozhraním (vidlice), které se nemění bez ohledu na to, zda se jedná o konvici, vysavač nebo notebook.
- Měřitelnost služby (measured service) – klíčovým rysem cloudové služby je měřitelnost služby. Navrátíme-li se k analogii s elektřinou – zaplatíte přesně tolik, kolik jste spotřebovali, s minimální granularitou, až po náklady na jednorázové uvaření konvice, pokud jste byli v domě pouze jednou za měsíc a vypili jste šálek čaje.
- Samostatné konfigurování služeb na požádání (on demand self service) – cloudový poskytovatel nabízí zákazníkovi možnost rozumného konfigurování služby, aniž by bylo nutné spolupracovat s pracovníky poskytovatele. Abychom uvařili konvici, není vůbec nutné předem kontaktovat Energetiku a upozorňovat je, a získávat povolení. Od okamžiku, kdy je dům připojen (uzavřena smlouva), mohou všichni spotřebitelé samostatně nakládat s poskytnutým výkonem.
- Okamžitá elasticita (rapid elasticity) – cloudový poskytovatel poskytuje prostředky s možností okamžitého zvyšování / snižování výkonu (v určených rozumných mezích). Jakmile je konvice zapnuta, poskytovatel okamžitě dodává do sítě 3 kW výkonu, a jakmile je vypnuta, snižuje dodávku na nulu.
- Konsolidace zdrojů do poolu (resource pooling) – vnitřní mechanismy poskytovatele služeb umožňují konsolidovat jednotlivé generující kapacity do společného poolu (bazénu) zdrojů s následným poskytováním zdrojů jako služby různým spotřebitelům. Zahrnující konvici, nás nejméně zajímá, z jaké konkrétní elektrárny přichází výkon. A všichni ostatní spotřebitelé spotřebovávají tento výkon spolu s námi.
Je důležité chápat, že výše popsané charakteristiky cloudu nejsou náhodné, ale jsou logickým vývodem z konceptu utility computingu. A veřejná služba by měla mít tyto charakteristiky v rámci konceptu. Při neshodě s některou z charakteristik služba nezhoršuje a nestává se "toxickou", pouze přestává být cloudovou. A kdo říká, že všechny služby musí být?
Proč o tom hovořím zvlášť? V uplynulých 10 letech od vzniku definice NIST bylo mnoho diskuzí o "skutečné cloudovosti" podle této definice. V USA se stále občas v právní sféře používá fráze "v souladu s písmenem zákona, ale ne duchem" — a u cloudových výpočtů jde především o ducha, pronájem zdrojů na dva kliknutí myší.
Je třeba poznamenat, že uvedených 5 charakteristik se vztahuje k veřejnému cloudu, ale při přechodu na privátní většina z nich se stává volitelnými.
- Univerzální přístup k síti (broad network access) – v rámci privátního cloudu má organizace plnou kontrolu jak nad generujícími zdroji, tak nad klienty-spotřebiteli. Tuto charakteristiku lze tedy považovat za automaticky splněnou.
- Měřitelnost služby (measured service) – to je klíčová charakteristika konceptu utility computingu, platba podle skutečné spotřeby. Ale jak by měla organizace platit sama sobě? V tomto případě dochází k rozdělení generace a spotřeby uvnitř společnosti, IT se stává poskytovatelem, zatímco obchodní divize jsou spotřebiteli služeb. A vzájemné vyrovnání probíhá mezi divizemi. Mohou existovat dva režimy fungování: chargeback (při skutečném vyrovnání a pohybu financí) a showback (ve formě reportingu o spotřebě zdrojů v rublech, ale bez pohybu financí).
- Samoobslužné konfigurování služeb na požádání (on demand self service) – uvnitř organizace může existovat společná IT služba, a v tomto případě tato charakteristika ztrácí smysl. Nicméně při přítomnosti vlastních IT specialistů nebo administrátorů aplikací v obchodních divizích je nutné zorganizovat portál samoobsluhy. Závěr – varianta je volitelná a závisí na struktuře podnikání.
- Okamžitá elasticita (rapid elasticity) ztrácí smysl v rámci organizace, protože soubor zařízení pro soukromý cloud je pevně stanoven. Může být omezeně použit v rámci interního vyrovnávání. Závěr – pro soukromý cloud to není aplikovatelné.
- Zkombinování zdrojů do poolu (resource pooling) je dnes již prakticky běžné, protože neexistují organizace, které by nepoužívaly serverovou virtualizaci. Tuto charakteristiku therefore můžeme považovat za automaticky plněnou.
Otázka: Co vlastně je to vaše soukromé cloudové řešení? Co musí společnost zakoupit a implementovat, aby ho vybudovala?
Odpověď: soukromý cloud je přechod na novou administrativní model interakce IT a Business, který se skládá z 80 % z administrativních opatření a pouze z 20 % z technologií.
Platba pouze za spotřebované zdroje a snadný vstup, aniž by bylo nutné investovat několik stovek milionů do kapitálových nákladů, vedly k novému technologickému prostředí a vzniku miliardových společností. Například současní giganti Dropbox a Instagram začali jako startupy na AWS bez vlastní infrastruktury.
Je důležité zdůraznit, že nástroje pro správu cloudových služeb se stávají ještě více zprostředkované, a klíčovou odpovědností ředitele IT se stává výběr dodavatelů a kontrola kvality. Pojďme se podívat na problematiku těchto dvou nových povinností.
Objevily se jako alternativa k tradičním těžkým infrastruktuře s vlastními datovými centry a hardwarem, cloudy se mohou zdát klamně jednoduché. Do cloudu je snadné vstoupit, ale otázka výstupu obvykle zůstává stranou. Jako v jakémkoli jiném odvětví se cloudoví poskytovatelé usilují o ochranu svého byznysu a ztížení konkurence. Jediným skutečně konkurenčním momentem je počáteční výběr poskytovatele cloudových služeb, a poté se poskytovatel maximálně snaží, aby zákazník neodešel. A rozhodně ne všechny tyto snahy budou zaměřeny na kvalitu služeb či jejich sortiment. Především se jedná o poskytování unikátních služeb a využívání neobvyklého systémového softwaru, který ztěžuje přechod k jinému poskytovateli. Při výběru poskytovatele služeb je tedy nutné zároveň vytvářet plán přechodu od tohoto poskytovatele (v podstatě kompletní DRP – plán obnovy po havárii) a promyslet architekturu ukládání dat a záloh.
Druhým důležitým aspektem nových povinností IT ředitele je kontrola kvality služeb od poskytovatele. Prakticky všichni poskytovatelé cloudu dodržují SLA podle svých vlastních interních metrik, což může mít velmi nepřímý význam pro obchodní procesy zákazníka. A proto zavedení vlastní monitorovací a kontrolní soustavy se stává jedním z klíčových projektů při přesunu významných IT systémů k poskytovateli cloudu. Pokračujíc v tématu SLA, je nutné zdůraznit, že naprostá většina cloudových poskytovatelů omezuje odpovědnost za nesplnění SLA na měsíční poplatek nebo na podíl z platby. Například, AWS a Azure při překročení prahu dostupnosti 95% (36 hodin měsíčně) poskytnou 100% slevu z předplatného, zatímco Yandex.Cloud – 30%.
A samozřejmě nesmíme zapomínat, že cloudy nejsou jen dílem obřích gigantů jako Amazon a Yandex. Cloudové služby mohou být i menší — velikosti kočky nebo dokonce myši. Jak ukázal případ CloudMouse, někdy se prostě cloud vyčerpá. Nedostanete žádnou kompenzaci, žádné slevy — nedostanete nic, kromě totální ztráty dat.
Vzhledem k výše uvedeným problémům s realizací IT systémů vysoké úrovně obchodní kritičnosti v cloudových infrastrukturách se v posledních letech objevuje jev nazývaný "cloudová repatriace".
Do roku 2020 došlo k vrcholu nafouklých očekávání pro cloudové výpočetní služby a koncept se nachází na cestě do údolí zklamání (podle hype cyklu Gartnera). Podle výzkumů a až 80 % korporátních zákazníků vrací a plánuje vrátit zátěže z cloudu zpět do vlastních datových center z důvodů:
- Zvýšení dostupnosti / výkonu;
- Snížení nákladů;
- Aby bylo možné vyhovět požadavkům na zabezpečení informací.
Co tedy dělat a jak to "ve skutečnosti" je?
Není žádných pochyb, že cloudové služby se etablovaly a budou hrát stále větší roli. Žijeme však v roce 2020 v konkrétní situaci. Co dělat s cloudy, pokud nejste startup, ale klasický korporátní zákazník?
- Cloudy jsou především místem pro služby s nepředvídatelnou nebo výrazně sezónní zátěží.
- Ve většině případů je levnější udržovat služby s předvídatelnou stabilní zátěží ve vlastním datovém centru.
- Práce s cloudy by měla začít zkušebními prostředími a nízko-prioritními službami.
- Zvážení umístění informačních systémů do cloudu začíná vypracováním metodiky přechodu z cloudu do jiného cloudu (nebo zpět do vlastního datového centra).
- Umístění informačního systému do cloudu začíná vypracováním schématu zálohování do vy kontrolované infrastruktury.
Zdroj: habr.com
