使用云伙伴系统，让您的迁移之旅不再孤单

Edmunds.com 全面迁移到 AWS 的相关经验

伙伴系统这个概念已经使用了数十年，应用范围涵盖生活的许多方面，包括学习、工作和探险。无论涉及哪一方面 (比如大学新生与其学长配对、空军飞行员与其僚机驾驶员或者您的周末潜水伙伴)，大多数伙伴系统不外乎两个目的。一个是安全性，通常出现在需要双方相互照顾的体育或危险活动中。另一个是新入学的学生或新来的员工与经验更丰富的伙伴配对以便获得培训和指导，以免出现常见的新手错误，从而自信满满地快速进步。

就我个人来讲，如果 2012 年在我开始全面向云迁移时拥有云伙伴，一定能帮我解决不少难题并省去实验的麻烦。当时，我是北美地区最大的汽车购物网站之一 Edmunds.com 的首席信息官。

但与现在不同的是，当时很难从正在成功迁移的其他公司找到大量伙伴系统资源。如果具备大规模全面的参考案例 (除 Netflix 之外)、托管迁移计划或成熟的咨询合作伙伴生态系统，则迁移工作会容易得多。幸运的是，现在有大量专注于云迁移的人员、流程和技术，这意味着，组织再也不用像我们当时迁移 Edmunds.com 那样孤军奋战了；而且，加快云使用率和更大限度节省成本的相关专业技术水准也在不断提升，这使全面迁移战略变得比以往更加可行。

作为一名终身冲浪爱好者，我可以告诉您，如果有伙伴系统的帮助，即使在危险条件下，冲浪也不是什么了不起的事情。单打独斗被认为是终极精神追求。而如今，如果我要去世界上的陌生地方冲浪，则更愿意采用更加实用的方法。在登上冲浪板之前，我会试着找一位曾经去过那里的“伙伴”，从他那里了解所需的所有海浪相关信息。例如，珊瑚礁有多浅？有鲨鱼出没吗？哪种潮汐状况最适合冲浪？听取了这些方面的建议并学习了别人的经验后，我心中的疑虑通常会打消不少，而且冲浪体验也会得到提升。

最近，我加入了一个前任首席信息官 (他们构成 AWS 企业战略团队) 团体。我们的目标是帮助技术高管思考和拟定其云优先策略，为此我们所采取的一种方法是：制定和简化新型迁移加速计划，以利用我们所积累的知识 (经验是没有压缩算法的)。作为前任首席信息官和 AWS 客户，我们曾经负责过自己的云迁移工作，并在此过程中帮助过各种类型和规模的企业完成了转型，我们的经历就像我到一个新地方冲浪时从伙伴那里获得提示和建议一样。

回想一下，我从 Edmunds.com 迁移经历中得到了三点重要启示；正如您将看到的，即使我们在 2016 年初关闭了最后一个 Edmunds.com 数据中心，我们经历的过程也仍然与大部分企业迁移当前所经历的云采用阶段非常接近 —

我们将完全停止运营这个高性能数据中心

实际上，这不是当时的确切想法。作为当时的首席信息官，我的主要目标是交付技术能力，以超前满足业务需求。在进行云迁移前的 7 年里，我们不知疲倦地工作，开发出了一种被认为极其高效的基础设施运营和 DevOps 实践。但是，这种效率需要企业付出代价，尽管它提供了每日自动发布能力和前所未有的可靠性。这种代价就是，公司需要将越来越多的有限资源分配给支持代码 (私有云和 DevOps 工具集)，从而导致没有足够的资源用于面向客户的应用程序代码 (新的客户功能和服务)。我们需要一种新的模式来控制支持代码与客户代码的比率，而不用牺牲任何功能。

2011/2012 年出现的新兴云趋势为企业提供了一种备选方案，它强调与单个公司孤军奋战相比，公有云 (尤其是 AWS 的规模) 能提供更好的基础设施和更优质的服务，而且价格更具竞争力。然而事实却不容乐观，围绕它的新闻层出不穷，报道内容无外乎：与成熟的本地安装相比，云更加昂贵且不太稳定。Netflix 早期曾采用 AWS，当时的情况有力地证明了这一论点：较成熟的大型企业可以在云中运行关键操作；但当时，我们无法为 Edmunds.com 业务找出更类似的参考实施。

同行参考在当时对我们来说极其重要，因为没有任何值得称道的伙伴系统迁移资源可以帮助我们利用成熟的云采用模式。

在缺乏这方面知识的情况下，我们分两步构建了我们的业务案例，这最后成为了任何公司进行云迁移的标准做法：

1. 概念验证项目，即展示在云中运行关键操作的可行性。
2. 全面云运营的实际财务模型，它能够经受住时间的考验，并至少展示出与当前基础设施的支出状况基本相当 (或成本更低) 的特征。

事后想来，决定采用完整版核心 Edmunds.com 网站来验证云的可行性并不是进行概念验证的最快或最简单的选择。但在将近 6 个月时间内经过几个专门的工程师的反复试验后，我们获得了无可争议的证据，甚至连之前总是跟我们唱反调的人都认为，云是 Edmunds.com 的最佳选择。如今，AWS 和出色的系统集成商开发了伙伴系统方法 (如停放区，这是 AWS 云采用框架的一个组件)，让迁移业务案例比我们当初采取的方法进展得更加快速。

我们对结果非常满意，进而转入下一步，开始深入探究云经济。这时，我们尚未发现通过采用云原生架构实现的生产力的巨大飞跃，但我们相信迁移到云不太可能会毁掉公司。

开发财务模型似乎是一项同样让人望而却步的任务。此类模型必须真实，并且必须避免激进的优化假设。我们已经做到了高效和节俭，但老实说，我不知道最后我们的运营费用是会增加还是会减少。因此，经过一个多月的分析，我惊讶地发现，我们开发的保守财务模型证明，在完成向 AWS 迁移的两年计划 (与主要数据中心租约到期时间一致) 后，我们竟然会节省一小笔运营费用。这还不包括资本设备支出每年所节省的数百万美元。这个计划也有点像沙袋，因为它以纯粹的简单地搬运假设为基础，而我们确信在整个迁移过程中运营支出会大幅降低，但我们不知道如何提前证明这一点。

财务模型表现不俗，概念验证结果也极具说服力，因此，我们怀着激动的心情向首席运营官做了汇报，这次汇报受到了热烈欢迎，首席运营官立即批准了我们的 AWS 迁移建议。

我要指出的一个形式上的错误是，我过分强调了自由现金流的节省。我几乎完全忽略了运营支出这个优势，认为它不是通过审批的前提条件；相反，我将侧重点放在了更大的组合现金节省数字上。但结果证明，支持运营支出预测假设对首席运营官而言更加重要。

现在 AWS 云经济小组重点关注的是，增强业务案例宣传信息和预测更深层次的云费用节省的能力。但是，这样一个通过成熟技术帮助客户进行迁移和 TCO 建模的团队当时尚未完全成形。现在，AWS 云经济小组会在云迁移早期提供一些最好的伙伴系统资源，因为该小组拥有数千个迁移的相关数据，此类数据可通过最大限度提高业务案例中的服务器利用率和员工工作效率，帮助预测和量化节省的费用。

我认为我们实际上要在这方面取得成功

它并非不堪一击。但如果项目涉及每一个应用程序和系统，就会面临相当大的风险，而且企业绝不会容忍因后端增强功能而导致的任何延迟或中断。不过，完成应用程序和数据迁移后，您会发现组织最大的风险与停机或性能问题毫不相干，而是与能否完成迁移相关。在迁移过程中停滞不前不仅会影响您的云 TCO 模型，还会让公司长期无法专注于优先事务。

如前所述，在云迁移中尽早“寻找伙伴”真得非常重要。已经创建的大量伙伴系统资源可帮助避免我们在 Edmunds.com 迁移中遇到的诸多难题，而 AWS 迁移加速计划 (MAP) 等计划或 AWS Database Migration Service (DMS) 等工具就是广泛使用且具有针对性的伙伴系统资源的两个示例。所开发的这些资源融合了来自数千个客户迁移的意见和经验，此类计划和工具涵盖了大量成熟的迁移模式，例如，从 Oracle 迁移到 Amazon 的 RDS 托管数据库服务。

尽管如此，在独自完成迁移的过程中，我们确实学到了一些有价值的东西。我相信，对于任何想要顺利轻松地到达终点的云驱动型组织来说，这些知识尤为重要 —

1. 调整您的初始迁移原则并不会对架构造成损坏或导致迁移失败。您的云迁移策略原则必须足够灵活，以适应云灵活性及在云中运行的新经验。实际上，我们在开始 Edmunds.com 迁移时所秉持的原则是，仅利用核心计算 (EC2) 和存储 (S3、EBS)。但是，我们之所以这么做是因为对更高级别的 AWS 服务 (如 Amazon RDS、Amazon CloudWatch 和 Amazon DynamoDB) 缺乏了解。我们很快意识到这些新型云原生服务的集成和成本优势，包括在客户代码上花费更多时间的功能。现在，Edmunds.com 使用的 AWS 服务有三十多种。
2. 为重构决策使用两周法则。我们是在灵活的原则 (可为我们提供重构机会) 下开始我们的两年迁移计划的；但由于数据中心租约的原因，任何因素都不能延迟两年目标，因此，直接迁移通常成为默认方法。然而，在迁移工作全面展开之后，团队却开发出了沿用至今的特定的两周经验法则。如果我们能在两周内重构堆栈内的次优组件或服务，我们就会重构，而不是直接迁移。例如，基于 NFS 的共享存储架构位于重构列表的前面，但它不符合两周法则，因此，我们将其安排在了迁移窗口的末期。另一方面，诸如负载均衡、缓存、OS 分配和 DNS 等许多对象也在迁移过程中使用新的两周法则进行了重构。根据迁移时间表或开发周期，您可能需要使用不同的时间段，但两周或一个开发冲刺是 Edmunds.com 的最优约束条件。此处提到的优质伙伴系统资源是指 AWS Application Discovery Service，系统集成商使用这项服务帮助公司发现和映射应用程序的依赖关系，然后再确定哪些内容适合直接迁移，哪些有机会重构。现在，您可以通过最近发布的 AWS Migration Hub 跟踪迁移状态。我会在以后的文章中介绍两周法则的其他相关信息。但在此期间，请务必阅读“将应用程序迁移到云的 6 大策略”，作者是 Stephen Orban，目前担任 AWS 全球企业战略主管。这篇文章很有启发性，提供了非常实用的构建思路。
3. 您无需弃用现有团队并重新聘用一组云专家。Edmunds.com 没有专门为云迁移招聘一名员工，更不用说“云专家”了。在这方面我们的经验是：建立清晰的领导机制和等效的云卓越中心 (CCoE)，并设定明确的目标和关键结果。我们的云迁移团队负责人 Ajit Zadgaonkar 的最初职责是领导我们的自动化测试团队 (SDET)。在与传统运营团队协作进行自动化配置及持续集成和交付方面，他的团队已经具备一定的经验。同样，Stephen Orban 也就此主题发布了一篇文章，建议您阅读他的这篇文章：“You Already Have the People You Need to Succeed With the Cloud”（您已经拥有成功实现云迁移所需的人才）。在这方面，需要考虑的另一个重要事项是，您要在新来的云/开发运营工程师与现有团队之间做出选择，前者对您的环境一无所知，后者在关键应用程序的依赖关系、流程和业务需求方面拥有多年的实践经验。我的 AWS 同事 Jonathan Allen 在 Capital One 中详细介绍了他经历的这个过程，以培训现有团队并让其为云迁移做好准备。

弄清楚人员和文化等因素与您做出的技术决策同等重要，因为在迁移加速进行并涉及更多应用程序时，他们使内部伙伴系统能够确保组织内的一致性。

我庆幸自己没有把未来搞砸

第三点也是最后一点启示更多的是关于迁移结束之后的事宜 – 从我在组织内的新职位和角度来看。在我们完成向 AWS 的迁移之后不久，我不再担任首席运营官/首席信息官，转而成为 Edmunds 的首位首席数字官。担任这个职务后，我的主要职责是开发下一代广告平台并将新的商业模式推向市场，例如，在线汽车零售和消息传递应用程序。因此，我从云服务提供者变身为消费者。回想起来，我绝对是一名要求苛刻的客户！

将所有应用程序和数据都按计划迁移到 AWS 之后，Edmunds.com 成功地将 IT 开支削减了 30%。通过开始使用云原生架构 (自动扩展、微服务、临时计算) 优化或重新思考堆栈的每一个组件，或者通过直接使用 AWS 服务将组件完全替换掉，团队实现了更大的节省。我的新团队努力完成的许多计划都有技术框架，这与最初迁移到 AWS 的对象不同，而且在有些情况下，它们完全是无服务器的。现在，已经出现了针对无服务器架构的新兴伙伴生态系统，它正在改变云和本地安装之间的对比结果。

这些新型 AWS 服务 (如 AWS Lambda、AWS Elastic Beanstalk、Amazon Kinesis 和 AWS GLUE) 绝不可能由 Edmunds.com 在内部合理地开发出来，但它们以之前难以想象的速度为客户提供了新功能。展望未来，在数据中心内可以完成的操作与云原生服务之间的差距只会越来越大。例如，主流的机器学习和人工智能与普通 Web 应用程序所要求的技术框架大相径庭。在内部维护这些不同的技能组合和专门的计算容量对大部分组织来说绝非最佳选择。

我会在以后的文章中，持续提供这方面的见解和建议。当然，目的是为了帮助您尽快上手，以便重塑自己的技术和业务。

在此期间，请试用伙伴系统，尽快开始或完成您的迁移。然后，您将可以使用云原生服务，减少用于维护基础设施的支持代码义务并交付更多客户代码。

最大的变化从简单的步骤开始 —

Philip Potloff
@philippotloff
potloff@amazon.com
企业战略家