Co je nativní pro cloud?

Tip

Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.

Miniatura titulní miniatury nativních aplikací .NET pro Cloud Native pro Azure eBook

Zastavte, co děláte, a požádejte kolegy, aby definovali termín "Nativní pro cloud". Existuje dobrá šance, že dostanete několik různých odpovědí.

Začněme jednoduchou definicí:

Architektura a technologie nativní pro cloud představují přístup k návrhu, vytváření a provozování úloh, které jsou integrované v cloudu a plně využívají výhod modelu cloud computingu.

Základy cloud native computingu poskytují oficiální definici:

Technologie nativní pro cloud umožňují organizacím vytvářet a spouštět škálovatelné aplikace v moderních dynamických prostředích, jako jsou veřejné, privátní a hybridní cloudy. Kontejnery, sítě služeb, mikroslužby, neměnná infrastruktura a deklarativní rozhraní API tento přístup ilustrují.

Tyto techniky umožňují volně propojených systémů, které jsou odolné, spravovatelné a pozorovatelné. V kombinaci s robustní automatizací umožňují technikům provádět změny s vysokým dopadem často a předvídatelně s minimálním zatížením.

Nativní pro cloud se týká rychlosti a flexibility. Obchodní systémy se vyvíjejí od umožnění obchodních schopností na zbraně strategické transformace, které urychlují obchodní rychlost a růst. Je nezbytné okamžitě získat nové nápady na trh.

Ve stejnou dobu se obchodní systémy také stávají stále složitějšími s uživateli, kteří vyžadují více. Očekávají rychlou odezvu, inovativní funkce a nulový výpadek. Problémy s výkonem, opakované chyby a nemožnost rychlého pohybu už nejsou přijatelné. Vaši uživatelé navštíví vašeho konkurenta. Nativní cloudové systémy jsou navržené tak, aby přijímaly rychlé změny, velké rozsahy a odolnost.

Tady jsou některé společnosti, které implementovaly techniky nativní pro cloud. Zamyslete se nad rychlostí, flexibilitou a škálovatelností, které jste dosáhli.

Společnost Prostředí
Netflix Má 600 a více služeb v produkčním prostředí. Nasadí 100krát denně.
Uber Má 1 000 služeb v produkčním prostředí. Nasadí každý týden několik tisíckrát.
WeChat Má 3 000 služeb v produkčním prostředí. Nasadí 1 000krát denně.

Jak vidíte, Netflix, Uber a WeChat zpřístupňují cloudové nativní systémy, které se skládají z mnoha nezávislých služeb. Tento styl architektury jim umožňuje rychle reagovat na tržní podmínky. Okamžitě aktualizují malé oblasti živé, složité aplikace bez úplného nasazení. Podle potřeby individuálně škálují služby.

Pilíře nativního pro cloud

Rychlost a flexibilita nativního pro cloud vychází z mnoha faktorů. Především je cloudová infrastruktura. Existuje ale ještě více: Pět dalších základních pilířů zobrazených na obrázku 1–3 také poskytuje základ pro systémy nativní pro cloud.

Základní pilíře nativní pro cloud

Obrázek 1–3 Základní pilíře nativní pro cloud

Lépe porozumíte významu jednotlivých pilířů.

Cloud

Nativní cloudové systémy plně využívají model cloudové služby.

Tyto systémy jsou navržené tak, aby se v dynamickém virtualizovaném cloudovém prostředí využívaly rozsáhlou výpočetní infrastrukturu a spravované služby PaaS (Platform as a Service). Zachází se základní infrastrukturou jako s jednorázovou – zřízenou v minutách a změněnou velikostí, škálováním nebo zničením na vyžádání – prostřednictvím automatizace.

Vezměte v úvahu rozdíl mezi tím, jak zacházíme s domácími mazlíčky a komoditami. V tradičním datovém centru se servery považují za domácí zvířata: fyzický počítač, který má smysluplný název a který se o ně staral. Škálování můžete škálovat přidáním dalších prostředků do stejného počítače (vertikální navýšení kapacity). Pokud se server změní na nemoc, můžete ho sestřovat zpět do zdraví. Pokud bude server nedostupný, všichni si všimnou.

Model služeb komodit se liší. Každou instanci zřídíte jako virtuální počítač nebo kontejner. Jsou identické a mají přiřazený systémový identifikátor, například Service-01, Service-02 atd. Škálování provedete vytvořením dalších instancí (horizontální navýšení kapacity). Nikdo si nevšimne, když instance přestane být k dispozici.

Model komodit zahrnuje neměnnou infrastrukturu. Servery se neopravují ani nemění. Pokud jeden selže nebo vyžaduje aktualizaci, zničí se a zřídí se nový – vše probíhá prostřednictvím automatizace.

Systémy nativní pro cloud přijímají model komoditních služeb. Nadále běží jako infrastruktura se škáluje nebo snižuje bez ohledu na počítače, na kterých běží.

Cloudová platforma Azure podporuje tento typ vysoce elastické infrastruktury s automatickým škálováním, samoopravením a možnostmi monitorování.

Moderní design

Jak byste navrhli aplikaci nativní pro cloud? Jak by vaše architektura vypadala? Jaké principy, vzory a osvědčené postupy byste dodržovali? Jaké obavy týkající se infrastruktury a provozu by byly důležité?

Dvanáctifaktorová aplikace

Široce přijímaná metodologie pro vytváření cloudových aplikací je dvanáctifaktorová aplikace. Popisuje sadu principů a postupů, které vývojáři sledují při vytváření aplikací optimalizovaných pro moderní cloudová prostředí. Zvláštní pozornost je věnována přenositelnosti napříč prostředími a deklarativní automatizací.

I když se vztahuje na jakoukoli webovou aplikaci, mnoho odborníků považuje dvanáctfaktorový základ pro vytváření aplikací nativních pro cloud. Systémy založené na těchto principech můžou nasazovat a škálovat rychle a přidávat funkce pro rychlé reakce na změny na trhu.

V následující tabulce je zvýrazněná metodologie dvanáctifaktorového faktoru:

Faktor Vysvětlení
1. Základ kódu Jeden základ kódu pro každou mikroslužbu uložený ve vlastním úložišti. Sledováno pomocí správy verzí, může se nasadit do více prostředí (qa, staging, production).
2. Závislosti Každá mikroslužba izoluje a zabalí své vlastní závislosti a přijímá změny, aniž by to mělo vliv na celý systém.
3. Konfigurace Informace o konfiguraci se přesunou z mikroslužby a externalizují se prostřednictvím nástroje pro správu konfigurace mimo kód. Stejné nasazení se může rozšířit napříč prostředími se správnou použitou konfigurací.
4. Backing Services Pomocné prostředky (úložiště dat, mezipaměti, zprostředkovatelé zpráv) by měly být zpřístupněny prostřednictvím adresovatelné adresy URL. Tím se prostředek oddělí od aplikace, aby byl zaměnitelný.
5. Sestavení, vydání, spuštění Každá verze musí vynucovat striktní oddělení fází sestavení, vydané verze a spuštění. Každý z nich by měl být označen jedinečným ID a podporovat možnost vrácení zpět. Moderní systémy CI/CD pomáhají naplnit tento princip.
6. Procesy Každá mikroslužba by se měla spouštět ve vlastním procesu izolovaném od ostatních spuštěných služeb. Externalizace požadovaného stavu do backingové služby, jako je distribuovaná mezipaměť nebo úložiště dat.
7. Vazba portu Každá mikroslužba by měla být samostatná se svými rozhraními a funkcemi vystavenými na vlastním portu. Tím se zajistí izolace od jiných mikroslužeb.
8. Souběžnost Pokud je potřeba zvýšit kapacitu, horizontálně navyšte kapacitu služeb napříč několika identickými procesy (kopiemi) na rozdíl od vertikálního navýšení kapacity jedné velké instance na nejvýkonnější dostupném počítači. Vyvíjejte aplikaci tak, aby byla souběžná, aby bylo možné škálovat v cloudových prostředích bez problémů.
9 . Disposability Instance služeb by měly být uvolnitelné. Upřednostněte rychlé spuštění, abyste zvýšili možnosti škálovatelnosti a řádné vypnutí, aby systém opustil ve správném stavu. Kontejnery Dockeru spolu s orchestrátorem ze své podstaty splňují tento požadavek.
10 . Parita pro vývoj/vývoj Udržujte prostředí v životním cyklu aplikace co nejblíže, abyste se vyhnuli nákladným zkratkám. V této části může přijetí kontejnerů výrazně přispět zvýšením stejného spouštěcího prostředí.
11 . Protokolování Zacházejte s protokoly vygenerovanými mikroslužbami jako se streamy událostí. Zpracovat je pomocí agregátoru událostí. Rozšíří data protokolu do nástrojů pro správu dat, jako je Azure Monitor nebo Splunk, a nakonec do dlouhodobé archivace.
12– procesy Správa Spouštět úlohy správy/správy, jako je čištění dat nebo výpočetní analýza, jako jsou jednorázové procesy. K vyvolání těchto úloh z produkčního prostředí použijte nezávislé nástroje, ale odděleně od aplikace.

V knize, Beyond the Twelve-Factor App, autor Kevin Hoffman podrobně popisuje každý z původních 12 faktorů (napsaný v roce 2011). Kromě toho probírá tři další faktory, které odrážejí dnešní moderní návrh cloudových aplikací.

Nový faktor Vysvětlení
13. První rozhraní API Udělejte všechno jako službu. Předpokládejme, že váš kód bude využívat front-endový klient, brána nebo jiná služba.
14. Telemetrie Na pracovní stanici máte hluboký přehled o vaší aplikaci a jejím chování. V cloudu ne. Ujistěte se, že váš návrh zahrnuje kolekci dat monitorování, specifických pro doménu a stavu nebo systému.
15. Ověřování/ autorizace Implementujte identitu od začátku. Zvažte funkce RBAC (řízení přístupu na základě role) dostupné ve veřejných cloudech.

V této kapitole a v celé knize se podíváme na řadu dalších 12 faktorů.

Dobře navržená architektura Azure

Návrh a nasazení cloudových úloh může být náročné, zejména při implementaci architektury nativní pro cloud. Microsoft poskytuje standardní standardní osvědčené postupy, které vám a vašemu týmu pomůžou poskytovat robustní cloudová řešení.

Dobře navržená architektura Microsoftu poskytuje sadu hlavních principů, které je možné použít ke zlepšení kvality úloh nativních pro cloud. Skládá se z pěti pilířů kvalitní architektury:

Principy Popis
Správa nákladů Zaměřte se na včasné generování přírůstkové hodnoty. Využijte principy Build-Measure-Learn , které urychlují dobu uvedení na trh a zároveň se vyhýbají řešením náročným na kapitál. Pomocí strategie průběžných plateb investujte při horizontálním navýšení kapacity místo toho, abyste předem poskytovali velkou investici.
Provozní dokonalost Automatizujte prostředí a operace, abyste zvýšili rychlost a snížili lidské chyby. Vrácení aktualizací problémů zpět nebo dopředu Od začátku implementujte monitorování a diagnostiku.
Účinnost výkonu Efektivní splnění požadavků umístěných na vašich úlohách Upřednostněte horizontální škálování (horizontální navýšení kapacity) a navrhněte ho do svých systémů. Průběžné provádění výkonu a zátěžového testování za účelem identifikace potenciálních kritických bodů.
Spolehlivost Vytvářejte úlohy, které jsou odolné i dostupné. Odolnost umožňuje úlohám zotavit se ze selhání a pokračovat v fungování. Dostupnost zajišťuje uživatelům přístup k vaší úloze za všech okolností. Navrhněte aplikace tak, aby očekávaly selhání a zotavily se z nich.
Zabezpečení Implementujte zabezpečení v celém životním cyklu aplikace od návrhu a implementace až po nasazení a provoz. Věnujte pozornost správě identit, přístupu k infrastruktuře, zabezpečení aplikací a suverenitě dat a šifrování.

Microsoft nabízí sadu online posouzení , která vám pomůžou vyhodnotit aktuální cloudové úlohy s pěti dobře navrženými pilíři.

Mikroslužby

Systémy nativní pro cloud zahrnují mikroslužby, oblíbený styl architektury pro vytváření moderních aplikací.

Vytvořené jako distribuovaná sada malých nezávislých služeb, které komunikují prostřednictvím sdílených prostředků infrastruktury, mají mikroslužby následující charakteristiky:

  • Každá z nich implementuje konkrétní obchodní funkce v rámci většího kontextu domény.

  • Každý z nich se vyvíjí samostatně a dá se nasadit nezávisle.

  • Každá z nich je samostatná zapouzdření vlastní technologie úložiště dat, závislostí a programovací platformy.

  • Každá běží ve vlastním procesu a komunikuje s ostatními pomocí standardních komunikačních protokolů, jako jsou HTTP/HTTPS, gRPC, WebSockets nebo AMQP.

  • Společně vytvoří aplikaci.

Obrázek 1–4 kontrastuje monolitický přístup k aplikacím s přístupem mikroslužeb. Všimněte si, jak se monolit skládá z vrstvené architektury, která se provádí v jednom procesu. Obvykle využívá relační databázi. Přístup mikroslužeb ale odděluje funkce do nezávislých služeb, z nichž každá má vlastní logiku, stav a data. Každá mikroslužba hostuje vlastní úložiště dat.

Monolitické nasazení versus mikroslužby

Obrázek 1–4 Monolitická architektura a architektura mikroslužeb

Všimněte si, jak mikroslužby propagují princip Procesů z dvanáctifaktorové aplikace, která je popsána dříve v kapitole.

Faktor č. 6 určuje, že každá mikroslužba by se měla spouštět ve vlastním procesu izolovaném od ostatních spuštěných služeb.

Proč mikroslužby?

Mikroslužby poskytují flexibilitu.

Dříve v kapitole jsme porovnávali aplikaci elektronického obchodování sestavenou jako monolit s mikroslužbami. V tomto příkladu jsme viděli některé jasné výhody:

  • Každá mikroslužba má autonomní životní cyklus a může se vyvíjet nezávisle a často nasazovat. Nemusíte čekat na čtvrtletní vydání, abyste nasadili novou funkci nebo aktualizaci. Můžete aktualizovat malou oblast živé aplikace s menším rizikem narušení celého systému. Aktualizaci je možné provést bez úplného opětovného nasazení aplikace.

  • Každá mikroslužba se může škálovat nezávisle. Místo škálování celé aplikace jako jedné jednotky můžete škálovat pouze služby, které vyžadují větší výpočetní výkon, aby splňovaly požadované úrovně výkonu a smlouvy o úrovni služeb. Jemně odstupňované škálování poskytuje větší kontrolu nad systémem a pomáhá snižovat celkové náklady při škálování částí systému, ne všechno.

Vynikající referenční příručka pro pochopení mikroslužeb je mikroslužby .NET: Architektura pro kontejnerizované aplikace .NET. Tato kniha podrobně popisuje návrh a architekturu mikroslužeb. Je to doplněk pro referenční architekturu mikroslužeb s plnou sadou, která je k dispozici jako bezplatný soubor ke stažení od Microsoftu.

Vývoj mikroslužeb

Mikroslužby je možné vytvářet na jakékoli moderní vývojové platformě.

Platforma Microsoft .NET je skvělou volbou. Free a open source má mnoho integrovaných funkcí, které zjednodušují vývoj mikroslužeb. .NET je multiplatformní. Aplikace se dají sestavit a spouštět ve Windows, macOS a ve většině variant Linuxu.

Platforma .NET je vysoce výkonná a ve srovnání s Node.js a dalšími konkurenčními platformami získala dobré skóre. Společnost TechEmpower provedla rozsáhlou sadu srovnávacích testů výkonu v mnoha platformách a architekturách webových aplikací. .NET získalo skóre v prvních 10 - dobře nad Node.js a dalšími konkurenčními platformami.

.NET spravuje Microsoft a komunita .NET na GitHubu.

Problémy s mikroslužbami

I když distribuované mikroslužby nativní pro cloud můžou poskytovat obrovskou flexibilitu a rychlost, představují mnoho výzev:

Komunikace

Jak budou front-endové klientské aplikace komunikovat s mikroslužbami back-endového jádra? Povolíte přímou komunikaci? Nebo můžete back-endové mikroslužby abstrahovat s fasádou brány, která poskytuje flexibilitu, kontrolu a zabezpečení?

Jak vzájemně komunikují back-endové základní mikroslužby? Povolíte přímé volání HTTP, která můžou zvýšit párování a ovlivnit výkon a flexibilitu? Nebo můžete zvážit oddělení zasílání zpráv pomocí technologií front a témat?

Komunikace je popsána v kapitole o komunikačních vzorech nativních pro cloud.

Odolnost

Architektura mikroslužeb přesouvá váš systém z procesu na komunikaci mimo proces. Co se stane v distribuované architektuře, když služba B nereaguje na síťové volání ze služby A? Nebo co se stane, když služba C bude dočasně nedostupná a ostatní služby, které ji volají, se zablokují?

Odolnost je popsána v kapitole odolnosti nativní pro cloud.

Distribuovaná data

Každá mikroslužba záměrně zapouzdřuje svá vlastní data a vystavuje operace prostřednictvím svého veřejného rozhraní. Pokud ano, jak se dotazujete na data nebo implementujete transakci napříč více službami?

Distribuovaná data jsou popsána v kapitole o vzorech dat nativních pro cloud.

Tajné kódy

Jak budou mikroslužby bezpečně ukládat a spravovat tajné kódy a citlivá konfigurační data?

Tajné kódy jsou podrobně popsané v zabezpečení nativní pro cloud.

Správa složitosti pomocí Dapr

Dapr je distribuovaný opensourcový modul runtime aplikace. Díky architektuře připojitelných komponent výrazně zjednodušuje instalatérství za distribuovanými aplikacemi. Poskytuje dynamické připevnění , které váže vaši aplikaci s předem sestavenými funkcemi infrastruktury a komponentami z modulu runtime Dapr. Obrázek 1–5 ukazuje Dapr od 20 000 stop.

Dapr na 20 000 metrůObrázek 1–5 Dapr na 20 000 metrů.

V horním řádku obrázku si všimněte, jak Dapr poskytuje sady SDK specifické pro jazyk pro oblíbené vývojové platformy. Dapr v1 zahrnuje podporu pro .NET, Go, Node.js, Python, PHP, Java a JavaScript.

I když sady SDK specifické pro jazyk vylepšují prostředí pro vývojáře, dapr je nezávislá na platformě. Programovací model Dapr pod kapotou zpřístupňuje možnosti prostřednictvím standardních komunikačních protokolů HTTP/gRPC. Každá programovací platforma může volat Dapr prostřednictvím nativních rozhraní HTTP a gRPC API.

Modrá pole uprostřed obrázku představují stavební bloky Dapr. Každý z nich zveřejňuje předem sestavený instalatérní kód pro funkci distribuované aplikace, kterou může vaše aplikace využívat.

Řádek komponent představuje velkou sadu předdefinovaných komponent infrastruktury, které může vaše aplikace využívat. Komponenty si můžete představit jako kód infrastruktury, který nemusíte psát.

Dolní řádek zvýrazňuje přenositelnost Dapr a různorodá prostředí, ve kterých může běžet.

Dapr má při pohledu na vývoj aplikací nativních pro cloud velký dopad.

Kontejnery

Je přirozené slyšet kontejner termínu uvedený v jakékoli konverzaci nativní pro cloud. V knize, Cloud Native Patterns, autor Cornelia Davis zjistí, že "Containers are a great enabler of cloud-native software" (Kontejnery jsou skvělým povolením softwaru nativního pro cloud). Základy cloud native computingu umístí kontejnerizaci mikroslužeb jako první krok v mapě tras nativní pro cloud – pokyny pro podniky, které začínají svou cestu nativní pro cloud.

Kontejnerizace mikroslužby je jednoduchá a jednoduchá. Kód, jeho závislosti a modul runtime se zabalí do binárního souboru označovaného jako image kontejneru. Image se ukládají do registru kontejneru, který funguje jako úložiště nebo knihovna pro image. Registr se může nacházet ve vývojovém počítači, v datovém centru nebo ve veřejném cloudu. Samotný Docker udržuje veřejný registr prostřednictvím Docker Hubu. Cloud Azure nabízí privátní registr kontejnerů pro ukládání imagí kontejnerů blízko cloudových aplikací, které je budou spouštět.

Při spuštění nebo škálování aplikace transformujete image kontejneru na spuštěnou instanci kontejneru. Instance běží na libovolném počítači, na kterém je nainstalovaný modul runtime kontejneru. Podle potřeby můžete mít tolik instancí kontejnerizované služby.

Obrázek 1–6 ukazuje tři různé mikroslužby, z nichž každá je ve vlastním kontejneru, která běží na jednom hostiteli.

Několik kontejnerů spuštěných na hostiteli kontejneru

Obrázek 1–6 Několik kontejnerů spuštěných na hostiteli kontejneru

Všimněte si, že každý kontejner udržuje vlastní sadu závislostí a modulu runtime, které se můžou lišit od sebe. Zde vidíme různé verze mikroslužby produktu spuštěné na stejném hostiteli. Každý kontejner sdílí řez základního hostitelského operačního systému, paměti a procesoru, ale je izolovaný od sebe.

Všimněte si, jak dobře model kontejneru přijímá princip Závislosti z dvanáctifaktorové aplikace.

Faktor č. 2 určuje, že každá mikroslužba izoluje a zabalí své vlastní závislosti a přijímá změny bez dopadu na celý systém.

Kontejnery podporují úlohy Linuxu i Windows. Cloud Azure otevřený zahrnuje obojí. Zajímavé je, že se jedná o Linux, ne Windows Server, který se stal oblíbenějším operačním systémem v Azure.

I když existuje několik dodavatelů kontejnerů, Docker zachytil podíl lva na trhu. Společnost řídí přesun softwarových kontejnerů. Stal se de facto standardem pro balení, nasazování a spouštění aplikací nativních pro cloud.

Proč kontejnery?

Kontejnery poskytují přenositelnost a zaručují konzistenci napříč prostředími. Zapouzdřením všeho do jednoho balíčku izolujete mikroslužbu a její závislosti od základní infrastruktury.

Kontejner můžete nasadit v libovolném prostředí, které hostuje modul runtime Dockeru. Kontejnerizované úlohy také eliminují náklady na předkonfigurování jednotlivých prostředí pomocí architektur, softwarových knihoven a modulů runtime.

Sdílením základního operačního systému a hostitelských prostředků má kontejner mnohem menší nároky než celý virtuální počítač. Menší velikost zvyšuje hustotu nebo počet mikroslužeb, které může daný hostitel spustit najednou.

Orchestrace kontejnerů

I když nástroje, jako je Docker, vytvářejí image a spouštějí kontejnery, potřebujete také nástroje pro jejich správu. Správa kontejnerů se provádí pomocí speciálního softwarového programu označovaného jako orchestrátor kontejnerů. Při provozu ve velkém s mnoha nezávislými spuštěnými kontejnery je orchestrace nezbytná.

Obrázek 1–7 znázorňuje úlohy správy, které orchestrátory kontejnerů automatizují.

Co orchestrátory kontejnerů dělají

Obrázek 1–7 Co orchestrátory kontejnerů dělají

Následující tabulka popisuje běžné úlohy orchestrace.

Úlohy Vysvětlení
Plánování Automatické zřizování instancí kontejneru
Spřažení/spřažení Zřiďte kontejnery v blízkosti nebo daleko od sebe, což pomáhá s dostupností a výkonem.
Monitorování stavu Automaticky rozpozná a opraví chyby.
Převzetí služeb při selhání Automatické opětovné zřízení instance, která selhala, na počítač, který je v pořádku.
Škálování Automaticky přidejte nebo odeberte instanci kontejneru, aby splňovala poptávku.
Sítě Umožňuje spravovat překryvné sítě pro komunikaci kontejnerů.
Zjišťování služeb Povolte, aby se kontejnery vzájemně vyhlely.
Postupné upgrady Koordinujte přírůstkové upgrady s nasazením nulového výpadku. Automaticky vrátit problematické změny.

Všimněte si, jak orchestrátory kontejnerů přijímají principy disposability a souběžnosti z dvanáctifaktorové aplikace.

Faktor č. 9 určuje, že "Instance služeb by měly být uvolnitelné, což dává přednost rychlým spuštěním, aby se zvýšily možnosti škálovatelnosti a řádné vypnutí, aby systém opustil ve správném stavu". Kontejnery Dockeru spolu s orchestrátorem ze své podstaty splňují tento požadavek."

Faktor č. 8 určuje, že "Služby škálovat na více instancí napříč velkým počtem malých identických procesů (kopií) na rozdíl od vertikálního navýšení kapacity jedné velké instance na nejvýkonnější dostupný počítač."

Existuje několik orchestrátorů kontejnerů, ale Kubernetes se stal de facto standardem pro nativní cloud. Jedná se o přenosnou, rozšiřitelnou opensourcovou platformu pro správu kontejnerizovaných úloh.

Mohli byste hostovat vlastní instanci Kubernetes, ale pak byste byli zodpovědní za zřizování a správu jejích prostředků , což může být složité. Cloud Azure nabízí Kubernetes jako spravovanou službu. Azure Kubernetes Service (AKS) i Azure Red Hat OpenShift (ARO) umožňují plně využívat funkce a výkon Kubernetes jako spravovanou službu, aniž byste ji museli instalovat a udržovat.

Orchestrace kontejnerů se podrobně zabývá škálováním aplikací nativních pro cloud.

Backing services

Systémy nativní pro cloud závisí na mnoha různých pomocných prostředcích, jako jsou úložiště dat, zprostředkovatelé zpráv, monitorování a služby identit. Tyto služby se označují jako backingové služby.

Obrázek 1–8 ukazuje řadu běžných backingových služeb, které systémy nativní pro cloud využívají.

Běžné backingové služby

Obrázek 1–8 Běžné backingové služby

Mohli byste hostovat své vlastní backingové služby, ale pak byste byli zodpovědní za licencování, zřizování a správu těchto prostředků.

Poskytovatelé cloudu nabízejí bohatou škálu spravovaných backingových služeb. Místo toho, abyste službu vlastní, jednoduše ji spotřebovali. Poskytovatel cloudu provozuje prostředek ve velkém měřítku a nese odpovědnost za výkon, zabezpečení a údržbu. Monitorování, redundance a dostupnost jsou součástí služby. Poskytovatelé zaručují výkon na úrovni služeb a plně podporují své spravované služby – otevřete lístek a opraví váš problém.

Nativní cloudové systémy upřednostňují spravované backingové služby od dodavatelů cloudu. Úspory v čase a práci mohou být významné. Provozní riziko hostování vašeho vlastního a problém může být nákladný.

Osvědčeným postupem je zacházet se službou backing jako s připojeným prostředkem, dynamicky svázaný s mikroslužbou s konfiguračními informacemi (adresou URL a přihlašovacími údaji) uloženými v externí konfiguraci. Tyto pokyny jsou popsány v dvanáctifaktorové aplikaci, které jsou popsány dříve v kapitole.

Faktor č. 4 určuje, že backingové služby by měly být zpřístupněny prostřednictvím adresovatelné adresy URL. Tím se prostředek oddělí od aplikace, aby byl zaměnitelný."

Faktor č. 3 určuje, že informace o konfiguraci se přesunou z mikroslužby a externě prostřednictvím nástroje pro správu konfigurace mimo kód.

Pomocí tohoto vzoru je možné připojit a odpojit backingovou službu beze změn kódu. Mikroslužbu můžete zvýšit z kontroly kvality do přípravného prostředí. Aktualizujete konfiguraci mikroslužby tak, aby odkazovat na backingové služby v přípravné fázi a vložil nastavení do kontejneru prostřednictvím proměnné prostředí.

Dodavatelé cloudu poskytují rozhraní API, která vám umožní komunikovat se svými vlastními backingovými službami. Tyto knihovny zapouzdřují proprietární instalatérii a složitost. Komunikace přímo s těmito rozhraními API ale úzce propojte váš kód s konkrétní backingovou službou. Je to široce uznávaný postup izolace podrobností implementace rozhraní API dodavatele. Představte si zprostředkující vrstvu nebo zprostředkující rozhraní API, která v kódu služby zpřístupňuje obecné operace a zabalí kód dodavatele do něj. Tato volná spojka umožňuje prohodit jednu backingovou službu za jinou nebo přesunout kód do jiného cloudového prostředí, aniž byste museli provádět změny v kódu hlavní služby. Dapr, probíraný dříve, následuje tento model se sadou předem připravených stavebních bloků.

V konečném myšlení podporují backing služby také zásadu bezstavové z dvanáctifaktorové aplikace, která je popsána dříve v kapitole.

Faktor č. 6 určuje, že každá mikroslužba by se měla spouštět ve vlastním procesu izolovaně od ostatních spuštěných služeb. Externalizace požadovaného stavu do backingové služby, jako je distribuovaná mezipaměť nebo úložiště dat."

Služby zálohování jsou popsány ve vzorech dat nativních pro cloud a vzorech komunikace nativních pro cloud.

Automation

Jak jste viděli, systémy nativní pro cloud přijímají mikroslužby, kontejnery a moderní návrh systému, aby dosáhly rychlosti a flexibility. Ale to je jen část příběhu. Jak zřídíte cloudová prostředí, na kterých tyto systémy běží? Jak rychle nasazujete funkce a aktualizace aplikací? Jak zaokrouhlíte celý obrázek?

Zadejte široce uznávaný postup infrastruktury jako kódu nebo IaC.

S IaC automatizujete zřizování platforem a nasazování aplikací. V podstatě používáte postupy softwarového inženýrství, jako je testování a správa verzí, na vaše postupy DevOps. Vaše infrastruktura a nasazení jsou automatizované, konzistentní a opakovatelné.

Automatizace infrastruktury

Nástroje, jako je Azure Resource Manager, Azure Bicep, Terraform z HashiCorpu a Azure CLI, umožňují deklarativní skriptování požadované cloudové infrastruktury. Názvy prostředků, umístění, kapacity a tajné kódy jsou parametrizované a dynamické. Skript je verze a vrácený se změnami do správy zdrojového kódu jako artefakt projektu. Vyvoláte skript, který zřídí konzistentní a opakovatelnou infrastrukturu napříč systémovými prostředími, jako je kontrola kvality, příprava a produkce.

Pod kapucí je IaC idempotentní, což znamená, že můžete spustit stejný skript přes a přes bez vedlejších účinků. Pokud tým potřebuje provést změnu, upraví a znovu spustí skript. Ovlivněny jsou pouze aktualizované prostředky.

V článku Co je infrastruktura jako kód, autor Sam Guckenheimer popisuje, jak "Týmy, které implementují IaC, mohou rychle a ve velkém dodávat stabilní prostředí. Vyhýbají se ruční konfiguraci prostředí a vynucují konzistenci tím, že představují požadovaný stav jejich prostředí prostřednictvím kódu. Nasazení infrastruktury s využitím IaC jsou opakovatelná a zabraňují problémům za běhu způsobeným odchylkou od konfigurace nebo chybějícími závislostmi. Týmy DevOps mohou spolupracovat s jednotnou sadou postupů a nástrojů, které poskytují aplikace a jejich podpůrnou infrastrukturu rychle, spolehlivě a ve velkém měřítku.

Automatizace nasazení

Dvanáctifaktorová aplikace, probíraná dříve, volá samostatné kroky při transformaci dokončeného kódu do spuštěné aplikace.

Faktor č. 5 určuje, že každá vydaná verze musí vynucovat striktní oddělení ve fázích sestavení, vydávání a spouštění. Každý by měl být označen jedinečným ID a podporovat možnost vrácení zpět."

Moderní systémy CI/CD pomáhají naplnit tento princip. Poskytují samostatné kroky sestavení a doručování, které pomáhají zajistit konzistentní a kvalitní kód, který je uživatelům snadno dostupný.

Obrázek 1–9 znázorňuje oddělení procesu nasazení.

Kroky nasazení v kanálu CI/CD

Obrázek 1–9 Kroky nasazení v kanálu CI/CD

Na předchozím obrázku věnujte zvláštní pozornost oddělení úkolů:

  1. Vývojář vytvoří funkci ve svém vývojovém prostředí a iteruje to, čemu se říká vnitřní smyčka kódu, spuštění a ladění.
  2. Po dokončení se tento kód nasdílí do úložiště kódu, jako je GitHub, Azure DevOps nebo BitBucket.
  3. Nasdílení změn aktivuje fázi sestavení, která transformuje kód na binární artefakt. Práce se implementuje s kanálem kontinuální integrace (CI). Automaticky sestaví, testuje a zabalí aplikaci.
  4. Fáze vydání vybere binární artefakt, použije informace o konfiguraci externí aplikace a prostředí a vytvoří neměnnou verzi. Verze se nasadí do zadaného prostředí. Práce se implementuje s kanálem průběžného doručování (CD). Každá vydaná verze by měla být identifikovatelná. Můžete říct, že toto nasazení používá verzi 2.1.1 aplikace.
  5. Nakonec se vydaná funkce spustí v cílovém spouštěcím prostředí. Vydané verze jsou neměnné, což znamená, že jakákoli změna musí vytvořit novou verzi.

Při použití těchto postupů se organizace radikálně vyvinuly způsob dodávání softwaru. Řada z nich přešla z čtvrtletních verzí na aktualizace na vyžádání. Cílem je zachytit problémy v rané fázi vývojového cyklu, když jejich oprava je levnější. Čím delší je doba trvání mezi integracemi, tím dražší problémy se vyřeší. Díky konzistenci v procesu integrace můžou týmy provádět změny kódu častěji, což vede k lepší spolupráci a kvalitě softwaru.

Infrastruktura jako automatizace kódu a nasazení spolu s GitHubem a Azure DevOps jsou podrobně popsány v DevOps.