上个月，JP Morgenthal在SearchSOA.com网上发表了一篇文章，文章呼吁技术领导者支持以架构为重的方法来进行关键性的改变。最近，我们和Morgenthal探讨了软件行业的其它趋势。并希望在这里和大家一起分享我们谈话的内容。首先我要借此机会向大家隆重介绍JP Morgenthal，不久他即将成为我们网站的专家，重点关注云计算，软件即服务以及SOA方面的内容。我想各位多年来一直关注XML、Java、SOA、 EAI，应该对这位大名鼎鼎的专家非常熟悉。多年来他一直在美国华盛顿工作，重点关注SOA、BPM以及云计算。他撰写了三本集成方面的书，最近面市的一著作名为“企业信息集成：一个解决实际问题的方法”。

　　大多数人都认为我们已经进入了云计算时代，但是云计算很可能会受到经济的影响。Google和Amazon在这方面取得了一定的成就，众多IT供应商也跃跃欲试，那么这些种类纷杂的云，更多的是以开发商为导向呢，还是以设计师为导向呢？

　　谈到交付信息和支持业务自动化的有效方法，人们大多各持己见。许多企业，特别是Global 2000，都在运营信息技术基础设施的重压下苦苦挣扎。而云计算恰巧为我们卸载这些负荷提供了机遇，相应来说，我们也要承担一定费用。

　　你是否认为SOA还是其它的架构对云计算的发展有帮助呢？

　　如果从整个架构的观点来看待这个问题，就会发现云其实是SOA架构的一个实例，从这个角度出发，事情就显得更为合理了。所有的一切都是以服务的形式被供应的，所以能够满足面向服务架构的标准。但是，对于某些人来说，SOA完全是关于企业服务总线、Java以及Web服务的，对于这些人来说，云和SOA是完全正交的。

　　同时也应该考虑分类模式——这里有企业SOA基础设施SOA，应用SOA。云是基础设施SOA；你正在运用面向服务架构这个概念创建可重用和“可测量”或者可计费环境。

　　是不是有些时候，人们在云计算中只能看到他们想看的事物呢？

　　大多数人在以解决方案的形式出售云，针对解决企业所遇到的各种各样的问题。你没必要对他们所有的禁戒都谨小慎微。

　　例如，如果你想白手起家，创建什么事物，总有一天，你要把它放到云当中，按照严格的标准予以测量。我认为，这种想法似乎有些天真。我认为早在设计应用之前，你就应该事先对其规模做出预测，你必须首先明白什么是规模，然后才能着手建设——明白规模会给你的应用带来多大影响。

　　此外，弹性也是云供应商的一大推销特色，那么在各个层面谁应该真正进行测量呢？举个例子，州政府一直准许公民使用服务，这种对于测量的需求已经初露端倪了。如果我提供的是一个客户应用，例如iTunes或者YouTube，此时你便需要动态，有弹性的测量方式。这就像是推销员兜售蛇油一样。

　　这样，你就明白了，其实所有的一切都是围绕费用管理和降低成本所展开的。如果你看看这些数据，假使你意识到许多人都在出租自己的硬件，并把大量的资金都挥霍在了硬件恢复、备份以及电源等等，你就会明白这些数据什么也说明不了。如果他们需要的更多，但是不想浪费更多的资金，此时IaaS就有相当的诱惑力了。如果此时有一个应用可以满足我的企业需求，并可以作为SaaS，这样一来我就不必把它带进来进行内部管理了，这种方法也很有吸引力。

　　此外，互操作还存在一定的问题。如果我进入云，我还要考虑到供应商锁定效应。如果我无法移动云，云供应商就会狮子大开口，漫天要价。况且，测量还处于初期阶段，目前尚不成熟，计划就显得更为困难了。“Amazon公司”就更难预测了。

　　有时我们把软件叠加成服务和云计算，这样做对吗？

　　作为服务的软件只是云的一个方面，是你要租用的一种服务。正如你要租用“数据库作为服务”或者“商业智能作为服务”或是整个栈或者“平台作为服务”创建应用一样。你也可能租用硬件，例如“我只需要CPU电源电压。”

　　但是，请千万不要领会错：这只不过是初步打算而已。目前市场才刚刚起步，还不太成熟，还要经历一个技术成熟度曲线，然后会经历一个动荡时期，在一个既定的经济状况下，这个动荡阶段很快就会过去。

　　目前的情况下，公司的CEO 或者CIO可能会问“我需要你分析一下，云计算究竟可以用来干什么……特别要注意成本节约。在审核云计算计划书时，尤其是在领导者已经决定启用云之后，企业设计师会问什么样的问题呢？”

　　性能，安全性以及隐藏的费用都很重要。但是你不能总让CIO关注你所谈论的技术问题。有时问题在于，那是否能独当一面。记住：保证方案的可行性是技术人员的工作，如果整个方案失败了，商业无法进行论证。公平的讲，有时你手中仅有的武器就是恐惧。当被问及“如果我们采用了云会怎样时”，我们可以节省许多钱。但是当问到“如果我们的数据被盗怎么办时？”很不幸，这就要看你所从事的是什么样的行业了。