AWS的流动性推动。Vogles说云计算和移动性将不可避免的相互关联。他表示移动设备的增多带我们进入了数据消费、内容更少的时代。他说：“年轻的企业是移动第一”。AWS希望通过中央ID管理或者是虚拟工作空间消除开发过程中的复杂性，使得开发更加灵活，从而更好的创新。Vogles说：“CIO已经给我们反馈，他们表示BYOD是非常重要的，但是他们不想管理设备。他们希望自己管理的是虚拟的工作空间和充分配置的环境”。

另言之，AWS也开始向其他移动玩家靠近。AWS也开始向其他移动玩家靠近设备管理相当于赌注。值得注意的是，亚马逊－谷歌和微软一样，与Box和Dropbox在文件分享和文档协作上的价格竞争非常激烈。

混合数据中心。“混合云对我们很重要” Vogles说。“很显然，我们是公共云，事实上，还是会有一些东西放在企业本地的。”确实，最大的问题是在将来怎样定义混合云。公有云和本地数据的比例会是1：9或者相反？或者一些适中？第三个答案是正确的，但关键在于如何定义适中。

Vogles提出像新闻集团这样的公司，它考虑通过AWS将40个数据中心合并成，这就是他们对混合云的定义。AWS的计划是提供一系列工具，如虚拟专用网络、直接连接以及联合身份验证等工具，帮助企业更加自然的连接到本地数据中心。AWS也提供VMware管理集成突帮助企业更好的管理混合云。

Yinal Ozkan，AWS的主要方案构架师的一段讲话强调了细微的差别。AWS的使用案例比比皆是，从卸载存储到分析云的灾难恢复。“例如，三星智能电视中心软件在AWS上运营，但是财务交易在在三星自己的基础设施上进行的。”Vogels介绍道。为什么？多项三星的业务依赖于基础设施的交易而且很难移动。另外，银行会在云计算中运行面向客户的运行维护，但是交易会在财务数据中心部门。

所以，怎样使混合数据中心转向更加公共化？Vogles说高性能计算（HPC）是云计算应用的一个关键领域。工业化公司比如像石油和天然气还有环境已经投资了高性能计算系统，但是本地资源确实提前好几个月预定的。

“在满负载的情况下，本地的高性能计算系统非常的昂贵，” Vogles说，所以额外的工作就需要转移到云上去完成。

遗留的基础设施和技术债务。AWS和亚马逊都有技术债务-遗留的基础设施，这些不可以简单的被投弃-Vogles说关键是建造一套不被锁定的系统。

Vogles说亚马逊假设今天的软件是无法运行两年的，软件必须能够随着时间的发展。“它的意思是我们没有被锁在历史系统中，” Vogles谈到，“当然我们有技术债务，但是可以改变我们系统和规模化运营。 这样，相较于客户来说，我们处在一个不利的境况中。”

值得注意，在某种程度上讲亚马逊书混合商店。亚马逊很多零售业务是运行在AWS上的，但是产品数据是缓存在本地的，Vogles解释说。这项产品的信息专门服务于硬件并为使用案例设计。“我们正在打算从本地转向云端。” Vogles补充道。

AWS使遗留的基础设施都是基于客户的要求进行淘汰的。比如说，AWS已经是第二代的了。Vogles曾说过传统的系统将会保持其他的能力。内部高性能计算系统的平均寿命是5到8年，但是研究人抱怨两年后就开始抱怨，因为他们没有最新的处理器。“我们可以将这些高性能计算系统应用于日常使用，并设立快速的更新周期。” Vogles说道。

当谈及遗留的基础设施，企业更希望是重组架构和面向未来，而不是将基础设施转向云。

大数据，MapReduce 和Hadoop。谷歌最近指出MapReduce 也只能到此为止了。对此，Vogles表示赞同。

最终，“MapReduce下降到低级的一层，”Vogels说。“运用 Hadoop和MapReduce自定义分析是至关重要的。最后，MapReduce将会被运用为方程式的一部分，但是将不会成为完整的图画。亚马逊的Redshift服务提供更加快速和简单的分析服务，这是MapReduce不能提供的，”他补充道。这里将会有MapReduce大量的应用， 当然也会吸引众多的开发者，但是最终，它也只是大数据的一个资产组合。

跟所有的企业数据一样，大数据唯有通过应用投射给用户才有用。对于设计或重新设计大数据应用的架构师来说，一个关键问题是究竟是用面向对象架构（SOA）还是RESTful API将大数据组件及服务与应用其他部分连接。从大数据产品要暴露的接口开始，然后在应用这一侧定义大数据接口。接下来，考虑安全和治理，最后，无论选择什么样的API都要小心地将管理和访问服务分隔开来。

做大数据应用的一个主要问题是与大数据容器本身进行交换的本质。这一关系包括了传统的哪一种抽象级别最适合应用的问题，所需的事务及状态控制以及必要的安全性。

大数据工具往往混合了API，部分RESTful以及部分类似SOA式的API。这种混编会导致一种混乱的景象，除非大数据接口被抽象为服务或资源，而不是直接暴露给应用。这样的话，只有一个组件需要做出变化——大数据适配器流程——如果大数据工具彻底改变了的话。

大数据应用，什么时候用SOA，什么时候用REST

在大数据适配器与其他组件之间的接口处，看看大数据是如何被用来为选择API进行指导的。SOA适合在向大数据容器这样的东西发布一组与应用绑定的特定能力的情况。这一模型可以是高度抽象的，意味着应用使用大数据可以与数据本身的技术和可分布性完全隔绝。

应用预期会在特定分析或规约流程的结果方面更多使用大数据，在这种情况下SOA是有意义的。如果应用需要知道作为资源集的大数据的情况，又不想把它抽象化为高层服务，那么RESTful接口也许会更合适。

在这种高度上进行应用审查，至关重要的一点是不要掉进这样一个陷阱，即假定大数据应用应该用Apache的WebHDFS这类现有的RESTful API来开发。通常而言，最好的办法是将大数据流程或设施与应用通过现有的接口连接起来，而不是那些用来直接进行文件系统级操作的。后一种类型的接口会产生可观的增量式开发工作，如果是在这个层面来写，要想将应用从一个大数据服务或设施迁移至另一个几乎是不可能的。

上下文、状态及事务性行为

事务就是工作的上下文，一个从业务角度产生流程步骤的逻辑序列。在确定是SOA还是REST最适合大数据应用时，第一个问题是事务性工作是否包含在大数据组件之内，或者大数据引用在事务中是否跨多个组件传播。第一种情况下，RESTful接口可轻易部署。而在第二种情况下，要想用REST,就得需要某种事务状态控制的机制。而SOA这两种情况都很容易处理。

在进行大数据的SOA和REST决策时，安全和治理也是很重要的点。SOA的安全、访问日志及控制是显式的，且与用户目录和应用控制是高度集成在一起的。而REST的安全和访问控制机制则可能是在外部应用的。这有可能是将大数据访问包装进SOA里面的一个有力的理由，即便在REST使用是在大数据产品级这种层次上也是如此。如果采用RESTful模型的话，必须明确如何建立起能通过正式治理评审的大数据安全。大多数用户会吸收VPN或SSL级的安全，但还会通过网络级的应用访问安全来增强。

最后，小心不要暴露过度。大多数情况下，大数据服务可分为两类——实际的数据访问服务以及数据服务平台管理和控制服务。所有的现代大数据架构都支持这两种，但因为平台管理和控制往往被视为是技术过程而非应用过程，其支持往往牵涉到通过简单的REST接口进行低级的功能访问。大数据管理服务应该尽量少直接暴露给应用开发者或用户，因为会导致相当重大错误的风险。

在需要平台管理工具为大数据使用进行准备时，最好是将这些功能在大数据适配器组件内实现，为应用开发者建立一个更容易的接口来使用，并确保在大数据分析开始之前永远都先经历必要的平台管理步骤。

为架构师和大数据专家预留对平台管理API的访问将是必要的，这样能让他们在日常的数据仓储维护任务中用到。部分用户建议对低级的平台管理API进行抽象，这样的话哪怕是平台管理实践也能跨多个实现应用，但经验告诉我们，要想在这种层次上建立有用的通用实践是很困难的。最好的做法有可能是就让专家和架构师在需要时采用特定的平台管理API就行了。

一旦大数据SOA/REST评审完成，永远要记得把这两种截然不同的API风格的结果与一般政策对照一下。一种工具被创建出来时，需要的绝不仅仅是确立的API基线支持，还包括不同的实践，要预料到更高层面的风险。确保在进行下去之前对风险进行了评估。

软件工程存在什么问题？直接讲这一问题是：当一个人一个组织提倡一种方法时，不单要阐明方法自身，还要阐明方法自身的边界。而不是潜在的认为每一个自己创建的方法都是全能型的。

因为软件是一个庞杂的概念，基于其本质来看只有设计模式、正交、信息隐藏这样基于纯粹思维的东西有可能是共通于所有软件的，而软件工程由于更多的要基于思维承载之物的特质，所以必然会有比较清晰的适用边界。

所以说更合理的状态是不只要有通用的软件工程，也应该有适用于互联网的软件工程，适用于国防部软件的软件工程等，后者才是真正面向实践的。敏捷，CMMI这类东西在描述方法的同时既要描述自己的方法论本身，也要描述自己面临的约束和适用边界。最好能说清楚，自己哪些东西是变量，面对哪类现实时要进行何种伸缩。

但实际上恰恰与此相反，每当一种工程方法出世的时候，它的作用总是潜在的有扩大的趋势，似乎一旦锤子在手之后，所有身边的东西就都变成了应该锤一锤的钉子。

这有市场的因素，因为扩大了后相关生意更好做一些，也可以拿到一些奖励什么的，但更多的还是因为自身并不做太多思考。作为一种结果，过去十年里种种方法论兴亡过手，但开发水平很可能并没因此而提高多少。有点年纪的人大致应该记得由ISO到CMMI，再到敏捷的故事。当前应该是敏捷正处在兴盛期，但反敏捷的声音已经出现。

这进一步导致了一个奇葩的结果：现场的人非常反感软件工程，说：我一看到软件工程的书我就略过。很多人不再相信什么工程方法，更多的跟着感觉走，但与此同时则是《人月神话》中描述的猛犸象挣扎于焦油坑现象一再上演。

如何定义或寻找方法论的边界

那究竟怎样才能去定义或寻找一种方法论的适用边界？

如果把所有影响软件的因素都涵盖于软件工程之内，那么这事儿就变成无边界的了，财务、公司运营、市场营销全对软件有影响，如果把他们都包含到软件工程的概念内，软件工程就变成了四不像，什么都是可也什么都不是。

这点上可以向经济学家取经，经济学家研究经济学的方法是：先假设某些因素不发生变动，进而观察几个特定因素的变化和关系。

我们可以先抽去商务因素、市场因素对软件的影响，寻找本质规律，用的时候再把商务因素、市场因素的权变加回来，看看如何弯曲本质规律以适应现实。

好比我们随意画圆的时候画出的圆很容易是不理想的，但只要我们知道了圆的理想方程，我们就总可以画出尽可能完美的圆。

带边界和约束的方法论示例

下面说个例子来看看这种带边界和约束的方法论可以是什么样子。一般来讲做软件的时候我们总会谈到自顶向下与自底向上，前一个在设计上还有个专有名词叫：Big Up Design Front。理想中的瀑布模型是比较纯粹的自顶向下，而迭代则是自底向上多些。

从开发模型的角度看，它们看着是对立的，但如果你把开发模型看成是最佳组合人与事的方式时，这种对立就会消失。

瀑布模型下，把软件构建的活动分解为：需求、设计、编码、单元测试、集成测试、系统测试等环节，并期望逐步推进。这一开发模型似乎从诞生那一天起，就开始饱受批评，比如被指摘不能很好的应对需求变化等。但这一模型根基是工作分解间的时序和因果关系，其本身并无错处。

其成立前提和适应场景是：

有人能够预先了解要开发产品的各种细节成员能力差异明显，构成明显的金字塔结构（少量极其优秀的人和较多能力较弱的人）

简单来讲就是在“想的人”对问题域非常清楚的情况下，比较彻底的分离想和做，最终“做的人”不用想。

虽然敏捷类思想不太考察这个维度，但事实上当组内一个人极度优秀，而其他人员平均水平比较差的时候，从项目的角度看，比较适合偏向瀑布，而不太适合导入敏捷类的迭代。

这个时候使用瀑布，可以获得更佳的生产率—当然你不能走极端，把瀑布绝对化。

但同样是使用瀑布模型如果上面的条件不具备，就会导致灾难：

没有合适的人确定需求，大部分勉强决定的规格可能完全没有意义。设计如果只是纸上谈兵，编码的人又无法修改，那么就会发生无休止的讨论，加剧内耗。

也就是说，假如说团队中的成员A，在经过一定的思考后可以预见到当前的实现方法会导致性能问题，那么就比较适合预先把应对措施定义下来(即使是Big Up Design Front)，而不能等迭代出问题再进行解决，后者的内耗明显是高的。

从上面的例子里我们可以得到两个彼此关联的结论：

人和项目特征决定了开发模型，而非反过来需要根据开发模型来调整人员配置等。这是因为在特定时空背景下，调整人和项目特征的可能性小。假如人和项目的变化是连续的，那么无疑的绝对的瀑布和迭代之间程度的变化也是连续的。作为结果，大多时候最优的开发模型必然既不是绝对的瀑布，也不是绝对的迭代，而是一种具体情境下的选择，可能偏向于瀑布，也可能偏向于迭代。

开发模型的价值就在于，如果我们能够在连续中找到这一最佳平衡点，在这一点上内耗最低。

这种对方法论的描述无疑是与许多教科书上相差很大的，但我比较相信这才是一种正确的方式。