Share via

Upřesnění aplikační platformy

  • Článek

Jakmile porozumíte problémům, které chcete řešit jako první na cestě k vytváření platforem, můžete zjistit, že budete muset řešit některé problémy s aplikační platformou. Tento článek obsahuje několik tipů, jak to udělat. Dozvíte se více o často zmeškaných nebo zapomenutých aspektech vytváření dobře navržené aplikační platformy. Konkrétně jde o správu infrastruktury, zabezpečení, správu nákladů, zásady správného řízení a pozorovatelnost.

Rozhodování o tom, kdy a kam investovat

Pokud dnes máte jednu nebo více aplikačních platforem, může být obtížné rozhodnout, kdy a kam investovat do vylepšení, která vyřeší problémy, které jste identifikovali. Pokud začínáte od začátku, má Centrum architektury Azure několik možných vzorů, které můžete vyhodnotit. Ale kromě toho je tady 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 nebo použít kombinaci těchto přístupů? I když jste spokojení s tím, co teď máte, nebo začínáte od začátku, budete chtít přemýšlet o tom, jak se přizpůsobit, abyste se mohli v průběhu času měnit. Bleskové řezání zřídka funguje. Bez ohledu na to, podobně jako technické systémy, jsou vaše aplikační platformy pohyblivým cílem. To, na co dnes přistanete, se bude měnit s postupem času. Toto myšlení a všechny související plány migrace budete chtít zahrnout do svého návrhu. Další informace o již pokryté infrastruktuře jako kódu (IaC) a přístupech k šablonám najdete v tématu Použití systémů softwarového inženýrství , které vám pomůžou spravovat některé z těchto variant pro nové aplikace.
Pokud chcete změnit to, co děláte dnes, s jakými produkty, službami nebo investicemi jste spokojení? Jak se říká: "Pokud není rozbitý, neopravujte to." Neměňte věci bez důvodu. 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 na dlouhodobé údržbě. Pokud například provozujete vlastní řešení monitorování, chcete tuto zátěž z provozního týmu odstranit a migrovat na nový spravovaný produkt?
Kde vidíte, že v průběhu času dochází k největším změnám? Jsou některé z těchto oblastí společné pro všechny (nebo většinu) typů aplikací vaší organizace? Oblasti, se kterými nejste vy nebo vaši interní zákazníci spokojeni a které se pravděpodobně nebudou často měnit, jsou skvělým místem, kde začít. Ty mají dlouhodobě největší návratnost investic. To vám také může pomoct zjistit, jak byste migraci na nové řešení usnadnili. Například modely aplikací bývají plynulé, ale nástroje pro analýzu protokolů mívají delší dobu použitelnosti. Můžete se také zaměřit na nové projekty nebo aplikace, které se spustí, zatímco potvrdíte, že změna směru má požadované výnosy.
Investujete do vlastních řešení v oblastech s nejvyšší přidanou hodnotou? Máte silný pocit, ž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, do kterých oblastí dodavatelé s největší pravděpodobností investují, a zaměřte své vlastní myšlení jinam. Začněte tím, že se budete považovat za integrátora, a ne jako vlastní infrastrukturu aplikací nebo poskytovatele modelů aplikací. Vše, co postavíte, bude muset být udržováno, které trpaslíky stojí na přední straně v dlouhodobém horizontu. Pokud máte pocit, že je naléhavě nutné vytvořit řešení na míru v oblasti, o které se domníváte, že se na ně dodavatelé budou dlouhodobě vztahovat, naplánujte ukončení platnosti nebo dlouhodobou podporu. Vaši interní zákazníci budou obvykle stejně spokojení (pokud ne více) s produktem, který je dostupný 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ž provádíte aktualizace, zvažte, že začnete s novými aplikacemi, abyste si před uvedením zjednodušili pilotní nápady. Zohlácte tuto změnu prostřednictvím IaC a šablon 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 alternativní ř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 jednu pevnou cestu, která vám pomůže spravovat změny v průběhu času.

Aspekty návrhu a architektury

I když existuje několik možných vzorů aplikační platformy, které můžete použít, tady jsou některé společné oblasti, které jsou kritické, ale často chybí při návrhu.

Správa infrastruktury

Jak je uvedeno v tématu Použití systémů softwarového inženýrství, nástroje pro IaC a automatizaci je možné kombinovat se šablonami pro standardizaci infrastruktury a nasazení aplikací. Pokud chcete snížit zatížení specifického prostředí platformy pro koncového uživatele, měli byste abstrahovat podrobnosti o platformě tím, že rozdělíte volby do relatable názvových konvencí, například:

  • Kategorie typů prostředků (vysoký výpočetní výkon, vysoké využití paměti)
  • Kategorie velikostí prostředků (velikost trička, malé střední a velké)

Cílem by mělo být mít šablony, které představují obecné požadavky, které byly testovány s přednastavenými konfiguracemi, aby vývojové týmy mohly okamžitě začít s poskytováním minimálních parametrů a bez nutnosti kontrolovat možnosti. Najdou se ale situace, kdy týmy budou muset u publikovaných šablon změnit více možností, než je k dispozici nebo žádoucí. Například schválený návrh může vyžadovat konkrétní konfiguraci, která je mimo podporované výchozí hodnoty šablony. V tomto případě můžou provozní týmy nebo týmy pro vytváření platforem vytvořit jednorázovou konfiguraci a pak rozhodnout, jestli šablona musí tyto změny začlenit jako výchozí.

Změny můžete sledovat pomocí nástrojů IaC s funkcemi detekce posunu, které můžou automaticky napravit posun (GitOps). Příklady těchto nástrojů jsou Terraform a nástroje IaC nativní pro cloud (příklady, rozhraní API pro cluster, crossplane, operátor služby Azure v2). Mimo detekci posunu nástrojů IaC existují cloudové konfigurační nástroje, které se můžou dotazovat na konfigurace prostředků, jako je Azure Resource Graph. Ty mohou sloužit jako dvě výhody; monitorujete změny mimo kód infrastruktury a zkontrolujete změněné přednastavené konfigurace. Abyste se vyhnuli příliš přísnému omezení, můžete v nasazeních implementovat tolerance také s předdefinovanými omezeními. Můžete například použít Azure Policy k omezení počtu uzlů Kubernetes, které může mít nasazení.

Samoobslužná nebo spravovaná?

Ve veřejných cloudech budete mít možnost využívat SaaS, PaaS nebo IaaS. Další informace o SaaS, PaaS a IaaS najdete v školicím modulu Popis konceptů cloudu. Služby PaaS nabízejí zjednodušené vývojové prostředí, ale jsou s modely aplikací 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 služby, které chcete nabízet nebo na které chcete přejít. To, jestli například vytváříte aplikace přímo na Azure Kubernetes Service (AKS) nebo prostřednictvím Azure Container Apps (ACA), závisí na vašich požadavcích na službu a na vaší interní kapacitě a dovednostech. Totéž platí pro služby ve stylu funkcí, jako jsou Azure Functions nebo Azure App 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 inkubace OSS Radius , se snaží zajistit rovnováhu mezi nimi, ale obecně jsou v dřívějších fázích vyspělosti než cloudové služby s plnou podporou a přítomností ve 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 měřítka je pro vás nejvhodnější. Při rozhodování nezapomeňte zohlednit své vlastní interní sady dovedností.

Sdílené vs. vyhrazené prostředky

V rámci vašeho majetku existuje mnoho prostředků, které může sdílet více aplikací, aby se zvýšilo využití a efektivita nákladů. Každý z prostředků, které je možné sdílet, má vlastní sadu aspektů. Jedná se například o aspekty sdílení clusterů K8s, ale některé se budou vztahovat na jiné typy prostředků:

  • Organizace: Sdílení prostředků, jako jsou clustery v rámci organizačních hranic, nikoli napříč, může zlepšit jejich soulad se směrem organizace, požadavky, prioritou atd.
  • Tenantská architektura aplikace: Aplikace mohou mít různé požadavky na izolaci tenantů; Pokud může existovat společně s jinými aplikacemi, budete muset zkontrolovat dodržování předpisů a zabezpečení jednotlivých aplikací. Například v Kubernetes můžou aplikace používat izolaci oboru názvů. Měli byste ale také zvážit tenanty aplikací pro různé typy prostředí. Často je například nejlepší vyhnout se kombinování testovacích aplikací s produkčními aplikacemi ve stejných clusterech, abyste se vyhnuli 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 vyladit vyhrazené clustery Kubernetes, abyste tyto problémy vystopili před nasazením do sdíleného clusteru. Bez ohledu na to je konzistence vašeho přístupu klíčem k tomu, abyste se vyhnuli nejasnostem a chybám.
  • Spotřeba prostředků: Seznamte se s využitím jednotlivých prostředků aplikace, volnou kapacitou a proveďte projekci, abyste odhadli, jestli je sdílení realizovatelné. Měli byste také vědět o omezeních 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 kvůli vyčerpání kapacity. Použití limitů prostředků, reprezentativního testování, monitorování výstrah a vytváření sestav může pomoct identifikovat spotřebu prostředků a chránit před aplikacemi, které spotřebovávají příliš mnoho prostředků, které můžou mít vliv na jiné aplikace.
  • Optimalizace sdílených konfigurací: Sdílené prostředky, jako jsou sdílené clustery, vyžadují další zvážení 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, zřízení, 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íjejí se, stanou se zastaralé.

Některé z těchto problémů jsou zjednodušeny řešeními PaaS, ale mnohé z těchto bodů se týkají i něčeho, jako je sdílení databáze. Sdílení má obě strany nahoru i dolů, a proto byste měli kompromisy pečlivě zvážit.

Další informace o aspektu clusteru Kubernetes v tomto článku najdete v dokumentaci k více tenantům Azure Kubernetes Service (AKS).

Správy

Zásady správného řízení jsou klíčovou součástí povolení samoobslužných služeb pomocí zábradlí, ale použití pravidel dodržování předpisů způsobem, který nemá vliv na obchodní hodnotu aplikací, je běžnou výzvou. Zásady správného řízení jsou široké téma, ale pokud se jedná o problém, na který narazíte, mějte na paměti oba aspekty tohoto prostoru:

  • Dodržování předpisů při počátečním nasazení (spustit vpravo): Toho lze dosáhnout pomocí standardizovaných šablon IaC, které jsou k dispozici prostřednictvím katalogů, se správou oprávnění a zásadami, které zajistí, aby bylo možné nasazovat pouze povolené prostředky a konfigurace.
  • Dodržování předpisů (zachovejte pravdu): Nástroje založené na zásadách vám 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ími systémy 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 Windows Zásady skupiny, 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í, které kontrolují navrhované změny a zabrání přímému přístupu k rovinám řízení prostředků (například Azure).

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

Zásady sice můžou vynucovat dodržování předpisů, ale můžou také neočekávaně porušit aplikace. Proto při použití ve velkém zvažte vývoj na praxi zásad jako kódu (PaC). Jako klíčovou součást vašeho počátečního a správného přístupu poskytuje PaC:

  • Centrálně spravované standardy
  • Správa verzí pro vaše zásady
  • Automatizované testování & ověřování
  • Zkrácení času na zavedení
  • Průběžné nasazování

PaC může pomoct minimalizovat poloměr výbuchu potenciálně chybných zásad pomocí funkcí, jako jsou:

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

Pozorovatelnost

Abyste mohli podporovat své aplikace a infrastrukturu, budete potřebovat pozorovatelnost a protokolování v celém zásobníku, který můžou technické, provozní a vývojářské týmy používat k tomu, aby viděly, co se děje.

Obrázek řídicího panelu Grafana

Požadavky se ale u jednotlivých rolí liší. Například technický a provozní tým platformy vyžaduje řídicí panely, které kontrolují stav a kapacitu infrastruktury s vhodnými upozorněními. 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ů s některou z těchto rolí může být přetížení kognitivních funkcí 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žití standardizovaných řídicích panelů a zjednodušovali zpracování příjmu dat prostřednictvím architektury pozorovatelnosti OpenTelemetry.
  • Oprávnění: Zvažte poskytnutí týmových řídicích panelů nebo řídicích panelů na úrovni aplikace, jako je Grafana , které poskytují souhrnná data pro všechny zájemce, a také zařízení pro důvěryhodné členy aplikačních týmů, které v případě potřeby bezpečně získají 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í dodržování předpisů. Nastavte výchozí hodnoty uchovávání informací a publikujte je jako součást úvodních pokynů.
  • Monitorování limitů prostředků: Provozní týmy by měly být schopné identifikovat a sledovat jakákoli omezení pro daný typ prostředku. Pokud je to možné, měla by se tato omezení zohlednit v šablonách nebo zásadách IaC pomocí nástrojů, jako je Azure Policy. Operace by pak měly proaktivně monitorovat pomocí řídicích panelů v něčem, jako je Grafana, a rozšířit sdílené prostředky tam, kde automatizované škálování není možné nebo povolené. Například monitorujte počet uzlů clusteru K8s z důvodu kapacity, jak se aplikace postupně připojují a upravují. Je potřeba upozorňovat a tyto definice by měly být uložené jako kód, aby je bylo možné 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 vyhladovění pomocí shromažďování metrik pomocí prometheus nebo Azure Container Insights. Můžete monitorovat používané sokety a porty, spotřebu šířky pásma sítě u chatty aplikací a počet stavových aplikací hostovaných v clusteru.

Zabezpečení

Zabezpečení se vyžaduje na každé vrstvě, od kódu, kontejneru, clusteru a cloudu nebo infrastruktury. Každá organizace má své vlastní požadavky na zabezpečení, ale na vysoké úrovni je potřeba pro vaši platformu zvážit tyto věci:

  • Dodržujte zásadu nejnižších oprávnění.
  • Sjednocte správu zabezpečení DevOps napříč několika kanály.
  • Ujistěte se, že jsou viditelné 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.

K řešení problémů v této oblasti budete potřebovat nástroje pro vyhodnocení nástrojů, které fungují napříč vašimi technickými a aplikačními systémy, prostředky a službami v cloudech a hybridních prostředích (například Microsoft Defender for Cloud). Kromě zabezpečení aplikací budete chtít vyhodnotit:

Požadavky na oprávnění se můžou v jednotlivých prostředích lišit. Například v některých organizacích nemají jednotlivé týmy povolený přístup k produkčním prostředkům a nové aplikace se nemůžou automaticky nasazovat, dokud se nedokončí kontroly. Ve vývojových a testovacích prostředích však může být povolené automatizované nasazení prostředků a aplikací a přístup ke clusterům pro účely řešení potíží.

Správa přístupu identit ke službám, aplikacím a infrastruktuře ve velkém může být náročná. Budete chtít zprostředkovatele identity vytvářet, udržovat a spravovat informace o identitě při poskytování ověřovacích služeb aplikacím a službám a které se můžou integrovat se systémy autorizace řízení přístupu na základě role pro správu ověřování a autorizace ve velkém měřítku (RBAC). Azure RBAC a Microsoft Entra ID můžete například použít k zajištění ověřování a autorizace ve velkém měřítku pro služby Azure, jako je Azure Kubernetes Service, aniž byste museli nastavovat oprávnění přímo v každém jednotlivém clusteru.

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

Správa nákladů & metadat

Náklady jsou dalším problémem, který může být pro vaše úsilí o vytváření platforem na vrcholu. Ke správné správě aplikační platformy potřebujete způsob, jak identifikovat vlastníky úloh. Budete potřebovat způsob, jak získat inventář prostředků, který se mapuje na vlastníky konkrétní sady metadat. V Rámci Azure můžete například použít popisky AKS, značky Azure Resource Manager spolu s koncepty, jako jsou projekty v prostředích nasazení Azure, a seskupit prostředky na různých úrovních. Aby to fungovalo, musí vybraná metadata při nasazování úloh a prostředků obsahovat povinné vlastnosti (používá se něco jako Azure Policy). To pomáhá s rozdělením nákladů, mapováním prostředků řešení, vlastníky atd. Zvažte spuštění pravidelného vytváření sestav ke sledování osamocených prostředků.

Kromě sledování může být potřeba přiřadit náklady jednotlivým aplikačním týmům na jejich 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é aplikačními týmy, nepokrývá náklady na sdílené prostředky, jako je poskytovatel identity, protokolování & úložiště metrik a využití šířky pásma sítě. U sdílených prostředků můžete rovnoměrně rozdělit provozní náklady podle jednotlivých týmů nebo poskytnout vyhrazené systémy (například úložiště protokolování), kde dochází k nerovnoměrné spotřebě. Některé typy sdílených prostředků můžou poskytovat přehled o spotřebě prostředků, například Kubernetes má nástroje, jako je OpenCost nebo Kubecost, a můžou vám pomoct.

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

Návrh vývojářské samoobslužné základny