Desatero hladkého soužití cloudu a on-premise z pohledu governance

Typické otázky, které řešíme při nasazení cloudu

• Pro co chci cloud využít?
• Jaký je vhodný poskytovatel pro IaaS/PaaS?
• Nepotřebuji více poskytovatelů?
• Jak do toho zapadá moje interní automatizace/privátní cloud?
• Které aplikace jsou pro cloud vhodné?
• Co udělám se stávající on-premise infrastrukturou, co si nechám v on-premise?
• Budu vyvíjet aplikace už jen pro cloud? A pro jaký?
• Které aplikace (SaaS) si vezmu z cloudu?
• Co musím udělat pro to, aby mohl cloud koexistovat s on-premise IT?
• Které procesy musím kvůli cloudu přidat, které upravit a které dělat jinak?

Přístup ke cloudu

Otázka přístupu ke cloudu je důležitá zejména pro organizace, které své IT nezačínají budovat přímo v cloudu, ale vycházejí z vlastního datacentra (on-premise).  Na postoji managementu závisí, jak se budou ke cloudu stavět týmy i jednotlivci v celé organizaci. Na trhu je možné vysledovat pětiúrovňovou škálu přístupů:

1. Bez cloudu – cloud je odmítnut
2. Respektujeme cloud – cloud je brán na vědomí, ale je využíván jen ve výjimečně
3. Opatrně do cloudu – cloud je akceptován a použit v případech, které dávají smysl
4. Cloud je první volba – vždy, když to jde, je použit cloud
5. Pouze cloud – neexistuje jiná volba než cloud

Využití cloudu a typy aplikací

Jaké typy cloudu můžeme využít, jsme rozebírali v tomto článku. Než se pustíme do otázky, k čemu cloud vlastně použít, je důležité si definovat rozdíl mezi interní a externí aplikací v organizaci.

Interní aplikace jsou ty, které vyvíjíme uvnitř organizace vlastními silami (nebo s pomocí externích firem). Vždy máme právo ovlivnit jejich architekturu a související infrastruktury. Interní aplikace většinou provozujeme ve vlastním datacentru, v cloudu pro ně využíváme IaaS/PaaS služby.

Externí aplikace jsou dodávané třetími stranami. Někdy mají podobu služby obsahující aplikaci a byznys procesy. U externích aplikací nemáme vliv na architekturu a infrastruktury. V cloudu jsou takové aplikace označovány jako SaaS aplikace.

Kdy je cloud užitečný pro interní aplikace?

U interních aplikací závisí použití cloudu na stavu on-premise infrastruktury a investičního cyklu. Pokud stojím před novým investičním cyklem, mohu se rozhodnout pro vyšší míru nahrazovaní on-premise infrastruktury.

V opačném případě volím spíše pozvolný náběh cloudu s formou doplňování. Rozhodování, k čemu cloud použít, je u interních aplikací primárně v rukách IT. Stačí zohlednit dopady na finance a vyřešit několik otazníků:

• Který cloud poskytovatel?
• Více vendorů – ano/ne (multicloud)?
• Koexistence s privátním cloudem (hybrid cloud)?
• Vazba na automatizaci a DevOps?

Výběr poskytovatele IaaS / PaaS cloudu / multicloudu

Komerční organizace si vybírají z předních světových poskytovatelů cloudu AWS, Microsoft Azure, Google, Oracle Cloud a někdy zahrnou i lokální cloud poskytovatele. Státní správa více zvažuje národní „certifikované“ poskytovatele cloudu.

Naše zkušenost z cloudových projektů říká, že kvůli faktorům jako prezence na našich trzích, finanční pobídky migrací, šíře portfolia služeb nebo úroveň zabezpečení a compliance, padá volba mezi AWS a Azure.

Při výběru cloudového poskytovatele vybíráme celou platformu, a ne pouze jednu službu. Dual vendor politika (nebo-li multicloud)  je důležité téma, pokud existují obavy a rizika ze závislosti na jediném poskytovateli.

Rozhodování, zda využívat multicloud, je těžké. Na jedné straně se nabízí benefit nezávislosti, proti kterému stojí na druhé straně dvojnásobné úsilí, investice a adopce více poskytovatelů. Pokud se nakonec rozhodnete pro dual vendor policy, doporučujeme rozložit adopce poskytovatelů do více let.

Chcete hybrid cloud? 

Otázka hybrid cloudu je otevřena, pokud už organizace investovala do privátního cloudu – rozšiřováním automatizace v on-premise infrastruktuře (VMware) nebo kvůli potřebě mít prostředí pro vývoj/orchestraci/automatizaci mikroslužeb (Openshift). Přemýšlení o nasazení veřejného cloudu otevírá otázky koexistence s cloudem privátním:

• Budeme pokračovat v aktivitách privátního cloud – ano/ne?
• K čemu budeme používat privátní cloud a na co veřejné poskytovatele cloudu?
• Budeme uvažovat o rozšíření privátního cloudu do veřejného?

Při hledání odpovědí na sebe zpravidla narážejí dvě protichůdné argumentace – kontinuita (evoluce) versus inovace (revoluce).

Někdo považuje za důležitější kontinuitu v používání privátního cloudu. Proto rozšíření datového centra do veřejného cloudu vnímá jako evoluční krok, který přinese stejné prostředí, minimální změny procesů a zachová investice do privátního cloudu.

Pro jiné je klíčová revoluce – zapomenout na privátní cloud a začít využívat jen cloud veřejný a s ním související benefity: inovace, kontinuální rozvoj technologií, vývoj cloud native aplikací nebo finesy cloud pricingu (pay-as-you-go, reserved pricing, časové využití workloadů).

Automatizace, DevOps a cloud native aplikace

Cloud je postaven na efektivním používání zdrojů a automatizaci, DevOps a cloud native aplikacích (aplikace založené na kontejnerech a mikroslužbách).

Automatizace v on-premise je budována „od píky“ nadšenými jednotlivci, kteří rádi objevují a chtějí si usnadňovat práci. Nicméně udržovat, rozvíjet a dokumentovat automatizační prostředí stojí hodně úsilí a energie.

 Veřejný cloud má automatizaci jako jeden ze základních parametrů. Automatizace, DevOps a cloud native aplikace jsou pozitivním motivátorem a akcelerátorem, proč cloud využít – proto by v žádné cloudové strategii neměly chybět.

 Pozitivní zprávou je, že většinu investic vložených do on-premise automatizace v cloudu využijete a znásobíte. Klíčem je integrace vaší DevOps platformy s cloudem a jednoduchost pro vývoji cloud native aplikací (kontejnery a mikroslužby).

Jak řídit koexistenci cloudu a on-premise?

Dalším veledůležitým tématem jsou principy a nástroje, se kterými uřídíte koexistenci on-premise a cloudu. Slouží k tomu těchto pět zásad:

1. Rozdělte IT na menší oblasti (samostatně jsou jednodušeji řešitelné).
2. Každou oblast řiďte podle stejných principů.
3. Využívejte vícerychlostní přístup.
4. Definujte si pravidla cloud/on-premise pro interní aplikace.
5. Definujte si pravidla cloud/externí dodavatele pro externí aplikace.

Třírychlostní přístup pro interní aplikace

Vícerychlostní přístup je vyzkoušený postup. Možná si vzpomenete na pojem dvourychlostní (bimodal) IT, který začal být používán před více než deseti lety. Pro rozdělení aplikací a infrastruktury podle „cloudovatelnosti“ je vhodné rozdělení na tři skupiny, které zároveň vyjadřují rychlosti nasazovaní nových verzí (release):

1. Legacy aplikace – nelze je migrovat do cloudu, nebo velmi obtížně, pomalý release
2. Cloud ready aplikace – lze je migrovat za určitých podmínek, rychlejší Release
3. Cloud native aplikace – jsou vyvíjeny přímo pro cloud, nejrychlejší release

U Legacy o cloudu ani nepřemýšlíme. Je důležité takovou kategorii mít a o cloud se u ní nepokoušet. Cloud native naopak bývá úplně nová kategorie. Abychom mohli mít cloud native aplikace mít, musíme změnit vývojové a provozní postupy a využívat přístup 12 faktorů (budeme se věnovat v dalších článcích). U Cloud ready aplikací (typicky nedávno napsané v JAVA, .NET) si definujeme podmínky, úsilí a náklady za jakých jsme schopni aplikace migrovat do cloudu.

U takto definovaných tří typů aplikací a související infrastruktury se organizaci jednodušeji definují principy governance, například: kam umisťuji aplikace, styl vývoje, využití do DevOps a automatizace, standardy architektury a vývoje, typ a rychlost release, typy aplikační integrace a mnoho dalších.

Následující obrázek ukazuje příklad jak si definovat základní principy Governance IT:

Governance procesů interních aplikací

Implementace cloudu se většinou dotkne většiny procesů IT. Co je nutné upravit a změnit, je vždy výsledkem analýzy cloudové maturity týmů a procesů (jednotlivým oblastem se budeme věnovat v dalších článcích).

Většina organizací bude při nasazení cloudu překvapena následující pěticí procesů, které jsou oproti zvyklostem s on-premise zcela jiné/nové – obsahem, provázaností i intenzitou, se kterou je nutné se jim věnovat.

Standardy/Blueprinty

V on-premise používáme pojem architekturní standardy, v cloudovém světe se více používá výraz blueprinty. Blueprinty lze jednoduše automatizovat a dlouhodobá udržitelnost velí mít jich jen nejnutnější malý počet.

Z pohledu governance je důležité definovat procesy vzniku, sizingu, update a schválení cloudových blueprintů, které ve světě on-premise buď vůbec nejsou, nebo jen ve velmi malém rozsahu.

Procurement/objednávání 

V on-premise tendrujeme konkrétní hardware/software/služby několikrát do roka a následně objednáváme jedno a více plnění.

V cloudu máme cenu poskytovatele transparentně jasnou dopředu. Záleží, jaké parametry si zvolíme, a cenovka je jasná. Pokud chceme lepší podmínky, musíme znát předpokládanou útratu v cloudu na následující 2–3 roky a vyžádat si od poskytovatele dodatečnou slevu.

Z pohledu governance je důležité definovat „billingovou“ strukturu a principy štítkování (tagy), abychom měli správný rozpad nákladů generovaný cloudovou platformou.

Konzumace služeb 

V on-premise děláme kapacitní plánování 1× ročně, design služeb je statický a vždy pokrývá výkonové rezervy a všechna prostředí.

V cloudu, je design dynamický a máme snahu mít v provozu jen ty nejnutnější prvky, abychom utráceli jen za to, co má smysl. Kontrolu konzumace služeb musíme řešit daleko častěji – nejlépe 1× měsíčně.

Čím častěji kontrolujeme plán konzumace služeb, tím méně je pravděpodobné, že budeme utrácet za něco zbytečně. Z pohledu governance je důležité definovat vlastníky kontroly konzumace služeb, frekvenci kontroly, pravidla správného i nesprávného vývoje útraty a včasného ukončení služeb.

Optimalizace služeb 

V on-premise se optimalizace služeb dělá jednou za „uherský rok“, anebo když jsou výkonové problémy. Vše je správně naddimenzováno, aby k problémům nedošlo, a licence nás nutí dělat sdílené technologické celky.

V cloudu se design dělá na mikroúrovni a je více než vhodné se optimalizaci služeb věnovat daleko častěji – ideálně čtvrtletně. Postihneme tím dlouhodobější trendy vyplývající z měsíčních kontrol konzumace služeb a novinek ve vývoji cloudových služeb.

Z pohledu governance je důležité definovat procesy optimalizace služeb, pokrývání špiček, časového vypínání a zapínání zdrojů, nových cenových plánů komponent.

Rozpočtování

V on-premise je běžné rozpočtování IT služeb na rok se 3–4 update po jednotlivých rozpočtových kapitolách. Alokace rozpočtů per aplikace není vyžadována a pokud se realizuje, je velmi pracná (zejména při určení alokačních klíčů).

V cloudu je rozpočet počítán na 2–3 roky, s průběžnou měsíční kontrolou a korekcemi po kvartálech. Bohužel v daleko větší granularitě (aplikace, prostředí, cloud komponenty).

Z pohledu governance je důležité mít procesy standardů/blueprintů, procurementu/objednávání, konzumace a optimalizace služeb správně nastavené a provázané, aby se dal rozpočet řídit.

Přístup k externím aplikacím

Externí aplikace se dělí na dva typy – outsourcované a SaaS.

Outsourcovaná aplikace je taková, která je nám poskytována na míru a dokážeme ovlivnit všechny klíčové parametry: poskytovatele, smlouvu, cenu, podmínky poskytovaní, bezpečnosti, governance atd. Aplikace je obvykle poskytována individuálně.

U SaaS aplikace jsou možnosti ovlivňovat smlouvu a podmínky poskytování omezené, služba je většinou poskytována více zákazníkům najednou.

Kdy je cloud užitečný pro externí aplikace?

Motivace k využití cloudu pro externí aplikace je oproti interním aplikacím rozdílná. Zatímco u interních se hledá použití celé cloud platformy, u externích aplikací je výběr individuální a má mnoho motivací:

• O co se chceme starat a v čem necháme odpovědnost (například za provoz a infrastrukturu) na někom jiném?
• Máme, nebo nemáme možnost výběru? Některé aplikace existují už jen v cloudu (např. aplikace produktivity Webex, M365, GApp).
• Jsme schopni a máme prostředky na inovace technologií? Nebo to cíleně chceme od poskytovatele, který to umí lépe, rychleji a má na to více peněz?
• Víme, že někdo se specializuje na vybrané byznys procesy, které nám umožní akcelerovat byznys anebo efektivitu procesů organizace, a navíc současně nabízí aplikaci – např. ServiceNow.

Rozhodování o výběru správného řešení je u SaaS aplikací daleko více v rukách byznysových jednotek s přihlédnutím k možnostem v IT.

Governance externích aplikací

Governance externích aplikací závisí na možnostech řídit podmínky dodávky aplikace/služby. Čím více umíme ovlivnit podmínky dodávky a smluvního ujednání, tím naše míra governance aplikace roste a klesá riziko (a naopak). Z tohoto pohledu je vhodné si externí aplikace rozdělit na tři skupiny:

1. SaaS bez governance – kontrakt je neměnný a online, obvykle nemůžeme mnoho/nic ovlivnit – typicky služba „ber, jak běží“.
2. SaaS s governance – kontrakt je částečně neměnný, můžeme upravovat podmínky služby – řídit si nastavení, integrovat identitu a řídit přístup k datům (např. SalesForce, JIRA, ServiceNow).
3. Outsourcingové aplikace – kontrakt je šitý na míru našim potřebám, můžeme ovlivnit mnoho parametrů včetně governance a rizik.

U outsourcingových aplikací si můžeme dovolit individuální governance. U SaaS aplikací s governance můžeme řídit governance pomocí integrace s korporátní identitou, řídit korporátní data, stanovit si rizikové faktory a tomu odpovídající kontrolní mechanismy bezpečnosti, GDPR a regulací – více nám poskytovatel ani platforma nenabídne.

Desatero hladkého soužití cloud a on-premise! 

Nasazení cloudu je velká změna. Organizace k ní potřebuje pomoc všech svých členů – a ti zase potřebují jednoduchý návod se srozumitelnými sděleními pro komunikaci a adopci. Pravidla governance na soužití cloudu s on-premise jsou důležitou součástí cloudové strategie i základní esencí pro řízení změny. Nabízím vám pro tyto účely jednoduché desatero:

• Je vhodné mít definováno, jaký je přístup celé organizace ke cloudu. Není důležitý přesný typ přístupu, ale jasně sdělená pozice.
• Platí matematika 1 + 1 = 3 (více zde). Proto si stanovte pravidla řízení cloudu, on-premise a soužití obou prostředí.
• Interní aplikace využívají cloud jinak než ty externí. Pravidla výběru a řízení cloudových platforem i poskytovatelů to musí respektovat.
• Svět není jednoduchý a musíme se jasně vypořádat s otázkami multicloud (dual vendor) a hybrid cloud.
• Cloud pomáhají akcelerovat automatizace a vývoj cloud native aplikací.
• DevOps je výborným spojovacím článkem úspěšné koexistence cloudu a on-premise prostředí.
• Cloud umožňuje oproti on-premise rychlejší nasazování aplikací. Pravidla řízení IT by měla respektovat vícerychlostní přístup jako jeden z klíčových parametrů governance.
• Rozdělte interní aplikace podle „cloudovatelnosti“ (legacy, cloud ready, cloud native) a definujte klíčové governance parametry – rychlost release a umístění aplikací, styl vývoje, využití do DevOps a automatizace, standardy architektury a vývoje, typy aplikační integrace a další.
• Rozdělte externí aplikace podle „vlivu na podmínky dodávky a smlouvy“ (SaaS bez governance, SaaS s governance, outsourcingové aplikace) a definujte klíčové governance parametry – integrace s identitou, řízení korporátních dat, stanovení rizikových faktorů a tomu odpovídající kontrolní mechanismy bezpečnosti, GDPR a regulací.
• Počítejte s tím, že na rozdíl od on-premise budete muset své řídící procesy rozdělit na tři typy: 1) necháte stejné, 2) musíte dělat jinak, 3) jsou pro vás novinkou.