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

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

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

　　但即使你可以移植所有逻辑到CRM系统，但示密钥生成的计算负载仍然要受CPU，堆栈大小与查询量的限制。

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

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

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

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

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

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

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

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