Adrian Cole发布JClouds 1.0

近日，JClouds 1.0发布了，其创建者Adrian Cole说到，JClouds的目标旨在提供一个公共接口以管理众多厂商、提供商、框架及API（从IaaS到PaaS）中的计算机节点和存储节点。

JClouds支持全世界30个不同的提供商。开发者与运维人员可以通过下游工具如Apache Whirr（运行云服务，如Hadoop、HBase、elasticsearch及Voldemort等）或Pallet（用于提供、配置及管理云计算资源的库）来使用JClouds，也可以直接通过API和Ant task将其当作库来使用。

InfoQ有幸采访到了JClouds的创建者及云互操作和运维领域的社区领导者Adrian Cole一探究竟。

InfoQ：JClouds 1.0增加了哪些主要特性？

JClouds 1.0.0增加了不少新特性，恕我无法一一列举，但我要重点介绍以下内容：

在可用性方面，David Santiago与Mattias Holmqvist完全重写了BlobStore与Compute Clojure API以更加适合于语言。Tim Peierls则修订了BlobStore的Java API以增强其直观度。

由于JClouds可以嵌入到管理与应用平台当中，因此模块化就变得愈发重要了。幸好，Gustavo Morozowski与Ioannis Canellos付出了巨大的努力来包装OSGi bundle和 Karaf集成：OSGi支持是我们最早的问题之一！

我们还为超级用户提供了大量的特性。比如说，Tibor Kiss将 BlobStore提升到了Petabyte级别，并在NGS平台中测试和打磨产品的内部构件。

Jeremy Whitlock领导了ProviderMetadata首个版本的开发工作，你可以使用它查询可用的云及详细信息，如控制台URL、友好的名字等等。Cloudsoft就通过这类详细信息执行范围内的部署规则，美国之外的用户也很喜欢这一点。

对于安全，我们提供了一个很棒的名为AdminAccess的工具，它会锁住节点并为你创建一个个性化用户，只需一步即可搞定。

对于很多人来说，重要的是我们所提供的连续带宽支持： Grid Dynamics与 GigaSpaces为流行的 OpenStack Nova平台提供了支持，我们还增加了不少新的云服务，有 澳大利亚的Ninefold（XEN与VMWare托管）和 英国的Stratogen（VMWare托管）。

InfoQ：在去年12月23日InfoQ的采访中，你提到JClouds可能会与libvirt合作，这样用户就可以使用JClouds进行可视化控制了？这件事有什么进展么？

没太多进展。从某种程度上来说，我们依赖于云控制者，比如OpenStack Nova和vCloud。另一个选择就是我们最近与Twitter协作开发的byon（Bring your own node）。你可以通过 BYON使用yaml语法赋予JClouds一个文件或是Web URL，其中包含有机器的详细信息。这是对我们尚不支持的平台的一个很好的解决方案。

InfoQ：JClouds支持哪些Cloud API呢（vCloud、Amazon EC2抑或其他）？

JClouds支持 EMC Atmos、 OpenStack Swift、 Eucalyptus Walrus（S3 clone）的存储设施、Amazon S3的衍生，甚至是磁盘上的文件。对于计算机一边，我们支持 vCloud（由VMWare创建）、 ElasticStack、Eucalyptus（开源的Amazon EC2 clone）、 Deltacloud（与JClouds有些重叠）、Amazon EC2的众多衍生以及byon格式。

Cole继续介绍JClouds的特性路线图。最近人们对于PaaS抽象的呼声越来越高，因此对其的支持也在路线图中体现了出来。对于JClouds来说，专注于PaaS还是最近才兴起的，之前主要专注于IaaS抽象。对PaaS的支持主要包括与Google App Engine和CloudBees Run@Cloud的合作。

另一个专注领域就是限流与伸缩了。现在有些提供商的节点数超过100就会出现一些问题。JClouds正致力于实现一些附加的内建策略，这样你就可以请求更大的资源池了。

Cole说他们正致力于负载平衡与虚拟化支持，不久之后就可与大家见面了。虚拟化支持包括可选择的启动源、ISO挂载、PXE、构建自己的镜像以及从其他机器克隆镜像等。虚拟化支持将会支持私有云。

InfoQ：JClouds与Jets3t、typica、Deltacloud及Dasein相比如何呢？能否谈谈质量、性能、范围以及成熟度等方面呢？

JClouds与其他产品之间最根本的差别在于我们在元数据的等值问题上花费了大量的时间。这是非常有帮助的，因为你可以直接公开需求了，比如说我在爱尔兰需要一台Ubuntu 10.04服务器。这种事情是很难处理的，但我们会不遗余力地做到更好。

来自Jets3t（Amazon S3 focused API）的James（Murty）开发了一套很可靠的库，与来自Typica的David一样（Amazon EC2及其他的Amazon services focused API能够处理如Eucalyptus这样的克隆）。他们在JClouds的开发过程中分享了其经验，尤其是James，他是一名敬业的开发者，数月以来都在孜孜不倦地努力工作。jets3t与typica都是成熟的库，他们都比JClouds年长。也就是说，他们并没有关注于便携性，因此你没法将其与JClouds互换。一般而言，我们在追赶Amazon特性的同时，jets3t与typica已经完成了这一切。在与jets3t进行性能比较时，我们的性能会更好。当然了，测试是我们自己编写的，呵呵。

Dasein与JClouds非常接近。他们差不多是同时开始的，事实上，它使用了JClouds组件实现了相当一部分云提供者。也就是说，Dasein有几个提供者是JClouds所不支持的，反之亦然。Dasein关注于单服务器操作，而JClouds则关注于机器群的引导。Dasein最酷的地方在于它公开了大量的规则，如防火墙规则等，而我们目前尚未做到这一点（Adrian Cole也是一名Dasein提交者）。

Cole又说到Deltacloud拥有非常“漂亮的REST API”。Deltacloud关注于API的便携性，而JClouds则关注于以便携的方式执行用例的方式。Deltacloud能够探测到定制机器的各种方式。你可以通过JClouds提供启动脚本，其他的细节问题都由JClouds帮你处理好了。因此JClouds能与Deltacloud集成也就没什么奇怪的了。

InfoQ：JClouds支持Eucalyptus么？ 你对Eucalyptus有何评价？

是的，JClouds支持Eucalyptus。我对Eucalyptus的评价是积极的。他们具有我们所说的兼容性问题，并且正致力于解决这些问题。

Eucalyptus是个流行的开源Amazon EC2、S3，它用于私有云计算。

InfoQ：如果我开始自己的私有云，那么JClouds将会支持哪个呢？现在是什么，将来又是什么呢？

如果你指的是on-prem计算云，那么你可以使用Eucalyptus、OpenStack或是vCloud 1.0。简而言之，我们还将支持cloud.com CloudStack 2.2.8，它是非常成熟且健壮的产品，基于商业与GPL许可。到今年底，我们将会支持vCloud 1.5，甚至还有可能支持OpenShift Power。现在还有其他一些云控制者，如OpenNebula和Abiquo，如果需要我们也将提供对其的支持。

InfoQ：在过去的3个月中，JClouds取得了哪些不俗的成绩（开发、架构增强等）？

在过去3个月中，OSGi取得了积极的进展。能够在离线的情况下连接到云资源，或是在应用运行时对其进行升级是我们重点考虑的问题。类似于典型的数据中心运维，云也可以步入维护阶段，这样你可能需要进行动态调整。OSGi与其他的模块化系统是解决这个问题的关键所在，我们向OSGi迈进的第一步对于我们和我们的用户来说都是至关重要的。

另一个重大进展是Tibor Kiss对数据传输的优化。我们已经实现了EC2集群节点与S3之间超过300MB/s的写速率，这使得云中Petabyte级别的传输成为可能。Andrew Phillips还实现了TweetStore示例，它会在Google App Engine中将twitter更新传输到BlobStores（这要归功于twitter4j）。他又对此更进一步，现在可以同时部署到CloudBees Run@Cloud PaaS上。我们现在准备将IaaS与PaaS整合起来，希望能向其他人提供一些有用的工具。

InfoQ：如果有人使用Google App Engine而不是EC2、Rackspace、Azure或是内部私有云，那么你对此有何看法呢？

现在PaaS有多种选择，因此无论选择GAE、Azure还是其他都是有原因的。

PaaS或是IaaS是个费用、服务层或是与需求一致性的决定。如果现有的PaaS能够满足你的需求，那么用就好了。你需要为此付出费用。如果你寻找托管的PaaS，那么请关注数据层。你需要清楚如何导入/导出工作、规则、历史以及维护窗口。

我对自己运行PaaS总是非常小心。他们通常是由很多层构成的，比如Rabbit MQ、CouchDB、Nginx、 Nagios等。如果你想使用自己的PaaS，那么你应该搞清楚其依赖来确保你可以对其提供支持，或是知道从哪里获得支持。此外，请对单服务器的快速起步PaaS或是IaaS示例持怀疑态度。在现实情况下，多服务器的部署通常都是困难的，涉及到手工或是文档中并未写明的过程。这些问题使得托管服务更具吸引力。

如果你需要一次性加载上百个节点，那么你需要使用EC2。我发现Rackspace在小范围情况下的表现与其他提供者一样。我认为在哪个公共云提供者上进行部署的决定主要在于业务价值上。比如说，从性能上考虑你想选择哪一个。他们是否部署在云X上，如果是，那么在哪个地区呢？哪个云能够满足你想使用的区域呢？哪些技术伙伴具有云X的经验？On-prem是个有效的决定，如果你在基础设施上有经验，那么它就极具价值了。今年还有不少产品会有助于on-prem云的实现。

InfoQ：哪一个IaaS提供者最易于上手（集成）？哪一个Bug最多？

最易于上手的提供者是那些运行着ElasticStack的提供者。他们几乎不会出现问题，在各个提供者之间能够保持一致性，从编程的角度来看也是非常简单的。

要说哪个Bug最多还真不好轻易下结论。我这里不会指名道姓。我想说的是，那些编写自己的云控制器，并且过去没有编写过具有核心竞争力的产品的公司更容易出问题。

InfoQ：能否谈谈Amazon BeanStalk？你打算围绕着Amazon抽取出更多的API么，比如Amazon Simple Notification Service、Elastic Load Balancing和Auto-Scaling等。

BeanStalk很有趣儿，当Amazon启动或停止时会产生严重的影响。我觉得这对于那些与BeanStalk竞争的ISV是个警告信号。也就是说它是个非常简单的服务，无需配置管理，因此它真正造成的影响很有限。对于其他的AWS服务来说，我们已经在JClouds提供了Elastic Load Balancing支持（比如OpenShift Flex）。其他的API就有待更多的人来验证了，我们尚未对其提供支持。

JClouds 1.0的发布令人印象深刻，同时JClouds的特性在不断发展当中，其目标也日趋明朗。

查看英文原文：Adrian Cole Announces JClouds 1.0 Release