Sdílet prostřednictvím

Upřesnění aplikační platformy pro zjednodušení vývoje aplikací a správy infrastruktury

  • Článek

Velkou součástí vylepšení postupů přípravy platformy vaší organizace je vyhodnocení aplikační platformy. Aplikační platforma zahrnuje všechny nástroje a služby používané k podpoře vývoje, nasazení a správy aplikací ve vaší organizaci.

Zjednodušení a standardizace

Infrastrukturu jako kód (IaC) a automatizační nástroje je možné kombinovat se šablonami pro standardizaci infrastruktury a nasazení aplikací. Aby se snížila zátěž specifik platforem pro koncového uživatele, abstrakce podrobností o platformě tím, že rozdělíte volby do relatovatelných zásad vytváření názvů, například:

  • Kategorie typů prostředků (vysoké výpočetní prostředky, vysoká paměť)
  • Kategorie velikosti prostředků (velikost trička, malá střední a velká)

Šablony by měly představovat obecné požadavky, které byly testovány s přednastavenými konfiguracemi, takže vývojové týmy můžou okamžitě začít s poskytováním minimálních parametrů a bez nutnosti kontrolovat možnosti. Existují však situace, kdy týmy potřebují změnit více možností u publikovaných šablon, než je k dispozici nebo žádoucí. Například schválený návrh může potřebovat konkrétní konfiguraci, která není součástí výchozích hodnot podporovaných šablon. V tomto případě můžou provozní týmy nebo technické týmy platformy vytvořit jednorázovou konfiguraci a pak rozhodnout, jestli šablona potřebuje tyto změny začlenit jako výchozí.

Pomocí nástrojů IaC můžete sledovat změny s funkcemi detekce odchylek, které můžou automaticky opravovat posun (GitOps). Mezi příklady těchto nástrojů patří Terraform a nativní cloudové nástroje IaC (příklady, rozhraní API clusteru, křížové roviny, operátor služby Azure v2). Mimo posun nástrojů IaC se zjistilo, že existují nástroje pro konfiguraci cloudu, které se můžou dotazovat na konfigurace prostředků, jako je Azure Resource Graph. Tyto výhody mohou sloužit jako dvě výhody; monitorujete změny mimo kód infrastruktury a kontrolujete změněné přednastavené konfigurace. Abyste se vyhnuli příliš pevnému, můžete v nasazeních implementovat tolerance i s předdefinovanými limity. Azure Policy můžete například použít k omezení počtu uzlů Kubernetes, které může mít nasazení.

Samoobslužně spravované nebo spravované?

Ve veřejných cloudech máte možnost využívat SaaS, PaaS nebo IaaS. Další informace o SaaS, PaaS a IaaS najdete v výukovém modulu Popis konceptů cloudu. Služby PaaS nabízejí zjednodušené vývojové prostředí, ale jejich modely aplikací jsou preskriptivnější. V konečném důsledku existuje kompromis mezi snadným používáním a kontrolou, kterou potřebujete vyhodnotit.

Během návrhu platformy vyhodnoťte a upřednostněte potřeby služeb vaší organizace. Například to, jestli vytváříte aplikace přímo ve službě Azure Kubernetes Service (AKS) nebo prostřednictvím služby Azure Container Apps (ACA), závisí na vašich požadavcích na službu a na vaší interní kapacitě a sadě dovedností. Totéž platí pro služby ve stylu funkcí, jako jsou Azure Functions nebo Aplikace Azure Service. ACA, Azure Functions a App Service snižují složitost, zatímco AKS poskytuje větší flexibilitu a kontrolu. Experimentální modely aplikací, jako je projekt osS Radius, se snaží zajistit rovnováhu mezi těmito dvěma modely, ale obecně se nacházejí v dřívějších fázích vyspělosti než cloudové služby s plnou podporou a přítomností v zavedených formátech IaC.

Problémy, které jste identifikovali při plánování, by vám měly pomoct vyhodnotit, který konec tohoto škálování je pro vás správný. Při rozhodování nezapomeňte určit vlastní interní sadu dovedností.

Sdílené a vyhrazené prostředky

Ve vaší organizaci existují prostředky, které můžou sdílet více aplikací, aby se zvýšilo využití a nákladová efektivita. Každá sdílená resourse má svou vlastní sadu aspektů. Jedná se například o důležité informace o sdílení clusterů K8s, ale některé se vztahují na jiné typy prostředků:

  • Organizace: Sdílení prostředků, jako jsou clustery, nikoli napříč hranicemi organizace, může zlepšit jejich soulad se směrem organizace, požadavky a prioritou.
  • Tenantská architektura aplikací: Aplikace můžou mít různé požadavky na izolaci tenantů. Potřebujete zkontrolovat individuální zabezpečení aplikací a dodržování právních předpisů, pokud můžou existovat společně s jinými aplikacemi. Například v Kubernetes můžou aplikace používat izolaci oboru názvů. Měli byste ale také zvážit tenanta aplikací pro různé typy prostředí. Často je například nejlepší vyhnout se kombinování testovacích aplikací s produkčními aplikacemi na stejných clusterech, aby nedocházelo k neočekávaným dopadům způsobeným chybnou konfigurací nebo problémy se zabezpečením. Nebo se můžete rozhodnout nejprve otestovat a ladit vyhrazené clustery Kubernetes, abyste mohli tyto problémy před nasazením ve sdíleném clusteru sledovat. Bez ohledu na to, že konzistencí ve vašem přístupu je klíčem k tomu, abyste se vyhnuli nejasnostem a chybám.
  • Spotřeba prostředků: Porozumíte využití prostředků aplikace, volné kapacitě a odhadněte, jestli je sdílení možné. Měli byste si také uvědomit limity spotřebovaných prostředků (limity kapacity datacentra nebo předplatného). Cílem je vyhnout se přesunu aplikace a závislostí kvůli omezením prostředků ve sdíleném prostředí nebo k incidentům živého webu při vyčerpání kapacity. Pomocí limitů prostředků, reprezentativního testování, monitorování upozorňování a generování sestav identifikujte spotřebu prostředků a chraňte před aplikacemi, které spotřebovávají příliš mnoho prostředků.
  • Optimalizace sdílených konfigurací: Sdílené prostředky, jako jsou sdílené clustery, vyžadují další aspekty a konfiguraci. Mezi tyto aspekty patří křížové účtování, přidělování prostředků, správa oprávnění, vlastnictví úloh, sdílení dat, koordinace upgradu, umístění úloh, vytvoření, správa a iterace základní konfigurace, správa kapacity a umístění úloh. Sdílené prostředky mají výhody, ale pokud jsou standardní konfigurace příliš omezující a nevyvíjí se, stanou se zastaralé.

Implementace strategií zásad správného řízení

Zásady správného řízení jsou klíčovou součástí povolení samoobslužných zábradlí, ale použití pravidel dodržování předpisů způsobem, který nemá vliv na obchodní hodnotu pro aplikace, je běžnou výzvou. Existují dvě části zásad správného řízení:

  • Dodržování předpisů při počátečním nasazení (začít vpravo): Toho je možné dosáhnout pomocí standardizovaných šablon IaC, které jsou zpřístupněny prostřednictvím katalogů, se správou oprávnění a zásadami, aby bylo zajištěno, že je možné nasadit pouze povolené prostředky a konfigurace.
  • Udržování dodržování předpisů (mějte pravdu): Nástroje založené na zásadách můžou zabránit nebo vás upozornit, když dojde ke změnám prostředků. Kromě základní infrastruktury zvažte také nástroje, které podporují dodržování předpisů v rámci prostředků, jako jsou K8s, spolu s operačním systémem používanými ve vašich kontejnerech nebo virtuálních počítačích. Můžete například chtít vynutit uzamčenou konfiguraci operačního systému nebo nainstalovat softwarové nástroje zabezpečení, jako jsou Zásady skupiny Windows, SELinux, AppArmor, Azure Policy nebo Kyverno. Pokud mají vývojáři přístup jenom k úložištím IaC, můžete přidat pracovní postupy schválení ke kontrole navrhovaných změn a zabránit přímému přístupu k rovinám řízení prostředků (například Azure).

Udržování dodržování předpisů vyžaduje nástroje pro přístup k problémům, vytváření sestav a reakce na problémy. Azure Policy je například možné použít s mnoha službami Azure pro auditování, vytváření sestav a nápravu. V závislosti na vašich potřebách má také různé režimy, jako je Audit, Deny a DeployIfNotExists.

I když zásady můžou vynutit dodržování předpisů, můžou také neočekávaně přerušit aplikace. Proto při provozu ve velkém zvažte vývoj zásad jako kódu (PaC). Jako klíčovou součást vašeho zahájení a udržování správného přístupu poskytuje PaC:

  • Centrálně spravované standardy
  • Správa verzí pro vaše zásady
  • Automatizované testování a ověřování
  • Kratší doba zavedení
  • Průběžné nasazování

PaC může pomoct minimalizovat poloměr výbuchu potenciálně špatných zásad s funkcemi, jako jsou:

  • Definice zásad uložené jako kód v úložišti, které se kontrolují a schvalují.
  • Automatizace pro zajištění testování a ověření
  • Postupné zavedení zásad a nápravy u stávajících prostředků pomáhá minimalizovat poloměr výbuchu potenciálně špatných zásad.
  • Úloha nápravy má integrovanou bezpečnost s ovládacími prvky, jako je zastavení úlohy nápravy, pokud selže více než 90 procent nasazení.

Implementace pozorovatelnosti a protokolování specifické pro konkrétní roli

K podpoře aplikací a infrastruktury potřebujete pozorovatelnost a protokolování v celém zásobníku.

Obrázek řídicího panelu Grafana znázorňující pozorovatelnost a protokolování

Požadavky se liší podle role. Například technický a provozní tým platformy vyžaduje řídicí panely ke kontrole stavu a kapacity infrastruktury s vhodnými výstrahami. Vývojáři vyžadují metriky aplikací, protokoly a trasování pro řešení potíží a přizpůsobené řídicí panely, které zobrazují stav aplikací a infrastruktury. Jedním z problémů některé z těchto rolí může být kognitivní přetížení z příliš velkého množství informací nebo mezer ve znalostech kvůli nedostatku užitečných informací.

Při řešení těchto problémů zvažte následující:

  • Standardy: Používejte standardy protokolování, abyste usnadnili vytváření a opakované používání standardizovaných řídicích panelů a zjednodušovali zpracování příjmu dat prostřednictvím architektury pozorovatelnosti OpenTelemetry.
  • Oprávnění: Poskytnutí týmových nebo aplikačních řídicích panelů pomocí něčeho, jako je Grafana , poskytuje souhrnná data pro každého, kdo má zájem, a také zařízení pro důvěryhodné členy aplikačních týmů, aby v případě potřeby bezpečně získal přístup k protokolům.
  • Uchovávání: Uchovávání protokolů a metrik může být nákladné a může vytvářet nezamýšlená rizika nebo porušení předpisů. Vytvořte výchozí hodnoty uchovávání informací a publikujte je jako součást vašich úvodních správných pokynů.
  • Monitorování limitů prostředků: Provozní týmy by měly být schopny identifikovat a sledovat všechna omezení pro daný typ prostředku. Tato omezení by se měla zohlednit v šablonách IaC nebo zásadách pomocí nástrojů, jako je Azure Policy. Operace by se pak měly proaktivně monitorovat pomocí řídicích panelů, jako je Grafana, a rozšířit sdílené prostředky, kde automatizované škálování není možné nebo povolené. Monitorujte například počet uzlů clusteru K8s pro kapacitu, protože jsou aplikace nasazené a upravené v průběhu času. Vyžaduje se upozorňování a tyto definice by se měly ukládat jako kód, aby se mohly programově přidávat do prostředků.
  • Identifikace klíčových metrik kapacity a stavu: Monitorování a upozorňování operačního systému a sdílených prostředků (příklady: procesor, paměť, úložiště) pro hladovění s využitím shromažďování metrik pomocí něčeho, jako je Prometheus nebo Azure Container Insights. Můžete monitorovat používané sokety nebo porty, spotřebu šířky pásma sítě chatty aplikací a počet stavových aplikací hostovaných v clusteru.

Sestavování v zabezpečení pomocí principu nejnižších oprávnění, jednotné správy zabezpečení a detekce hrozeb

Zabezpečení se vyžaduje v každé vrstvě od kódu, kontejneru, clusteru a cloudu nebo infrastruktury. Toto jsou minimální doporučené kroky zabezpečení:

  • Dodržujte zásadu nejnižších oprávnění.
  • Sjednocení správy zabezpečení DevOps napříč několika kanály
  • Zajistěte kontextové přehledy pro identifikaci a nápravu nejdůležitějších rizik.
  • Povolte detekci a reakci na moderní hrozby napříč cloudovými úlohami za běhu.

Pokud chcete pomoct s řešením problémů v této oblasti, potřebujete nástroje k vyhodnocení nástrojů, které fungují napříč systémy technických a aplikací, prostředky a službami napříč cloudy a hybridními službami (například Microsoft Defender for Cloud). Mimo zabezpečení aplikací vyhodnoťte:

Požadavky na oprávnění se můžou lišit podle prostředí. V některých organizacích například nemají jednotlivé týmy povolený přístup k produkčním prostředkům a nové aplikace se nemůžou automaticky nasazovat, dokud nebudou kontroly dokončeny. Automatizované nasazení prostředků a aplikací a přístup ke clusterům pro účely řešení potíží by ale mohly být povolené ve vývojových a testovacích prostředích.

Správa přístupu identit ke službám, aplikacím a infrastruktuře ve velkém může být náročná. Zprostředkovatelé identit pro vytváření, údržbu a správu informací o identitě. Váš plán by měl zahrnovat ověřovací služby pro aplikace a služby a které se dají integrovat se systémy řízení přístupu na základě role (RBAC) ve velkém měřítku. Pomocí ID Microsoft Entra můžete například poskytovat ověřování a autorizaci ve velkém měřítku pro služby Azure, jako je Azure Kubernetes Service, aniž byste museli nastavovat oprávnění přímo na každém jednotlivém clusteru.

Aplikace můžou potřebovat přístup k identitě pro přístup ke cloudovým prostředkům, jako je úložiště. Potřebujete zkontrolovat požadavky a posoudit, jak to může poskytovatel identity podporovat nejbezpečnějším způsobem. Například v rámci AKS můžou nativní cloudové aplikace využívat identitu úloh, která se federuje s ID Microsoft Entra, aby bylo možné ověřovat kontejnerizované úlohy. Tento přístup umožňuje aplikacím přistupovat ke cloudovým prostředkům bez výměn tajných kódů v kódu aplikace.

Snížení nákladů identifikací vlastníků úloh a sledováním prostředků

Správa nákladů je další součástí přípravy platforem. K správné správě aplikační platformy potřebujete způsob, jak identifikovat vlastníky úloh. Chcete získat inventář prostředků, které se mapují na vlastníky konkrétní sady metadat. V rámci Azure můžete například použít popisky AKS, značky Azure Resource Manageru a koncepty, jako jsou projekty v prostředích nasazení Azure, a seskupit prostředky na různých úrovních. Aby tato funkce fungovala, musí vybraná metadata při nasazování úloh a prostředků obsahovat povinné vlastnosti (například Azure Policy). To pomáhá s přidělováním nákladů, mapováním prostředků řešení a vlastníky. Zvažte spuštění pravidelného vytváření sestav pro sledování osamocených prostředků.

Kromě sledování možná budete muset přiřadit náklady jednotlivým aplikačním týmům pro využití prostředků pomocí stejných metadat se systémy správy nákladů, jako je Microsoft Cost Management. I když tato metoda sleduje prostředky zřízené týmy aplikací, nevztahuje se na náklady na sdílené prostředky, jako je poskytovatel identity, protokolování a úložiště metrik a spotřeba šířky pásma sítě. U sdílených prostředků můžete stejně dělit provozní náklady jednotlivými týmy nebo poskytovat vyhrazené systémy (například úložiště protokolování), kde je spotřeba neuniformní. Některé sdílené typy prostředků můžou poskytovat přehledy o spotřebě prostředků, například Kubernetes má nástroje, jako jsou OpenCost nebo Kubecost a můžou pomoct.

Měli byste také hledat nástroje pro analýzu nákladů, kde můžete zkontrolovat aktuální útratu. Například na webu Azure Portal existují upozornění na náklady a upozornění rozpočtů, která můžou sledovat spotřebu prostředků ve skupině a posílat oznámení, když dosáhnete přednastavených prahových hodnot.

Rozhodnutí o tom, kdy a kam investovat

Pokud máte více než jednu aplikační platformu, může být obtížné rozhodnout, kdy a kam investovat do vylepšení, která řeší problémy, jako jsou vysoké náklady nebo špatná pozorovatelnost. Pokud začínáte znovu, centrum architektury Azure má několik potenciálních vzorů, které můžete vyhodnotit. Kromě toho je zde několik otázek, které byste měli zvážit, když začnete plánovat, co chcete udělat:

Otázka Tipy
Chcete přizpůsobit stávající aplikační platformu, začít znovu používat nebo použít kombinaci těchto přístupů? I když jste spokojení s tím, co už máte nebo začínáte nové, chcete přemýšlet o tom, jak se v průběhu času přizpůsobit. Okamžité změny zřídka fungují. Vaše aplikační platformy jsou pohyblivým cílem. Váš ideální systém se mění podle času. Chcete tuto myšlenku zohlednit a všechny související plány migrace do vašeho průběžného návrhu.
Pokud chcete změnit, co dnes děláte, jaké produkty, služby nebo investice jste spokojení? Jak se říká, "pokud není nefunkční, neopravujte ho." Neměňte věci bez důvodu, abyste to udělali. Pokud ale máte nějaká domácí řešení, zvažte, jestli je čas přejít k existujícímu produktu, abyste ušetřili dlouhodobou údržbu. Pokud například provozujete vlastní řešení monitorování, chcete tuto zátěž z provozního týmu odebrat a migrovat na nový spravovaný produkt?
Kde vidíte většinu změn v průběhu času? Jsou některé z těchto oblastí společné pro všechny (nebo většinu) typů aplikací vaší organizace? Oblasti, se kterými vy nebo vaši interní zákazníci nejste spokojení, a často se nemění, jsou skvělým místem, kde začít. Jedná se o největší návratnost investic v dlouhodobém horizontu. To vám také pomůže vyžehlit, jak byste usnadnili migraci na nové řešení. Modely aplikací mají například tendenci být proměnlivé, ale nástroje pro analýzu protokolů mají tendenci mít delší dobu životnosti. Můžete se také zaměřit na nové projekty nebo aplikace, které se mají spustit, zatímco potvrdíte, že změna směru má požadované vrácení.
Investovali jste do vlastních řešení v oblastech s nejvyšší přidanou hodnotou? Cítíte se silně, že jedinečná funkce platformy infrastruktury aplikací je součástí vaší konkurenční výhody? Pokud jste identifikovali mezery, než začnete dělat něco vlastního, zvažte, které oblasti dodavatelé pravděpodobně investují, a zaměřte se na vlastní myšlení jinde. Začněte tím, že si začnete myslet jako integrátor, ne jako vlastní infrastrukturu aplikací nebo poskytovatele modelu aplikace. Cokoli, co sestavíte, bude nutné udržovat, které trpaslíky stojí v dlouhodobém horizontu. Pokud se domníváte, že je nutné vytvořit řešení v oblasti, na kterou se domníváte, budou dlouhodobě pokryti dodavateli, naplánujte ukončení nebo dlouhodobou podporu. Vaši interní zákazníci budou obvykle stejně šťastní (pokud ne více) s produktem mimo police jako vlastní.

Přizpůsobení stávajících investic do aplikační platformy může být dobrým způsobem, jak začít. Když provedete aktualizace, zvažte možnost začít s novými aplikacemi, aby se zjednodušily pilotní nápady před uvedením jakéhokoli druhu. Faktor v této změně prostřednictvím šablon IaC a aplikace. Investujte do vlastních řešení pro vaše jedinečné potřeby v oblastech s vysokým dopadem a vysokou hodnotou. V opačném případě zkuste použít off-the-police řešení. Stejně jako u technických systémů se zaměřte na automatizaci zřizování, sledování a nasazování, a ne na předpokladu, že byste museli předpokládat jednu pevnou cestu, která vám pomůže zvládnout změnu v průběhu času.

Související obsah

Návrh samoobslužného základu pro vývojáře