API兼容战争验证抽象的云计算方法

　　正如你可能知道，今年五月，美国联邦巡回上诉法院判决裁定，甲骨文(Oracle)控告Google Android 侵犯 Java API 版权的官司中甲骨文胜诉，甲骨文有权根据版权法来保护其软件。这一裁决在整个软件业界有着巨大的影响，尤其是在云计算领域，其需要利用API来提供相关需求的资源。

　　这充分显示了用户避免被锁定，并且能够更自由的在云计算的应用程序之间迁移的强烈愿望，而且可以更轻松地通过API的兼容性实现。但它也带来了一个抽象的方法，促使云供应商的创新，超越强加给用户的API兼容性，寻求更具便携性的边界。

　　API的兼容性成为云计算领域的一大热门话题已经有很长一段时间了。事实上，去年夏天，Cloudscaling的首席执行官Randy Bias和Rackspace的Robert Scoble就已经围绕着在OpenStack提供充分的AWS的API兼容是否符合最佳利益进行过一场非常激烈的公开辩论。

　　另一方面，IBM已进行了Jumpgate项目的投资，使非基于OpenStack的云能够更容易的实现OpenStack API兼容。甲骨文与谷歌的这场官司让更多的云用户看到了API兼容可以作为一种更自由的在云供应商之间迁移工作负载，而不必改变他们的手工工具的方法。

　　云的便携兼容性是否真的在于API?

　　这一问题的关键在于我们想要实现的云的便携性真的存在吗?今天的云的客户，尤其是企业的IT部门非常担心被锁定在一家单独的供应商，而失去了市场议价权，或者无法随时间的推移满足其业务需求，他们迫切希望能够将不同的工作负载托管到不同的云。很多人认为，多云策略是在一定程度上实现高可用性和灾难恢复的最好的方法。同时，不同类型的工作负载运行在包括公共和私有云的不同云平台，可以假设他们都运行保持一个单一的目标，也是最好的。

　　最终用户实现云便携性的一个方法是在所有可能的供应商都使用一款通用的API。即使在这宗官司获得最终法律裁决之前，最终可能的结果也是全行业因为对于产生API怀疑，因为云供应商想要提供分化的功能，而如果要处理对于API兼容性的支持，这些分化的功能就会得到稀释。庆幸的是，还有一个办法能够为用户提供了他们想要的便携性，而又不用限制云供应商使用一款共同的API。

　　一个抽象的验证方法

　　这一法律问题是为了帮助客户指出自由的在不同的云之间迁移工作负载的正确的方式不是通过一款普通的API，而是通过一个抽象层，可以帮助理解应用程序和各产品的优缺点，提供和配置应用程序运行所需要的资源，在每款不同的云进行相应的优化。

　　许多云管理平台(CMPs)均支持这一概念，作为一种实现通用API所能够实现的便携性效应的方式，同时又不限制云计算供应商的创新。

　　云管理平台的技术通常需要创建一个应用程序的需求，涉及核心原语，如计算，存储，网络，安全相关的元数据描述等，没有定义特定的云基础设施。通常在应用程序的配置文件，模板或蓝图中完成，在通过手动或自动手段完成后，完整的应用程序配置文件可用于本地部署应用程序到任何支持私有或公共云的环境，方便在各种便携式云之间迁移，且易于管理。

　　除了应用程序配置文件，这种抽象方法的一个关键因素是云配器。往往是单一的，多租户虚拟设备驻留在私有或公共云，这种云配器负责协调应用程序的需求，通过应用程序配置文件的输出表示，通过云计算的最佳实践的基础设施和服务，允许其提供相关的资源来部署应用程序。

　　在这个模型中，关键的责任是云管理平台的不断更新云，以便让用户能够充分利用每家云供应商的创新技术，他们不再需要关注打破API兼容性的问题。然而，由于采用了抽象的方法，用户免受相关变化和简单继承的优势都通过云管理平台写入云配器。在云管理平台集中特定的云供应商的专业知识能够通过应用程序抽象配置文件屏蔽最终用户，并使云供应商的系统中的每一个特定用户都体验到API的好处。

　　从变化中抽象隔离

　　无论对于这方面的法律裁决是怎样的，许多专家认为，最好的地方是在技术栈确保客户拥有相同的选择。即使他们能合法的这样做，云计算供应商也不会百分之百的让 API与云平台兼容，因为这限制了他们的创新能力。通过上述抽象的方式，使某些供应商原本在另一家并不存在的API功能特点也可以方便的使用，让客户得到他们想要的功能，同时仍然保持云计算特有的功能优势，及其便携性。