现象一：没有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所示）。
图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所示。
图2 PaaS层的构成
架构师和开发人员选择哪些种方式构建PaaS能力层，取决于自身情况，切勿将PaaS的理解局限在Cloud Foundry等传统意义的PaaS上。
总结
没有API的公有云服务使国内开发人员无法在IaaS上构建Cloud-Native应用。无Cloud-Native应用的开发经验，使开发人员对PaaS的理解有限，从而极大限制了国内在PaaS领域的创新。
因此，我给出以下建议。
- 国内公有云服务商将开放API放在最高优先级，而且这个API最好与AWS兼容或者类似。
- 不要热衷于使用OpenStack或者CloudStack搭建私有云，要先学会在公有云上构建Cloud-Native应用，进而实现云服务各个层面的业务创新
- 除了传统PaaS外，还应关注如何基于IaaS构建符合自己需求的PaaS能力层。
谈对国内公有云两个计费现象的思考
2013年，我在《程序员》杂志发表了“ 对国内云计算三个现象的思考”，文章中分析了国内云计算的三个现象：
- 现象一：没有API 的公有IaaS服务
- 现象二：鲜有成功的Cloud-Native应用
- 现象三：对PaaS的理解较单一
而在过去一年多的时间里，国内的云计算领域发生了很多重大事件，比如：AWS入华、Azure正式商用、阿里云强势爆发、UCloud/青云等独立第三方云服务厂商获得大笔风险投资等等， 种种迹象都表明云计算在国内已经步入加速发展阶段。 对于上述三个现象，我目前的看法是：
IaaS API方面：主流的公有云IaaS厂商都提供了API。 但是， 有了API并不代表其坚持API优先的原则。 API优先要求云服务提供者“Eat your own dog food”，即通过调用基础服务的API来构建各种上层服务，同时给生态圈合作伙伴提供平等的机会。
原生云应用方面： 云的成功案例越来越多，但是大部分集中在游戏等行业， 对传统行业的渗透才刚刚开始。另外，我们还缺少像Netflix这样毫无争议的示范案例。
PaaS方面： Cloud Foundry开始偏向企业私有云领域。由于大部分的公有云用户对云服务器的需求仍在个位数级别范围内，因此他们对第三方自动化管理部署工具、应用生命周期管理、混合云管理工具的需求仍不强烈。
成本费用（Cost）和安全（Security）一直以来都是公有云的两个焦点问题。 本文的主旨就是讨论云服务的计费模式。 下面是笔者观察到的国内公有云计费方面的两个现象，主要涉及计算资源的计费模式。
现象一：包年包月
包年包月对服务提供者和消费者都有好处。云服务提供者可以将包年包月类型的虚机集中起来管理，可提高虚机密度，进而提高资源使用效率；云消费者可以降低使用成本。 包年包月计费方式看似和AWS的预留实例类似，但是实质上有许多不同之处。
- AWS预留实例不影响用户使用EC2的方式，只是在计费时价格不同而已。当用户创建虚机时，无论用户是用管理控制台、CloudFormation、OpsWorks、命令行工具、还是第三方管理工具，其计费结果都是一样的。但是对目前国内云服务商比如阿里云， 用户只能通过管理控制台才能订购包年包月虚机， 用户无法通过API订购包年包月虚机。
- 按量计费启动的虚机无任何折扣，其价格比包年包月贵很多。 如果用户订购的是按量付费类型虚机，无论其订购多少、使用时间多长， 用户都无法享受到任何折扣。 任何云服务都是可编程的资源（API），Cloud-Native云应用会充分利用这些API来实现高可用、可扩展、安全的分布式应用。 按量计费的虚机将会是未来的主流，云服务商应该想办法降低按量计费的虚机的使用成本。
从目前看， 降低用户使用计算资源费用的办法主要有三个：AWS的预留实例方式、Google的阶梯使用折扣方式（Sustained Use Discounts， 对于一个虚机，单价在一个计费周期内是随着运行时间的增加而反向下降的）和国内特色的包年包月方式。 它们各自的特点和区别是：
1. AWS预留实例方式不会影响用户的使用方式，但是AWS预留方式帮助用户省钱的前提是用户必须能够准确预测未来计算资源使用量。 由于业务的不可预测性， 准确预测未来资源使用量是很难的。 AWS预留实例采购方式通常是1年或者3年，这使得预测变更加困难。
2. Google的阶梯使用折扣方式不会影响用户的使用方式，同时用户也不需要预测未来资源使用量，最为简单直观。
3. 国内的包年包月和按量计费是互相排斥的方式， 影响用户的使用方式，而且按量付费方式无任何折扣。
本文的重点不是关注云服务商的绝对价格。下表列出了国内外典型云服务厂商一款相似虚机类型（2核8G内存Linux虚机）的月平均费用对比， 主要是想让大家对各厂商计费方式有个直观的认识。
| 类别 | 月平均费用（元） | 备注(2014/08/06的价格) |
| 青云按量 | 0.774 * 720 = 557 | 北京2区（PEK2）， 青云不提供包年包月，也不提供其他折扣 |
| 阿里云包年 | （374 × 10）/12 = 312 | 青岛数据中心， 假设使用满一年 |
| 阿里云包月 | 374 | 青岛数据中心，假设使用满一月 |
| 阿里云按量 | 1.368 × 720 = 985 | 青岛数据中心，假设使用满一月 |
| UCloud包年 | 4500/12 = 375 | 华东双线，假设使用满一年 |
| UCloud包月 | 450 | 华东双线，假设使用满一月 |
| UCloud按小时 | 0.90 × 720 = 648 | 华东双线，假设使用满一月 |
| AWS预留（Medium Utilization） | （362/12 + 0.055 × 720） × 6.2 = 432 | m3.large/us-east，一年预留实例, 假设使用满一年，汇率6.2 |
| AWS预留 （Heavy Utilization） | （443/12 + 0.037 × 720） × 6.2 = 394 | m3.large/us-east，一年预留实例，假设使用满一年, 汇率6.2 |
| AWS On-Demand | 0.14 × 720 × 6.2 = 624 | m3.large/us-east，汇率6.2 |
| Google Cloud Platform | (0.14 * 180 + 0.14 * 180 * 0.8 + 0.14 * 180 * 0.6 + 0.14 * 180 * 0.4) * 6.2 = 437 | n1-standard-2/us ，假设使用满一月 |
现象二：秒级计费
一些国内新兴的云服务公司把秒级计费做为其特性之一进行宣传， 取到非常好的效果。这是因为Google的计费最小单位是10分钟， 而AWS/阿里云等的最小单位更是高达1个小时， 和秒级计费单位有很大差距。
但如果用户使用云服务达到一定的量，则最小计费单元对用户使用云服务总费用的影响是微乎其微的。从上述的对比表格中我们可以看出， 假如用户使用一个月的时间， 青云的费用并不比其他云服务低。 这和电信运营商对语音通话的计费单位是按照分还是按照秒的道理是一样的。整体性降价对用户更有实质意义。
秒级计费更多还是反映了云服务的使用哲学，即根据业务的变化，用户可以通过API（或者是基于API的管理工具）动态调整资源的使用量， 由此来节省费用。 比如， 晚上的时候，业务量都比白天小，用户可以设定自动伸缩来动态调整资源的使用量。 阿里云的问题在于其提供的包年包月计费方式限制了用户的使用方式（只能从管理控制台启动），限制了用户充分利用云的可编程特性； 另一方面， 其对按量付费的使用方式不提供任何折扣， 用户使用按量付费虚机的成本很高。
总结
在国内，人们热衷于比较各个云服务厂商的价格，却忽略了云服务的计费模式。我认为计费模式将对国内云计算生态圈的发展和促进用户构建云应用的方式转变会起到非常重要的作用。 云服务的定价体系和计费系统是一个系统工程，每个厂商、每个服务有自己的计费方式。但是公有云服务本质上是Utility服务，无论是哪个厂商， 其计费背后的原则应该是一致的，这些原则包括：
1. 按使用量计费。 任何云服务都是可编程的资源（API）， 用户可以非常方便的使用这些资源，按照使用量的多少来计费。
2. 使用越多、需求越稳定， 价格则越便宜。
3. 规模越大，价格越便宜：随着云服务商规模的扩大，其运营成本会下降，这时应该降价让利于云消费者。
4. 无差别原则： 用户创建的资源，无论是通过AWS管理控制台还是第三方管理工具， 其价格是一样的。
5. 费用可视化、可跟踪原则： 云服务厂商提供了费用查询接口， 让费用可视化、可跟踪成为可能，从而帮助用户优化、降低成本费用。
6. 定价依据的是消耗的计算/存储/数据传输等成本。比如， AWS提供了很多免费的服务，这些服务之所以免费是因为其是管理服务，本身不消耗资源，比如Autoscaling服务、OpsWorks、Beanstalk、IAM、CloudFormation。
作者简介
阮志敏， AWS认证架构师（专业级别）， 长期关注于如何使用云服务进行业务创新， 对云服务生态圈有较深入的思考。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
