PaaS with CloudStack 已翻译 100%

在阿姆斯特丹的CCC(CloudStack Collaboration Conference)上关于PaaS的一些讨论

非常荣幸在十一月份的CCC(CloudStack 沟通合作交流会)上看到一些关于PaaS的讨论,  来自于Gigaspaces 的 Uri Cohen (@uri1803),  Sixsq 的 Marc-Elian Begin (@lemeb) 和来自于 CloudSoft的 Alex Heneveld (@ahtweetin) 都参与了讨论，而且还有一些关于Paas定义的讨论(具体可参看Docker和Vagrant)

PaaS的差异

在AWS FAQ上关于应用程序管理的文章，非常好的解释了不同的PaaS方案之间的差异。这里非常清晰的列出从操作控制到纯粹的应用系统部署等一系列需求，我们可能会主张把真实的PaaS提取的操作细节和底层基础架构的管理完全隐藏起来，这样说来，虚拟架构部署的自动化已经达到了非常成熟的状态，由此也模糊了IaaS和PaaS的定义。但AWS提供的服务还是涵盖了全部范围，这并不奇怪。

因为我更专注在操作层面，所以更加倾向于把PaaS看做是一个基础设施的自动化框架。比方说，我想要找到一个工具来部署MongoDB 集群或者RiakCS集群，但我并不想寻找一个预装好MongoDB，只能通过旋转按钮来增加集群的大小或管理碎片的一个抽象的平台。应用程序开发人员将会更加愿意要一个像Google App Engine 的这类东西以及了解开源版本的应用范围。我会尽快在下一个帖子中列出PaaS的差异，另外@DavidLinthicum刚刚写的一个文章(PaaS isn't dying -- it's becoming part of IaaS)还是很值得一看的。

支持 CloudStack

在CloudStack社区里最有意思的事情就是看这些对CloudStack使用各种不同方案的支持，不论是在应用程序管理的哪个方面。

• Gigaspaces的Cloudify中关于OpenStack的所有支持都是在Twitter上支持的，对于CloudStack的支持的不足，曾经我也为此而烦恼，这也是我为什么我在阿姆斯特丹遇到Uri Cohen非常高兴的原因。Uri Cohen做了一个非常出色的演讲并且演示了Cloudify。印象最为深刻的就是其灵活的UI以及在云端提供完整的应用程序/基础设施的能力。它的底层使用了Apache jclouds，因此Cloudify没有理由不支持和CloudStack的通话。Uri在圣诞节做了一件了不起的事情，现在CloudStack support经过测试并且被记录下来，它不仅在商用版本(Citrix CloudPlatform) 而且在开源版本(Apache CloudStack)上都运行良好，当然在我的邻近云( exoscale)上也运行的不错。

• Slipstream还不广为人知，但也值得一看。@lemeb 在CCC上演示了CloudStack驱动。从那时起，他们还提供了一个slipstream cloud orchestration架构的托管版本，这个原本是放在exoscale CloudStack云上的。仔细想想，除了通过抽取不同的云API而在多个云上自动部署应用程序，还提供了针对虚拟基础设施的应用程序部署模板，其实我们可以把Slipstream当做一个云代理(Cloud broker) 而非PaaS

• Cloudsoft核心应用程序部署引擎是brooklyn,最开始是来自于Alex Heneveld 贡献给Apache Whirr 的，我也写了好几遍， 然而brooklyn可以使用OpenShift来支持PaaS额外的一些层。我还需要和Alex确认一下他们是怎么做的，是否和我认为的OpenShift使用了LXC的想法一致。既然CloudStack提供LXC支持，那么一个人足矣可以使用Brooklyn在CloudStack上部署LXC集群，然后用OpenShift管理部署的应用程序。

• 在OpenShift上聪明的注释。据我所知，事实上它是使用静态集群的，其扩展性是来自于节点中Containes的使用。因此在技术上你可以在CloudStack上创建一个OpenShift集群，但是我不认为OpenShift会和CloudStack API有直接的对话而创建节点。Openshift绕过了IaaS API，当然我还没有验证过这点，也许我理解错了。

  
  

• 为了Vagrant而讨论PaaS似乎有点牵强，但是它的确能够达到基础设施部署的标准，也可以和 AWS OpsWorks相比。为了让开发人员的操作人员在同样的环境中工作，Vagrant可以帮助定义复制机器(reproducible machines),带有插件的Vagrant还可以帮助在公共云上的部署，能够处理多服务器的定义。所以你可以把Vagrantfile看作是虚拟基础设施部署的定义模板。事实上，我们有很多Vagrant boxes可以用来部署Apache Mesos集群, MongoDB,RiakCS集群等。这并不是说在生产环境上管理堆栈，但是至少可以帮助我们开发。在CCC大会上来自于Klarna的Hugo Correia演示了带有CloudStack插件的Vagrant.Exoscale创建了一套对于开发部署来说非常有含金量的exoboxes，所有的CloudStack供应商都应该开始效仿。

• 目前在CloudStack中并没有支持Docker，这也使我想到了Docker。既然我们支持LXC，那在CloudStack上支持Docker集群也未必是难事。你甚至可以在一个镜像中安装Docker然后部署到KVM或Xen上。当然也会有人说在VM中使用容器起不了什么作用，不管怎样，只有通过Docker远程API你才能够管理你的容器。OpenStack已经有了和Docker的集成，我们将深入研究Docker的功能来看如何更好地和CloudStack集成

• 正如我提到的，AWS(亚马逊云服务)有很多Paas，比如说OpsWorks, CloudFormation, Beanstalk. CloudStack已经有了EC2接口但是必须要借助第三方方案来使CloudFormation生效。这个目前还在开发阶段但是马上就要做好了。可以参考 stackmate 和它的web interface stacktician。不久的将来通过CF interface我们还可以看到OpSwork 和 Beanstalk 接口。

• 最后，虽然不会出席CCC但是PaaS的领袖仍然是CloudFoundry.，下周我还要去伦敦和Andy Piper见面，讨论最近CloudStack 支持合并到CloudFoundry 社区的事情, 这个合并是由日本的朋友完成的，我还没来及测试。当然同在一个社区，我们应该更加紧密的联系，确保在ACS为CloudFoundry提供出色的支持。

直到现在，我们还没有清晰的定义PaaS和IaaS的边界，其实这个更加高度的依赖于上下文，依赖于你是谁，你要达到怎样的目标。另外，CloudStack提供了多个接口给PaaS，或者也可以说PaaS给CloudStack提供了多个插口。