迁移至云端：真的像看上去那样让人望而生畏吗？

在当前的商业环境中，实现云原生经常被认为取得业务成功的关键。通常我们认为实现“云原生”对企业来讲是一个巨大的变化，但是这种看法并不一定准确。在本文中，我们将深入探讨云迁移（Cloud Migration）的概念及其对企业支撑基础设施的影响。

什么是云和云原生服务？

“云”指的是可以通过互联网访问的远程服务器网络，企业可以从“Hyperscaler”那里以按使用计费的方式租用基础设施和服务。

我们主要有三种类型的云：

• 公有云：云服务可以公开访问，任何人都可以租用，比如 AWS。

• 混合云：结合了“企业自建（on-premise）”和云托管服务或基础设施的环境。

• 私有云：云服务是由某个组织专门建立、拥有和使用的。

“云原生”服务指的是在云上构建、部署和运行的应用程序和服务。这些服务旨在利用云所提供的特性和能力，如可扩展性、高可用性和弹性。

什么是云供应商？

云供应商指的是向组织提供基于云的基础设施和服务的公司。这些服务可以采用按使用付费的方式租用，使组织可以节省构建和维护自己的基础设施相关的前期成本和持续成本。

云供应商负责托管基础设施并进行投资以支持必要的升级和维护。这包括对硬件、软件和人员的投资，以确保服务的安全和可靠。这些投资相关的成本通常会通过运维费用而不是资本费用的方式转嫁给消费者。

长远来看，对于组织来讲，从云供应商那里租用所需的服务通常更划算，因为这能让他们避免构建自己基础设施的前期成本。此外，组织还可以根据需要进行扩展或伸缩，而不会产生增加或移除物理硬件的费用。

总而言之，云供应商为组织提供了一系列的 IT 资源和服务，而无需承担拥有和维护基础设施的负担。

什么是“云原生服务”？

“云原生服务”指的是专门为在云平台上运行而设计的服务和基础设施，它们由云供应商托管和维护。这些服务可以包括各种产品，如虚拟机（VM）、应用服务器、VPN、负载均衡器、路由器、数据库和磁盘存储。它们可以分为三个主要的类别，即计算服务、网络服务和存储服务。

• 计算服务：真正“做事情”的服务，如 VM、应用服务器等。

• 网络服务：实现“连接”的服务，如 VPN、LB 和路由器。

• 存储服务：“数据”服务，如数据库、磁盘存储等。

云原生服务提供了强大而灵活的基础设施，可以帮助组织实现其应用程序的现代化，提升可扩展性并降低运维成本。

云迁移的策略和方法

什么是云迁移？

云迁移指的是将全部或部分数据、基础设施或计算服务转移到云供应商中。

如下概述了云迁移规划的“6R”方式，也就是不同的迁移类型：

• 重新托管（Rehost，提升并转移）：将服务“按照原样”进行虚拟化，并转移到云资源中。它们通常用于专有的应用服务，如 web 应用或内部自建应用。

• 重新平台（Re-platform）：使用云原生替代方案将内部自建服务“按照原样”转移到云中，例如云托管的数据库。它也可以包含迁移至 PaaS 的服务。

• 重新购买（Repurchase）：将服务转移至 SaaS 产品（如果存在的话），如使用 Office365 的电子邮件和文档等。

• 重构（Refactor）：部分或全部地重新设计服务架构，以充分利用云原生服务，比如微服务架构。

• 保留（Retain）：原样保留一些服务，通常是遗留或高度定制的后端。

• 停用（Retire）：如果可以停用以前的服务的话，那使用原生服务替换现有的服务。

典型的云迁移项目方法论

在整个项目的过程中，很重要的一点就是持续监控和管理云环境，以确保其安全、经济高效，并与业务目标保持一致。这可能涉及到持续的维护和支持，以及对基础设施和应用的定期优化和升级。云迁移的典型方法涉及多个关键阶段，包括：

发现阶段：发现阶段用来定义业务和技术场景/范围，以及要迁移的资产：

• 迁移的范围

• 业务信息调查

• 技术信息调查

• 资产和 CMDB 发现

评估阶段：评估阶段用来规划迁移并查看潜在的执行方法：

• 业务评估

• 技术评估和 PoC

• 迁移的任务罗列（backlog）和 MVP

• 迁移规划和批准

迁移：迁移阶段用来运行规划的迁移步骤，包括技术和组织方面的措施：

• 技术迁移

• 组织迁移（流程和结构）

• 稳定化（Stabilization）

• 准备移交至 SRE/OP

运行状态阶段：由指定的运行团队持续跟进：

• SRE/DevOps 团队根据实际情况进行管理

通常会迁移哪些服务和特性？

在进行迁移的时候，通常该迁移和配置哪些服务呢？下述是常见的示例：

• 数据：静态数据、SQL、NoSQL、文件存储

• 网络：拓扑、VNETS、子网、LB4/7、防火墙、VPN、路由器、连接等

• 计算：应用和服务器

• DEVOPS：构建、测试和部署流程

• 项目和 BU：组织结构

• 安全性：WAF、安全组、隔离、对等、秘钥、证书、监控等

• 预算：控制和监控

• 可观测性和 SRE：监控、日志、跟踪、告警、事件处理、补丁等

• IAM：用户、组、权限和 AD/LDAP 等

• 控制：管理和监督

迁移用例：技术场景

迁移用例指的是企业需要将其 IT 基础设施和服务迁移至云中的某些具体场景和情况。根据业务类型和当前 IT 基础设施的状态，这些用例可能会有所差异。各种各样的用例可以驱动不同的云迁移和技术场景，包括：

• 数据：静态数据、文件和数据库

• 网络基础设施

• 计算资源和应用

数据迁移

首先，我们看一下数据迁移的一些方案。

静态数据：

• BLOB 和静态数据

• 使用在线传输进行迁移：UPLOAD、RSYNCH 方法

• 离线方法，如传输设备或归档媒体

• 取决于数据的大小

文件数据：

• 文件和目录数据

• 使用在线传输，如 SMB、UPLOAD 和 RSYNCH

• 离线方法，如传输设备或归档媒体

• 取决于数据的大小

(No)SQL 数据:

• 数据库数据

• 导出和导入

• 实例 synching

• ETL 方法

• 迁移工具

• 数据库文件传输

• 虚拟化提升并转移

其次，我们看一下网络和拓扑结构迁移的一些方案。

网络与拓扑结构迁移

网络迁移通常是最需要人工操作的，因为它需要将物理基础设施和拓扑结构映射到云供应商特定的 IaaS 中。典型的方式如下所示：

最后，我们看一下计算服务迁移的一些方案。

计算服务迁移

计算迁移涉及将应用服务器、应用和服务器集群迁移到云中。它不仅仅是迁移基础设施，还可能为云环境重构服务的架构。常见的方法如下所示：

重新托管

• 重新托管服务器：用来将现有的服务器“按照原样”提升并转移到云中的方式

• 虚拟化内部自建的主机并将镜像上传至云中

• 通过这些云镜像创建实例或实例组

• 还可以使用云供应商提供的一些内部迁移工具来指导这一过程

• 最容易实现，但不能充分利用云架构的优势

重新平台:

• 重新平台服务：将服务迁移至类似的云原生技术

• 应用服务，如 Web 服务器、WebAPI、REST 应用，可以被“Docker 化”，并托管在容器引擎（如 Kubernetes）上。直接部署到云托管的应用沙箱中，如 EBS 或 AppEngine

• 应用的二进制文件并没有重构。它只是“原封不动”地部署到云管理的服务中。

重构

• 重构服务：也就是对应用架构进行重构，使其最适合可用的云服务

• 这高度依赖你的架构，但是很可能会包含如下内容：

• 将应用逻辑分解成适当的微服务或宏服务

• Docker 化并部署至容器服务，如 Kubernetes

• 使用原生的消息和事件服务来提供服务间的通信

什么是 Docker 和 Kubernetes？

我们需要注意的两项关键技术是 Docker 和 Kubernetes，以便于在将应用迁移至云的过程中获益。

容器化和 Docker

• 容器化是一个构建轻量级、自包含镜像的过程，该镜像中包含了所有的操作系统、中间件和要部署应用的二进制依赖。

• 镜像一旦构建完成之后，就可以部署至支持 Docker 的操作系统（大多数均支持）中并且能够“按照原样”运行。

• 与 VMware 类型的镜像不同，Docker 镜像非常小，可以在任何操作系统轻松扩展。

• 它们是许多云原生技术的关键所在，可以移植到任何地方。

Kubernetes

• Kubernetes 是一个“容器编排器”平台，它是一项“一站式”的技术，能够管理任意容器的部署、监控、扩展、安全性、负载均衡、健康和进程间通信。

• 它是实现云收益（如可扩展性、管理服务和成本）的最常见事实标准技术之一。

我们进一步看一下云迁移的业务影响，其中既有积极的，也有消极的。

业务影响

积极影响和消极影响分别是什么呢？

与所有的组织化变革一样，我们需要考虑潜在的影响。

积极的影响

• 成本更低：你只需要为使用的资源付费（计量服务）

• 管理服务：服务的补丁、升级、可用性均会由平台为你进行管理

• 弹性：服务可以根据需要自动扩展

• SRE：提供了像监控、跟踪、DRaaS 这样的支撑技术，并且能够更加紧密地集成，实现开箱即用

• 控制：你可以使用 IaaS 和 PaaS 来选择想要达到的控制水平

• 授权：现在，团队可以完全拥有自己的服务，直至生产环境

消极的影响

• 重新培训：对于运维、运行时和开发部门，需要进行组织上的重新培训

• 控制：对环境的控制权会有一定的损失

• 流程：业务流程和结构可能必须要做出改变和适应，以更好地支持云（DevOps 和 Ops/SRE）

• 重构：应用和服务可能需要重构，以更好地利用“现代”架构模式

• SRE：现有的监控和恢复方案可能也需要替换，从而会带来成本的增加

• 停机时间：迁移所造成的停机时间可能是一个问题

如何缓解这些影响呢？

业务

• 循序渐进地进行迁移

• 确定迁移的范围并加以控制，你并不需要一次性完成所有迁移

• 既有项目与新项目

• 对于既有（brownfield）项目，使用重新托管、重新平台或混合云作为起点。不要尝试一开始就试图重构所有的东西。

• 对于新（greenfield）项目，在设计时应该考虑云的问题。

• 员工和团队

• 对现有员工进行云技术的再培训，或使用新招聘的员工来增强他们的能力。

• 对于运维部门，保持结构不变，或将其转移到项目团队中。

• 预算控制与筹资模式

• 使用集中式的资金管理或分布式的项目资金管理方式

• 审查哪种方式最适合你

技术

• 服务迁移

• 首先，从数据服务开始，然后是计算服务，接下来是网络，但是请注意“事实来源”问题和复杂性。

• 始终根据要迁移的服务来实施安全性、IAM 策略、预算控制和可观测性。

• 在思想中，始终要有一以贯之的最终状态，即便只将其中的一部分进行了迁移。

• 在适当的地方使用混合和重平台方案

• 微服务和容器化

• 云技术与容器化技术配合得最好。.

• 新的应用架构在设计时就应考虑到这一点。

迁移到云端一开始可能会让人感到畏惧，但如果仔细规划并有合适的资源，它可以是一个简单直接和相对无痛的过程。

为何迁移并不那么令人望而生畏？

需要记住的关键事项： 在研究云迁移时，必须记住以下几点和心理成熟度模型：

• 迁移可以循序渐进地进行

• 很多服务可以“按照原样”进行转移

• 只迁移有价值的东西

• 混合云方式能够达到“两全其美”

• 服务的重构可以逐步完成

• 迁移工具确实存在，可以帮助完成这一过程

总结

云服务是指托管在云中的基础设施即服务（IaaS）或平台即服务（PaaS）的产品。云迁移涉及将数据、基础设施和应用程序转移到云中的管理服务。一个成功的云迁移策略必须考虑技术和业务目标，并根据业务优先级确定增量式迁移的次序。利用“重新托管”、“重新平台”或混合云策略有助于最大限度地减少迁移过程中的工作量。尽管重构要迁移的服务有助于优化其对云的使用，但这并不是一个必需的步骤。如果计划得当，你可以一次只迁移一小部分，但仍然能够得到很大的好处。

原文链接：

Migrating to the Cloud: Is It as Intimidating as It Appears?