“合抱之木，生于毫末;九层之台，起于累土; 千里之行，始于足下。” –老子
今年的Re: Invent大会令我颇有惊艳之感。我有幸以客户的身份参与到各前续活动之内，并在数十家企业客户及其它从业方的关注之下进行自我展示。除了丰富的新内容、服务以及来自各个行业且规模不一的客户之外，AWS合作伙伴生态系统亦呈现出不断发展之势。三年之前，浏览各参与方的展示内容只需10分钟，但今年琳琅满目的内容给我带来了长达1小时的美好回忆。
关于本次会议中的核心内容，请大家参看Andy所做之主题演讲。
云已经成为新的标准。
实现云技术是一场漫长的旅程，我们无法在一夜之间走完这段道路。在上一篇博文中，我写到了一部分企业在完成这段旅程中所面临的种种挑战与机遇。企业踏上的这段云旅程可以也应该以流程化姿态呈现。在此期间，大家有机会成功降低成功、提高执行速度并发展新型技能，同时为客户带来更加可靠且全局可用性更高的服务项目。
目前尚未踏上这段旅程的企业则正在考虑如何才能将云技术引入自己的现有环境。这将帮助他们在向所关注领域投入资源时，充分享受由云技术所带来的种种优势。
在道琼斯公司，我们自上世纪七十年代开始、每十年注对企业架构进行一次调整。在这种情况下，坦白地讲，大部分基础设施与流程并没能带来预期效果。我们在新项目的推进速度方面也较为迟缓，因此失败的尝试往往会导致高昂的成本支出。不过在新项目的发展过程中，我们通过与AWS协作而积累到大量专业知识与经验，技术更新速度也得到长足进步。我们从单一新型应用程序起步，随后构建起VPC将该应用与防火墙后的服务项目加以对接，迁移部分灾难恢复应用，并在具备一定经验储备后仅用时六周就完成了一座数据中心的整体迁移。到这时，我们才下决心在未来三年内将75%的整体基础设施转移至云环境当中。我们在实施过程中学到了很多，这使我们赫然发现在云环境下成果构建原来能够如此快捷、如此出色，其实际效果远远优于原有内部基础设施方案。我们开始考虑将基础设施事务分别交由AWS与自有数据中心承担，并利用AWS作为各个项目的主要实现手段。
通过总结自身经验以及与客户进行交流，我发现一旦这段云旅程步入正轨、企业积累到一定经验，其它事务将以加速方式结出喜人的硕果。云技术带来的收益非常明显，而且在我们了解到如何打理云服务这一新型标准之后，原本几乎不可能实现的目标将成为云迁移名单中的优先选项。在各个阶段，大家都能够从多种方案中做出选择，包括是否重新设计云梅、是否使用AWS Marketplace、是否接受开源机制或者与之相关的技术方案组合。随着体会的不断深入，正确的道路将自行出现在我们面前。
也就是说，目前规模庞大的可用AWS服务选项及其不断改进的良好态势已经极具吸引力，大多数正在考虑将云计算引入自身体系的大型技术企业都很难抗拒这种诱惑。大家可以希望了解如何才能将AWS融合到自身建立起的现有网络拓扑结构、服务器与存储模型、内部虚拟化、桌面管理以及管理模式当中。
下面一起来看好消息……
AWS并不是个非此即彼、非黑即白的命题。目前已经存在大量执行策略，用于指导大家保证AWS能够与现有投资资产并行不悖。整个迁移过程的实施速度尽在控制，并可根据业务需求及压力作出调整。
作为初期目标，我们不太可能刚一起步就打算将所有业务全部迁移至云环境当中。而且从合理性角度来看，中止一切现有活动、直接进行现有基础设施迁移也毫无明智性可言，特别是在现有基础设施仍有其专长所在的情况下。
很多客户告诉我们，他们发现其能够在不对现有基础设施进行任何修改的情况下轻松体验AWS的实际使用感受。在此之后，客户也能够非常便捷地在现有基础设施与AWS之间建立起业务对接关系。一旦连接建立起来，我们将迎来充满可能性的新起点。从这里开始，大家的云之旅程已经悄然开启。
一段典型的企业云旅程
在过去几个月中，我有机会与来自不同行业且足迹遍布世界各地的几十位企业客户进行交流。将这部分信息与我个人在道琼斯及News Corp在转化为云优先企业过程中积累到的经验相结合，我为大家总结出了以下这段常见的云技术实现流程：
1. AWS试点项目。试点对象可以是经过明确定义的项目或者是采取模糊成功指标的研发工作。企业中的常见起步用例包括简单网站、移动应用程序后端、灾难恢复站点、开发及测试环境下的额外容量、非关键性任务应用程序迁移或者创建面向未来需求的新型执行标准。
2. VPC集成。在此阶段大家的任务是建立连接，从而保证AWS能够作为现有企业网络之外的延伸机制发挥功效。网络工程师应当以审慎的态度推进这项工作，从而避免带来任何可能给企业带来不便的负面状况。不过除此之外，这其实是一项非常简单的实践活动，所需时间仅为数小时、而非数天或者数周。
3. 混合工作负载。企业中的大多数工作负载都属于这一类别。通常情况下，现有基础设施中的一部分关键性资产需要耗费较长时间才能顺利被迁移至云环境当中。但除此之外，那些较为灵活的系统——具体情况取决于资产实际情况——能够立即成为迁移备选项。首先将注意力集中在这些非关键性系统中能够帮助企业客户快速获得收益，而在此期间积累下的经验与信心也有助于企业日后更顺利地完成共享资产迁移。在经历过数次系统迁移之后，大家会发现整个流程要比预想中更为轻松。我就曾亲眼见证过多家客户的实际执行过程，在运行混合应用程序方面积累到一定经验之后，这些企业开始全面奉行云优先指导方针。这种作法还能够鼓励企业以逆向思维看待云迁移工作。相较于论证某个项目能否在云环境中实现，企业更应当去证明其为什么无法在云环境中实现。在这种情况下，企业往往倾向于利用托管SaaS解决方案打理各种常见的企业后台功能，例如HRIS、电子邮件以及协作系统。
4. 直接连接。在内部数据中心与AWS之间直接起专用连接通道往往成为网络敏感型应用程序在混合模式下正常运作的前提条件。根据我的个人经验，大家在实际实施过程中也需要采取此类方式。当然，直接连接并非尝试混合工作负载时的一般性先决条件。
5. AWS原生生态系统。随着更多资产迁移到AWS当中并享受由该平台带来的功能优势，企业可能迎来了发展临界点，即其整体系统中利用云平台实现的功能开始多于由混合环境所实现的功能。部分企业已经就此给出自己的解决思路，即“全面”贯彻云战略——其中Infor、Sun Corp以及凯宾斯基酒店都是这方面的典型代表。
以上情况与大家在自己企业中的经历是否相符？欢迎各位在评论中分享您的体会。