Příprava cloudového prostředí: jak na to?

 

Jak systematicky postupovat, když je třeba připravit cloudové prostředí na migraci workloadů a aplikací?

Lukáš Hudeček

 

Je to vlastně stejné, jako když stavíme dům, na který jsme si připravili projekt a rozpočet. Nejprve potřebujeme inženýrské sítě (jako jsou elektřina a voda), zajištěnou přístupovou cestu na pozemek a vybetonovanou základovou desku. Teprve pak můžeme stavět jednotlivá patra a skončit střechou. Stejné je to s přípravou cloud prostředí – i zde začínáme systematicky od začátku.

 

 V tomto článku vám představím kroky k přípravě cloudového prostředí na migraci aplikací. Těmto krokům se také říká příprava landing zóny. Kdo začíná stavbu od prvního patra, bez základní desky a inženýrských sítí, většinou mu nezbude, než stavbu zbourat a začít zase od začátku.

 

 

Procesy a modifikace pro cloudové scénáře

V první řadě budeme modifikovat, případně analyzovat stávající procesy s ohledem na jejich použití v cloudu.

Tento krok zahrnuje například posouzení stávající sady směrnic a procesů pro IT service management (ITSM), jako jsou především change management, incident managementa problem management.

Z pohledu security se zaměříme na modifikaci bezpečnostní politiky, řízení business continuity a zahrnutí cloudových procesů. Posuzujeme také kompatibilitu a možnosti stávajících nástrojů pro podporu cloudových operací.

Z pohledu řízení kapacit pak potřebuji, aby se interní lidé dostali v určitém čase na potřebný skillset pro podporu cloudových operací. V neposlední řadě řešíme zajištění potřebného know-how ze strany dodavatelů.

 

 Architektura a její rozšíření

Stávající architekturu budeme rozšiřovat o nové cloudové prostředí. Řešíme, jak provedeme propojení a zda je vůbec potřebujeme. Určujeme, které typy workloadu a aplikací budeme v cloudu provozovat, které prostředí do něj přesuneme (DEV, TEST, PROD) a jak robustní bude cloudové prostředí v návaznosti na SLA a Business continuity.

Z pohledu architektury se zaměřujeme především na:

• Definice nových standardů od architekturních bloků až po vznik celých artefaktů.  Zde můžu vyjít z referenční architektury, kterou má každý cloudový poskytovatel veřejně dostupnou.
• Definice provozních politik tak, aby administrátoři nemohli deployovat cokoliv a kdekoliv a aby měli nastavené limity maximální velikosti služby (případně cost limity).
• Definice Azure Managment Group a subskripcí. V případě AWS to jsouOrganization Units a Accounts. Tyto základní prvky slouží pro rozdělení prostředí dle různých kritérií jako DEV/TEST nebo sdílené prostředky, unikátní prostředky, požadavky na bezpečnost apod.
• Následné vytvoření blueprintů – šablon, které popisují prostředí a ve kterých jsou zaneseny všechny parametry (IaaC). Nebo se může jednat o rozšíření interního katalogu služeb (jako například Azure ARM templates a AWS Cloud Formation).
• CICD – použití nástroje pro řízení deploymentu a uložiště kódu (Azure DevOps, AWS CodeBuild a AWS CodePipeline).

 

Security a cloud compliance

Bezpečnost v cloudu je další velké téma. Ještě před pár lety jsem se setkával s tvrzením, že „cloud se nedá zabezpečit“, protože všechno je dostupné z venkovního internetu a „data nemám u sebe“. Naštěstí už tyto názory dávno vzaly za své.

Velcí cloudoví hráči splňují veškeré možné normy, včetně ISO norem ISO 27001, CIS Benchmark, apod. Je nutné je pouze správně implementovat. Pomocí zásad a automatizace můžu snadno nasadit a nakonfigurovat Azure Security Center nebo AWS Security Hub i v rozsáhlých prostředích.

Použití umělé inteligence a automatizace vám umožní rychle identifikovat hrozby, zjednoduší jejich prošetřování a pomůže vám automatizovat nápravné akce. Případně je možné do security zapojit nějaký SIEM systém, jako třeba Azure Sentinel, který umí spojovat události ze všech systémů a na základě toho odhalit rizika.

V cloudu se nabízí zabezpečení v několika vrstvách, jak na straně uživatelského účtu, tak vlastního sytému:

• Z pohledu uživatelského účtu je ideální používat SSO, kde mám jeden účet ke všem provozovaným aplikacím, a ten mám zabezpečen minimálně MFA autentizací, nejlépe v kombinaci s Conditional Accessem a Device managementem. Toto řešení umožňuje definovat mnoho přístupových podmínek dle různých stavů, například včetně geolokace.
• Ze strany aplikace mohu použít různé WAF řešení s L4/L7 aplikačním Firewallem a DDos ochranou. Dále mohu šifrovat data na úrovni filesystému i databáze. Logy z těchto komponent končí taktéž v security centru, případně v SIEM řešení.

 

 

Roadmapa jako plán postupu v čase

Roadmapa je důležitá pro celkové plánovaní a vyhodnocování. Obsahuje časovou osu projektů, které nastanou v následujících měsících nebo letech. Slouží pro odhady trvání a řízení návaznosti v jednotlivých projektech.

Plán implementace se týká všech výše a níže zmiňovaných témat a obsahuje:

• Definice a pokrytí všech potřebných standardů architektury, security, compliance a governance.
• Přípravu landing zóny, kde máme nastaveny alespoň minimální požadavky pro začátek migrace aplikací.
• Z pohledu aplikací máme alespoň analyzované základní údaje jako životní cyklus aplikace, KO kritéria, složitost a kritičnost aplikace a rozsah integrací. Toto téma bylo blíže popsáno v minulém článku Jak dostat aplikace do cloudu.

 

Cloud governance jako definice a politiky

V governence části definujeme standardy a postupy. Většinou se jedná o rozšíření nebo zrcadlení procesů a nastavení z on-premise části.

Zaměřujeme se především na tyto oblasti:

• Azure Management Groups a subskripce, případě AWS Organizations Groups.
• Jmenné konvence – na internetu jsou popsány standardy, přičemž se většinou tvoří prefixem nebo sufixem k názvu zdroje. Tady pozor – ne každý vytvořený objekt se dá jednoduše přejmenovat. Než se nadějeme, odladěný test se z ničeho nic povýší na produkci a různé zkomolené názvy zůstanou prostředkům napořád a povedou ke zmatení.
• Tagování – tvoříme doplňkové informace, kterými můžeme obohatit daný zdroj např. o vlastníka nebo prostředí, ke kterému patří. I s tím bych však byl opatrný. Už jsem zažil třeba i admin účet včetně hesla napsaný v tagu.
• Provozní politiky – vyhodnocují aktuální konfiguraci prostředků oproti definici zásad.
• Odpovědnosti – přiřazení rolí v rámci týmů implementace, architektury, bezpečnosti, podpory, nasazování aplikací atd.
• Standardy – především technické.
• Implementace nástroje CICD – viz obrázek.

 

 

Cost management a řízení financí

Jakmile se dotkneme financí, všichni manažeři zbystří: „To zase bude peněz!“ Plánování financí a vypočet TCO v letech je dnes pro většinu organizací rutinní činností. V cloudových službách je obsažen monitoring a predikce spotřeby podle trendu. Je důležité kontinuálně vyhodnocovat spotřebu a optimalizovat prostředky, a to například následujícími způsoby:

• Rezervací výkonu na 1 až 3 roky. Zde je třeba dobře rozmýšlet a počítat, zda nakupovaný výkon skutečně budu dlouhodobě spotřebovávat.
• Vypínáním procesů, které běží pár hodin denně nebo jednou za čas; typicky neprodukční prostředky.
• Optimalizací využití prostředků dle měření. Zde bývá největší prostor pro úspory. Pro optimalizaci můžu využít specializovaný software jako Densify.

 

 

Landing zone jako naše základová deska

Landing zóna je připravená plocha, kam začínám migrovat aplikace a workloady. To, co jsme si v předchozích částech popsali, tak v landing zóně realizuji.

Mám navrženou architekturu, tedy postup, jak budu vytvářet objekty, a vydefinoval jsem si komponenty, které můžu použít. Prostředí mám rozparcelované po management skupinách a subskripcích. Mám vybudovanou síťovou topologii, IP adresaci a VPN připojení. Mám implementovaný Access a Identity management v případě Azure (RBAC).

Definoval jsem si jmenné konvence. Připravil jsem si blueprinty tak, abych mohl deployovat jednotlivé komponenty upravené dle standardu organizace a definoval a nastavil jsem provozní a bezpečnostní politiky. Mám nastavený log management a monitoring prostředí a v cost managementu nastavené limity útrat, dle jednotlivých kritérií.

Můžeme tedy začít budovat naší novou plně virtuální a automatizovatelnou část infrastruktury.

 

 

Na přípravu nejste sami

Článek berte jako inspiraci pro váš začátek s přípravou cloudového prostředí, což je disciplína, kterou musí absolvovat každá organizace před migrací workloadů a aplikací. Celé téma je samozřejmě komplexnější a určitě se nevejde na pár stránek.

Jak bylo řečeno, je potřeba začít budováním základů a pokračovat po jednotlivých vrstvách dle stanovené roadmapy až po plánovanou migraci aplikací.

Velcí cloudoví hráči jako Azure, AWS a Google mají definované cloud adoption frameworky pro usnadnění a podporu nasazení cloudového prostředí. Existují finanční incentivy a programy, které vám s adopcí mohou pomoci. Současně existuje popsaná referenční architektura a obrovské množství šablon a definic, třeba i na Githubu.

V navazujícím článku našeho seriálu se zaměří kolega Jakub Procházka na téma Náklady v cloudu. Další kapitoly najdete v naší Encyklopedii cloudu – stručném průvodci cloudovým prostředím.