Azure je velký cloud s fantastickým tempem vývoje, obrovskou flexibilitou a možnostmi, širokou plejádou služeb a je to ideální místo pro vaše IT potřeby. Přesto někdy jsou důvody proč provozovat něco lokálně. Pro moderní aplikace s lokálním nasazením je tu Azure Stack. Podmnožina Azure dostupná ve vašem sklepě a konzistentní s ovládáním Azure. Bezpečné a rychle nasaditelné řešení. Azure Stack je pro ty, kteří chtějí využívat Azure u sebe, ne pro ty, co si užívají budování cloudu. Máte rádi Azure, ale pro některé situace potřebujete běžet lokálně? Podívejme se co je Azure Stack a kdy ho využít.
Nápad nabídnout kousek Azure do datového centra zákazníka nebo providera není nový. Něco takového chtěl Microsoft celou dobu, ale cesta k Azure Stack nebyla jednoduchá a firma se při ní hodně naučila. Myslím, že je dobré a poučné tento historický kontext vnímat - osvětluje to některá designová rozhodnutí Azure Stacku.
Pojďme významným zákazníkům nabídnout Azure tak, jak se to dělá v Microsoft datových centrech. Tato myšlenka pochází z roku 2011 a měla několik problémů. Tím největším bylo, že nejmenší jednotka nasazení (scale unit) v Azure je 800 fyzických serverů. To už je panečku pořádná investice, na kterou je málo který zákazník připraven. Navíc operační model vyžadoval stejnou komplexitu a znalosti jako provoz Azure samotného. I když zákazník něco takového chtěl, bylo to tak komplikované, že se mu o to stejně Microsoft musel kompletně starat. Tento model sice pár zákazníků našel, ale úspěšný moc nebyl.
Dobře, nainstalovat skutečný Azure je nesmírně složité a nákladné, pojďme na to jinak. Jak zajistit nasazení v menší škále? Co použít metody klasického on-premises produktu, čili Hyper-V a System Center a nad to přidat vrstvu, která simuluje Azure? Takhle vznikl Azure Pack, rozšíření on-premises produktů. To byla o poznání úspěšnější varianta, ale rovněž přinesla úskalí. V okamžiku, kdy máte pod kapotou on-premises řešení, je dost obtížné zajistit konzistentní chování. V Azure je všechno softwarově definované - compute, storage i networking, ale tady máte klasičtější řešení, které vaši schopnost přinést Azure konzistenci značně limituje. Ten hlavní problém není udělat produkt, který připomíná podmnožinu Azure jako snapshot v čase, ale hlavně udržet krok s jeho vývojem. Azure se mění velmi rychle a inovuje fantastickým tempem. Výsledkem bylo, že rozdíl mezi Azure a Azure Pack se nejen nezmenšoval, ale ani nezůstával stejný. Právě naopak - neustále se zvětšoval, protože Azure přišel s novým portálem a API (Azure Resource Manager) a to už se do Azure Pack nikdy nedostalo.
Bylo tedy potřeba se vrátit k rýsovacímu prknu a to se staro v roce 2015 a v té době začaly také poprvé do tisku unikat zvěsti o Azure Stack. První snahy stále ještě stavěly na on-premises světě System Center a nad to se pokoušely dát vrstvu nového Azure (ARM). Brzy se ale přišlo na to, že oba negativní aspekty předchozích snah by se znova opakovaly. Podobně jako u prvního pokusu zde byla neuvěřitelná komplexita variant a celé to bylo neudržitelně složité a také minimální velikost instalace se blížila deseti fyzickým serverům, což byl overhead, který byl zkrátka moc - cílem bylo nabídnout Azure Stack už od 4 nodů. Podobně jako v případě Azure Pack tady bylo příliš mnoho "překladů" mezi Azure a on-premises modelem a začalo být zřejmé, že by znovu nebylo možné udržet s vývojem Azure krok. Muselo se na to jinak.
Řešením bylo použít řešení co nejpodobnější fungování Azure a co nejvíc binárek mít stejných, ale zapracovat na schopnosti seškálovat prostředí dolu z 800 serverů jako minimum pro scale unit až k cílovým 4 serverům. To se podařilo. A jak na komplexitu a udržitelnost v čase? Jediné rozumné řešení je zabalit Azure Stack do formy hotového řešení ve spolupráci s hardwarovými výrobci. Nebude možnost nainstalovat si sami, v nabídce budou hotová řešení s předem otestovaným hardware a nastavením, které bude provádět Microsoft společně s hardwarovým partnerem. Žádný nekonečný počet variant a s tím nekonečný počet problémů, který by vedl k snížení použitelnosti řešení a hlavně k neschopnosti udržet krok s Azure.
Výsledkem je Azure Stack. Řešení pro ty, co chtějí využívat Azure cloud u sebe, nikoli pro ty, co si chtějí cloud sami postavit. Pod kapotu zkrátka nemáte přístup - nepodíváte se do Hyper-V, nebudete řešit jak funguje virtuální síť ani nastavovat BGP mezi virtuální a fyzickou sítí, nebudete mít možnost instalovat neschválený software na nody (třeba nějaké monitorovací agenty), využijete vyladěné storage technologie včetně RDMA na síťové úrovni apod. Stejně jako v Azure máte cloud a do něj přistupujete cloudově, neřešíte jak to tam vevnitř funguje. Rozdíl oproti Azure samozřejmě je, že tam položky do katalogu služeb publikuje Microsoft, u Azure Stack máte portál pro operátora, díky kterému publikujete služby a provádíte správu Azure Stack jako je instalace updatů (které jsou mimochodem v průměru jednou měsíčně - tempo potřebné k udržení kroku s Azure).
Kdy tedy dává smysl použít Azure Stack? Pro jaké situace je určen?
Jsou situace, kdy potřebujete běžet u sebe. Ve většině případů je to spíše pocit nebo zvyk, compliance často vyžaduje pouze data v EU, což dokáže velký Azure garantovat. Ale jsou situace, kdy to skutečně jinak neprojde.
Extrémním případem je scénář ponorka nebo záoceánská loď. Velmi mne překvapilo kolik serverového výkonu je v takových případech potřeba a běžet v ponorce věci z veřejného cloudu je samozřejmě nemožné. Podobně extrémní zcela odpojené situace mohou být vidět v některých armádních složkách, zpravodajství apod.
Častější je spíše nedostatečná konektivita nebo problém s latencí. Pokud běžíte real-time aplikace, které třeba řídí výrobu, dělat to z cloudu nemusí být možné. Zvýšená latence může dělat problémy, ale hlavně je tu riziko výpadku spojení. To nesmí způsobit havárii nebo zastavení výrobní linky. V těchto případech je užitečné mít cloud lokálně.
Co když modernizujete aplikaci, která běží na mainframu a má hromadu lokálních dat. Chcete využít velkého Azure pro moderní část aplikace - strojové učení, umělou inteligenci, moderní aplikační platformu, ale z tohoto prostředí nechcete nebo nemůžete přistupovat legacy protokoly do staré aplikace. To co typicky uděláte je, že vybudujete moderní fasádu pro stávající svět. Legacy aplikaci obalíte vrstvou moderních API, které poskytují potřebný překlad a ochranu (například rate-limit, protože nechcete, aby bug v moderní části aplikace nadměrně zatížil váš core systém). Tuto část aplikace ale chci také řešit a nasazovat cloudově. Například testovat a vyvíjet ve velkém Azure, kde mám obrovskou flexibilitu a neomezené zdroje a produkci nasazovat stejným způsobem, například ARM šablonou do VM nebo PaaS služby Application Services (Web App, API App, Azure Functions).
Podívejme se na důvody proč zvoli Azure Stack.
Smyslem Azure Stack je přinést konzistenci s Azure. Umožní vám to vyvíjet a nasazovat aplikace tak, že výsledný balíček (například ARM šablonu) můžete poslat jak do velkého Azure, tak do Azure Stack. Představme si třeba, že z důvodů uvedených výše musí moje produkční aplikace běžet lokálně. Konzistence mi přináší to, že pro její vývoj a testování mohu použít flexibilitu velkého Azure a přitom stejným způsobem provést deployment produkční verze do Azure Stack. Dá se na to koukat i opačně. Produkční verzi zákaznické aplikace chci používat v Azure z důvodu elasticity, obrovské škálovatelnosti a integraci dalších vlastností (třeba DDoS ochranu, identity apod.), ale mám volné CAPEX prostředky. Ty mohu využít k nákupu Azure Stack, vývoj provádět na něm a snížit tak OPEX náklady na vývoj.
Pokud jste dodavatelem řešení pro vaše zákazníky můžete svou aplikaci zabalit do ARM šablon a/nebo zprovoznit v Azure Application Services či Kubernetes. Díky konzistenci mohou vaši zákazníci sáhnout po nasazení ve velkém Azure nebo do svého Azure Stack, když potřebují vaše řešení lokálně nebo využít hostovaného Azure Stack, který jim nabídnete třeba vy ze svého datového centra. Ve všech případech máte konzistentní způsob nasazování a správy.
Jak dlouho vám trvá postavit cloud? Jak složité je sladit upgrady všech komponent tak, aby to i v průběhu času všechno hrálo dohromady? Jaké je riziko, že se to někde zadrhne, například vám výběrovky různých komponent vyjdou tak, že to dohrmady neštimuje? Pokud chcete cloud především používat, Azure Stack je ideální řešení. Objednáte si balíček obsahující všechny potřebné hardwarové a softwarové komponenty (servery, virtualizovanou storage, síťové prvky, hypervisor a veškerý potřebný software), který připravil Microsoft ve spolupráci s hardwarovým partnerem (například HPE, Dell EMC, Cisco, Huawei, Lenovo apod.). Přivezou vám bednu, provedou základní zapojení a už na vás svítí Azure portál. Veškeré updaty jsou na měsíční bázi a chodí v plně odladěných balíčcích, kdy jednoduše provedete upgrade jak driverů tak softwarové platformy. Život s Azure Stack je podstatně jednodušší, než se souborem nezávislých komponent.
Úžasnou vlastní Azure Stack je, že byl kladen extrémní důraz na bezpečnost. Když se podíváte jak to funguje, často zjistíte, že takhle bezpečně postavené řešení nemáte. Všechno je výborně promyšlené. Používá se konceptů nejnižšího možného oprávnění, takže nikde nikde nejsou všemocné účty (například Domain Admin pro doménový řadič, který je pod kapatou, vlastně neexistuje). Nemáte neomezený přístup do spodku a tím ani případný útočník, vaše oprávnění to neumožňují (při troubleshootingu umí Microsoft vygenerovat dočasný token pro hlubší přístup, ale s tím musíte vy a Microsoft explicitně souhlasit a je to časově omezené). A co když už se útočník nějak dostane dovnitř? I na to se myslí. Na nodech jsou whitelistované aplikace a procesy, všechno je digitálně podepsané, takže ani útočník nemůže spustit hackovací nástroje i kdyby se dovnitř nějak dostal.
Pokud chcete udělat privátní cloud bezpečně, Azure Stack takový je a je od začátku takto designovaný. Podívejte se na podrobnosti a když nic jiného, bude vás to inspirovat k tomu, jak přistupovat k bezpečnosti obecně.
Pojďme si také uvést situace, kdy Azure Stack není ideální volba. Důležité je zmínit, že ne všechno musí být řešeno stejně. Dává mi smysl používat Azure, nasadit Azure Stack pro speciální situace, pro IoT využít IoT Edge a pro klasické workloady, které nechcete přenést do Azure a potřebujete schopnost postavit si sami na svém železe, použijete klasické řešení. Taková kombinace je myslím naprosto běžná.
Azure Stack je doplněk k velkému Azure, nikoli jeho náhrada. Při přemýšlení bych doporučoval vždy velký Azure preferovat. Nabídne vám podstatně širší množství služeb zejména v PaaS oblasti a umožní vám tak rychleji vyvíjet a získat větší přidanou hodnotu. Pro použití Azure Stack bych měl mít skutečně zásadní důvod, například regulatorní.
I v oblasti IaaS nabízí Azure víc zejména díky pay-as-you-go modelu a široké nabídce stále se rozšiřujících typů strojů. Pokud uvažujete o novém prostředí pro své stávající aplikace, Azure je ideální místo. Díky Azure Migrate můžete svoje VM jednoduše přesunout a třeba takový SAP patří na specializované stroje v Azure, ne do Azure Stack. Použijte Azure Stack spíše pro moderní aplikace, které v nějaké své části z důvodů konektivity nebo compliance musí běžet lokálně.
Pokud chcete to nejnovější, bude to vždy Azure. Azure Stack, přestože nabízí konzistenci s Azure, bude vždy o něco pozadu. Tak například novější funkce VM jako je přímá integrace Security Center přímo v portálu, sériový port, nový průvodce při vytváření VM, Availability zóny, přímá integrace Azure Backup v portálu a tak podobně pro Azure Stack zatím nejsou. Stejné je to ve všech dalších oblastech - například Blob Storage v Azure dnes umí soft delete, immutable storage, tiering či geo-replikaci, což v Azure Stack zatím není. V okamžiku kdy se tohle v Azure Stack objeví, bude Azure už zase o kousek dál. Azure Stack má ambici držet s Azure krok, ale to neznamená, že funkce Azure nebudou v Azure Stack s určitým zpožděním.
Možná je vaším primárním záměrem IoT aplikace, která by přenesla některé funkce do lokálního zpracování. Co potřebujete je přenést část funkcí Azure jako je Machine Learning, Azure Functions nebo Stream Analytics blíže senzorům do IoT Edge zařízení, které bude malé ať už půjde o Raspberry nebo standardní Intelovské malé PC s Linux či Windows. Azure Stack je na tohle moc velký.
Azure IoT Edge vám umožní provozovat některé funkce Azure přímo na kraji v souvislosti s IoT. Nedává vám v tom zařízení Azure jako takový, jen některé jeho funkce řízené z cloudu. Nepřipojujete se na API lokálního zařízení. Azure Stack je lokální cloud. Má lokální API, které je konzistentní s Azure.
Pokud vám jde o to vybudovat si cloud, Azure Stack není pro vás. Ten je pro ty, co chtějí cloud rovnou používat, o jeho budování nestojí. Pokud jste fanoušky výběrovek na servery, storage, sítě, hypervisor, cloud software a baví vás si to všechno smotnovat a udržovat, Azure Stack není to pravé. Pokud potřebujete pod kapotu a ladit si velikosti jednotlivých mašin, hrát si s low-level nastavením a balancovat si zátěž s využíváním Live Migration, čili chcete řešit co je na jakém nodu, Azure Stack není pro vás. Pokud chcete místo L3 napojení sítě výsledného cloudu využívat segmentaci podle VLAN, řešit si SDN sami, Azure Stack není pro vás. A v neposlední řadě pokud chcete využít vámi definovaného hardware, například storage pole vašeho oblíbeného výrobce, do Azure Stack ji rozhodně nepřipojíte.
Pokud jsou vaše potřeby tyto, nabízí Microsoft ve Windows Server 2016 potřebné technické prostředky pro virtualizaci sítě (SDN), storage (S2D) i compute (Hyper-V) a nad tím můžete mít ovládací vrstvu System Center. Všechno si vybudujete sami, propojíte sami, nastavíte sami.
Dnes jsme probrali důvody pro nasazení Azure Stack a jeho základní výhody. V příštích článcích se podíváme jak je postavený, jak se ovládá, co konkrétně za služby nabízí a jak se s ním žije. Vraťte se pro další porci a vyzkoušíme si Azure Stack rozchodit v single-node testovací verzi s Azure Stack Development Kit.