第7章 云原生还是直接迁移

最初发布于2017年1月30日：http://amzn.to/cloud-native-vs-lift-and-shift

“在我们渴望的机会、不堪的回忆以及过往的错误之间，永远存在着矛盾与冲突。”

——Sean Brady

我曾经与多位高管探讨过对IT组合内各类应用程序进行迁移的具体方法。虽然这些问题不存在百试百灵的通用答案，但我们仍然会投入可观的时间同企业一道制定严谨的迁移计划，同时充分考虑到其实际目标、应用程序的年龄、架构以及现有约束性条件。而这项工作的意义，在于帮助他们将现有IT组合中的应用程序划分至6种迁移策略中的一种（第6章）。

在某些情况下，选择可能显而易见。我看到很多组织正着手将其后台技术与最终用户计算类应用程序迁移为即服务模式（以“重新采购”方式转换为Salesforce以及Workday等方案）；一些组织希望清退自己不再使用的系统；也有部分组织打算稍后再回头处理那些自己可能不想或者没有能力立即迁移的系统（特别是大型机，但实际上大型机也可以迁移至云端，详见第9章）。

但对于其他一些情况，答案可能没那么明显。第7章将探讨重构与重新托管（即“直接迁移”）之间的区别。我曾听到很多高管（在学到更多之前我自己当初也同样）表示，他们只会在“找到正确方法”之后才选择进行云迁移——换言之，找到迁移至云原生架构的途径。大多数高管倾向于选用重新托管策略，因为他们希望实现快速的迁移。诸如数据中心租约到期、避免昂贵的更新周期或者快速符合预算分配，都足以成为这种强有力的理由，并直接带来相当于内部总体持有成本30%左右的节约成效。

平台更新可以视为重新托管与重构之间的一种存在状态，意味着我们不需要投入大量时间进行整体重构，但同时又针对应用程序进行一定调整以充分发挥云原生功能或者实现其他优化效果。这部分中间地带包括根据实际容量场景设置正确的实例规模，无须过度购买仍能确保其具备规模伸缩能力；或者由WebLogic等付费产品转移至Apache Tomcat等开源替代方案。

那么，哪种方法更适合您的组织？

如果不考虑特定机会和限制条件（感兴趣的朋友可以通过邮件与我就此进行交流），我们很难得出明确的答案。但在这里，我可以通过一些故事为大家提供一些可供参考的观点。

首先来看Yury Izrailevsky在博文中表达的意见。Yury是网飞公司云与平台工程副总裁，同时亦是业界备受尊敬的意见领袖。

网飞公司的云迁移之旅始于2008年8月，当时我们刚刚经历了一场严重的数据库损坏事故，且在三天时间里无法向成员配送DVD产品。就在那时，我们意识到我们必须远离现有数据中心内纵向扩展关系数据库中存在的单点故障，转向更为可靠、具备横向扩展能力的分布式云系统。

我们选择了Amazon Web Services（AWS）作为云服务供应商，因为其为我们提供规模最大且最为广泛的服务与功能选项。到2015年，我们的大多数系统（包括全部面向客户的服务）已经全面迁移至云端。从那时开始，我们开始进一步投入时间以寻求安全可靠的云迁移路径，希望解决计费基础设施与客户及员工数据管理系统两大难题。我们很高兴地在2016年1月，也就是经过七年的持续努力，终于全面完成云迁移，同时关闭了流媒体服务使用的最后一个数据中心！

考虑到云计算带来的明显收益，我们为什么用了整整七年才完成全面迁移？实际上，云迁移是一项艰苦的工作，我们在这一过程中必须做出一系列艰难的选择。可以说，最简单的云迁移方式就是将所有系统从数据中心不经改变，直接投放至AWS云中。但如果这样做，内部数据中心的所有问题与限制也将随之一同流入云端。因此，我们选择了云原生方法，几乎重构了自身所有技术方法，并从根本层面改变了企业的运营方式……我们构建起众多新系统，也在过程中学习到大量新技能。将网飞全面改造成一家云原生企业是一项费时费力的大工程，但这一举措最终使我们在市场上占据更为有利的位置，并持续快速发展成强大的全球电视网络。

Yury的经验既有指导性又具启发性，我完全相信他们摸索出的重新架构方法与经验充分符合网飞公司的实际需求。

但大多数企业与网飞的情况不同，其选择云迁移的动机自然也有所差别。

几年之前在道琼斯担任CIO时，我们最初抱持着一种象牙塔般的理想态度——即迁移的一切都需要进行重新架构，从而全面甚至强制性实现自动化与云原生功能。这套方法原本工作得不错，直到我们必须在不到两个月时间内腾出一座数据中心。我们开始直接将该数据中心内的大部分负载直接托管至AWS中，同时进行了一些平台更新工作，希望能够在实现某些小规模优化的同时继续满足时间限制的要求。有些朋友可能会说，要不是之前已经积累了一些经验，我们根本不可能在短时间内完成这项工作——也许有道理，但我们确实在匆忙之中交出了不错的答卷。我们将成本降低了约30%，这个经历帮助我们建立了商业案例，通过将75%的应用程序迁移至云端帮助整个新闻集团（我们道琼斯的母公司）节约或重新支配超过1亿美元资金，并将我们的数据中心由原本的56座合并为6座。

作为数字化转型工作的重要组成部分，GE石油与天然气公司将数百款应用程序重新托管至云端。在这一过程中，他们将总体拥有成本降低了52%。GE的Ben Cabanas作为一位极具前瞻性的技术高管，曾告诉我与我的经历相似的故事。他们当初也曾计划对一切进行重新设计，但此后他们很快意识到这项计划耗时太久，而直接进行重新托管同样能够带来巨大的成本节约以及宝贵的经验积累。

在这方面，耐克公司全球CIO Jim Scholefield作出了一语双关的总结：“有时候，我会告诉团队，直接‘动起来’就行了。”

有些批评者可能会说，重新托管改变不了“烂摊子”，但我认为不止于此。我将重新托管的优势归结为两大核心。（我相信还有其他优势，感兴趣的朋友可以联系我提供更多观点，我会在后续文章中讲述您的故事……）

首先，重新托管在自动化情况下需要的时间投入更低，其通常能够直接将总体拥有成本降低约30%。在从过程中积累经验的同时，您将能够更轻松地重构技术以进一步增强成本节约效果，包括正确调整实例规模以及选择开源替代方案。您的实际节约效果可能与我们说的有所不同，具体取决于您的原有内部IT成本以及对成本的衡量准确度。

其次，一旦开始在云端运行，应用程序重构与重塑的难度将显著下降。这一方面是因为工具链集成度的明显提升，另一方面则是因为员工将在接触重新托管方法的过程中逐步掌握云原生架构的相关知识。我们的一位合作客户就曾在几个月时间内通过对多款核心客户应用程序进行重新托管节约了30%的成本，并在后续无服务器架构重构中一举削减了高达80%的总体拥有成本！

重构往往需要更长时间，但对于企业而言，这也是一种非常高效的文化构建途径。如果应用程序符合市场需求，亦会带来健康的投资回报率。当然，更重要的是，重构将为您在接下来的数年时间中奠定稳固的持续创新的基础，帮助您在激烈的市场竞争中提升业绩表现。

虽然我承认，在这方面不存在适用于一切组织的统一答案，当业务应用需要新的能力（包括性能、可伸缩性、全球化、实现DevOps或敏捷模式等）时，建议大家充分考虑利用云原生架构进行重构。而对于那些您不打算重新采购、清退或者稍后处理的稳定应用程序，重新托管或平台更新往往是比较理想的选择。无论选择哪一种迁移路径，您都将为持续重塑创新铺好道路。