Sdílet prostřednictvím

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

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 nástroje pro automatizaci je možné kombinovat se šablonami pro standardizaci infrastruktury a nasazení aplikací. Pokud chcete snížit zatížení specifik platforem pro koncového uživatele, můžete abstrahovat podrobnosti o platformě rozdělením možností 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ů (například velikost trička v malých, středních a velkých)

Š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ž jsou dostupné 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 musí 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). Příklady těchto nástrojů jsou Terraform a cloud-nativní IaC nástroje (například Cluster API, Crossplane, Azure Service Operator v2). Mimo detekci odchylek nástrojů IaC 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; sledovat změny mimo kód infrastruktury a kontrolovat změněné přednastavené konfigurace. Aby nedošlo k přílišné pevnosti, můžete v nasazeních implementovat tolerance s předem definovaný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 software jako službu (Saas), platformu jako službu (PaaS) nebo infrastrukturu jako službu (IaaS). Další informace o SaaS, PaaS a IaaS najdete v výukovém modulu Popis typů cloudových služeb. 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. Ať už například vytváříte aplikace přímo ve službě Azure Kubernetes Service (AKS) nebo prostřednictvím služby Azure Container Apps , 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 Azure App Service. Container Apps, Functions a App Service snižují složitost, zatímco AKS poskytuje větší flexibilitu a kontrolu. Experimentální modely aplikací, jako je projekt Radius OSS, usilují o zajištění rovnováhy mezi oběma koncepty, ale obecně se nacházejí v ranějších fázích vývoje než cloudové služby s plnou podporou a přítomností v zavedených formátech IaC.

Problémy, které jste identifikovali během 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ý prostředek má svou vlastní sadu aspektů. Jedná se například o aspekty sdílení clusterů Kubernetes, ale některé platí pro jiné typy prostředků:

  • Organizace: Sdílení prostředků, jako jsou clustery, uvnitř hranic organizace spíše než napříč nimi, může zlepšit jejich soulad se směrem organizace, požadavky a prioritou.
  • Tenantská architektura aplikace: Aplikace mohou mít různé požadavky na izolaci tenantů; Potřebujete zkontrolovat zabezpečení jednotlivých aplikací a dodržování právních předpisů, pokud může existovat společně s jinými aplikacemi. Například v Kubernetes mohou aplikace využít izolaci prostoru názvů. Měli byste ale také zvážit aplikačního tenanta 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 tyto problémy před nasazením do sdíleného clusteru mohli sledovat. Konzistence ve vašem přístupu je klíčem k tomu, abyste se vyhnuli nejasnostem a chybám.
  • Spotřeba prostředků: Seznamte se s využitím prostředků jednotlivých aplikací a volnou kapacitou 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í a předejít incidentům na živých stránkách při vyčerpání kapacity. Pomocí limitů prostředků, reprezentativního testování, upozorňování monitorování a generování sestav identifikujte spotřebu prostředků a chraňte se 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í

Řízení je klíčovou součástí umožnění samoobsluhy s mantinely, ale použití pravidel souladu způsobem, který neovlivní čas k dosažení obchodní hodnoty aplikací, je běžnou výzvou. Existují dvě části zásad správného řízení:

  • Počáteční dodržování předpisů pro nasazení (začít vpravo): Toho lze 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 se zajistilo, že je možné nasadit pouze povolené prostředky a konfigurace.
  • Udržování dodržování předpisů (zůstat v pořádku): 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 je Kubernetes, spolu s operačním systémem používaným 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ů, jako je Azure.

Udržování shody vyžaduje nástroje pro identifikaci, vykazování a řešení problémů. 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. Při provozu ve velkém proto zvažte přechod na praxi politika kódu (PaC). Jako klíčovou součást vašeho správného začátku a udržení na správné cestě poskytuje PaC:

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

PaC může pomoct minimalizovat rozsah dopadu nežádoucí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ěřování
  • Postupné zavádění zásad prostřednictvím fází a řešení u stávajících zdrojů pomáhá minimalizovat dopad potenciálně špatné zásady.
  • Nápravné opatření má zabudovanou bezpečnostní funkci s kontrolními mechanismy, jako je zastavení opatření, pokud selže více než 90 procent nasazení.

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

Abyste podpořili své aplikace a infrastrukturu, potřebujete pozorovatelnost a protokolování v celém stacku.

Snímek obrazovky řídicího panelu Grafana zobrazující pozorovatelnost a protokolování

Požadavky se liší podle role. Například technické týmy platformy a provozní týmy vyžadují ří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ů, se kterým může některá z těchto rolí narazit, je 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í:

  • Normy: Použijte standardy protokolování, abyste usnadnili vytváření a opakované použití standardizovaných řídicích panelů a zjednodušovali zpracování příjmu dat prostřednictvím architektury pozorovatelnosti OpenTelemetry.
  • Oprávnění: Poskytněte týmové řídicí panely nebo řídicí panely na úrovni aplikace pomocí něčeho, jako je Grafana, k poskytování souhrnných dat pro všechny, kteří mají zájem, a také nástroje, které umožní důvěryhodným členům aplikačních týmů bezpečně získat přístup k protokolům, pokud je potřeba.
  • Udržová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 Kubernetes z hlediska kapacity, jak jsou aplikace nasazovány a měněny 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ů (například procesoru, paměti a úložiště) pro hladovění s využitím shromažďování metrik pomocí něčeho, jako je monitorování Prometheus nebo Kubernetes ve službě Azure Monitor. 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.

Zabudování zabezpečení za použití zásady nejnižších oprávnění, uvednocené 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, aby byly viditelné kontextové přehledy pro identifikaci a řešení vašich 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 řešení potíží ale může 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 vytvářejí, udržují a spravují informace o identitě. Váš plán by měl zahrnovat ověřovací služby pro aplikace a služby a tato služba by se měla integrovat se systémy autorizace 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 služby Azure Kubernetes Service 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 způsob, jak získat inventář prostředků přiřazených k vlastníkům podle konkrétního souboru 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 rozdělováním nákladů, mapováním zdrojů řešení a vlastníky. Zvažte pravidelné spouštění generování zpráv pro sledování nepřiřazený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řehled o spotřebě prostředků. Kubernetes má například nástroje, jako je OpenCost nebo Kubecost, a může 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:

Question 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. Je třeba zohlednit tuto úvahu a jakékoliv související plány migrace ve vašem budoucím 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řešit, jak usnadnit 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 a aplikace, které je třeba spustit, zatímco přitom potvrzujete, že změna směru má požadované výnosy.
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 přizpůsobeného, zvažte, do kterých oblastí dodavatelé pravděpodobně investují, a zaměřte své úsilí jinam. Začněte tím, že si představujte sami sebe jako integrátora, a nikoli jako poskytovatele infrastruktury aplikací nebo poskytovatele modelu aplikace. Cokoli, co vytvoříte, je potřeba udržovat, což dlouhodobě převyšuje počáteční náklady. Pokud cítíte naléhavou potřebu vytvořit řešení v oblasti, o které máte podezření, že ji dlouhodobě pokryjí dodavatelé, naplánujte postupné 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šilo testování nápadů před zavedením jakéhokoli druhu. Zahrňte tuto změnu prostřednictvím IaC a šablonování aplikací. 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 standardní ř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

  • Last updated on