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?