对国内云计算三个现象的思考

发布于 2013年09月11日

现象一:没有API 的公有IaaS服务

近一两年来,国内公有IaaS“服务”如雨后春笋一般大量出现。其中有几家厂商对外开放了其对象存储的API。而除了阿里云提供了ECS API外,在其他厂商云服务主页上却看不到类似AWS EC2 API的开放API。【注:我没有使用过阿里云ECS API,其官网上只提供了一遍介绍性文章和功能简单的SDK,网络上也没有查询到相关的成功案例。API是否成熟的标志是用户可以通过Rightscale等云管理软件、jclouds等库进行管理和操作。】

如果在没有开放API的情况下,就发布IaaS“服务”,那么说明API在产品优先级中处于很低的位置。这表明国内的公有IaaS服务商没有真正理解AWS成功的根本原因,其对AWS的模仿仅限于“产品名称”上。如果不能通过API进行自动化控制,仅通过Console进行管理是非常烦琐的, 而且无法支持自动化的部署和运维,也无法实现自动伸缩、HA、Failover等高级特性。

反观国外的公有云服务,除了AWS外,无论是Rackspace,还是后推出的Azure、GCE、HP Cloud等都是有API的。四大开源IaaS平台软件OpenStack、CloudStack、Eucalyptus和OpenNebula也都是有API的,有些甚至与AWS完全兼容。为什么API如此重要?

Amazon CTO Werner Vogels的观点“Everything is a Programmable Unit”便是答案。IaaS的真正价值不在于自动化编排和管理数据中心物理资源,而是彻底改变上层平台和应用使用IT资源的方式。AWS基于核心EC2 API,构建出了很多上层服务,逐步形成一个完整的云服务体系。而开放的API也为开发者和第三方厂商提供了在IaaS平台上广阔的创新空间,如PaaS、应用生命周期管理软件、DevOps工具、混合云管理工具等。

没有API的公有云导致国内用户不能开发真正的Cloud-Native应用,这就是要分析的第二个现象。

现象二:鲜有成功的Cloud-Native应用

在AWS出现之前,“Cloud-Native应用”这个概念并不存在。AWS快速发展的背后,是大量构建、运行于AWS之上的成功Cloud-Native应用,如Netflix、Zynga、Pinterest、Heroku、Reddit等。让我们看看Pinterest在2013年1月时的一些数据。

  • 8000万对象被存储在S3中,共计410TB的数据存储量。这是2012年8月份数据的10倍。EC2实例也已增长了近3倍。
  • 在2011年底,Pinterest大约12名员工,而今,大约有31名(人数还是很少)。
  • 高峰时,EC2上要花费52美元/小时,晚上及其他非高峰时间,访问量会急剧下滑,仅该项可减少到15美元/小时。
  • Web层用了150个EC2实例;70个主数据库分布在全球不同区域,以实现数据库的并行备份,实现系统冗余。
  • ELB被用作实现实例间的复杂均衡服务,ELB API使得实例的移动更容易实现。

Cloud-Native应用的核心改变是:Fit App to Infra,而不是Fit Infra to App。Amazon CTO说,21世纪应用架构的四个属性是Controllable、Resilient、Adaptive和Data-Driven。既要充分利用云基础设施的可编程性、可扩展性等特性,又要解决云基础设施的不可靠问题,这是云时代软件开发的新挑战(如图1所示)。

看到这个图,大家自然会想到解决这个Gap的就是PaaS,但这里PaaS要解决的问题和国内大部分人所理解的PaaS要解决的问题有差异。究其原因,是国内用户缺乏切实的Cloud-Native App开发经验,导致国内对PaaS的理解单一,出现了单一的Cloud Foundry PaaS热。

现象三:对PaaS的理解较单一

相比于IaaS,人们对PaaS的理解不尽相同。Netflix为我们展现了一种不同于通常人们所理解的PaaS。Netflix是构建在AWS上的最大Service,其使用的EC2实例数在10k数量级。Netflix认为其将服务迁移到AWS上后,其技术的核心工作是在AWS之上构建一个PaaS层。目前,这个PaaS中的大部分组件已经被Netflix开源了。当大家看完Netflix的开源项目后,会发现这个PaaS和我们通常概念中的PaaS(如Cloud Foundry)有差异。我们一般认为:SaaS的目标用户是最终用户;PaaS的目标用户是开发者;IaaS的目标用户是IT Ops。

但问题是对于很多应用,特别是复杂应用,传统意义上的PaaS根本无法满足需求。例如,可以在Cloud Foundry平台上运行一个Cloud Foundry吗?显然是不行的。对于复杂的、大规模的应用,开发人员需要拥有对整个Full-Stack的控制。因此,开发者也是IaaS的目标用户,特别在PaaS发展的早期。开发者可以基于IaaS构建支撑其Cloud-Native应用的PaaS能力层。但对于开发者而言,构建介于Cloud-Native App和Infra之间的PaaS能力层有多种选择。除了传统的PaaS外,可以选择IaaS提供的附加上层Service,还可以选择第三方云管理工具,也可以完全自己搭建,如图2所示。

架构师和开发人员选择哪些种方式构建PaaS能力层,取决于自身情况,切勿将PaaS的理解局限在Cloud Foundry等传统意义的PaaS上。

总结

没有API的公有云服务使国内开发人员无法在IaaS上构建Cloud-Native应用。无Cloud-Native应用的开发经验,使开发人员对PaaS的理解有限,从而极大限制了国内在PaaS领域的创新。

因此,我给出以下建议。

  • 国内公有云服务商将开放API放在最高优先级,而且这个API最好与AWS兼容或者类似。
  • 不要热衷于使用OpenStack或者CloudStack搭建私有云,要先学会在公有云上构建Cloud-Native应用,进而实现云服务各个层面的业务创新
  • 除了传统PaaS外,还应关注如何基于IaaS构建符合自己需求的PaaS能力层。

作者阮志敏,目前就职于三星电子中国通信研究院,从事Paas相关的工作。