在国际航空安全协会（IASA）八月份的《特殊双重问题：TOGAF 9和云》中，Julian Keith Loren被介绍为程序员、CTO兼Trouble-maker董事长，发表了一篇文章，文章题目与其介绍十分吻合：《云软件架构：零三角洲探索、无锁定、混合部署就绪应用（Cloud Software Architecture: The Quest of Zero-Delta, No-Lock-In, Hybrid-Deployment-Ready Applications）》。

　　Loren将微软的Azure与“亚马逊EC2、Terremark企业云、Rackspace的Mosso云服务器这样的云服务器实例”放在同一条线上，但其同时指出“微软Azure的最终价格尚不可用”。这似乎是可以与亚马逊的EC2比得上的新的“袋中的黑猫”，仅因为袋子上标记着“微软制造”。但这也不是全部，根据Loren列出的厂商都“提供无订货提前期、无合约、只需为你所使用的基础部分付费。”当然，我们都梦想将我们的业务应用送到云端，而且没有合约，也就是没有任何来自云提供者的债务。一些IT人事认为业务人员不够聪明，但却都相信假如自己参与其中，业务人员在没有合约的情况下就不会那么愚笨了。

　　至于单独的软硬件厂商所提供的“无锁定”云性能，Loren表示：“结果就是在产品、应用修正需求之间的不一致，以及云服务实例和数据中心服务实例本质不同，将会促使你改变软件架构。这也正是麻烦开始的地方。如果没有特殊照顾，你可以不改变软件架构，转而匹配具体提供者的需求。”我之所以分享这个建议是因为这个问题正发生在我参与的项目中。人们不会为比所穿的鞋子小一码的新鞋子买单，仅仅因为这些鞋子还在商店里面。我所理解的唯一的可能是这些人没钱支付正确的尺码和另一家商店。也就是说他们将支付三次，错误的尺码、脚适应错误的鞋子以及在可能的地方修改鞋子。

　　为什么有人想改变工作的软硬件架构，尤其是如果所提供的平台是错误的（从架构的观点看）？是为了取悦云提供者？我们是客户端，我们需要服务于我们所希望的，别人提供不了什么。如果云计算是不能提供，要求我们改变工作的软硬件架构，那它就应该成长到足够适应市场的时候才提供服务。

　　下面我们回到Azure上来。Loren提到了微软杰出工程师Yousef Khalidi，并表示：“Yousef Khalidi强调云服务器实例本质上不同于传统的对等物。他建议部署到云端的应用尽可能的无状态而且要与卓越的故障处理合为一体。这个建议在云环境下并不意外，云环境下预期会经常发生故障。” Loren的文章更深层地概括了“失败—安全性（Fail-Safety）：失败的高预期率。在设计应用的时候，应预见常规故障并处理。无状态（Stateless）：你的服务应尽可能无状态。如果‘有状态’是必须的，它应该从服务中抽取出来。”

　　现在在Azure中我们应该“预见常规故障”并以某种方法处理。为什么以某种方法？因为当常规的（可能，非微软）架构师设计应用时，他们都会提供尽可能低的失败率，也就是所说的来自云环境的高失败率，而不是来自应用。Khalidi建议我们绝不要把SOA 服务放到云端（我认为这是对Azure所讲的）。众所周知，任何SOA服务都是作为一项流程实施的，而不是很多流程。我从不会要求架构师、设计者或者开发者改变SOA服务，仅仅因为有人不能够正确支持。为什么？因为消费者竞争是面向服务的唯一基本原则，如果你不能满足消费者的需求，你就会失去顾客，最终失去市场。

　　Khalidi建议微软的服务在OASIS SOA定义中并不是SOA服务。在微软，一项服务“脱离流程”和“本地”编程实体。也就是说如果一项特殊业务功能的实施要求分布在多于一个的服务器上，而并不能通过微软的一项服务处理。现在，你可以想象云部署问题的范畴所在，SOA解决方案设计者并不知道业务服务在哪里以及如何由云提供者部署？因此，在微软云端，忘记SOA部署；使用RPC代替，Azure保证没有问题（如果你处理了常规故障）。

　　最后，Loren建议“可能的云软件架构方法”基于紧密参考和可扩展对称性。他表示：“因为云服务器实例的标准制定‘比需求更大’，很可能将要在一个实例中部署多项服务，”这对于云提供者很有意义，同样也可能是Khalidi预测的常规故障的一个原因。

　　我们是消费者，我们不关心也不应该关心提供服务给我们的人的便利和利益，这是他们的工作。如果我设计了松耦合的服务，他们必须在任何平台和环境上运行松耦合。如果一个环境不能提供，这个环境就不合格，而且我的应用可能出现意外。