一位开发者的手记：跨云编程烦恼重重

　　大多数云应用程序都有开发功能(或者至少能够编写脚本)，允许深度定制，加上一定程度的数据库访问和计算能力，但就算是最好的云计算应用程序，也会受到平台/开发环境的限制，应用程序不是通用的运行时或通用的对象容器。举个例子，开发语言必须为多租户部署提供安全，不能让用户的代码将虚拟机，数据库或整个应用程序搞瘫掉，除此之外，某些类型的语言结构必须限制，以防资源被过度使用和死锁(的确，试想Salesforce.com上运行了上亿行用户代码，要让它们保持快速响应和良好的正常运行时间是一项非常艰巨任务)。

　　我们就以Salesforce的APEX为例，不需要太多的技巧，语言本身能够处理大多数业务逻辑，但在云开发环境中，要受平台的限制，比如说，在J2EE中有一个很好的库能够完成你想要的任务，但J2EE在你的云平台上是不可用的，就算你只需要这个库的一组方法也不行，许多底层功能必须靠你自己实现。

　　我们举一个现实世界中的例子：许可密钥生成。软件厂商可能会使用许可密钥强制他们的最终用户签订协议，CRM系统管理这些许可密钥(作为客户资产的一部分)，在CRM应用程序内也能够生成完整的密钥，所以，软件组织要求将密钥系统移植到CRM中，其实密钥生成也使用的是CRM平台的加密方法。

　　但是，就算你能够移植所有逻辑到CRM系统，但密钥生成的计算负载仍然要受CPU，堆栈大小和查询量的限制。

　　解决办法是调用一个毗邻云中的服务执行数据处理，遗憾的是，目前还没有适合这种情形的设计模式，因为：

　　你需要访问的部分数据可能因为政策，组织策略，安全或其它原因不能移动，还有一种情况是，其它系统也在使用这些需要移动的数据。

　　如果你的其它云需要处理驻留在CRM数据库中的大量数据，你可能想要的是数据的摘要，汇总，归纳或图形展示，而不是原始记录。

　　其它云可能对RESTful协议，比如，JSON支持得更好，但它们可能对WSDL和SOAP支持得不好。

　　根据计算的性质，在CRM系统中完成所有工作，只从远程云调用很小的方法可能会很有意义，相反地，在远程完成所有的工作，作为一个完整的服务进行调用可能也有意义。

　　如果计算需要评估系统状态(比如，工作量，锁或数据变化)，网络流量(和结果延迟)可能会成为一个严重的问题。

　　安全，测试和部署注意事项不能被忽略，必须时刻关注，就算管理员、开发人员以及组织的所有权发生了变化，也要将影响降到最低(思考一下将来企业重组对开发人员的影响，他们届时是不是还有足够的访问权访问其它云)。

　　所以，第一步是为你特定的应用程序确定最佳架构，找出什么数据元素需要传输，并跨云重构你的类。

　　原文出处，参考链接如下：http://www.itworld.com/hardware/161153/trouble-coding-across-clouds-part-1

　　原文名：The trouble with coding across the clouds: Part 1

　　作者：David Taber