Sun Cloud API：简单就够了吗？

William Vambenepe 的一篇最新博文讨论在我们的数据中心自动机制中我们用灵活性作为代价，究竟想要换取多少的简单性。这是受到了Sun 的 Sun Cloud 项目所引发的。William 注解到：

SUN API 非常简化，而且其作者对此引以为傲。他们确实应当为避免了不必要的复杂性而骄傲。但他们也可能排除了（至少目前而言）一些必要的复杂性。

Sun Cloud 的基础是资源模型以及访问 / 操纵这些资源的 API。Sun Cloud 所定义的资源模型都是围绕着云资源为基本而展开的，这是从用户角度所见的云中所有可获取资源的一个展现，并且提供了对云本身及其组件的访问。一个云可以包含一个或多个虚拟数据中心 (VDC)－这是从用户角度所见的单个虚拟数据中心的所有可获取资源的展现。一个 VDC 包含了一系列公共地址－静态，公开访问的 IP 地址，可通过一个接口依附于一个特定的 VM 上；集群－VM 和 VNet 资源群组，根据公共功能进行分门别类；卷－远程 WebDAV 卷，可由使用访问这一信息的同一凭证访问到。一个卷的内容在一个时间点上的展现由快照来定义。我们由上定义了一个集群包含虚拟机(VM)－联合于一个集群的虚拟计算机，由备份来定义其状态，表示一个特定 VM 和虚拟网络－一个可能附着联接于 VM 的接口的虚拟专属网。一个接口表示联接到一个特定 VM 的网络接口卡 (NIC)，并记录 (从这一 VM) 到一个 VNet(虚拟专属网) 或一个公开地址 (来自因特网的可获取的静态公开 IP 地址) 的 IP 连接。

根据 Tim Bray 的博文来看，Sun 集群所提供的 API，表示为：

…一个对于存储，计算以及网络服务的统一视图。它是基于 VDC 的概念构建的，包含了网络和服务器集群以及公开 IP 地址和存储服务。其想法是给予你管理和操控的能力来构建真正有雄心的大事业。VDC 这一概念确实巧妙，我相信往后任何严肃的 Cloud API 都会需要类似的东西。

在其底层，该接口是基于 HTTP，并努力向 RESTful 靠近。所有的资源－服务器，网络，虚拟数据中心－都以 JSON 的方式表达…这一接口不仅仅是资源的 CRUD 操作；还有类似“启动服务器”和“快照存储”这样的操作。这都是经典的 REST 模式所没有教给你的。这里有一个它如何运作的例子：一个服务的展现包括了一堆“控制器”URI；对其中某个的 POST 操作组成了对某一事件的请求，比如重启服务器。

在低层的 REST 之上，有一系列的库，为那些不想与 HTTP messaging 打交道的人而设计；Java，Ruby，Python 都现成可获取。在此之上有一个命令行接口适用于 Shell 脚本，除了它是发出 JSON 而不是传统的 Unix 文本行以外。

最后，还有一个 Web 图形用户界面，你可以简单地通过拖拽来构建你的 VDC。这是很棒的展示软件，我能预见人们使用它在很快的时间内作出快速的特定的服务器部署。但我打赌，为了为困难的工作做好准备，你将会选择用脚本配置部署，而不是依靠拖拽。

对于基于这一简单层次模型的 API 是否能表达真实数据中心的复杂性，William 提出了自己的疑问：

看看现在的数据中心。为所有的网络设备，存储，服务器，虚拟化管理器，操作系统和其包含的基础设施服务做一个清单。考虑下所有这些资源所需要的配置设定 (如同他们将会在一个完全的，权威的并且一致的 CMDB 中被表达一样，那个最不可捉摸的东西)。加入他们所暴露的所有控制与 API。这是很庞大的数据，就算你不考虑进应用层面。这可比 Sun Cloud API 所能描述的模型大了好几个数量级。其鸿沟 (CMDB 模型与 Sun Cloud 模型之间) 在于我们需要查看和分析的到底是什么。它们为何还差得很远？理想的数据中心自动化和虚拟化模型到底应该是多大？

他的建议是：

准确的位置是，在“全能的 CMDB 模型”与“Sun Cloud 模型”中间的一个平衡，以及一些相应的增量的复杂层次。当然现在要说“中间的某一点”是一种妥协还太早了。

Sun Cloud 。为云创建者和用户都提供了一系列的 API。时间会告诉我们这一简单的资源和 API 集合是否能被证明是足够用于构建和使用云的，或者说我们将会需要更加复杂的 API 集合。

查看英文原文： Sun Cloud API: Is Simplicity Enough?