Workloads vóór de migratie ontwerpenArchitect workloads prior to migration

Dit artikel gaat in op het evaluatieproces door activiteiten te bekijken die te maken hebben met het definiëren van de workloadarchitectuur binnen een bepaalde iteratie.This article expands on the assessment process by reviewing activities associated with defining the architecture of a workload within a given iteration. Zoals beschreven in het artikel over incrementele rationalisering worden er tijdens elke bedrijfstransformatie die een migratie vereist, architectonische aannames gedaan.As discussed in the article on incremental rationalization, some architectural assumptions are made during any business transformation that requires a migration. In dit artikel worden die aannames toegelicht. Ook worden er enkele vermijdbare obstakels gedeeld en kansen geïdentificeerd die de bedrijfswaarde kunnen vergroten door die aannames in vraag te stellen.This article clarifies those assumptions, shares a few roadblocks that can be avoided, and identifies opportunities to accelerate business value by challenging those assumptions. Met dit incrementele model voor architectuur kunnen teams sneller handelen en bedrijfsresultaten eerder behalen.This incremental model for architecture allows teams to move faster and to obtain business outcomes sooner.

Architectonische aannames vóór de migratieArchitecture assumptions prior to migration

De volgende aannames zijn kenmerkend voor alle migratiepogingen:The following assumptions are typical for any migration effort:

  • IaaS.IaaS. In het algemeen wordt ervan uitgegaan dat het migreren van workloads voornamelijk bestaat uit het verplaatsen van virtuele machines van een fysiek datacenter naar een clouddatacenter via een IaaS-migratie, waarbij minimale herontwikkeling of herconfiguratie vereist is.It is commonly assumed that migrating workloads primarily involves the movement of virtual machines from a physical datacenter to a cloud datacenter via an IaaS migration, requiring a minimum of redevelopment or reconfiguration. Dit wordt ook wel de migratie van liften en verschuivingen genoemd.This is known as a lift and shift migration. (Uitzonderingen volgen.)(Exceptions follow.)
  • Architectonische consistentie.Architecture consistency. Door de basisarchitectuur tijdens een migratie te wijzigen, wordt de complexiteit aanzienlijk verhoogd.Changes to core architecture during a migration considerably increase complexity. Het opsporen van fouten in een gewijzigd systeem op een nieuw platform brengt veel variabelen met zich mee die moeilijk te isoleren kunnen zijn.Debugging a changed system on a new platform introduces many variables that can be difficult to isolate. Daarom mogen workloads tijdens de migratie alleen kleine wijzigingen ondergaan. Deze wijzigingen moeten grondig worden getest.For this reason, workloads should undergo only minor changes during migration and any changes should be thoroughly tested.
  • Test van buitengebruikstelling.Retirement test. Migraties en het hosten van assets zorgen voor operationele en potentiële kapitaallasten.Migrations and the hosting of assets consume operational and potential capital expenses. Er wordt van uitgegaan dat alle workloads die worden gemigreerd, zijn gecontroleerd om doorlopend gebruik te valideren.It is assumed that any workloads being migrated have been reviewed to validate ongoing usage. De keuze om ongebruikte assets buiten gebruik te stellen, zorgt voor onmiddellijke kostenbesparingen.The choice to retire unused assets produces immediate cost savings.
  • Het formaat van assets wijzigen.Resize assets. Er wordt van uitgegaan dat slechts weinig on-premises assets volledig gebruikmaken van de toegewezen bronnen.It is assumed that few on-premises assets are fully using the allocated resources. Vóór de migratie wordt ervan uitgegaan dat het formaat van assets wordt gewijzigd om zo goed mogelijk aan de huidige gebruiksvereisten te voldoen.Prior to migration, it is assumed that assets will be resized to best fit actual usage requirements.
  • Vereisten voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR).Business continuity and disaster recovery (BCDR) requirements. Er wordt van uitgegaan dat er vóór het plannen van de release met het bedrijf een overeengekomen SLA voor de workload is onderhandeld.It is assumed that an agreed-on SLA for the workload has been negotiated with the business prior to release planning. Deze vereisten zullen waarschijnlijk kleine wijzigingen in de architectuur veroorzaken.These requirements are likely to produce minor architecture changes.
  • Downtime van migratie.Migration downtime. Downtime om het workloadniveau te verhogen kan evengoed een negatief effect op het bedrijf hebben.Likewise, downtime to promote the workload to production can have an adverse effect on the business. Soms moeten de oplossingen die met een minimale downtime moeten worden overgezet, architectonisch worden gewijzigd.Sometimes, the solutions that must transition with minimum downtime need architecture changes. Er wordt van uitgegaan dat een algemeen begrip van de downtime-vereisten is vastgesteld vóór het plannen van de release.It is assumed that a general understanding of downtime requirements has been established prior to release planning.

Obstakels die kunnen worden vermedenRoadblocks that can be avoided

De gespecificeerde aannames kunnen obstakels creëren die de voortgang kunnen vertragen of latere knelpunten kunnen veroorzaken.The itemized assumptions can create roadblocks that could slow progress or cause later pain points. Hier volgen enkele obstakels die u vóór de release in de gaten moet houden:The following are a few roadblocks to watch for, prior to the release:

  • Technische schulden betalen.Paying for technical debt. Sommige verouderde workloads gaan gepaard met een hoge hoeveelheid technische schulden.Some aging workloads carry with them a high amount of technical debt. Dit kan leiden tot uitdagingen op de lange termijn doordat de hostingkosten bij iedere cloudprovider worden verhoogd.This can lead to long-term challenges by increasing hosting costs with any cloud provider. Wanneer technische schulden de hostingkosten onnatuurlijk verhogen, moeten alternatieve architecturen worden overwogen.When technical debt unnaturally increases hosting costs, alternative architectures should be evaluated.
  • Gebruikersverkeerpatronen.User traffic patterns. Bestaande oplossingen kunnen afhankelijk zijn van bestaande netwerkrouteringspatronen.Existing solutions may depend on existing network routing patterns. Deze patronen kunnen de prestaties aanzienlijk vertragen.These patterns could slow performance considerably. Daarnaast kan de introductie van nieuwe hybride WAN-oplossingen (wide area network) weken of zelfs maanden duren.Further, introduction of new hybrid wide area network (WAN) solutions can take weeks or even months. Bereid u vroeg in het architectonische proces op deze obstakels voor door de verkeerspatronen en wijzigingen van kerninfrastructuurservices in aanmerking te nemen.Prepare early in the architecture process for these roadblocks by considering traffic patterns and changes to any core infrastructure services.

Bedrijfs waarde versnellenAccelerate business value

Voor sommige scenario's is mogelijk een andere architectuur vereist dan de aangenomen IaaS-strategie voor opnieuw hosten.Some scenarios could require an different architecture than the assumed IaaS rehosting strategy. Hier volgen enkele voorbeelden:The following are a few examples:

  • Alternatieven voor PaaS.PaaS alternatives. PaaS-implementaties kunnen de hostingkosten verlagen en kunnen tevens de tijd verminderen die nodig is om bepaalde workloads te migreren.PaaS deployments can reduce hosting costs, and they can also reduce the time required to migrate certain workloads. Zie het artikel over het evalueren van assets voor een lijst met benaderingen die baat zouden kunnen hebben bij een PaaS-conversie.For a list of approaches that could benefit from a PaaS conversion, see the article on evaluating assets.
  • Geplande implementaties/DevOps.Scripted deployments/DevOps. Als een workload een bestaande DevOps-implementatie of andere vormen van geplande implementatie heeft, kunnen de kosten voor het wijzigen van die scripts lager zijn dan de kosten voor het migreren van de asset.If a workload has an existing DevOps deployment or other forms of scripted deployment, the cost of changing those scripts could be lower than the cost of migrating the asset.
  • Herstelpogingen.Remediation efforts. De herstelpogingen die nodig zijn om een workload voor te bereiden op migratie, kunnen uitvoerig zijn.The remediation efforts required to prepare a workload for migration can be extensive. In sommige gevallen kan het zinniger zijn om de oplossing te moderniseren dan om de onderliggende compatibiliteitsproblemen op te lossen.In some cases, it makes more sense to modernize the solution than it does to remediate underlying compatibility issues.

In elk van deze gespecificeerde scenario's zou een alternatieve architectuur de best mogelijke oplossing kunnen zijn.In each of these itemized scenarios, an alternative architecture could be the best possible solution.

Volgende stappenNext steps

Nadat de nieuwe architectuur is gedefinieerd, kunnen nauwkeurige kostenramingen worden berekend.After the new architecture is defined, accurate cost estimations can be calculated.