Delen via

Plan voor moderne toepassingsplatforms

  • Artikel

De planmethodologie van de Cloud Adoption Framework helpt bij het maken van een algemeen plan voor cloudacceptatie om de programma's en teams te begeleiden die betrokken zijn bij uw digitale cloudtransformatie. Deze richtlijnen bevatten sjablonen voor het maken van uw achterstand en plannen voor het ontwikkelen van de benodigde vaardigheden in uw teams, allemaal op basis van wat u probeert te doen in de cloud.

De toepassing van de planmethodologie richt zich op de vijf R's van het rationaliseren van uw digitale activa. Het meest voorkomende pad naar de cloud is gericht op snelheid, efficiëntie en herhaalbaarheid van de migratie- en moderniseringsprocessen. Vanaf de vijf R's geeft planning meestal prioriteit aan opties voor opnieuw hosten met beperkte parallelle ondersteuning voor opties voor opnieuw ontwerpen en herbouwen.

Digitale activa

Wanneer u uw digitale activa plant, wilt u inventarisgegevens verzamelen en uw activa rationaliseren. In een containerimplementatieplan is het essentieel dat alle assets, zoals VM's, gegevens en toepassingen, worden gegroepeerd op de workload die ze ondersteunen. Zodra de groepering en basisrationalisatie is voltooid, kunt u deze workloads evalueren om het pakket te bepalen en de opties opnieuw hosten of opnieuw ontwerpen.

De standaardsjabloon voor het cloudimplementatieplan is verantwoordelijk voor de typen werk die nodig zijn voor een typische cloudimplementatie. Maar u moet wel taken toevoegen aan uw plan voor het verpakken van de workload in containers en de indeling van de containerinrichting.

Waarschuwing

In dit artikel wordt ervan uitgegaan dat de lezer al de aanbevolen procedures volgt die worden beschreven in de reeks artikelen over het bouwen van een cloudacceptatieplan in Azure DevOps. Als u uw cloudacceptatieplan bijhoudt in een spreadsheet of andere hulpprogramma's voor het bijhouden van projecten, zijn de volgende secties nog steeds van toepassing, maar moeten de bruikbare stappen voor het toevoegen van gegevens aan uw plan worden aangepast.

Waarschuwing

Het opnemen van een moderne toepassingsplatformstrategie in standaardmigratieprocessen (of een migratiefactory) vereist een volwassen implementatie van taken die zijn gekoppeld aan het ontwerpen van workloadarchitecturen voorafgaand aan de migratie. Het voortzetten van deze strategie zonder deze taken zal de migratie vertragen en kan leiden tot slechte architectuurbeslissingen voor de geïmplementeerde containerhosts en ondersteunende workloads.

Potentiële workloads identificeren

In het moderne toepassingsplatformscenario krijgen rendementen op de langere termijn, waarvoor een grotere investering vooraf nodig is, prioriteit boven efficiëntere migratieprocessen. De investeringen op de langere termijn worden in specifieke onderdelen van het plan weergegeven als een grotere focus op het mogelijk maken van innovatie en het stroomlijnen van bewerkingen voor specifieke groepen workloads.

Als u de strategie en het plan wilt afstemmen, identificeert u alle workloads die waarschijnlijk worden beïnvloed door de toevoeging van moderne toepassingsplatforms in uw strategie voor cloudimplementatie. Deze veronderstellingen worden gevalideerd voordat technische wijzigingen worden geïmplementeerd. Als u wilt helpen bij het identificeren van potentiële kandidaten, zoekt u naar de volgende criteria binnen uw portfolio met workloads:

  • Actieve ontwikkeling of DevOps-investeringen: Een percentage van de productieworkloads wordt actief ontwikkeld. Sommige kunnen zelfs worden beheerd via doorlopende DevOps-procedures.
  • Workloadportabiliteit: Sommige workloads worden beïnvloed door naleving, gegevensbescherming of operationele beperkingen die mogelijk draagbaarheid vereisen voor privéclouds, edge-providers of zelfs meerdere openbare cloudproviders.
  • Workloadconsolidatie: Veel workloads (met name workloads met een laag gebruik) kunnen in aanmerking komen voor consolidatie op containerhosts, wat resulteert in weinig servers/VM's en lagere operationele kosten.
  • Verouderde workloads: Verouderde workloads kunnen updates van besturingssystemen blokkeren en zelfs migratie naar de cloud voorkomen. Verouderde workloads die niet compatibel zijn met de Azure-functies, kunnen een kandidaat zijn voor migratie op een containerhost.

Werkbelastingen van kandidaten document

Notitie

De volgende lijst met overwegingen moet alleen worden gedocumenteerd voor migratiekandidaten die zijn geïdentificeerd door de bovenstaande criteria.

Wanneer u een plan voor cloudimplementatie maakt, wordt elke workload gedocumenteerd volgens de richtlijnen in Workloads definiëren en prioriteren. Elke workload die in aanmerking komt voor het moderne toepassingsplatformscenario, vereist aanvullende informatie om de uitvoering van het plan te begeleiden. In dit artikel wordt het belang benadrukt van het documenteren van zakelijke en technische invoer om de workload te definiëren. Voor kandidaten voor het moderne toepassingsplatform moeten de volgende gegevenspunten worden toegevoegd aan de definitie van de workload.

Zakelijke invoer

Hieronder volgen bedrijfsgerelateerde gegevenspunten die van invloed kunnen zijn op de beslissing om een workload op te nemen in de moderne toepassingsplatformstrategie.

  • Nalevingsfactoren: Welke specifieke nalevingscriteria zijn de drijvende kracht achter overwegingen bij het hosten van deze workload in een privécloud?
  • Stuurprogramma's voor gegevensbescherming: Welke gegevensbeveiligingsmaatregelen zijn de reden voor overwegingen om deze workload in een privécloud te hosten?
  • Operationele beperkingen: Welke operationele beperkingen zijn de drijvende kracht achter overwegingen bij het hosten van deze workload in een privécloud?
  • Resultaten van het moderne toepassingsplatform: Welke van de volgende is de driver achter het evalueren van deze workload als containerkandidaat? DevOps, draagbaarheid, consolidatie, verouderde of meerdere van deze stuurprogramma's.
  • Operationeel model: Wordt deze workload centraal beheerd (door centrale IT/CCoE), de-centraal (door workloadteam) of met bedrijfsactiviteiten (centrale ondersteuning en workloadspecifieke bewerkingen)?

Technische invoer

Hier volgen gegevenspunten van de technologieteams die van invloed kunnen zijn op de beslissing om een workload op te nemen in de strategie voor het moderne toepassingsplatform.

Locatieoverwegingen:

Overwegingen met betrekking tot waar de workload wordt gehost.

  • Hostingvereiste voor openbare cloud: Is er een specifieke technische beperking gekoppeld aan de vereiste voor de openbare cloud?
  • Hostingvereiste voor privécloud: Is er een specifieke technische beperking gekoppeld aan de vereisten voor de privécloud?
  • Edge-hostingvereiste: Is er een specifieke technische beperking gekoppeld aan de randvereiste?
  • Vereiste voor draagbaarheid: Is er een specifieke technische beperking gekoppeld aan de vereiste voor cloudportabiliteit?

Overwegingen voor bewerkingen:

Overwegingen met betrekking tot de bewerkingen van het platform, hosts en workloads.

  • Primair cloudplatform: Organisaties moeten een primair cloudplatform definiëren om hulpprogramma's voor operationeel beheer te bieden. Sommige organisaties hebben mogelijk meer dan één primair cloudplatform voor het beheren van verschillende typen bewerkingen. Wat is het primaire cloudplatform voor deze workload?
  • Aanvullende bewerkingsplatformen: Wordt deze workload ook beheerd door extra bewerkingsplatforms?
  • Vereisten voor cloudhosting: Is voor deze workload een specifieke strategie voor cloudhosting vereist? Openbare cloud, privécloud of cloudportabiliteit
  • Gestandaardiseerd indelingsplatform: Als het bedrijf een standaardoplossing voor containerindeling heeft, neemt u de naam op van het gestandaardiseerde platform dat moet worden overwogen. Voorbeelden: Azure Kubernetes Service (AKS), AKS-engine of Kubernetes.
  • Overwegingen voor aangepaste indeling: Is er een vereiste voor een niet-standaard containerindelingsplatform? Zo ja, leg die vereiste dan uit.
  • Gestandaardiseerde hostbewerkingen: Er wordt vanuit gegaan dat workloads niet vijandig zijn en kunnen worden gehost op gedeelde containers die worden ondersteund door gestandaardiseerde hostbewerkingen. Is deze workload compatibel met deze aanpak?
  • Overwegingen voor aangepaste hostbewerkingen: Als de workload niet compatibel is met gestandaardiseerde bewerkingen, met welke specifieke vereisten moet u dan rekening houden bij het instellen van hostbewerkingen voor deze workload?

Toepassingsoverwegingen:

Overwegingen die specifiek zijn voor de wijze waarop de toepassing wordt ontwikkeld en in de toekomst zal worden ontwikkeld.

  • PaaS-runtime (Platform as a Service): Openbare cloudproviders produceren consistente toepassingsruntimes, ook wel PaaS-aanbiedingen (Platform as a Service) genoemd. In Azure worden de PaaS-runtimes geleverd door Azure App Service. Kan deze toepassing worden uitgevoerd op een PaaS-runtime? Welke runtime is het meest compatibel?
  • Gestandaardiseerde runtime: Als de toepassing niet compatibel is met een PaaS-runtime, wordt er dan een gestandaardiseerde runtime geleverd door de organisatie? Op welke runtime wordt deze workload gebouwd?
  • Aangepaste runtime-overwegingen: Welke specifieke overwegingen vereisen een aangepaste runtime voor deze workload?
  • Runtimebeperkingen: Zijn er beperkingen opgelegd aan de toepassing door de gekozen runtime?
  • Toepassingsafhankelijkheden: Is deze workload afhankelijk van bestaande systemen die zich op een specifieke locatie bevinden (zoals openbaar of privé)? Voorbeelden hiervan zijn een ERP-systeem zoals SAP dat wordt uitgevoerd in een specifieke oplossing.
  • Zwaartekracht van gegevens: Is deze workload afhankelijk van een gegevensbron die zich op een specifieke locatie bevindt (zoals openbaar of privé)? Voorbeelden zijn een afhankelijkheid van de gegevens in SAP of andere gecentraliseerde gegevensbronnen.
  • Overwegingen voor goedgekeurde lijsten: Zijn de overwegingen voor aangepaste bewerkingen goedgekeurd voor gebruik binnen uw cloudplatform? Welke goedgekeurde services moeten worden opgenomen in de implementatie?

Overwegingen voor initiële containers

Het verpakken van uw workloads in containers is het eerste werk waaraan moet worden gepland en waaraan moet worden gewerkt. De tweede is het plannen van de hosting van deze containers.

PaaS-oplossingen voor gestandaardiseerde runtimes, indeling en bewerkingen

Sommige workloads zijn zeer zelfstandig en profiteren niet noodzakelijkerwijs van de geavanceerde besturingselementen en infrastructuurvereisten die worden geleverd bij een groot platform zoals Kubernetes. Omdat uw workload in een container is geplaatst, betekent dit nog niet dat deze moet worden geïmplementeerd in Kubernetes. Azure biedt diverse oplossingen voor het uitvoeren van workloads binnen uw portfolio waarvoor niet het beheer- en infrastructuurniveau is vereist dat AKS vereist. De volgende oplossingen volgen deze planningsbenadering:

Overweeg het gebruik van een lichtere oplossing voor uw containers met workloads die u niet verwacht complexer te maken en die overeenkomen met de doeleinden en limieten van deze oplossingen.

Gestandaardiseerde indeling met aangepaste runtimes en bewerkingen in de openbare cloud

Voor workloads die niet kunnen worden uitgevoerd in een volledig beheerd PaaS-platform en besturingselementen op infrastructuurniveau moeten worden doorgegeven, die geavanceerde implementatiefuncties willen gebruiken, zoals die van containerorchestrators, of die verwachten dat ze in modulaire complexiteit toenemen, gaat u naar Azure Kubernetes Service (AKS). AKS lost zowel containerhosting op, maar biedt ook uitgebreide opties voor architectuur, SRE, beveiliging, implementatie, bewaking en infrastructuur.

De functieset van het platform wordt geleverd met een vereiste om het platform te leren, zowel op het niveau van de clusteroperator als op het niveau van de workload. Houd rekening met de opleiding van uw operationele teams, architectuurteams en engineeringteams voor workloads in de migratietijdlijnen. Omdat AKS een platform is, moet u er ook voor zorgen dat werkbelastingteams de scheiding van verantwoordelijkheden binnen dit platform en hun huidige hostingregeling begrijpen. Het kan op sommige manieren vergelijkbaar zijn, maar zal waarschijnlijk nieuw zijn in andere.

Aangepaste indeling, runtimes en bewerkingen in de openbare cloud

Voor zeer gespecialiseerde workloads of specifieke organisatievereisten biedt Azure twee andere belangrijke platforms in de containerindelingsruimte.

  • Azure Red Hat OpenShift
  • Azure Service Fabric

Als er reden is om alternatieven te verkennen, zorg er dan voor dat er tijd wordt toegewezen om inzicht te krijgen in de voordelen en afwegingen van alle platformopties. De standaardoplossing van Azure is AKS. In deze documentatie wordt ervan uitgegaan dat AKS de gekozen technologie is.

Bewerkingen op cloudplatforms standaardiseren

Vaak implementeren klanten verschillende containerorchestrators in privécloud-, edge- en openbare cloudomgevingen. Om bewerkingen op deze verschillende cloudplatforms te standaardiseren, kunnen klanten een uniforme benadering voor bewerkingen opnemen door hun hulpprogramma's voor cloudbewerkingen uit te breiden naar meerdere cloudplatforms.

In Azure kunnen organisaties bewerkingen in verschillende orchestrators standaardiseren door ongelijksoortige containerhosts te onboarden in Azure Arc voor Kubernetes. Dit hulpprogramma zorgt voor consistente bewaking, bewerkingen en governance voor elke containerhost.

Toepassingsruntimes in privécloud- en edge-omgevingen

Wanneer workloads moeten worden uitgevoerd in een privécloud of edge-omgeving, maar de workload het beste wordt ondersteund door een PaaS-runtime, zijn er enkele hulpprogramma's waarmee ontwikkelaars kunnen bouwen op basis van consistente PaaS-runtimes met behulp van Azure App Service:

  • Azure Stack HCI: Hiermee kunt u Azure App Service systeemeigen hosten in Azure Stack, beheerd door de Azure Stack-operator.
  • Azure Stack HCI voor AKS: Hiermee kunt u aangepaste runtimes hosten die worden uitgevoerd op AKS in Azure Stack, beheerd door Azure Stack- en AKS-operators om portabiliteit naar andere Kubernetes-oplossingen mogelijk te maken.
  • Azure App Service op Kubernetes met Azure Arc: Hiermee staat u elke Kubernetes-host toe om toepassingsservices te bieden in Azure. Alle hosts worden een klein exemplaar van Azure App Service. Omdat elke host ook wordt ge onboardd in Azure Arc, kunnen deze hosts ook worden beheerd via consistente cloudgebaseerde hostbewerkingen.

Plan voor gereedheid van modern toepassingsplatform

Naast het vaardigheidsplan voor cloudimplementatie moeten de cloudacceptatieteams mogelijk vaardigheden ontwikkelen met betrekking tot container en Kubernetes voordat ze uw plan uitvoeren:

Zorg ervoor dat er tijd is toegewezen aan workloadteams om migratieplannen vast te leggen en uit te voeren. De bestaande toepassing of het externe systeem (zowel afhankelijkheden als systemen die afhankelijk zijn van deze workload) moet mogelijk worden gewijzigd met extra flexibiliteit om de migratie te ondersteunen. Dit geldt voor zowel preproductie- als productieomgevingen.

Volgende stap: Uw omgeving of Azure-landingszone controleren

In de volgende lijst met artikelen wordt u begeleid bij specifieke punten in het cloudacceptatietraject om u te helpen succesvol te zijn in het scenario voor cloudimplementatie.