翻译于 2014/02/07 18:00
1 人 顶 此译文
In November at the CloudStack Collaboration Conference I was pleased to see several talks on PaaS. We had Uri Cohen (@uri1803) from Gigaspaces, Marc-Elian Begin (@lemeb) from Sixsq and Alex Heneveld (@ahtweetin) from CloudSoft. We also had some related talks -depending on your definition of PaaS- with talks about Docker and Vagrant.
The differences between PaaS solutions is best explained by this picture from AWS FAQ about application management.
There is clearly a spectrum that goes from operational control to pure application deployment. We could argue that true PaaS abstracts the operational details and that management of the underlying infrastructure should be totally hidden, that said, automation of virtual infrastructure deployment has reached such a sophisticated state that it blurs the definition between IaaS and PaaS. Not suprisingly AWS offers services that covers the entire spectrum.
Since I am more on the operation side, I tend to see a PaaS as an infrastructure automation framework. For instance I look for tools to deploy a MongoDB cluster or a RiakCS cluster. I am not looking for an abstract plaform that has Monogdb pre-installed and where I can turn a knob to increase the size of the cluster or manage my shards. An application person will prefer to look at something like Google App Engine and it's open source version Appscale. I will get back to all these differences in a next post on PaaS but this article by @DavidLinthicum that just came out is a good read.
非常荣幸在十一月份的CCC(CloudStack 沟通合作交流会)上看到一些关于PaaS的讨论, 来自于Gigaspaces 的 Uri Cohen (@uri1803), Sixsq 的 Marc-Elian Begin (@lemeb) 和来自于 CloudSoft的 Alex Heneveld (@ahtweetin) 都参与了讨论,而且还有一些关于Paas定义的讨论(具体可参看Docker和Vagrant)
在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)还是很值得一看的。
What is interesting for the CloudStack community is to look at the support for CloudStack in all these different solutions wherever they are in the application management spectrum.
Cloudify from Gigaspaces was all over twitter about their support for OpenStack, and I was getting slightly bothered with the lack of CloudStack support. That's why it was great to see Uri Cohen in Amstredam. He delivered a great talk and he gave me a demo of Cloudify. I was very impressed of course by the slick UI but overall by the ability to provision complete application/infrastructure definitions on clouds. Underlying it uses Apache jclouds, so there was no reason that it could not talk to CloudStack. Over christmas Uri did a terrific job and the CloudStack support is now tested and documented. It works not only on the commercial version from Citrix CloudPlatform but also with Apache CloudStack. And of course it works with my neighbors Cloud exoscale
Slipstream is not widely known but worth a look. At CCC @lemeb demoed a CloudStack driver. Since then, they now offer an hosted version of their slipstream cloud orchestration framework which turns out to be hosted on exoscale CloudStack cloud. Slipstream is more of a Cloud broker than a PaaS but it automates application deployment on multiple clouds abstracting the various cloud APIs and offering application templates for deployments of virtual infrastructure. Check it out.
Cloudsoft main application deployment engine is brooklyn, it originated from Alex Heneveld contribution to Apache Whirr that I wrote about couple times. But it can use OpenShift for additional level of PaaS. I will need to check with Alex how they are doing this, as I believe Openshift uses LXC. Since CloudStack has LXC support, one ought to be able to use Brooklyn to deploy a LXC cluster on CloudStack and then use OpenShift to manage deployed applications.
A quick note on OpenShift. As far as I understand, it actually uses a static cluster. The scalability comes from the use of containes in the nodes. So technically you could create an OpenShift cluster in CloudStack, but I don't think we will see OpenShift talking directly to the CloudStack API to add nodes. Openshift bypasses the IaaS APIs. Of course I have not looked at it in a while and I may be wrong :)
Talking about PaaS for Vagrant is probably a bit far fetched, but it fits the infrastructure deployment criteria and could be compared with AWS OpsWorks. Vagrant helps to define reproducible machines so that devs and ops can actually work on the same base servers. But Vagrant with its plugins can also help deployment on public clouds, and can handle multiple server definitions. So one can look at a Vagrantfile as a template defintion for a virtual infrastructure deployment. As a matter of fact, there are many Vagrant boxes out there to deploy things like Apache Mesos clusters, MongoDB, RiakCS clusters etc. It's not meant to manage that stack in production but at a minimum can help develop it. Vagrant has a CloudStack plugin demoed by Hugo Correia from Klarna at CCC. Exoscale took the bait and created a set of -exoboxes- that's real gold for developers deploying in exoscale and any CloudStack provider should follow suit.
Which brings me on to Docker, there is currently no support for Docker in CloudStack. We do have LXC support therefore it would not be to hard to have a 'docker' cluster in CloudStack. You could even install docker within an image and deploy that on KVM or Xen. Of course some would argue that using containers within VMs defeats the purpose. In any case, with the Docker remote API you could then manage your containers. OpenStack already has a Docker integration, we will dig deeper into Docker functionality to see how best to integrate it in CloudStack.
AWS as I mentioned has several PaaS like layers with OpsWorks, CloudFormation, Beanstalk. CloudStack has an EC2 interface but also has a third party solution to enabled CloudFormation. This is still under development but pretty close to full functionality, check out stackmate and its web interface stacktician. With a CF interface to CloudStack we could see a OpSWork and a Beanstalk interface coming in the future.
Finally, not present at CCC but the leader of PaaS for enterprise is CloudFoundry. I am going to see Andy Piper (@andypiper) in London next week and will make sure to talk to him about the recent CloudStack support that was merged in the cloudfoundry community repo. It came from folks in Japan and I have not had time to test it. Certainly we as a community should look at this very closely to make sure there is outstanding support for CloudFoundry in ACS.
It is not clear what the frontier between PaaS and IaaS is, it is highly dependent on the context, who you are and what you are trying to achieve. But CloudStack offers several interfaces to PaaS or shall I say PaaS offer several connectors to 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提供了多个插口。