大多数云应用程序都有开发功能(或至少可以编写脚本)，允许深度定制，加上一定程度的数据库访问和计算能力，但即使是***的云计算应用程序，也会受到平台/开发环境的限制，应用程序不是通用的运行时或通用的对象容器。例如，开发语言必须为多租户部署提供安全，不能让用户的代码将虚拟机，数据库或整个应用程序搞瘫掉，此外，某些类型的语言结构必须限制，以防资源被过度使用和死锁(的确，试想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
 

【编辑推荐】

1. 使用Microsoft Azure 让云迁移变得简便的5种方法
2. VMware的混合云迁移工具：vCloud Connector
3. 企业CRM等业务系统迁移到 "云"中的***实现 
4. 云计算该“迁移”还是“自建”? 
5. 云迁移全攻略：哪些应用适合迁移
6. 云迁移≠云转型 先迁移还是先转型？
7. 实战系列 Windows Azure开发者之任务