云和API标准的现状差不多和早期SOA和Web服务标准是完全符合的，我们期望标准运动能追寻一种类似的趋势。云标准组将会通过从Web服务标准的错误和成功中学习获取更好的机会。

　　在波士顿Cloud Camp上关于云标准的讨论起源于一个问题“我们想标准化什么？”我们回顾标准发现表象上有三个属性。这些包括“API锁定”（和厂商锁定类似的概念）、迁移问题和丰富性或者API的功能性。

　　在（为API和服务）设定标准时，一个有意思的问题是标准化的粒度。一些API范围有限，仅在单一目的的单一应用上起作用。其他的通过很多不同的目的解决了应用的更广阔的范围。

　　扩展问题影响功能的一个典型的例子是libcloud，libcloud用多种流行的运服务器提供者简化集成流程。其方法依赖于使用“最小公分母（lowest common denominator）”确保所有提供者支持之间的兼容性。换句话说，它为所有分担每个系统缺失细节的供应商提供了基础性能，协助其在其特定论关于表现得更好。

　　云端也存在虚拟化问题。如果优化自动化扩展应用有一个单一的最佳途径就好了。但是在创建“标准化触发器”时会有并发症。在哪一点上系统应该被触发，以便联机带来更多服务器？在哪一点上系统应该知道允许服务器离开？计算中应该包含什么样的度量？

　　任何例子，回答都是响亮的“看情况而定。”不同的应用有不同的需求。如果我们想确保五个九可用性，我们可能愿意承受一些延迟来避免故障时间风险。速度和可影响相比只是一种对分的解决方法。把围绕硬件、脚本语言和任何开发者争论的事情的问题总结起来，再一次证明你不能面面俱到。

　　但也有些地方云其实已经在实践中很好地标准化了。例如，服务提供商的基础设施API可以看做云标准的光辉榜样。

　　事实上，云的想法来自电信服务提供商从点到点服务到VPN的过渡时期。云是其客户负责结束的位置的标记方式，提供商负责接管。