您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

在迁移之前架构工作负荷Architect workloads prior to migration

本文通过回顾与定义给定迭代中工作负荷体系结构相关的活动,扩展了评估过程。This article expands on the assessment process by reviewing activities associated with defining the architecture of a workload within a given iteration. 增量合理化一文中所述,在任何需要迁移的业务转换过程中都会做出一些体系结构假设。As discussed in the article on incremental rationalization, some architectural assumptions are made during any business transformation that requires a migration. 本文阐明了这些假设,分享了一些可以避免的障碍,并指出了通过挑战这些假设来加速实现业务价值的机会。This article clarifies those assumptions, shares a few roadblocks that can be avoided, and identifies opportunities to accelerate business value by challenging those assumptions. 借助这种体系结构增量模型,团队可以更快地取得进展和业务成效。This incremental model for architecture allows teams to move faster and to obtain business outcomes sooner.

迁移之前的体系结构假设Architecture assumptions prior to migration

以下假设对于任何迁移工作都是典型的:The following assumptions are typical for any migration effort:

  • IaaS.IaaS. 通常假设,迁移工作负荷主要涉及通过 IaaS 迁移将虚拟机从物理数据中心迁移到云数据中心,这需要最少的重新开发或重新配置工作。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. 此方法称为 " 提升并 迁移"。This approach is known as a lift and shift migration. (后跟异常。)(Exceptions follow.)
  • 体系结构一致性。Architecture consistency. 在迁移过程中改变核心体系结构会大大增加复杂性。Changes to core architecture during a migration considerably increase complexity. 在新平台上调试变更后的系统会引入许多难以隔离的变量。Debugging a changed system on a new platform introduces many variables that can be difficult to isolate. 因此,在迁移过程中,工作负荷只应进行少量变更,任何变更都应经过全面测试。For this reason, workloads should undergo only minor changes during migration and any changes should be thoroughly tested.
  • 停用测试。Retirement test. 资产迁移和托管会消耗潜在运营资本支出。Migrations and the hosting of assets consume operational and potential capital expenses. 假设要迁移的任何工作负荷都已经过审阅,以验证持续使用情况。It is assumed that any workloads being migrated have been reviewed to validate ongoing usage. 选择停用未用资产可以立即节省成本。The choice to retire unused assets produces immediate cost savings.
  • 调整资产大小。Resize assets. 假设很少有本地资产充分利用分配的资源。It is assumed that few on-premises assets are fully using the allocated resources. 在迁移之前,假设资产会调整为最能满足实际使用需求的大小。Prior to migration, it is assumed that assets will be resized to best fit actual usage requirements.
  • 业务连续性和灾难恢复 (BCDR) 要求。Business continuity and disaster recovery (BCDR) requirements. 假设在发布计划之前已与企业就工作负荷 SLA 达成一致协商。It is assumed that an agreed-on SLA for the workload has been negotiated with the business prior to release planning. 这些要求可能会产生次要体系结构变更。These requirements are likely to produce minor architecture changes.
  • 迁移故障时间。Migration downtime. 同样,将工作负荷升级到生产的故障时间可能也会对业务产生不利影响。Likewise, downtime to promote the workload to production can have an adverse effect on the business. 有时,必须在最短故障时间内转换的解决方案需要变更体系结构。Sometimes, the solutions that must transition with minimum downtime need architecture changes. 假设在发布计划之前已大致了解故障时间要求。It is assumed that a general understanding of downtime requirements has been established prior to release planning.
  • 用户流量模式。User traffic patterns. 现有解决方案可能依赖现有网络路由模式。Existing solutions may depend on existing network routing patterns. 这些模式可能会显著降低性能。These patterns could slow performance considerably. 此外,引入新的混合广域网 (WAN) 解决方案可能需要数周甚至数月的时间。Further, introduction of new hybrid wide area network (WAN) solutions can take weeks or even months. 在迁移之前,假定登陆区域已考虑了相关的流量模式和对任何核心基础结构服务的更改。Prior to migration, it is assumed that your landing zones have already considered the relevant traffic patterns and changes to any core infrastructure services.

缓解潜在障碍Mitigating potential roadblocks

逐条列出的假设可能会造成障碍,进而减慢进度或导致后续难点。The itemized assumptions can create roadblocks that could slow progress or cause later pain points. 下面是发布之前需要注意的几个障碍:The following are a few roadblocks to watch for, prior to the release:

  • 偿还技术债务。Paying for technical debt. 一些老化的工作负荷带来了大量的技术债务。Some aging workloads carry with them a high amount of technical debt. 技术债务可以通过使用任何云提供商增加托管成本来产生长期挑战。Technical debt can lead to long-term challenges by increasing hosting costs with any cloud provider. 如果技术债务导致托管成本异常增加,应评估备选体系结构。When technical debt unnaturally increases hosting costs, alternative architectures should be evaluated.
  • 提高可靠性。Improving reliability. 标准操作基准在云中提供了一定程度的可靠性和恢复能力。Standard operations baselines provide a degree of reliability and recovery in the cloud. 但是,某些工作负荷团队可能需要更高的 Sla,这可能会导致体系结构更改。But, some workload teams may require higher SLAs which could lead to architectural changes.
  • 高成本工作负荷。High-cost workloads. 在迁移期间,应将所有资产进行优化,以使调整大小与实际使用情况保持一致。During migration, all assets should be optimized to align sizing with actual usage. 但是,某些工作负荷可能需要体系结构修改才能解决特定的成本问题。But, some workloads may require architectural modifications to address specific cost concerns.
  • 性能要求。Performance requirements. 当工作负荷性能影响直接业务时,可能需要考虑额外的结构。When workload performance has a direct business impact, extra architectural consideration may be required.
  • 保护应用程序。Secure applications. 安全要求通常是集中实施的,并应用于公文包中的所有工作负荷。Security requirements tend to be implemented centrally and applied to all workloads in the portfolio. 但是,某些工作负荷可能具有特定的安全要求,这些要求可能会导致体系结构更改。But, some workloads may have specific security requirements that could lead to architectural changes.

上述每个条件都作为潜在迁移障碍的指标。Each of the above criteria serve as indicators of potential migration roadblocks. 迁移工作负荷后通常会解决上述标准。The above criteria is usually addressed after a workload is migrated. 但如果在迁移工作负荷之前需要这些条件中的任何一个,则应将其从迁移 wave 中删除并单独进行评估。But if any of those criteria are required before a workload is migrated, it should be removed from the migration wave and evaluated individually.

Microsoft Azure Well-Architected 框架Microsoft Azure Well-Architected 检查有助于指导这些与特定工作负荷的技术所有者的对话,以考虑用于部署工作负荷的替代选项。The Microsoft Azure Well-Architected Framework and Microsoft Azure Well-Architected Review can help guide those conversations with the technical owner of a specific workload to consider alternative options for deploying the workload. 然后,这些工作负荷会在你的云采用计划中分类为示意图。Those workloads would then be classified as a rearchitecture effort in your cloud adoption plan. 如果需要额外的时间来重塑工作负荷,则不应将这些备用工作负荷采用路径视为迁移过程的一部分。Given the extra time required to rearchitect a workload, these alternative workload adoption paths should not be considered part of the migration process.

加速业务价值Accelerate business value

一些方案可能需要与假设的 IaaS 重新托管策略不同的体系结构。Some scenarios could require an different architecture than the assumed IaaS rehosting strategy. 下面是几个示例:The following are a few examples:

  • PaaS 现代化。PaaS modernization. 某些技术资产可以迁移到更现代的平台即服务解决方案,从而降低迁移期间的风险。Some technology assets can be migrated to more modern Platform as a Service solutions, reducing risk during migration. 自动迁移工具(如 Azure Migrate)建议甚至自动执行现代化机会。Automated migration tools like Azure Migrate suggest and even automate modernization opportunities. 一些正在进行的现代化的示例包括低风险更改,如使用 Azure 数据库迁移服务 (dm) 实现数据库的现代化。A few examples of in-flight modernization would include low risk changes like the use of Azure Database Migration Service (DMS) to modernize databases. 有关受益于 PaaS 转换的方法列表,请参阅评估资产一文。For a list of approaches that could benefit from a PaaS conversion, see the article on evaluating assets.
  • 脚本部署/DevOps。Scripted deployments/DevOps. 如果工作负荷现有 DevOps 部署或其他形式的脚本部署,变更这些脚本的成本可能低于迁移资产的成本。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.
  • 修正工作。Remediation efforts. 准备工作负荷以供迁移所需的修正工作量可能会很大。The remediation efforts required to prepare a workload for migration can be extensive. 在某些情况下,新式化解决方案比修正基础兼容性问题更有意义。In some cases, it makes more sense to modernize the solution than it does to remediate underlying compatibility issues.

在上面逐条列出的每个方案中,备选体系结构可能是最佳解决方案。In each of these itemized scenarios, an alternative architecture could be the best possible solution.

后续步骤Next steps

定义新体系结构后,可以计算出准确的成本估计After the new architecture is defined, accurate cost estimations can be calculated.