AWS CIO:速度与激情 企业云旅程五步走

Stephen Orban现任AWS企业市场战略总监。在加入AWS之前，他是道琼斯全球CIO，负责领导道琼斯集团的信息技术战略和实施。Stephen在道琼斯内部率先倡导了“云优先”的战略，帮助道琼斯集团全面采用云服务，“All-in-AWS”。基于自身的经验和AWS丰富的服务，Stephen开设了专门面向企业客户的专栏，探讨企业客户在采用云服务过程中最重要的议题，并分享AWS客户的成功经验。

今年的AWS旧金山技术大会令我颇有惊艳之感。我有幸在大会前的企业云专场做了题为《企业的云旅程》的主题演讲，并在众多企业客户及其它业方的关注之下分享了自己的心路历程。除了丰富的新内容、新服务以及来自各个行业且规模不一的客户的精彩介绍，AWS合作伙伴生态系统亦呈现出不断发展之势。三年之前，浏览合作伙伴的展示内容只需15分钟，但今年琳琅满目的布展内容给我带来了长达数小时的美好回忆。

云已经成为新常态

实现云技术是一场漫长的旅程，我们无法在一夜之间走完这段道路。企业在完成这段旅程中会面临种种挑战与机遇。企业踏上的这段云旅程可以也应该以流程化姿态享受其过程。在此期间，大家有机会成功降低成本、提高执行速度并发展新型技能，同时为客户带来更加可靠且全局可用性更高的服务内容。

目前尚未踏上这段旅程的企业则正在考虑如何才能将云技术引入自己的现有环境。这将帮助他们在向所关注领域投入资源时，充分享受由云技术所带来的种种优势。

在我曾任CIO的道琼斯公司，我们自上世纪七十年代开始、每十年专注对企业架构进行一次调整。在这种情况下，坦白地讲，大部分基础设施与流程并没能带来预期效果。我们在新项目的推进速度方面也较为迟缓，因此失败的尝试往往会导致高昂的成本支出。而近年在新项目的推进过程中，我们通过与AWS协作而积累到大量专业知识与经验，技术更新速度也得到长足进步。我们从单一新型应用程序起步，随后构建起VPC将该应用与位于防火墙后的服务项目加以对接，迁移部分灾难恢复应用系统，并在具备一定经验储备后仅用时六周就完成了一座数据中心向AWS的整体迁移。其后，我们下决心在三年内将75%的整体基础设施转移至云环境当中。我们在实施过程中学到了很多，这使我们赫然发现在云环境下竟然能够如此快捷、如此出色的成功构建新架构，而云部署的实际效果远远优于原有内部基础设施方案。我们开始考虑将基础设施事务分别交由AWS与自有数据中心承担，并利用AWS作为各个项目的主要实现手段。

通过总结自身经验以及与客户进行交流，我发现一旦这段云旅程步入正轨、企业积累到一定经验，其它事务将以加速方式结出喜人的硕果。云技术带来的收益非常明显，而且在我们了解到如何打理云服务这一新型技术之后，原本几乎不可能实现的目标将成为云迁移名单中的优先选项。在各个阶段，大家都能够从多种方案中做出选择，包括是否重新设计开发运维、是否使用AWS Marketplace、是否接受开源机制或者与之相关的技术方案组合。随着对云体会的不断深入，正确的IT道路将自行出现在我们面前。也就是说，目前规模庞大的可用AWS服务选项及其不断改进的良好态势已经极具吸引力，大多数正在考虑将云计算引入自身体系的大型技术企业都很难抗拒这种诱惑。大家可以了解如何才能将AWS融合到自身建立起的现有网络拓扑结构、服务器与存储模型、内部虚拟化、桌面管理以及企业IT管理模式当中。

下面一起来看好消息……

AWS并不是一个非此即彼的命题

目前已经存在大量执行策略，用于指导大家保证AWS能够与现有投资资产并行不悖。整个迁移过程的实施速度尽在控制，并可根据业务需求及压力作出调整。

作为初期目标，我们不太可能刚一起步就打算将所有业务全部迁移至云环境当中。而且从合理性角度来看，中止一切现有活动、直接进行现有基础设施迁移也毫无明智性可言，特别是在现有基础设施仍有其专长所在的情况下。

很多客户告诉我们，他们发现其能够在不对现有基础设施进行任何修改的情况下轻松体验AWS的实际使用感受。在此之后，客户也能够非常便捷地在现有基础设施与AWS之间建立起业务对接关系。一旦连接建立起来，我们将迎来充满可能性的新起点。从这里开始，大家的云之旅程已经悄然开启。

一段典型的企业云旅程

在过去几个月中，我有机会与来自不同行业且足迹遍布世界各地的几十位企业客户进行交流。将这部分信息与我个人在道琼斯及News Corp在转化为云优先企业过程中积累到的经验相结合，我为大家总结出了以下这段常见的云技术实现流程：

1. AWS试点项目。试点对象可以是经过明确定义的实施项目也可以是采取模糊成功指标的研发工作。企业中的常见起步实例包括简单网站、移动应用程序后端、灾难恢复站点、开发及测试环境下的额外容量、非关键性任务应用程序迁移或者创建面向未来需求的新型执行标准。

2. VPC集成。在此阶段大家的任务是建立连接，从而保证AWS能够作为现有企业网络之外的延伸机制发挥功效。网络工程师应当以审慎的态度推进这项工作，从而避免带来任何可能给企业带来不便的负面状况。不过除此之外，这其实是一项非常简单的实践活动，所需时间仅为数小时、而非数天或者数周。

3. 混合架构承担工作负载。企业中的大多数工作负载都属于这一类别。通常情况下，现有基础设施中的一部分关键性资产需要耗费较长时间才能顺利被迁移至云环境当中。但除此之外，那些较为灵活的系统——具体情况取决于资产实际情况——能够立即成为迁移备选项。首先将注意力集中在这些非关键性系统中能够帮助企业客户快速获得收益，而在此期间积累下的经验与信心也有助于企业日后更顺利地完成共享资产迁移。在经历过数次系统迁移之后，大家会发现整个流程要比预想中更为轻松。我就曾亲眼见证过多家客户的实际执行过程，在运行混合应用程序方面积累到一定经验之后，这些企业开始全面奉行云优先指导方针。这种作法还能够鼓励企业以逆向思维看待云迁移工作。相较于论证某个项目能否在云环境中实现，企业更应当去证明其为什么无法在云环境中实现。在这种情况下，企业往往倾向于利用托管SaaS解决方案打理各种常见的企业后台功能，例如HRIS、电子邮件以及协作系统。

4. 使用DirectConnect. 在内部数据中心与AWS之间直接起用专用连接通道DirectConnect往往成为网络敏感型应用程序在混合模式下正常运作的前提条件。根据我的个人经验，大家在实际实施过程中也需要采取此类方式。当然，直接连接并非尝试混合架构时的先决条件。