Technologie Azure pro proces sestavení

Dokončeno

V této lekci se seznámíte s vztahem mezi procesem inovací a některými technologiemi v odvětví, které vám můžou pomoct se sestavováním nových funkcí do aplikací.

DevOps

Po zahájení fáze sestavení pro ověření vaší inovační hypotézy by se požadované cykly vývoje, integrace a nasazení měly co nejvíce zjednodušit. V této fázi přichází DevOps. DevOps můžete definovat jako "procesy a nástroje pro rychlé a spolehlivé doručování softwarových funkcí". Tady jsou podrobnosti o této definici:

• Procesy a nástroje: DevOps a inovační proces jako celek vychází ze vzorů kultury, které podporují změnu. Azure a GitHub nabízejí skvělé nástroje pro DevOps, ale nákup licence nestačí. Vaše procesy a organizační kultura se musí vyvíjet tak, aby zahrnovaly změny a inovace.

• Rychlé doručování softwarových funkcí: Procesy a nástroje DevOps přijímají koncept selhání rychle. Vytvoření MVP nebo prototypů pro rychlé ověření, jestli funkce, na které pracujete, je základem konceptu DevOps.

• Spolehlivé doručování softwarových funkcí: Organizace pro změnu averze často přidružují rychlé změny k výpadkům. DevOps ale slibuje přesně opačnou: rychlost rychlé změny a vysokou úroveň spolehlivosti. Tato spolehlivost je možná integrací testování v počátečních fázích vývojového cyklu v procesu označovaného jako "posun doleva".

  Pokud se vývoj funkce v průběhu času považuje za čáru zleva doprava. Starší proces vývoje by pak na konci vývojového cyklu prováděl ověřování uživatelů a kontrolu kvality. Na pravé straně tohoto řádku. DevOps vám doporučí co nejdříve testovat a ověřit na levé straně tohoto časového řádku.

DevOps vtělí stejné základní koncepty zdravé inovační kultury. Přijetí metodologie je klíčem k přechodu na agilní inovační cyklus.

Architektury mikroslužeb

Modularita je dobře známá technika, která snižuje složitost při navrhování složitých systémů. Pokud je systém složitou interakcí mnoha částí, které nelze oddělit (často označované jako "monolit"), těsné vzájemné závislosti komponent ztěžují vylepšení systému. Všechny změny je potřeba ověřit ve zbytku systému, takže testovací proces je složitý.

Pokud je systém modulární, můžete ho rozdělit do menších subsystémů, které vzájemně komunikují prostřednictvím dobře definovaných rozhraní. Zavedení změn v jednom z těchto subsystémů je jednodušší, protože pokud jeho rozhraní s ostatními moduly zůstane konstantní, bude celkový systém dál fungovat.

Architektury mikroslužeb jsou vzory aplikací, které využívají modularitu. Aplikace jsou rozděleny do samostatných malých komponent, které lze vyvíjet nezávisle na sobě, potenciálně i pomocí různých programovacích jazyků. Každá komponenta nebo mikroslužba může fungovat samostatně. Můžete ho podle potřeby škálovat, můžete ho řešit potíže jako jednu jednotku. Můžete ho upravit nezávisle na ostatních mikroslužbách.

Otázkou, kterou organizace často ptají, je, co dělat, pokud je aplikace monolitická. Má organizace před zavedením inovací přepracovat aplikaci na architekturu mikroslužeb, nebo může procesy inovace a přepracovávat paralelně? Na tuto otázku neexistuje žádná odpověď. Závisí na složitosti a obchodní důležitosti aplikace, které je potřeba vzít v úvahu.

Společnost Tailwind Traders tuto otázku řešila při zavádění inovací na své platformě elektronického obchodování. Společnost se rozhodla zahájit projekt tak, aby přepracovala aplikaci elektronického obchodování na architekturu mikroslužeb, protože obchodní důležitost aplikace tuto snahu odůvodnila. Nemělo by modulární aplikaci vážně ovlivnit schopnost firmy Tailwind Traders reagovat na měnící se trendy na online trhu.

Společnost Tailwind Traders se však rozhodla řešit některé hlavní mezery ve své platformě současně. Čekání na dokončení projektu návrhu aplikace by znamenalo ztrátu významného podílu na trhu s novými startupy, které právě teď narušují trh elektronického obchodování.

Projekty se vzájemně spolupracují, a to na základě obchodní hodnoty inovací. Cílem návrhu je zaměřit se na nejdůležitější oblasti aplikace, kde je potřeba upravit prostředí zákazníků na nejvyšší úrovni.

Kontejnery

Technologie kontejnerizace není exkluzivní pro architektury mikroslužeb, ale koncepty spolupracují. Kontejnery představují způsob, jak zapouzdřovat kód aplikace a jeho závislosti, aby je bylo možné snadno nasadit na libovolné platformě.

Tradiční nasazení aplikací vyžadují, aby organizace nejdříve nainstalovala software, jako je modul runtime aplikace, programovací knihovny nebo externí komponenty. Tento přístup často vede k problému "funguje na mém počítači": je obtížné replikovat stejné prostředí napříč vývojem, testováním, přípravou a produkčním prostředím. Malé rozdíly ve způsobu instalace závislostí aplikace můžou způsobit, že aplikace bude při testování fungovat správně, ale při nasazení do produkčního prostředí selže.

Kontejnery mění pravidla hry. Závislosti aplikace jsou zabalené spolu s kódem aplikace v autonomní jednotce nasazení označované jako image kontejneru. Bez ohledu na to, jestli je kontejner aplikace nasazený na přenosném počítači vývojáře nebo v produkčním clusteru se stovkami uzlů, je zpracování závislostí stejné. Kontejner funguje úplně stejně, takže testování aplikací je spolehlivější a důvěryhodnější.

Kontejnery mají dlouhou cestu, protože Docker vydal svůj kód jako open source v roce 2013. Kontejnery teď podporují linuxové i windows a různé architektury procesoru. Azure nabízí řadu nabídek, které umožňují spouštění úloh založených na kontejnerech. V této lekci se seznámíte s některými z nich.

Kubernetes a Red Hat OpenShift

Modul runtime kontejneru je technologie, která spouští kontejnery v počítači, ale v produkčním prostředí se vyžaduje další logika. Kdo nasadí více kontejnerů, pokud se vyžaduje vyšší výkon? Kdo restartuje kontejnery, pokud mají problém? Pokud je k dispozici více počítačů, kdo se rozhodne, na kterém z nich má být spuštěn určitý kontejner? Za tyto a další úlohy zodpovídá platforma orchestrace kontejnerů.

První verze Kubernetes byla vydána v roce 2015 a brzy se stala standardem de facto pro orchestraci kontejnerů. Clustery Kubernetes se skládají z několika pracovních uzlů. Každý pracovní uzel má modul runtime kontejneru, takže může spouštět kontejnery, ve kterých řídicí rovina Kubernetes plánuje nasazení kontejnerizovaných aplikací. Tato řídicí rovina se obvykle spouští v sadě základních uzlů. Zodpovídá za správné fungování aplikace, vertikální navýšení nebo snížení kapacity aplikace a provádění všech požadovaných aktualizací.

Jedním z hlavních důvodů popularity Kubernetes je nezávislost hardwaru, kterou kontejnery poskytují. Vzhledem k tomu, že aplikace založené na kontejnerech je možné spolehlivě nasadit do libovolného modulu runtime kontejneru, můžete kubernetes spouštět v cloudech, které používají různé hypervisory. Nasazené aplikace by se měly chovat podobným způsobem (za předpokladu, že základní hardwarové prostředky jsou podobné). Mnoho organizací přijalo Kubernetes jako abstraktní vrstvu, která umožňuje konzistentní procesy nasazení aplikací jak místně, tak i ve veřejných cloudech.

Spouštění Kubernetes v Azure je snadné. Služba Azure Kubernetes Service je jednoduchá a nákladově efektivní, protože se zákazníkovi účtují jenom náklady na pracovní uzly. Microsoft nese náklady a provoz řídicí roviny, která obsahuje základní komponenty. Microsoft opravuje a aktualizuje operační systém pracovních uzlů a dále snižuje provozní složitost správy clusteru Kubernetes pro spouštění kontejnerů Linuxu a Windows.

OpenShift je platforma pro nasazení aplikací založená na Kubernetes, vyvinutou a podporovanou společností Red Hat. Zahrnuje mnoho dalších funkcí. Některé organizace, které se rozhodnou spouštět své aplikace na OpenShiftu, to dělají kvůli těmto dodatečným funkcím a podpoře, kterou Poskytuje Red Hat. Spuštění OpenShiftu v Azure je opět jednoduché. Azure Red Hat OpenShift se skládá z clusteru OpenShift, kde Microsoft spravuje řadu jeho aspektů, včetně celého životního cyklu clusteru.

Azure App Service

Aplikace Azure Service je platforma, kde mohou organizace spouštět své webové úlohy bez nutnosti spravovat jakýkoli orchestrátor nebo základní operační systém. Jediným požadavkem je nahrání kódu aplikace do služby prostřednictvím jedné z mnoha dostupných metod nasazení. Azure provádí zbytek: škálování a snížení kapacity aplikace, opravy a údržba základních virtuálních počítačů a mnoho dalšího, aniž by vyžadovalo křivku učení Kubernetes.

Aplikace Azure Service podporuje úlohy založené na kontejnerech, takže místo kódu aplikace můžete nahrát image kontejneru. Podporuje také úlohy Linuxu a Windows a mnoho různých modulů runtime aplikací.

Aplikace Azure Service podporuje různé cenové modely, včetně možnosti bez serveru.Azure Functions. Ve službě Azure Functions se účtují pouze využití aplikací. Neexistují žádné pevné náklady.

Bezserverový model je zajímavý pro inovace, protože umožňuje nasadit nové mikroslužby, aniž by se vám účtovaly vysoké měsíční faktury, pokud je trh nepřijímá. Tento model je dalším příkladem strategie rychlého selhání, kdy inovace nemusí nutně znamenat vysoké výdaje.

Aplikace Azure Service také nabízí funkce, které podporují nasazení zaměřená na DevOps, jako jsou sloty webových aplikací. Sloty jsou přípravné oblasti, kde můžete nasadit nové funkce, aniž by to mělo vliv na produkční prostředí. Sloty jsou skvělé z hlediska inovací, protože můžete přesměrovat malý výběr zákazníků na tuto novou verzi aplikace. Pak můžete ověřit, jestli je vaše inovační hypotéza správná. Nakonec, pokud chcete zvýšit úroveň nového kódu do produkčního prostředí, můžete sloty "prohodit", aby přípravné prostředí bylo produkční verzí.

Shrnutí

V této lekci jste se dozvěděli, jak technologie podporují inovace:

• Procesy a nástroje DevOps poskytují vašim vývoj a provozním týmům supermoc při rychlém a spolehlivém poskytování nových funkcí.
• Aplikace můžete změnit na mikroslužby, abyste umožnili inovace na jejich komponentách jednotlivě, aniž by to ovlivnilo zbytek.
• Kontejnery umožňují spolehlivé nasazení aplikací napříč několika platformami a prostředími.
• Kubernetes je cloudová platforma pro orchestraci pro spouštění kontejnerizovaných aplikací.
• Aplikace Azure Služba může spouštět webové úlohy s minimální režií na správu. Nabízí mnoho funkcí, jako jsou bezserverové sloty nebo sloty aplikací, které urychlují cyklus inovací.

Společnost Tailwind Traders se rozhodla zahájit návrh své aplikace elektronického obchodování na architekturu mikroslužeb. Prvním subsystémem aplikace, který odděluje od "monolitu", je platební služba, protože jste ji identifikovali jako kritickou oblast, kde konkurence zákazníkům nabízí lepší hodnotu.

Po subsystému plateb se více komponent aplikace převede na nezávislé mikroslužby. Mikroslužby můžou komunikovat prostřednictvím rozhraní REST API. Kód aplikace pro každou mikroslužbu se má kontejnerizovat a organizace pro vývoj a provoz využívají osvědčené postupy DevOps.

Vzhledem k tomu, že společnost Tailwind Traders nechce záviset na žádném konkrétním veřejném cloudu, rozhodli jste se vytvořit interní znalosti Kubernetes a nasadit aplikaci do clusterů Azure Kubernetes Service. Pokud je potřeba vyvíjet nové mikroslužby, společnost se rozhodla zvážit azure Functions jako platformu pro nasazení MVP, aby snížila náklady na vývoj.

Kam se podívat dál

Mnoho konceptů v této lekci je podrobněji vyjádřeno v článcích o architekturách přechodu na cloud, které umožňují přechod na digitální vynálezy a Kubernetes v rámci architektury přechodu na cloud.