Plánování moderních aplikačních platforem

  • Článek

Metodika plánování Cloud Adoption Framework pomáhá vytvořit celkový plán přechodu na cloud, který bude řídit programy a týmy zapojené do cloudové digitální transformace. Tyto doprovodné materiály poskytují šablony pro vytváření backlogu a plány pro budování potřebných dovedností napříč vašimi týmy, a to vše na základě toho, co se v cloudu pokoušíte dělat.

Použití metodiky plánování se zaměřuje na pět zásad racionalizace digitálních aktiv. Nejběžnější cesta ke cloudu se zaměřuje na rychlost, efektivitu a opakovatelnost procesů migrace a modernizace. Od pěti zásad plánování obvykle upřednostňuje možnosti změn hostitele s omezenou paralelní podporou pro možnosti změna architektury a opětovného sestavení.

Digitální aktiva

Při plánování digitálních aktiv budete chtít shromáždit data inventáře a racionalizovat vaše aktiva. V plánu přechodu na kontejnery je důležité, aby všechny prostředky, například virtuální počítače, data a aplikace, byly seskupené podle úloh, které podporují. Po dokončení seskupování a základní racionalizace můžete vyhodnotit tyto úlohy a určit možnosti balíčku a změnit hostitele nebo změnit architekturu.

Šablona standardního plánu přechodu na cloud představuje typy práce vyžadované v typickém úsilí o přechod na cloud. Do plánu ale budete muset přidat úlohy pro zabalení úlohy do kontejnerů a orchestraci zřizování kontejnerů.

Upozornění

V tomto článku se předpokládá, že čtenář již používá osvědčené postupy uvedené v sérii článků o vytváření plánu přechodu na cloud v Azure DevOps. Pokud svůj plán přechodu na cloud sledujete v tabulkovém kalkulátoru nebo jiných nástrojích pro sledování projektů, platí i nadále následující části, ale kroky přidání dat do plánu je potřeba upravit.

Upozornění

Začlenění moderní strategie aplikační platformy do standardních procesů migrace (nebo migrační továrny) bude vyžadovat vyspělou implementaci úloh spojených s návrhem architektur úloh před migrací. Pokračování v této strategii bez těchto úloh zpozdí migraci a může vést k špatným rozhodnutím o architektuře nasazených hostitelů kontejnerů a podpůrných úloh.

Identifikace kandidátských úloh

Ve scénáři moderní aplikační platformy mají dlouhodobější výnosy, které vyžadují vyšší počáteční investice, přednost před efektivnějšími procesy migrace. Dlouhodobé investice jsou v konkrétních částech plánu vyjádřeny jako větší zaměření na umožnění inovací a zefektivnění operací pro konkrétní skupiny úloh.

Pokud chcete začít sladit strategii a plán, identifikujte všechny úlohy, které budou pravděpodobně ovlivněny přidáním moderních aplikačních platforem ve vaší strategii přechodu na cloud. Tyto předpoklady budou ověřeny před implementací jakýchkoli technických změn. Pokud chcete pomoct s identifikací potenciálních kandidátů, vyhledejte v rámci svého portfolia úloh následující kritéria:

  • Investice do aktivního vývoje nebo DevOps: Procento produkčních úloh bude ve fázi aktivního vývoje. Některé můžou být dokonce spravovány prostřednictvím průběžných postupů DevOps.
  • Přenositelnost úloh: Některé úlohy jsou ovlivněné dodržováním předpisů, ochranou dat nebo provozními omezeními, která mohou vyžadovat přenositelnost mezi privátním cloudem, hraničními zařízeními nebo dokonce několika poskytovateli veřejného cloudu.
  • Konsolidace úloh: Řada úloh (zejména úloh s nízkým využitím) může být kandidáty na konsolidaci hostitelů kontejnerů, což vede k několika serverům a virtuálním počítačům a snížení provozních nákladů.
  • Starší úlohy: Starší úlohy můžou blokovat aktualizace operačních systémů a dokonce zabránit migraci do cloudu. Starší úlohy, které nejsou kompatibilní s funkcemi Azure, můžou být kandidátem na migraci na hostitele kontejneru.

Zdokumentovat kandidátské úlohy

Poznámka

Následující seznam aspektů by měl být zdokumentován pouze pro kandidáty na migraci určené podle výše uvedených kritérií.

Při vytváření plánu přechodu na cloud se jednotlivé úlohy zdokumentují podle pokynů v tématu Definování a stanovení priority úloh. Všechny úlohy, které jsou kandidáty na scénář moderní aplikační platformy, budou vyžadovat další informace, které vám pomůžou s prováděním plánu. Tento článek zdůrazňuje důležitost dokumentování obchodních a technických vstupů k definování úlohy. Pro kandidáty na moderní aplikační platformu by se do definice úlohy měly přidat následující datové body.

Obchodní vstupy

Níže jsou uvedené datové body související s podnikáním, které můžou ovlivnit rozhodnutí zahrnout úlohu do strategie moderní aplikační platformy.

  • Obchodní faktory dodržování předpisů: Jaká konkrétní kritéria dodržování předpisů jsou hnacím motorem pro hostování této úlohy v privátním cloudu?
  • Ovladače ochrany dat: Jaká opatření na ochranu dat jsou důvodem pro hostování této úlohy v privátním cloudu?
  • Provozní omezení: Jaká provozní omezení jsou důvodem pro hostování této úlohy v privátním cloudu?
  • Výsledky moderní aplikační platformy: Který z následujících faktorů stojí za vyhodnocením této úlohy jako kandidáta kontejneru? DevOps, přenositelnost, konsolidace, starší verze nebo více těchto ovladačů.
  • Provozní model: Bude se tato úloha spravovat centrálně (centrálním oddělením IT/CCoE), de centralálně (týmem úloh) nebo podnikovým provozem (centrální podpora a provoz specifický pro úlohy)?

Technické vstupy

Následují datové body od technologických týmů, které můžou ovlivnit rozhodnutí o zahrnutí úlohy do strategie moderní aplikační platformy.

Důležité informace o umístění:

Důležité informace týkající se místa, kde bude úloha hostovaná.

  • Požadavek na hostování veřejného cloudu: Souvisí s požadavkem na veřejný cloud konkrétní technické omezení?
  • Požadavek na hostování privátního cloudu: Souvisí s požadavkem na privátní cloud určité technické omezení?
  • Požadavek na hostování Edge: Souvisí s požadavkem na hraniční zařízení nějaké konkrétní technické omezení?
  • Požadavek na přenositelnost: Souvisí s požadavkem na přenositelnost cloudu konkrétní technické omezení?

Důležité informace o provozu:

Důležité informace týkající se provozu platformy, hostitelů a úloh

  • Primární cloudová platforma: Organizace by měly definovat primární cloudovou platformu, která bude poskytovat nástroje pro správu provozu. Některé organizace můžou mít více než jednu primární cloudovou platformu pro správu různých typů operací. Jaká je primární cloudová platforma pro provoz této úlohy?
  • Další provozní platformy: Budou tuto úlohu spravovat také nějaké další provozní platformy?
  • Požadavky na hostování cloudu: Vyžaduje tato úloha konkrétní strategii hostování v cloudu? Veřejný cloud, privátní cloud nebo přenositelnost cloudu
  • Standardizovaná orchestrační platforma: Pokud má společnost standardní řešení pro orchestraci kontejnerů, uveďte název standardizované platformy, která se má zvážit. Příklady: Azure Kubernetes Service (AKS), modul AKS nebo Kubernetes.
  • Aspekty vlastní orchestrace: Existuje požadavek na nestandardní platformu pro orchestraci kontejnerů? Pokud ano, vysvětlete tento požadavek.
  • Standardizované hostitelské operace: Předpokládá se, že úlohy nejsou nepřátelské a můžou být hostované ve sdílených kontejnerech podporovaných standardizovanými hostitelskými operacemi. Je tato úloha kompatibilní s tímto přístupem?
  • Důležité informace o přizpůsobených operacích hostitele: Pokud úloha není kompatibilní se standardizovanými operacemi, jaké konkrétní požadavky byste měli vzít v úvahu při vytváření postupů hostitelských operací pro tuto úlohu?

Důležité informace o aplikaci:

Aspekty specifické pro vývoj a vývoj aplikace v budoucnu.

  • Modul runtime Platformy jako služby (PaaS): Poskytovatelé veřejných cloudů vytvářejí konzistentní moduly runtime aplikací, často označované jako nabídky platforma jako služba (PaaS). Moduly runtime PaaS poskytované Azure App Service v Azure. Mohla by tato aplikace fungovat v modulu runtime PaaS? Který modul runtime je nejkomppatibilnější?
  • Standardizovaný modul runtime: Pokud aplikace není kompatibilní s modulem runtime PaaS, poskytuje organizace standardizovaný modul runtime? Na jakém modulu runtime bude tato úloha postavena?
  • Aspekty vlastního modulu runtime: Jaké konkrétní aspekty by vyžadovaly přizpůsobený modul runtime pro tuto úlohu?
  • Omezení modulu runtime: Vynucuje vybraný modul runtime aplikaci nějaká omezení?
  • Závislosti aplikací: Závisí tato úloha na existujících systémech, které se nacházejí v určitém umístění (například ve veřejném nebo privátním)? Příkladem může být systém ERP, jako je SAP spuštěný v konkrétním řešení.
  • Závažnost dat: Závisí tato úloha na zdroji dat, který se nachází v určitém umístění (například ve veřejném nebo privátním)? Mezi příklady patří závislost na datech v SAP nebo jiných centralizovaných zdrojích dat.
  • Aspekty seznamu schválených položek: Jsou aspekty vlastního provozu schválené pro použití v rámci vaší cloudové platformy? Které schválené služby musí být součástí nasazení?

Důležité informace o počátečních kontejnerech

Zabalení úloh do kontejnerů je první část práce, kterou je potřeba naplánovat a na které je potřeba pracovat. Druhým je plánování hostování těchto kontejnerů.

Řešení PaaS pro standardizované moduly runtime, orchestraci a operace

Některé úlohy jsou vysoce samostatné a nemusí nutně těžit z pokročilých ovládacích prvků a požadavků na infrastrukturu, které se dodávají s velkou platformou, jako je Kubernetes. To, že je vaše úloha kontejnerizovaná, neznamená, že se musí nasadit do Kubernetes. Azure nabízí řadu řešení pro spouštění úloh v rámci vašeho portfolia, která nevyžadují úroveň správy a infrastruktury, kterou vyžaduje AKS. Následující řešení by se při plánování řídila tímto přístupem:

Zvažte použití jednoduššího řešení pro kontejnery s úlohami, u které neočekáváte nárůst složitosti a které odpovídají účelům a omezením těchto řešení.

Standardizovaná orchestrace s vlastními moduly runtime a operacemi ve veřejném cloudu

U úloh, které se nedají spustit na plně spravované platformě PaaS a musí se předávat na ovládacích prvcích na úrovni infrastruktury, chcete používat pokročilé funkce nasazení, jako jsou ty, které nabízejí orchestrátory kontejnerů, nebo očekávat, že se zvýší modulární složitost, přejděte na Azure Kubernetes Service (AKS). AKS řeší hostování kontejnerů, ale nabízí také rozsáhlé možnosti architektury, SRE, zabezpečení, nasazení, monitorování a infrastruktury.

Sada funkcí platformy obsahuje požadavek na výuku platformy na úrovni operátora clusteru i na úrovni úloh. Promítněte do časových os migrace vzdělávání vašich provozních týmů, týmů architektury a technických týmů úloh. Vzhledem k tomu, že AKS je platforma, zajistěte, aby týmy úloh rozuměly oddělení odpovědností v rámci této platformy od jejich aktuálního uspořádání hostingu. Může to být v některých ohledech podobné, ale pravděpodobně bude nové v jiných.

Přizpůsobená orchestrace, moduly runtime a operace ve veřejném cloudu

Pro velmi specializované úlohy nebo specifické požadavky organizace nabízí Azure další dvě hlavní platformy v prostoru pro orchestraci kontejnerů.

  • Azure Red Hat OpenShift
  • Azure Service Fabric

Pokud existuje důvod k prozkoumání alternativ, zajistěte, aby byl přidělen čas na pochopení výhod a kompromisů všech možností platformy. Výchozím řešením Azure je AKS a tato dokumentace předpokládá, že zvolenou technologií je AKS.

Standardizace operací napříč cloudovými platformami

Zákazníci často nasazují různé orchestrátory kontejnerů v privátním cloudu, hraničních zařízeních a prostředích veřejného cloudu. Aby mohli zákazníci standardizovat operace napříč těmito různorodými cloudovými platformami, mohou začlenit jednotný provozní přístup rozšířením svých nástrojů cloudového provozu na více cloudových platforem.

V Azure můžou organizace standardizovat operace napříč různými orchestrátory onboardingem různorodých hostitelů kontejnerů do Azure Arc pro Kubernetes. Tento nástroj zajišťuje konzistentní monitorování, provoz a zásady správného řízení v rámci každého hostitele kontejneru.

Moduly runtime aplikací v privátním cloudu a hraničních prostředích

Pokud se úlohy musí spouštět v privátním cloudovém nebo hraničním prostředí, ale nejlépe je podporuje modul runtime PaaS, existuje několik nástrojů, které vývojářům umožní stavět na konzistentních modulech runtime PaaS pomocí Azure App Service:

  • Azure Stack HCI: Umožňuje hostování Azure App Service nativně ve službě Azure Stack spravované operátorem Služby Azure Stack.
  • Azure Stack HCI pro AKS: Umožňuje hostovat vlastní moduly runtime spuštěné v AKS v rámci služby Azure Stack spravované operátory Azure Stack a AKS, aby bylo možné provádět přenositelnost do dalších řešení Kubernetes.
  • Azure App Service v Kubernetes pomocí Azure Arc: Umožňuje libovolnému hostiteli Kubernetes poskytovat aplikační služby v Azure. Všichni hostitelé se stanou malou instancí Azure App Service. Vzhledem k tomu, že každý hostitel je také onboardován do Služby Azure Arc, je možné tyto hostitele spravovat také prostřednictvím konzistentních cloudových operací hostitelů.

Plán připravenosti moderní platformy aplikací

Kromě plánu dovedností přechodu na cloud mohou týmy přechodu na cloud před spuštěním vašeho plánu potřebovat rozvíjet dovednosti související s kontejnerem a Kubernetes:

Zajistěte, aby týmy úloh vyčlenily čas na dokumentaci a plány migrace na sucho. Stávající aplikaci nebo externí systém (závislosti i systémy, které závisí na této úloze) může být potřeba upravit s větší flexibilitou, aby bylo možné podporovat migraci. To platí pro předprodukční i produkční prostředí.

Další krok: Kontrola prostředí nebo cílové zóny Azure

Následující seznam článků vás provede pokyny v konkrétních bodech na cestě k přechodu na cloud, které vám pomůžou být úspěšní ve scénáři přechodu na cloud.