将应用程序放到云上

　　云服务供应商称他们可以为用户提供一切，而且客户无需自己打理IT基础架构。从电子邮件到Web托管、全面的应用管理以及丰富的随需计算资源，云成了最近几年一项最重要的技术转变。本文作者是来自旧金山的资深市场顾问Dave Rosenberg，他同时还是开源基础设施与集成软件改革者Mule Source公司的CEO。本文介绍了他们公司选择云服务的经历。

　　是不是听起来太完美了?以至于让人不禁怀疑云是否真的有那么好?根据我的经验，我估计在过去两年里，公司可以轻松卸下50%甚至100%的需求到基于云的服务上，以最小化(宕机等故障对)业务的影响，并接近零风险。

　　当然云也未必适应一切需求。如某些高性能低延迟的需求对云来说是非常具有挑战性的。但有些情况下，可以采用云服务以实现较低成本和最小化风险。

　　有三种情况适合使用云：计算能力的需求(如亚马逊网络服务EC2和S3，谷歌的App Engine); SaaS(软件即服务)应用，如Salesforce.com和NetSuite;还有就是通过互联网提供的PaaS(平台即服务)进行应用开发和部署，如Force.com 。

　　随着云产品不断走向成熟，相信我们会看到多代产品以及许多改变，现在还不知道存储即服务适合哪个领域，但市场已经有多种产品在供应了。

　　我为什么选择云

　　最近，我在为一家开源软件公司工作，我们公司员工遍布世界各地。这使我们非常依赖于利用技术管理人际关系、业务、通信和软件开发人员。

　　一个成员地理位置很分散的团队合作起来会特别麻烦，即使是最基本的交流都会非常艰难。如果Skype(一种网络即时语音沟通工具)不好用，一个开发会议将耗掉一整天的时间;如果电子邮件出了问题，那么多项业务流程都将需要大量人工干预;如果Salesforce.com无法使用，我们将无法获得销售或支持所需的客户数据。

　　对于初创公司来说，将业务系统外包给(理论)专家的做法是非常有吸引力的，大多数人已经适应外包某些元素，如Web服务器和电子邮件。否则在IT人员非常少的公司，程序员往往得帮助系统管理员。

　　我们的目标是：不在公司安放任何与程序开发无关的物理机器或应用。作为一家软件公司，我们决定保证：程序员是编写代码的，不是执行系统管理任务的。但可悲的是，人生并不是非黑即白。我们的托管系统和云服务仍然需要程序员花费少量的时间在上面，只能用这个原因来解释：他们知道他们希望该系统做什么。

　　发展云服务

　　为了保持开发系统的稳定，同时不要在硬件上花费大量资金，我们将所有的开发应用都迁移到Contegix上。Contegix是一家托管服务提供商，广泛支持客户业务及我们使用的产品。我们的团队也有权去修改我们的托管主机，所以每次更改我们不必走麻烦的流程才能进入(除非我们希望那样)。

　　将开发系统托管让我们看起来好像比别人奇怪。但是，当他们意识到多数开发人员正在关闭自己的代码行以便轻松的将本地代码片与网上的合并在一起时，他们都释然了。

　　我们确实遇到过一些麻烦。开发应用(Confluence, Jira, Bamboo,以及自定义代码)无法集成，所以我们做了大量工作为了让所有系统能够完全交互。还有，我们中有个人订了一些我们确实不需要的服务器。我们结束了它们的虚拟化以最大化质量保证和满足测试需求。

　　云中的商业应用

　　我们使用的多数云应用软件可以支持我们的业务需求，从为用户提供下载的托管软件到处理客户数据的软件。而这些都不占用我们的核心计算能力，我们很高兴让别人来管理它们。

　　Web服务器和下载。我记得早在1996年的一天，有个人踢到了服务器的供电插头，使得所有的Bell实验室和朗讯科技网络的网站都中断了。人们都在走廊恐慌的晃来晃去。在此之后，我就决定我永远都不需要自己管理我的Web服务器或DNS 。

　　在我现在工作的开源公司里，我们坚守这一信念，把我们的网站和企业内网放在Rackspace公司托管，因为我们提供软件下载，所以需要专门的机器和足够的带宽以保证没有网络阻塞。

　　我们最终将我们的产品下载迁移到了亚马逊的S3，把应用放在那我们不用担心管理、带宽，或其他任何事情。我们每月花不到100美元购买15,000的下载(15,000-plus downloads)。大家知道亚马逊的服务中断过，当时我们确实遭受了一次到两次的业务中断，但我们可以轻松地改变我们的站点指向我们的主Web服务器。如果你能接受偶尔停机的奢侈，S3 服务在价格或性能上也许适合你。

　　我们也开始在EC2上运行软件演示。

　　客户关系管理。我们最初试了SugarCRM，但是早期缺乏客户支持入口模块(这在以后增加了)，所以我们选择了Salesforce.com 。

　　Salesforce.com相对来说更易用，但这是在熬过了最初的三到几个月的痛苦试验和错误之后。除了基本功能之外，我们建立了一个非常简单的客户入口，并利用Salesforce.com的应用接口程序(APIs)将数据导入我们的视线。这体验非常棒，直到我们发现我们已超额调用API，并被迫升级到更昂贵的服务。然而，两年多来，我们没有遇到任何停机事故，也没有丢失任何信息。

　　电子邮件。我们从第一天起就决定：绝不考虑自己管理我们的电子邮件服务器。今天对大多数业务来说，电子邮件是至关重要的。而且对我们来说电子邮件极为重要，因为我们有一个全球研发支持团队，不断整合并建立服务器、论坛、博客等等。有这么多东西需要处理，我们可不想再多添一个――恢复宕掉的电子邮件系统。让别人帮我们处理电子邮件系统听起来是个相当不错的主意。

　　在不到两年的时间里，我们改变了四次电子邮件服务提供商，并与IMAP ，Zimbra公司，Gmail做了多次尝试。这一切始于Rackspace公司的IMAP，总的来说用着还可以――除了没有日程表，而且随着我们公司的成长，我们共享日程表的需求也更强烈了。

　　在2006年底我们换到了Zimbra公司。但是，有几位同事的日程表和联系人丢了。虽然Zimbra的团队非常积极的帮助我们解决问题，但这实在是有点儿吃不消。所以，我们又回到Rackspace公司的IMAP，但Zimbra那边也在运行着。

　　后来， Rackspace公司开始提供微软的Exchange托管。我在另一家公司领教过Exchange托管噩梦，坚决拒绝再次经受这种残酷的折磨。另外，对一个开源公司来讲，依靠微软让人感觉太怪异了。

　　然后，谷歌应用服务走进我们的视线。于是我们再次更换服务供应商。我们与谷歌应用服务的首次测试在最初的几天状态很好。每个人都觉得使用POP和Gmail界面还可以，而且我们有理由相信，它不会像Zimbra那样吞掉我们的的日程表了。哪能出错阿?

　　但事实证明，很多地方都可能出错。在Gmail支持IMAP之前，POP执行有几个非常奇怪的毛病，你不能取出你自己发给自己的邮件，包括抄送的邮件也一样。信息仿佛在大气中消失了。用户管理就像是一场恶梦;我们有40个化名的名单必须单独进入邮件系统才行。

　　需要五分钟才能进去，我们的程序员就要崩溃了。因此，我们又换回到Zimbra的服务。邮件正常使用还是要比提供日程表更重要。而且Zimbra已经推出了新版本，同步做的更好了，还有新的用户界面。但是Gmail提供海量存储，而且我们的同事大多数喜欢Gmail的界面，所以尽管我们搬回到Zimbra，但一些人还在想念谷歌。这就是为什么当谷歌推出Google Apps Premier Enterprise (GAPE)的时候，我们又跑去试了试。

　　GAPE使用起来相当不错，除了少数小毛病，例如，如果你使用IMAP，你就会收到这个奇怪的“所有邮件”文件夹，似乎跟许多版本Mac邮件永不停止的同步。但是，GAPE满足了我们所有的要求，包括同Salesforce.com的整合。

　　我觉得电子邮件和日程表的应用是人们最私人的应用，也是最难以忘记或变更的。在电子邮件方面，功能需求可能只是一方面，而不是全部。

　　我为什么又在我的新公司做这一切

　　最后，我们本着避免花费大量资金、甩开繁琐的基础架构建设的原则，选择了云服务。尽管使用云服务并非没有挑战，但我完全可以说，我将义无反顾。事实上，我已经开始行动了：我的新公司的IT架构就采用了非常简单的购买云服务的方式，最小硬件资本支出，依靠值得信赖的供应商来打点一切。

　　是的，选择云要求你必须放弃一些控制欲，以获得一些其他好处。但我认为，正面影响远大于负面影响。