云服务的价格能够压缩到怎样的水平?

　　目前对于IT部门而言，这场激烈的云服务价格战仅仅存在于三大顶级云服务供应商之间——这是因为其它几十家供应商在云容量规模方面根本达不到这三家巨头的水平或者说高度。谷歌、微软以及AWS各自拥有着超过一百万台设备。而且根据AWS公司所给出的一部分自有数据中心数据，其基础设施内的设备数量很可能在140万台到560万台之间，而且我们认为其设备数量超过300万台的可能性非常高。Gartner公司在去年发布的报告中则预测称，AWS旗下的设备总数应该在240万台左右。Gartner方面同时指出，AWS的整体服务器数量达到了其后十四家云服务供应商设备总和的五倍。Rackspace Hosting与IBM SoftLayer各自拥有着规模较小的云服务体系。根据Rackspace公司发布的财报显示，截至今年三月底该公司拥有11万4105台设备，而SoftLayer在2014年一月时的设备总量已经超过了10万台，而且根据IBM方面的说法其每年约以2万台的速度递增。因此截至目前，蓝色巨人的基础设施规模应该在12万5千台左右。换句话来说，一旦我们将视线投向AWS、谷歌以及微软之外的云服务供应商，其现有基础设施的规模、或者说服务器整体数量会出现快速跳水。

　　而这一点非常关键，至少就目前来说大部分云服务仍然立足于裸机设备，而这也是单一应用程序、集群化应用程序节点或者虚拟机管理程序的托管基础——而且至少与软件容器机制相比，这种方式的日常成本显然要高得多。所有这些裸机设备都能够在不同时段实现共享，但却无法在同一时间范围内被并行使用。而这就令我们很难提高资源利用率，这意味着云服务供应商几乎无法利用多种工作负载及客户需求对裸机设备成本进行摊薄。

　　正是考虑到裸机服务器节点的上术局限，如今OpenStack项目才将其作为Ironic方案的一大关键性发展方向。任何能够在裸机之上实现应用程序部署提速的机制都将有效改进资源使用效率。而且如果容器能够将更多处理任务囊括在同一台设备之上，那么即使不打算借此取代服务器虚拟化方案，这也足以将资源利用率推向新的水平。这种裸机配置加软件容器的技术组合在很多情况下甚至有能力取代管理程序与虚拟机在云环境当中的地位，而这自然也有助于云服务供应商完成对摩尔定律的遵循。在大多数情况下，容器将运行在虚拟机基础之上，而这在提高安全水平以及工作负载管理能力的同时，当然也会浪费掉一部分设备性能、从而削弱摩尔定律的理论收益。

　　从客户的角度出发，谷歌公司对其Cloud Platform作出的价格持续下调承诺确实非常美好，而这也许意味着谷歌拥有出色的先见之明。下面我们来看谷歌公司自2013年11月首次推出其Compute Engine基础设施云服务之后，到底有没有践行自己的降价承诺：

　　没有哪家云服务供应商愿意把钱浪费在不必要的基础设施容量购置上，而谷歌公司在过去十八个月当中已经将其Compute Engine容量使用费降低了50%的作法并不代表其会在未来十八个月中继续保持这一降价趋势。另外，这自然也不代表所有类型的计算与存储容量都能获得同样的价格下调幅度。事实上，Compute Engine的价格下调速度在一年之前基本保持平稳，但不同类型的实例有着不同程度的成本变动曲线。微型实例的降价幅度约为30%，而标准实例的价格降幅仅为20%，负载强度较高的存储实例价格降幅约在15%，而高CPU使用率实例的价格下调空间只有可怜的5%。

　　以上图表当中所示的典型价格曲线指的是全部客户在使用Compute Engine时为特定实例类型所支付的平均使用成本，这似乎意味着大部分客户都已经享受到了谷歌公司所提供的长期使用折扣——这项政策会自动应用至Compute Engine上的按需实例当中。随着按需实例使用周期的不断延长，从第二个月起用户所需支付的实例价格开始不断降低。如果大家每个月使用某实例的时长比例仅在25%甚至更低，那么我们需要为其支付全额使用费; 但在这一比例提升至每月50%时，各位则可以享受到10%的计费折扣。(计费机制并非以周为单位而是以小时为单位，不过我们选择以周计算来简化显示效果。)

　　当然，谷歌公司的想法是尽可能早且尽可能持久地帮助Cloud Platform完成所需容量规划及调度。而且预订虚拟机实例则属于另一种达成这项目标的工具。在这种情况下，容量需求可能不像供应流程那样易于预测，或者使用量相对而言较为混乱。(只有云服务供应商能够了解资源容量的分配情况，他们甚至会向华尔街等主要客户发出警告，表示过去的性能水平并不能作为未来性能的保证。)在预订虚拟机实例的帮助下，所有此类实例都将以beta形式存在于各Cloud Platform区域当中，而谷歌公司直接将所有实例类型的价格削减70%; 当然，使用此类新型实例时需要注意一点，即谷歌可以在任何时间将其关闭，而且运行在其上的工作负载最长不能超过24小时，而且用户无法以实时迁移方式将其中的虚拟机负载转移到按需实例当中。这类实例最典型的适用情况就是应用程序需要以分布式方式运行，且能够在任何时候遭遇节点丢失时继续正常运行。举例来说，大家可以将其视为在Hadoop与MapReduce领域非常常见的三重数据存储负载。大家也可以将应用程序的一部分片段运行在按需实例当中，另一部分则交由预订实例负责。当然，大家应该将此作为对现有按需实例方案的补充，而非以廉价方式获取资源容量的办法。