Landingszones herstructureren

Een landingszone is een omgeving voor het hosten van uw workloads die vooraf zijn ingericht via code. Omdat de infrastructuur van de landingszone is gedefinieerd in code, kan deze worden geherstructureerd op dezelfde manier als elke andere codebasis. Herstructurering is het proces van het wijzigen of herstructureren van broncode om de uitvoer van die code te optimaliseren zonder het doel of de kernfunctie te wijzigen.

De Ready-methodologie maakt gebruik van het concept van herstructurering om de migratie te versnellen en veelvoorkomende blokkeringen te verwijderen. In de stappen in het overzicht wordt een proces besproken dat begint met een vooraf gedefinieerde landingszonesjabloon die het beste aansluit bij uw hostingfunctie. Vervolgens kunt u de broncode herstructureren of toevoegen om de mogelijkheid van landingszones uit te breiden om die functie te leveren via verbeterde beveiliging, bewerkingen of governance. In de volgende afbeelding ziet u het concept van herstructurering.

Afbeelding 1: herstructurering van landingszone.

Algemene obstakels

Wanneer klanten overstappen op de cloud, zijn overwegingen met betrekking tot landingszones de meest voorkomende obstakels voor acceptatie en bedrijfsresultaten in verband met de cloud. Klanten neigen vaak naar een van de volgende twee obstakels. Verschillende teams leunen vaak naar een van deze twee obstakels, wat resulteert in culturele impasses die acceptatie bemoeilijken.

Beide primaire blokkeringen zijn gebaseerd op één overtuiging: de cloudomgeving en de bestaande datacenters moeten op of bijna functiepariteit zijn met betrekking tot bewerkingen, governance en beveiliging. Dit is een verstandig doel op lange termijn. Maar de pijn komt voort uit de delicate balans tussen de timing om dat doel te bereiken en de snelheid die nodig is om bedrijfsresultaten te leveren.

Blocker: Werkt te snel

Het kostte jaren en aanzienlijke inspanningen om de huidige status van beveiligingsgovernance en -bewerkingen in het huidige datacenter te bereiken. Het vereist ook waarnemingen, leren en aanpassing om te voldoen aan de unieke beperkingen van die omgeving. Het repliceren van dezelfde procedures en configuraties kost tijd. Het bereiken van volledige functiepariteit kan ook leiden tot een omgeving die ondermaats presteert in de cloud. Deze pariteitsbenadering leidt vaak ook tot aanzienlijke ongeplande overbesteding in de cloudomgeving. Probeer niet om vereisten voor de huidige status toe te passen op een toekomstige statusomgeving als een poort voor een vroege fase. Een dergelijke aanpak blijkt zelden winstgevend te zijn.

Afbeelding 2: Te snel handelen is een veelvoorkomende blokkering.

In de bovenstaande afbeelding heeft de klant een doelstelling van 100 workloads die in de cloud worden uitgevoerd. Om daar te komen, implementeert de klant waarschijnlijk zijn eerste workload en vervolgens de eerste tien workloads voordat ze klaar zijn om een van de workloads vrij te geven voor productie. Uiteindelijk bereiken ze het doel van het implementatieplan en hebben ze een robuust portfolio in de cloud. Maar de rode X in de afbeelding laat zien waar klanten vaak vastlopen. Wachten op de totale uitlijning kan de eerste workload uitstellen met weken, maanden of zelfs jaren.

Blocker: Te laat handelen

Aan de andere kant kan te laat handelen aanzienlijke gevolgen op de lange termijn hebben voor het succes van de cloudimplementatie. Als het team wacht op het bereiken van functiepariteit totdat de implementatie is voltooid, ondervinden ze onnodige obstakels en zijn er verschillende escalaties nodig om de inspanningen op schema te houden.

Afbeelding 3: Te laat handelen is een veelvoorkomende blokkering.

Net als bij te snel handelen, wacht de klant in deze afbeelding te lang om enterprise-gereedheid te bereiken in landingszones. Door te lang te wachten, wordt de klant beperkt op de hoeveelheid herstructurering en uitbreiding die hij in de omgeving kan uitvoeren. Deze beperkingen beperken hun vermogen om te blijvend succes te stimuleren.

Balans vinden

Om deze veelvoorkomende obstakels te voorkomen, raden we een iteratieve aanpak aan op basis van een goed gestructureerd plan voor cloudimplementatie, waarmee de leermogelijkheden worden gemaximaliseerd en de tijd voor bedrijfssucces wordt geminimaliseerd. Herstructurering en parallelle inspanningen zijn essentieel voor deze aanpak.

Waarschuwing

Implementatieteams die een doelstelling op de middellange termijn (binnen 24 maanden) hebben om meer dan 1000 assets (toepassingen, infrastructuur of gegevensassets) in de cloud te hosten, zullen hoogstwaarschijnlijk niet succesvol zijn met een herstructureringsbenadering. De leercurve is te hoog en de tijdlijn is te krap om organische benaderingen voor het verwerven van vaardigheden mogelijk te maken. Een completer uitgangspunt waarvoor minder aanpassingen nodig zijn, is een beter pad om uw doelstellingen te bereiken. Uw implementatiepartners kunnen u waarschijnlijk door een betere aanpak leiden.

De rest van dit artikel richt zich op enkele belangrijke beperkingen die een herstructureringsbenadering mogelijk maken, terwijl het risico wordt geminimaliseerd.

Theorie

Het concept van herstructurering van een landingszone is simpel, maar voor de uitvoering zijn de juiste randvoorwaarden vereist. In het hierboven beschreven concept wordt het basisproces toegelicht:

• Wanneer u klaar bent om uw eerste landingszone te gaan bouwen, begint u met een kant-en-klare landingszone die is gedefinieerd via een sjabloon.
• Zodra die landingszone is geïmplementeerd, gebruikt u de richtlijnen in de artikelen onder de Enhance sectie van de inhoudsopgave om uw eerste landingszone te herstructureren en toe te voegen.
• Herhaal het proces van controleren en toevoegen totdat u een bedrijfsklare omgeving hebt die voldoet aan de verbeterde vereisten van uw beveiligings-, operationele en governance-teams.

Ontwikkelingsaanpak

Het voordeel van een aanpak op basis van herstructurering is de mogelijkheid om parallelle iteratiepaden te maken voor ontwikkeling. In de onderstaande afbeelding ziet u een voorbeeld van twee parallelle iteratiepaden: cloudimplementatie en cloudplatform. Beide verlopen in hun eigen tempo, met een minimale kans dat het ene pad een obstakel wordt voor de dagelijkse inspanningen van het andere team. Afstemming op het implementatieplan en de randvoorwaarden voor herstructurering kan leiden tot overeenstemming over mijlpalen en duidelijkheid over aan status gerelateerde afhankelijkheden.

Afbeelding 4: Parallelle iteratie van landingszone.

In de bovenstaande voorbeelden van iteratiepaden migreert het cloudimplementatieteam hun portfolio van 100 workloads naar de cloud. Tegelijkertijd doet het cloudplatformteam er alles aan om op koers te blijven met het cloudimplementatieplan om ervoor te zorgen dat de omgeving is voorbereid voor deze workloads.

In dit voorbeeld worden de geplande iteraties als volgt uitgevoerd:

• Het cloudplatformteam start de ontwikkelingsfase door een eerste landingszone te implementeren. Het cloudimplementatieteam kan deze landingszone gebruiken om hun eerste workload te implementeren en testen.
• Ter voorbereiding op de volgende implementatie van tien workloads door het cloudimplementatieteam, werkt het cloudplatformteam vooruit om herstructurering toe te passen en een verbonden omgeving toe te voegen, waarbij de cloud als een perimeternetwerk wordt beschouwd.
• Voordat het implementatieteam de eerste productieworkload kan vrijgeven, moet er door het beveiligingsteam een beveiligingsanalyse worden uitgevoerd. Terwijl het implementatieteam de eerste tien workloads implementeert, gaat het platformteam aan de slag met het definiëren en implementeren van beveiligingsvereisten.
• Op het moment dat de eerste workload wordt vrijgegeven voor productie, moeten beide teams voldoende ervaring hebben opgedaan om zich voor te bereiden op een gedeeld servicemodel voor de langere termijn. Door de architecturen van kernservices te centraliseren, kunnen de inspanningen van het governance-team en het operationele team in lijn worden gebracht. Door kernservices te centraliseren, kan het implementatieteam zich voorbereiden op het schalen en vrijgeven van de volgende reeksen productieworkloads.
• Naarmate het doel van het migreren van 100 workloads dichterbij komt, zal het team qua samenwerking en structuur op organische wijze evolueren naar een Cloud Center of Excellence-team.

Het configureren van een ondernemingsbrede omgeving zal enige tijd in beslag nemen. Deze aanpak zal hier geen invloed op hebben. Deze aanpak is bedoeld om in een vroeg stadium obstakels weg te nemen en kansen te bieden aan het platformteam en het implementatieteam om samen te leren.

Randvoorwaarden voor herstructurering van landingszone

Alle sjablonen voor landingszones hebben hun beperkingen. Randvoorwaarden of beleidsregels voor herstructurering moeten deze beperkingen weerspiegelen. Voordat u begint met het proces van het herstructureren van een landingszone, is het belangrijk om een beeld te hebben van de vereisten op de lange termijn van het cloudimplementatieplan en de classificatie van de kandidaatworkloads, vergeleken met de beperkingen van de eerste sjabloon.

Als voorbeeld van het instellen van randvoorwaarden voor de herstructurering, kunnen we de ontwikkelingsaanpak uit het vorige voorbeeld vergelijken met de blauwdruk voor een landingszone uit het CAF.

• Op basis van de veronderstellingen voor de blauwdruk uit het CAF voor een landingszone is deze initiële landingszone niet bedoeld voor vertrouwelijke gegevens of essentiële workloads. Deze functies moeten worden toegevoegd via herstructurering van de zone.
• In dit voorbeeld gaan we ervan uit dat voor de portfolio van 100 workloads mogelijkheden vereist zijn voor het hosten van zowel essentiële gegevens als vertrouwelijke gegevens.

Om een balans te vinden tussen deze twee conflicterende vereisten, zijn het implementatieteam en het platformteam overeengekomen om zich te houden aan de volgende voorwaarden:

• Het cloudimplementatieteam geeft prioriteit aan productieworkloads die geen toegang hebben tot vertrouwelijke gegevens en die niet als essentieel worden beschouwd.
• Vóór vrijgave naar productie controleert het team dat over de beveiliging en operationele bewerkingen gaat of aan deze beleidsregel is voldaan.
• Het cloudplatformteam werkt samen met de beveiligings- en governance-teams om een basislijn voor beveiliging te implementeren. Zodra de implementatie is goedgekeurd door het beveiligingsteam, kan het implementatieteam workloads gaan migreren die toegang hebben tot vertrouwelijke gegevens.
• Het cloudplatformteam werkt samen met het operationele team om een basislijn voor beheer te implementeren. Als het operationele team de implementatie heeft goedgekeurd, kan het implementatieteam workloads met kritieke gegevens gaan migreren.

In dit voorbeeld zorgt de bovenstaande set overeengekomen voorwaarden ervoor dat het implementatieteam aan de slag kan met de migratie. De voorwaarden zorgen er ook voor dat de interacties tussen het platformteam en andere teams al vorm zijn geven, aangezien ze samen werken aan een omgeving die op de langere termijn bedoeld is voor de hele onderneming.

Voldoen aan vereisten voor de lange termijn tijdens herstructurering

De sectie van de Ready-methodologie voor het verbeteren van uw landingszone zal helpen bij het aanpassen van de vereisten op de langere termijn. Naarmate het cloudimplementatieteam vordert met hun overstapplan, raadpleegt u Uw landingszone uitbreiden voor hulp bij het nemen van beslissingen en herstructurering om te voldoen aan de veranderende vereisten van verschillende teams.

Afbeelding 5: Diepere methodologieën die helpen bij een parallelle iteratie van landingszones.

Elke subsectie van Uw landingszone uitbreiden is gekoppeld aan een van de toevoegingen die in de bovenstaande afbeelding zijn omkaderd. Afgezien van deze basisuitbreidingen zullen de diepere methodologieën (zoals governance of beheer) van dit kader helpen om verder te gaan dan basiswijzigingen in de landingszone om disciplines op lange termijn te implementeren.

Volgende stappen

Als u aan de slag wilt gaan met een herstructureringsproces, gaat u aan de slag met azure-landingszones.

Azure-landingszones