第8章 认真考量直接迁移方法的四个理由

——Joe Chung，AWS企业战略师兼布道者

初次发布于2017年12月6日：http://amzn.to/4-reasons-lift-and-shift

“……需要改造的是环境，而非人； 可以确信，只要为人提供正确的环境，他们将表现得更好。”

——Buckminster Fuller

作为AWS公司的一名企业战略师，我经常与客户讨论应采取哪些策略帮助其将工作负载迁移至云端。有时候，企业客户的高管会表示不想把任何遗留工作负载迁移至云端；相反，他们希望专注于利用AWS Lambda等无服务器服务开发出全新架构。我也理解为什么企业不愿意背着传统技术债务将应用迁移至云端——虽然这样做有助于减少“烂摊子”，还有成本节约的好处。此外，考虑到我们生活在一个安全审查极为严格的时代，组织在云环境中将执行远高于内部数据中心的标准。这可能要求企业对其应用程序进行重构；但根据我的个人经验以及从众多客户身上观察到的实际情况，直接迁移应该被视为将工作负载迁移至AWS云的核心迁移路径之一。

AWS公司企业战略全球负责人Stephen Orban就曾通过一个典型案例解释了各类组织为何应当将直接迁移视为一种重要的迁移策略与手段。Stephen提到的相关助益包括降低成本以及提升性能与韧性。我会在后面对此进行深入讨论，因为根据实践经验，我发现直接迁移对于大多数组织而言确实是一种均衡且整体性的迁移方法。

在讨论直接迁移为何能够为应用程序注入新的活力之前，我想首先介绍一下考量软件应用的新型心智模型。我认为应用程序就像是自然界中的有机物，其出生、进化、变形、沟通，并与其所处环境内的其他生物进行相互作用。进一步说，这些应用程序与其他应用程序沟通并共同生存在作为生态系统的数据中心环境之内。在我看来，这些应用程序的执行与演进能力在很大程度上受到实际环境的影响——类似于生物DNA会根据周边环境调整自身表达。在这里，我希望提出的论点是，AWS能够提供更理想的环境（主要体现在服务规模与多样性方面），且其实际水平远远超过绝大多数内部数据中心。

理由一——SSD为王

AWS提供13个计算实例系列，具体包括内存优化型实例、存储优化型实例以及服务器优化型实例等。尽管虚拟化为企业带来了更灵活的资本分配能力，但大多数组织显然无法提供同样丰富的资源配置选项。而且需要强调的是，这种性能多样性在利用固态驱动器（Solid-State drives，SSD）的场景下变得尤为重要。配备SSD的存储I/O密集型实例特别适合匹配数据库等工作负载。目前各类存储介质的价格正在全面走低，但大多数企业仍然很难承担得起将原有磁盘驱动器全部升级为SSD所带来的高昂投入。在这方面，SSD的速度通常比传统磁盘驱动器快2～5倍，因此能够为某些特定工作负载类型带来巨大的性能提升空间。此外，在AWS的帮助下，组织可以更有针对性地使用SSD支持型实例。当然就像我之前的公司那样，客户也可以将全部数据库迁移至SSD支持型实例中，从而为每一位员工带来生产效率增强。

理由二——破除应用程序顽疾

大多数人都会从横向扩展的角度理解云资源的弹性，但其同样具备纵向扩展能力。虽然大家可以对内部环境进行纵向扩展，但AWS提供的上限阈值要远超大多数内部数据中心。例如，AWS中资源配置最为强大的实例来自X1虚拟服务器系列。这一x1e.32xlarge实例拥有128个vCPU、4 TB内存，配备SSD存储以及接入EBS的巨大专用传输带宽（14000Mb/s）。客户普遍利用这一实例承载SAP HANA等高强度工作负载。

我接触过的一位客户，他就面临着严峻问题：发现某款应用程序中存在导致性能瓶颈的查询错误。由于更改代码的风险太高，因此其选择将该数据库服务器直接迁移至X1实例，并在当前峰值使用需求结束后回退到更加低廉的实例规模。作为曾经在IT部门负责应用程序开发的员工之一，我一直非常赞赏这种利用基础设施性能破解应用程序顽疾的办法。当然，我也希望能在开发周期之初就揪出这些问题，但如果做不到，AWS提供的强大资源储备能够帮助你解脱束缚，这是开发运营团队的福音。

理由三——各有所长

关系型数据库（简称RDMS）在过去40年间一直是应用程序后端的唯一选项。尽管关系数据库在多种查询类型中确实有出色的表现，但仍有一些可能令其“水土不服”的工作负载存在。全文搜索就是一个典型实例，这也解释了基于Lucene技术的Apache Solr以及ElasticSearch为何能够在这类用例中广受好评。

下面再来聊聊我职业生涯中的另一个故事——这也是我多年经验总结出的一项结论，即“各有所长”。具体来讲，我会根据特定用例的需求选择最适宜的技术，而非依据团队已经掌握、比较适应的技术做出最佳技术决策。这项原则的一个实例，是我参加的一个应用程序团队曾尝试在业务发展过程中开发更多的创新成果。当时，用户一直在抱怨我们缺乏创新精神并且开发不够敏捷，特别是在应用程序的内部搜索功能方面做得不够。我们打算在应用程序之外启动一个ElasticSearch实例，借此将应用程序数据整合至ElasticSearch中，而后对前端Web应用程序进行小规模重构。（ElasticSearch提供多种基于REST的出色API）我之所以一直对这个故事印象很深，是因为团队当时没有冒着巨大风险对应用程序进行整体重构并立即引入Amazon ElasticSearch或者Amazon CloudSearch实例。通过这种方式，团队也不需要在NoSQL集群的配置技能与管理方面投入精力与资源。AWS云直接使众多服务各取所需，帮助应用程序顺利演进。

理由四——整体式应用的演进

相信大家对于微服务架构的优势已经不再陌生。总结其核心强项，就是经过精心设计的微服务架构往往拥有可观的独立部署能力与可扩展性。此外，如果微服务能够配合正确的粒度控制或“限界情境”，那么风险影响半径也将得到有效削减（例如性能与变更等）。

像网飞与亚马逊这样的企业已经全面普及微服务架构以推动创新并扩展自有应用程序。但一般来讲，人们对微服务仍然存在着不少认知误区——特别是其独立性，或者说该如何在不同微服务之间进行清晰的界线划分。对于这个问题，我和我的团队总结出了一套简单有效的判断方法：如果破坏掉数据库，有多少其他团队或者微服务会因此受到影响？很多客户在这种情况下才会不安地意识到，他们的后端实际上仍然为多个团队所共享。在我看来，为了实现独立部署与可扩展性，微服务应该与代码库、表达层和业务逻辑直至持久性存储隔离开来。

如果我对微服务隔离的观念引起了您的共鸣，那么如何在架构上实现这种隔离将耗费不菲。在我看来，在内部基础设施中，启动新代码库、Web服务器、应用服务器以及数据库服务器往往会带来高昂的成本（包括配置与运营等成本）；此外，配置过程也将相当缓慢。与之相反，在云环境中启动这些基础设施组件则既快速又便宜，特别是在使用Amazon RDS或者AWS Lambda的情况下。

关于如何对整体式应用程序进行演进，我们已经在re：Invent大会上多次提及——也就是gilt.com的演示资料。可喜的是，gilt.com演讲人讲解的应用程序的演进同样适用于众多企业级应用。简言之，由于可扩展性与敏捷性有限，Gilt当时需要发展其电子商务平台。因此，该公司开始在原有应用程序之外启动微服务架构，并一路推进直到围绕原有的核心应用程序形成了众多的“微服务丛林”。这里要向大家强调一点：这类微服务架构会很难在内部环境构建完成——特别是考虑到前端与后端技术多样性。

如果您一直因为“烂摊子”问题而怯于行动，希望本章内容能够帮助您开拓思路、为直接迁移做好准备，并勇于将其作为迁移工作中的核心策略。