Co znamená cloud native?

Návod

Tento obsah je výňatek z elektronické knihy Architektura cloud-native .NET aplikací pro Azure, která je k dispozici na .NET Docs nebo jako bezplatné PDF ke stažení, které si můžete přečíst offline.

Stáhnout PDF

Přerušte svou práci a požádejte své kolegy, aby definovali termín "Cloud Native". 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í funkci 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.

Cloud-native se týká rychlosti a agility. 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	Zkušenost
Netflix	Má 600 a více služeb v produkčním prostředí. Systém se nasadí 100krát denně.
Uber	Má více než 1 000 služeb v produkčním prostředí. Nasazuje se několikrát tisíckrát každý týden.
WeChat	Má více než 3 000 služeb v produkčním prostředí. Distribuuje 1 000 krá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é části ž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 agilita cloud-native 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.

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

Vezměme si čas na lepší pochopení významu jednotlivých pilířů.

Oblak

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

Tyto systémy jsou navrženy tak, aby dobře fungovaly v dynamickém virtualizovaném cloudovém prostředí, a intenzivně využívají výpočetní infrastrukturu Platform as a Service (PaaS) a spravované služby. Zachází se základní infrastrukturou jako s dočasnou – nasazenou během minut, kterou lze dle potřeby změnit, škálovat nebo zničit – vše 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. Můžete zvětšit kapacitu přidáním dalších prostředků do stejného počítače (vertikální navýšení kapacity). Pokud server onemocní, pečujete o něj, abyste jej navrátili ke 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. Pokračují v provozu bez ohledu na to, na jakých počítačích běží, zatímco se infrastruktura flexibilně přizpůsobuje měnící se poptávce.

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é?

Aplikace Twelve-Factor

Široce přijímaná metodologie pro vytváření cloudových aplikací je Twelve-Factor 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í.

Ačkoli je použití možné pro jakoukoli webovou aplikaci, mnoho odborníků považuje Twelve-Factor za pevný základ pro vývoj cloudově natívních aplikací. 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.

Následující tabulka uvádí metodologii Twelve-Factor:

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 být nasazeno 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í zajistit striktní oddělení fází sestavení, vydání 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řednostňujte rychlé spuštění, abyste zvýšili možnosti škálovatelnosti, a zajistěte řádné ukončení, aby systém zůstával ve správném stavu. Kontejnery Dockeru spolu s orchestrátorem ze své podstaty splňují tento požadavek.
10 - Parita vývoj/provoz	Udržujte prostředí v životním cyklu aplikace co nejblíže, abyste se vyhnuli nákladným zkratkám. Zde může adopce kontejnerů výrazně přispět podporou stejného spouštěcího prostředí.
11 - Protokolování	Zacházejte s protokoly vygenerovanými mikroslužbami jako s událostními toky. Zpracovat je pomocí agregátoru událostí. Šíří protokolová data do nástrojů pro dolování dat/správu protokolů, jako je Azure Monitor nebo Splunk, a nakonec do dlouhodobé archivace.
12. Procesy správy	Spouštět administrativní nebo manažerské úlohy, jako je čištění dat nebo analytika, jako 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	Vše přetvořte na 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 to nepotřebujete. Ujistěte se, že váš návrh zahrnuje sběr monitorovacích, doménově specifických a zdravotních / systémových dat.
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ů.

Azure Well-Architected Framework (Azure Dobře Navržený Rámec)

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í.

Microsoft Well-Architected Framework poskytuje sadu hlavních principů, které lze použít ke zlepšení kvality úlohy nativní pro cloud. Rámec se skládá z pěti pilířů efektivity architektury:

Zásady	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ého platebního modelu investujte při rozšiřování 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ě splňte požadavky kladené na vaše pracovní úlohy. 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 pomohou při hodnocení aktuálních cloudových úloh podle pěti pilířů cloudové architektury.

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á a zapouzdřuje vlastní technologii úložiště dat, závislosti a programovací platformu.

• 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.

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

Všimněte si, jak mikroslužby propagují princip Procesy z aplikaceTwelve-Factor, 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 plně škálovatelnou referenční architekturu mikroslužeb, která je volně 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.

.NET je vysoce výkonný a ve srovnání s Node.js a dalšími konkurenčními platformami se dobře vyhodnotil. Společnost TechEmpower provedla rozsáhlou sadu srovnávacích testů výkonu v mnoha platformách a architekturách webových aplikací. .NET se umístilo mezi prvními 10 - výrazně 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 zabalit bránovou fasádou, 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á mohou zvýšit propojení a ovlivnit výkon a agilitu? 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 základní infrastrukturu distribuovaných aplikací. 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. 1–5 ukazuje Dapr z výšky 20 000 stop.

obrázek 1-5. Dapr ve výšce 6 096 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.

Při pohledu do budoucna má Dapr potenciál mít významný dopad na vývoj aplikací nativních pro cloud.

Kontejnery

Je přirozené slyšet, jak je termín kontejner zmíněn v každé diskusi o cloud-native technologiích. V knize Cloud Native Patterns autor Cornelia Davis pozoruje, že "Containers are a great enabler of cloud-native software" (Kontejnery jsou skvělým umožititelem cloud-native softwaru). Nadace Cloud Native Computing Foundation umístí kontejnerizaci mikroslužeb jako první krok v Trail MapCloud-Native – pokyny pro podniky, které začínají svou cloud-native cestu.

Kontejnerizace mikroslužby je jednoduchá a přímočará. Kód, jeho závislosti a modul runtime se zabalí do binárního souboru označovaného jako kontejnerový obraz. 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.

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 runtime, které se mohou mezi sebou lišit. 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ávislostí z aplikaceTwelve-Factor.

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. Azure cloud otevřeně přijímá 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 získal většinu trhu. Společnost vede hnutí 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 rozsahu 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í.

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

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

Úkoly	Vysvětlení
Plánování	Automatické zřizování instancí kontejneru
Afinitní/anti-afinitní	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řepnutí při selhání	Automatické opětovné přidělení instance, která selhala, na počítač, který je v dobrém stavu.
Stupňování	Automaticky přidejte nebo odeberte instanci kontejneru, aby splňovala poptávku.
Síťování	Umožňuje spravovat překryvné sítě pro komunikaci kontejnerů.
Zjišťování služeb	Umožněte kontejnerům navzájem se nalézt.
Postupné upgrady	Koordinujte postupné aktualizace s nasazením bez výpadků. Automaticky vrátit zpět problematické změny.

Všimněte si, jak orchestrátory kontejnerů přijímají principy disposability a souběžnosti z aplikaceTwelve-Factor.

Faktor č. 9 určuje, že "Instance služeb by měly být snadno uvolnitelné, což preferuje rychlá spuštění, aby se zvýšily možnosti škálovatelnosti a zajištění řádných vypnutí, které zanechají systém 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 se škálují napříč více instancemi velkého počtu malých identických procesů (kopií) na rozdíl od škálování nahoru jedné velké instance na nejvýkonnějším dostupném stroji."

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 Cloud-Native aplikací.

Podpůrné služby

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í.

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í úroveň výkonu služeb a plně podporují své spravované služby – vytvořte požadavek a oni váš problém opraví.

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 spojené s hostováním vlastních služeb může rychle vést k nákladným potížím.

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 aplikaciTwelve-Factor, která je popsána 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 jsou spravovány externě pomocí 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. Můžete přesunout mikroslužbu z testovacího prostředí do přípravného prostředí. Aktualizujete konfiguraci mikroslužby tak, aby odkazovala na podpůrné služby ve stávající fázi, a provedete vložení 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í infrastrukturu a složitost. Komunikace přímo s těmito rozhraními API ale úzce propojí váš kód s konkrétní podporující 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ů.

Na závěr podpůrné služby také podporují zásadu Bezstavovost z Twelve-Factor aplikace, jak bylo diskutováno 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 na podpůrné služby, jako je distribuovaný cache 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.

Automatizace

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?

Přichází široce uznávaný přístup infrastruktury jako kódu, neboli 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é informace jsou parametrizované a dynamické. Skript je verzovaný a commitovaný do správy zdrojového kódu jako součást 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 povrchem je IaC idempotentní, což znamená, že můžete opakovaně spouštět stejný skript 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 IaC se dají opakovat a brání problémům za běhu způsobeným posunem 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í

Aplikace Twelve-Factor, jak bylo diskutováno dříve, vyžaduje samostatné kroky při převodu dokončeného kódu na spuštěnou aplikaci.

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í.

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. Nahrání aktivuje build fázi, která transformuje kód na binární artefakt. Práce se implementuje s pipelinou 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 mezi integracemi, tím dražší je řešení problémů. 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.

předchozíDalší