Tento článek popisuje, jak tým společnosti Microsoft pro komerční softwarové inženýrství (CSE) ve spolupráci s globálním prodejcem nasadí vysoce dostupné bezserverové řešení napříč cloudovými platformami Azure a Amazon Web Services (AWS) pomocí architektury Bezserverové architektury.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Tok dat
- Uživatelská aplikace může pocházet z libovolného zdroje, který se může přihlásit do cloudu. V této implementaci se uživatel přihlásí k aplikaci brány, která vyrovnává zatížení požadavků 50–50 mezi cloudy Azure a AWS.
- Každá odpověď se také směruje přes bránu API Manageru, která ji pak odešle do aplikace žadatele.
Komponenty
Bezserverová architektura
Toto řešení používá bezserverovou architekturu, která je k dispozici od společnosti Serverless, Inc. Bezplatná verze bezserverové architektury zahrnuje rozhraní příkazového řádku, další moduly plug-in a omezené monitorovací služby. Edice Pro nabízí provozní možnosti napříč cloudy, jako je rozšířené monitorování a upozornění. Architektura podporuje jazyky Node.js a Python a hostitele cloudu AWS i Azure.
Pokud chcete používat Azure s bezserverovou architekturou, potřebujete:
- Node.js k balení mikroslužeb
- Azure Functions poskytovat funkce srovnatelné s jinými cloudovými platformami
- Bezserverová architektura pro podporu vícecloudového nasazení a monitorování
- Bezserverová multicloudová knihovna, která vývojářům poskytuje normalizovaná rozhraní API modulu runtime
- Azure Functions bezserverový modul plug-in pro podporu nasazení ve více cloudech. Tento modul plug-in nebyl zpočátku v souladu se srovnatelným modulem plug-in AWS Lambda a pro tento projekt byl rozšířen.
Následující obrázek znázorňuje kanál zpracování. Vrstvy middlewaru představují všechny přechodné funkce potřebné před dosažením obslužné rutiny.
Rozhraní API nezávislá na cloudu
Bezserverová implementace na každé platformě podporuje jednotlivé funkce jako mikroslužby, jednu pro každý funkční uzel virtuálního počítače, a podle potřeby provádí zpracování. Každá funkce AWS Lambda má odpovídající funkci Azure Functions. Bezserverová multicloudová knihovna vytváří podobné mikroslužby z obou cloudů do normalizovaného rozhraní REST API nezávislého na cloudu, které můžou klientské aplikace používat pro rozhraní s některou platformou. Vzhledem k tomu, že abstraktní vrstva rozhraní API poskytuje kód pro adresování odpovídajících mikroslužeb pro každou platformu, transakce nepotřebují překlad. Rozhraní nezávislé na cloudu umožňuje uživatelským aplikacím komunikovat s cloudem, aniž by věděly nebo se staraly o to, ke které cloudové platformě přistupují.
Tento koncept znázorňuje následující diagram:
CI/CD s Využitím GitOps
Primární úlohou bezserverové architektury je abstrakce všech aspektů infrastruktury nasazení aplikace do cloudu. Díky přístupu založenému na manifestu může bezserverová architektura řešit všechny problémy s nasazením a umožnit tak automatizaci nasazení podle potřeby, aby podporovalo GitOps.
I když tento počáteční projekt používal ruční nasazení, je reálné implementovat bezserverová sestavení, testy a nasazení v rámci cloudů nebo napříč cloudy. Tento proces může využívat pracovní postup pro vývojáře GitOps: sestavení z Gitu, použití bran kvality pro testování a hodnocení a nabízení bezserverových řešení oběma poskytovatelům cloudu. Provedení všech nasazení pomocí bezserverové architektury od začátku projektu je nejúčinnější způsob, jak pokračovat.
Správce rozhraní API
Api Manager může být existující nebo vlastní aplikace. Apigee API Manager v této implementaci™ fungoval pouze jako směrovač pro zajištění vyrovnávání zatížení 50 až 50 transakcí pro dvě cloudové platformy a byl pro své možnosti nedostatečně využitý.
Api Manager musí být schopný:
- Nasazení v rámci cloudové platformy nebo mimo cloudovou platformu podle potřeby
- Směrování zpráv do a z obou cloudových platforem
- Protokolování požadavků na provoz za účelem koordinace asynchronního provozu zpráv
- Přenos požadavků a odpovědí pomocí běžného rozhraní REST API z a do uživatelské aplikace
- Monitorujte stav obou cloudových nasazení bezserverové architektury a ověřte jejich schopnost přijímat požadavky.
- Provádění automatizovaných kontrol stavu a dostupnosti na každé cloudové platformě za účelem podpory směrování a vysoké dostupnosti
Alternativy
Řešení by mohly implementovat jiné jazyky, jako je Python, pokud je podporují bezserverové implementace cloudových platforem, AWS Lambda a v tomto případě Azure Functions. Tento projekt použil Node.js k zabalení mikroslužeb, protože zákazník byl obeznámen s Node.js a platformy AWS i Azure ho podporují.
Řešení může používat libovolnou cloudovou platformu, která podporuje bezserverovou architekturu, nejen Azure a AWS. Bezserverová architektura v současné době hlásí kompatibilitu s osmi různými poskytovateli cloudu. Jediným upozorněním je zajistit, aby prvky, které podporují architekturu s více cloudy nebo její ekvivalent, byly dostupné na cílových cloudových platformách.
Api Manager v této počáteční implementaci fungoval pouze jako směrovač, který poskytoval 50–50 transakčnímu zatížení pro dvě cloudové platformy. Api Manager může pro konkrétní scénáře zahrnovat jinou obchodní logiku.
Podrobnosti scénáře
V bezserverové architektuře poskytovatel cloudu dynamicky přiděluje prostředky mikroslužeb ke spouštění kódu a účtuje pouze poplatky za použité prostředky. Bezserverová architektura abstrahuje kód aplikace z implementace infrastruktury, nasazení kódu a provozních aspektů, jako je plánování a údržba.
Stejně jako u jiných služeb má každý poskytovatel cloudu vlastní bezserverovou implementaci a pro zákazníky je obtížné použít jiného poskytovatele bez značného provozního dopadu a nákladů. Potenciální zákazníci můžou tuto situaci považovat za oslabení jejich pozice vyjednávání a flexibilitu. Uzamčení dodavatele je jednou z největších překážek přechodu na podnikový cloud.
Opensourcová architektura Bezserverová architektura je univerzální cloudové rozhraní pro vývoj a nasazení bezserverových výpočetních řešení napříč poskytovateli cloudu. Open-sourcing a běžná rozhraní API pro bezserverové funkce pomáhají poskytovatelům, zákazníkům a partnerům vytvářet řešení napříč cloudy pro nejlepší služby. Bezserverová architektura snižuje překážky přechodu na cloud tím, že řeší problémy s redundancí dodavatelů a redundancí poskytovatelů napříč cloudy. Zákazníci můžou svá řešení optimalizovat na základě nákladů, flexibility a dalších aspektů.
CsE a produktový tým Azure společně přepsali bezserverové rozhraní příkazového řádku, aby podporovalo nové funkce Azure Functions, jako jsou Premium Functions, API Management a KeyVault. Bezserverové rozhraní příkazového řádku teď poskytuje standardní rozhraní pro nasazení GitOps do Azure i AWS. Tým také vyvinul bezserverovou multicloudovou knihovnu, která poskytuje normalizované rozhraní API modulu runtime pro nasazení bezserverových aplikací do AWS i Azure.
Tento návrh poskytuje vysokou dostupnost s převzetím služeb při selhání typu aktivní-aktivní mezi několika cloudovými platformami na rozdíl od převzetí služeb při selhání typu aktivní-pasivní . Pokud služba jednoho poskytovatele cloudu přestane být v pořádku nebo je nedostupná, může toto řešení požadavky směrovat na jinou cloudovou platformu.
Tento projekt splnil následující technické cíle:
- Vytvořte řešení pro různé obory.
- Pomocí bezserverové knihovny pro více cloudů můžete podporovat rozhraní API nezávislé na cloudu, které se připojuje k mikroslužbám bez ohledu na to, kde jsou nasazené.
- Podpora pracovního postupu procesu CI/CD GitOps pro vývoj, testování a nasazení na všech podporovaných cloudových platformách
- Použijte přístup založený na rozhraní API prostřednictvím ověřené cloudové brány a vyrovnávání zatížení mezi cloudovými platformami tím, že bránu použijete jako směrovač.
Mezi další potenciální výhody použití bezserverové architektury patří:
- Prevence nebo omezení uzamčení dodavatele
- 40–60+ % redukce kódu během vývoje pomocí bezserverové knihovny pro více cloudů
- Vývoj nejlepších řešení, která kombinují služby různých poskytovatelů cloudu
- Eliminace většiny složitosti platformy a infrastruktury a požadavků na údržbu
- Snadnější sdílení dat, porovnání výkonu a nákladů a možnost využívat speciální nabídky
- Vysoká dostupnost aktivní-aktivní
Potenciální případy použití
- Pište aplikace na straně klienta pro různé platformy pomocí rozhraní API nezávislého na cloudu z bezserverové multicloudové knihovny.
- Nasazení kolekce funkčních mikroslužeb v bezserverové architektuře na více cloudových platformách
- Používejte aplikaci nezávislou na cloudu napříč cloudovými platformami, aniž byste museli vědět, která platforma ji hostuje.
Požadavky
Tento článek nepopisuje řešení zabezpečení, i když je počáteční nasazení zahrnovalo. Existuje mnoho možných řešení zabezpečení, která jsou závislá na platformě, a tato architektura by měla pojmout jakékoli rozumné řešení. Ověřování uživatelů je minimální předpokládané zabezpečení.
Vzhledem k tomu, že je obtížné vyjádřit rozdíly mezi nabídkami funkcí AWS a Azure, v rané fázi by se mělo zaměřit na mapování funkcí dostupných na jednotlivých cloudových platformách a identifikaci nezbytných požadavků na transformaci. Z těchto informací můžete vyvinout rozhraní API nezávislé na platformě.
Použití opensourcového řešení může představovat rizika z důvodu problémů s dlouhodobou údržbou a podporou jakéhokoli opensourcového softwaru.
V bezplatné bezserverové architektuře je monitorování omezené především na řídicí panel pro správu. Monitorování je k dispozici v nabídce placeného podniku. Modul plug-in Azure Functions Serverless v současné době neobsahuje ustanovení pro pozorovatelnost nebo monitorování a k implementaci těchto funkcí by bylo potřeba upravit.
Toto řešení by mohlo použít metriky k porovnání výkonu a nákladů mezi cloudovými platformami a umožnit tak zákazníkům bezproblémovou optimalizaci využití napříč cloudovými platformami.
Nasazení tohoto scénáře
Tradiční modrozelené nasazení vyvíjí a nasazuje aplikaci do dvou oddělených, ale identických prostředí, modrého a zeleného, což zvyšuje dostupnost a snižuje riziko. Modré prostředí je obvykle produkční prostředí, které obvykle zpracovává živý provoz, a zelené prostředí je nasazení převzetí služeb při selhání podle potřeby. Kanál CI/CD obvykle v rámci stejné cloudové platformy automaticky nasadí modré i zelené prostředí. Tato konfigurace se považuje za aktivní-pasivní .
V multicloudovém řešení se modrozelené nasazení implementuje na obou cloudových platformách. V případě bez serveru jsou pro každou cloudovou platformu nasazeny dvě duplicitní sady mikroslužeb, jedna jako produkční prostředí a druhá jako prostředí převzetí služeb při selhání. Toto nastavení typu aktivní-pasivní v rámci každé cloudové platformy snižuje riziko, že tato platforma bude mimo provoz, zvyšuje její dostupnost a umožňuje vysokou dostupnost aktivní-aktivní ve více cloudech.
Sekundární výhodou modrozeleného nasazení je možnost použít nasazení převzetí služeb při selhání na každé cloudové platformě jako testovací prostředí pro aktualizace mikroslužeb před jejich uvolněním do produkčního nasazení.
Další kroky
- Ukázkový kód a soubor README pro tuto implementaci na GitHubu
- Bezserverová architektura
- Školení: Úvod do Azure Functions
- Přehled Azure Functions