为什么私有云的定位应该是PaaS,而不是IaaS?


【编者的话】IT界已经对私有云架构争论了好久,虽然有很对公司尝试了Iaas私有云方案,但始终不尽如人意,因为把目光仅仅集中在Iaas上是一个一开始就错误的想法。与此同时,围绕Mesos的私有云方案真正奏效了,基于Mesos构建私有PaaS不仅仅是大势所趋,它已经在很多公司证明了自己的价值。

在IT界数年针对私有云架构的优点的不断的争论之后,一个切实可行且企业可用的私有云架构终于来到了我们面前。并且与其它在过去的一个世纪出现的技术方案不同,它已经在世界上的一些巨头公司,和采用先进技术的最多的公司里都证明了自己的价值。

重要的是,我们指的不是IaaS。到目前为止IaaS方案已经被尝试过太多次,难以统计,并且还没有怎样扩散开来。不断的有初创公司尝试但无功而返,也不乏大公司步其后尘 - 包括像OpenStack这样的项目 - 结果却未能将私有的IaaS打造成为一个可伸缩的商业产品(sclable business)。

那问题出在哪呢?这是因为IaaS并不是云计算用户的终极目标 - 至少在他们还有选择的情况下不会是。高效运维和可伸缩的基础设施(scalable infrastructure)只是提高开发者效率和商业敏捷性的途径。对于CIO来讲,一个投入大量资源开发的项目却只能达到一半的目标,这付出很难能看到什么回报。

这就是为什么私有云计算的未来是立足于另外一个开源平台 - Apache Mesos- 之上,并且以更加像一个PaaS平台的面貌示人。这方案之所以行得通是因为它仍然具有运维高效性的特点,人们通常把这一点拿来作为兜售部署私有云时列举的原因之一,但是这种以围绕Mesos风格的私有云真正可以奏效的原因是它能给开发者带来更快、更简单及更灵活的用户体验,而这才是云一直的核心。

你可能不会相信我的这些话。但你会相信Gartner的话,相信Twitter、Apple、Yelp、Hubspot、Autodesk、eBay、Ericsson、Capgemini以及其他已经基于Mesos打造出他们自己的功能完整且无比牢靠的私有PaaS系统的大公司的话。

为什么选择私有PaaS而不是私有IaaS?

有一个很争议的观点,把目光仅仅集中在可复制(replicating)的IaaS云平台,如AWS,是一个一开始就错误的想法。毕竟,AWS当初引人注目是仅仅是因为凭信用卡几分钟内就可以使用,而不是因为它看起来是部署应用最好或者最简单的方式。

下面是Gartner的VP和杰出分析师Thomas Bittman对于私有PaaS的看法,这出自2014年10月的一篇有关于采用私有云技术时犯的最大的错误的报告:


尽管大部分的私有云是IaaS,使用虚拟机来作为工作单元,然而单纯的IaaS的价值是有限的。即便是公有云IaaS提供商们也在他们IaaS功能的基础上提供了不少额外功能,包括很多便于开发者使用的工具,用来准备(provision)虚拟机和对虚拟机内部进行管理的工具,和越来越多的PaaS的服务。
...
通过重写PaaS层,通过要求和公有云PaaS的协作,或是通过SaaS模型从一个对外的提供者来获得服务,这些方法都能使一些应用提供更好的服务。尽管,私有的PaaS仍然相对少见,但是支撑私有PaaS的技术会日趋成熟 - 特别是对于云的混合模式而言。
实际上,它们正在慢慢成熟;因为这只是一个时间问题。一直以来都是开发者推动着云计算技术的采用。他们是AWS的第一批用户,因为其让他们不用烦请IT的协助;他们是PaaS的第一批用户(如早期的Heroku),因为其帮助他们摆脱AWS的复杂度;他们也是SaaS工具,如NewRelic的第一批用户,因为其帮助他们监控他们刚刚启动的云服务。

就如Marten Mickos(Eucalyptus Systems的前任CEO,也是MySQL之前的CEO)今年年初巧妙而简介的说:


开发者再也不问你要服务器了。他们甚至不问你要一个LAMP套件(stack)。他们想要API。
— Mårten Mickos (@martenmickos)
2015年5月29日
很可能还要一些容器。

本质上,开发者想要把创建和部署新的应用纳入他们快速的code-deploy-test循环的一部分。如果你总是在等待IT准备可靠的镜像,那么持续交付、持续集成和微服务就永无可能。并且,坦白的讲,开发者不会关心在何处部署他们的应用和服务,只要这个部署过程比较容易。

这里就是IT和运维真正需要施展身手和改变世界的地方。通过选择合适的软件套装(假如至少是Mesos和Docker),聪明的CIO能满足商业层的需求,如提高资源利用率、降低用电开销以及减少宕机时间,同时保证提供快速灵活,符合开发者需求的平台。

基于Mesos构建私有PaaS不仅仅是大势所趋

对于很多Mesos的用户来说,包括上面列举的对公商业的公司,私有的PaaS不仅仅是一个新兴的技术 - 它已经站在了我们的面前。Mesos提供了服务器层面的调度和通常的资源管理能力和抽象(resource-management capabilities and abstractions),然后更高层次的工具如Marathon、Docker和其他一些自己开发(并且通常开源)的工具提升了开发者的体验。

几乎对于一个公司来说,PaaS-on-Mesos架构已经大大地提升了在平台上部署应用的舒适度和速度。得益于Mesos,很多用户终于能够拥抱微服务的架构,甚至把玩新出现的大型数据框架,因为Mesos可以基于实际所需资源调度workload(工作量),并且支持在同一个集群里任何类型的workload。

已经有好几个由大公司构建的PaaS框架,方便运行在Mesos(并且扩展一点的说,DCOS)之上,并且已经开源。这些包括:

  • Marathon:由Mesosphere开发和提供支持,并且其也预装在我们的数据中心操作系统(DCOS)产品之上,Marathon被设计用来运行需要长时间不间断运行的服务,并且通常作为PaaS环境中的那些Docker容器的部署环境。Marathon能处理资源的分配和运行的服务可用性。

  • Apache Aurora:Aurora最初是Twitter开发用来作为PaaS-type layer。Twitter很可能是世界上最大的Mesos用户,在数据中心成千上万的节点上使用,现在用来管理公司很多核心服务所需要的资源。就如Marathon一样,Aurora负责保证即使在服务器宕机的情况下,工作仍然能持续运行。

  • Singularity:Singularity由HubSpot开发,这是在其对即将由Meso管理的AWS镜像,针对占用大进行重新架构之后开发的。HubSpot把Singularity称为“箱子里的PaaS”,意思是其提供的抽象足以让对Mesos不熟悉的人轻松启动job。

  • DeisEngine Yard很多年一直是公共PaaS的首要提供者,最近他们发布了焕然一新的核心平台,通过Deis提供对私有的基于Docker的平台强有力的支持。今年早些时候,Deis项目开始集成Mesos。

  • Apollo:这是一个特别有意思的项目,因为它是由最大的咨询公司和系统集成商Capgemini开发,用来服务该公司的大客户。Apollo使用了很多额外的组件,这包含Terraform和Packer,来让用户可以构建私有的IaaS和私有的PaaS环境。

  • Ochothon:CAD的专家Autodesk最初创建了一个叫Ochopod容器编排层,它可以简化内部的IT流程。并且Ochothon是设计用来运行于Marathon之上的一个版本。当公司趋向于以Mesos为中心的基础设施,Ochothon提供了一系列高水准性能,使一个集群内容器间的互通实现自动化。


通过在DCOS添加了对其他容器编排,Mesosphere对开源的支持往前又进了一步,PaaS在开发的时候没有考虑到Mesos,但是仍然提供了很多好用的功能。这些包括Google领头的Kubernetes项目、Docker的Swarm、Red Hat的OpenShift和最后的Cloud Foundry。

在过去几年,也有其他很多基于Mesos的PaaS系统被开发构建,但还不是开源的,一些公开讨论过他们系统的公司包括:

  • Yelp:Yelp在Marathon的基础上构建了一个基于Docker的微服务架构,叫做PaaSTa。它能在公司和AWS的机器的镜像之间完成Docker容器自动化部署和服务集成。PaaSTa和相关的投入对于Yelp的持续部署环境至关重要,并且该公司现在每天需要启动超过一百万的容器来支持其代码-测试(code-testing)的流程。

  • Apple:Apple构建了一个自己的Mesos调度器,名字叫J.A.R.V.I.S.(Just A Rather Very Intelligent Scheduler 一个有点相当智能的调度器)。它在后端支撑了整个Siri的应用。Mesos的集群遍布成千的节点,让开发者可以更容易的部署组成Siri的单个服务。

  • eBay:对于eBay来说,目标是从现有的(专有且基于VM的)持续化集成方案迁移到一个基于Mesos的方案。在他的方案中,每一个开发者都分配有一个Jenkins的实例,用到的是Mesos和Marathon,Meso实际运行在OpenStack的实例之上。

  • Ericsson:这位通讯巨头使用Mesos和Marathon来作为一个PaaS系统的基础,可以用来支撑数据分析,并且全局的在数千个数据中心强制SLA。


DCOS让PaaS更容易

然而尽管所有之前提到的案例都显示Mesos可能带来的各种美好的愿景,现实是不是每一个公司都有足够的资源和热情来构建牢靠(mission-critical)且完全依赖开源技术的系统,假如要自己从头做起就更难。

DCOS让构建一个私有的PaaS相对的简单了,因为其提供了要构建一个PaaS所有必要的组件和原语(primitive),不管是在前置或者公有的云。DCOS提供了开源的Mesos的所有功能,另外还有在UI/UX,SDK和商业支持方面一些重大的改善。

一个高层次的架构是像下面这样的:
dcos-positioning.png

其中的IaaS层在这里严格的指准备(provision)和管理机器。他们可以是物理的机器、虚拟机或者是公有云主机的实例。DCOS中默认的PaaS服务是Marathon,这是一个开源的由Mesosphere开发的技术。然而,Yelp和其他公司都证明,Marathon也可以用来作为更加自定义化层的基础-通常会牵涉到特定的用来配置运行其上的容器的方法。

除了PaaS通常大家都知道的优点,DCOS也能让部署混合云架构变的容易-这意味着你的私有PaaS可以运行在公有云之上。Workload的移植性是DCOS核心要保证的东西,因此将前置环境的一部分或者所有应用迁移到公有云上(或者是方向相反的移动)会十分自然。资源都有同样的抽象,用户体验保持不变,而且代码不需要改变。

今天商业的现实是商业要求快速改变,意味着对于IT基础设施的和开发者的需求都也在快速改变。很多公司一直都在寻求把私有云作为让后者与前者保持一致的方案,今天私有云终于开始登上舞台为自己代言。尽管其可能不是我们六年前想象其的样子,但是这已经没有什么关系。

因为这一次,it works。

原文链接:WHY YOUR PRIVATE CLOUD COULD LOOK A LOT LIKE PAAS(翻译:钟最龙 审校:魏小红)

1 个评论

哇咔咔 这样子的话 我就不用吊死在 OpenStack 上了

要回复文章请先登录注册