谷歌公司精心构建的Cloud Platform使用户能够更为轻松地启动实例或者在必要时随时使用Google API。

　　如果要说哪家企业真正拿出了以云为核心的计算体系，那么胜出者非谷歌莫属。自发展之初开始，谷歌公司就建立起一套立足于深邃互联网环境的业务定位，而其搜索引擎目前仍然是现代世界上最为强大的工程奇迹之一。大家是否还记得，谷歌搜索引擎上一次停机事故出现在哪一年?

　　公有云评测：谷歌云玩转灵活性

　　很明显，每一家企业都希望能够建立起像谷歌这样以信息为基础且跨越整个互联网的业务体系，并借此积累丰富的技术经验。作为这一领域的先驱者，如果谷歌公司需要某些技术方案，那么其工程师必须自行着手开发，而后完成相关部署。如今，每个人都能够借此获得谷歌技术的收益，意味着以每小时或者每次点击为基础建立起谷歌级别的系统并获得谷歌级别的可靠性水平。

　　使用Google Cloud的最便捷方式就是在Google Compute Engine当中启动一个实例。通过对应网页点击几下或者对API进行几次调用，大家就能够启动这套运行在谷歌基础设施机架内部的虚拟机系统了。

　　用户可以从18种标准Linux发行版当中做出选择(包括Ubuntu、Debian、红帽以及CentOS等等)或者——这可能有点出乎大家的意料——选择两种Windows Server版本(包括2008 R2或者2012 R2)。运行Windows会带来相对略高的使用成本：单vCPU虚拟机标准版本下每月额外支付14.60美元。这部分由操作系统带来的溢价会随着所添置计算核心数量的增加而提升。

　　设备与容器

　　谷歌公司还提供极为广泛的硬件选项外加大量预定义的配置方案，其中最多包含32个虚拟计算核心以及高达208 GB内存。如果大家不喜欢这些标准选项，其UI当中还提供多种滑块设计组件，允许买家随意选择10 GB或者34 GB内存容量。然而，内存容量与计算核心数量紧密相关，这意味着我们无法选择太过极端的组合——例如单CPU配合180 GB内存……当然，大家也不可能使用这种配置。

　　对于开发人员而言，比较实用的选项包括微型与小型实例，其采用共享式CPU并提供几乎任意内存容量水平(包括0.6 GB内存或者1.7 GB内存)。其使用价格亦非常低廉，甚至低到可以忽略不计。微型实例的每小时使用成本仅为0.9美分，这意味着运行一整个月也只需要6.57美元。

　　Google Compute Engine控制台允许大家通过选定CPU数量与内存容量随时启动自己需要的计算实例。

　　不过最终价格可能比这还要低。谷歌公司已经通过向用户提供“持久使用”折扣，以奖励那些保持设备长久运转的客户。当月第一周云服务按全价计算，但第二周持续运行服务的用户则能够享受20%价格折扣。如果大家能够让自己的设备全月运转，那么最后两周的折扣则分别高达60%与40%。这意味着如果我们每月全程运行设备，那么最终将享受到30%的价格折扣。

　　需要注意的是，我们并不需要持续运行实例以享受上述优惠价格。Compute Engine账户会按分钟计算且据此进行费率调整。谷歌公司的虚拟机启动速度极快，因此我们完全可以随时将其关停半小时或者一小时。而更短的间歇时间可能就不太可行了，因为Compute Engine持续会将虚拟机的启动计费时长设置为最低10分钟。

　　另外，我们还可以利用其它方式节约成本。大家能够通过预约实例实现批量处理与非必要工作运行，无论其是否真正进行或者执行相关处理。当这类预约实例开始进行时，我们能够享受到高达70%的折扣，这样的优惠幅度绝对令人难以抗拒。另外，与Amazon的点实例计费方式不同，谷歌的预约实例采用固定计费机制，其基于拍卖市场上出售的过剩计算周期价格。如果大家希望拥有成本预测能力，那么这类预约实例绝对不容错过。

　　值得指出的是，磁盘空间使用费会单独计算，其部分原因在于磁盘运作本身也确实独立于设备之外。我们需要将持久性磁盘“附加”至计算实例当中，而在实例结束之后，磁盘存储内容还将继续存在。大家可以随后将其附加至其它设备。另外，如果大家不再需要这部分磁盘记录，则可将其删除。再有，我们能够利用快照功能对磁盘内容进行重复数据删除，甚至将其同时附加至多个虚拟机系统——但在这种情况，磁盘将处于只读模式之下。

　　大家会在Google Cloud Engine当中发现大量预构建虚拟机选项——虽然其丰富程度仍然无法同Amazon以及Azure相提并论。

　　谷歌云服务中的一类新型方案，此选项允许大家利用谷歌自家的Kubernetes建立起虚拟机集群——这款工具旨在对抗已经在市场上拥有广泛支持的Docker容器技术。在这种情况下，各虚拟机都将由Compute Engine负责实现。

　　要使用这套系统，大家需要对Kubernetes在Docker之外带来的额外特性拥有充分的理解。大家可以将多个容器在pod上进行处理，这种方式特别适合大量容器共享同一类资源的情况——例如使用同一块本地磁盘。

　　而使用这些功能的具体成本取决于用户实际运行多少个Compute Engine实例。如果大家使用的节点数量不超过5个，那么只需要为这些实例付费即可。如果节点达到6个或者更多，那么每小时需要为每个节点支付15美分。

　　平台与API

　　原始实例并非我们的惟一选项。App Engine是一套完全不同的解决方案，而且自刚刚诞生起就选择了一条非常激进的发展路线。相较于立足于操作系统构建服务器体系并全部使用root权限，App Engine更像是一种计算助手。我们可以使用相对较少的代码，而App Engine能够自行完全其余工作。具体来讲，谷歌方面会处理负载均衡器、服务器、操作系统乃至数据库等负载，并最终根据应答一条HTTP请求所占用的计算周期数量创建账单。

　　这意味着我们能够相当轻松地建立起一款应用程序。App Engine的首个版本只接受Python代码。而如今，我们已经可以上传Java、PHP或者谷歌自己的Go语言代码。谷歌公司的模板与库拥有非常强大的解决能力。其标准方案能够对接Django(Python)或者WordPress(PHP)等开源框架，而后为其添加一系更扩展。

　　其中最棘手的部分是重新审视我们的数据库访问流程。大部分基础开源框架都会假定其能够向本地磁盘进行写入。App Engine当然希望我们将数据写入至谷歌的Cloud SQL、Cloud Storage或者NoSQL Datastore当中。这意味着App Engine能够更为轻松地将用户的应用程序一次性扩展到更多虚拟机当中，因为谷歌不希望用户被文件系统的管理工作所束缚。

　　Google Cloud Platform的大部分神奇能力，外加其它一些有趣服务，都能够通过其开放API实现。

　　App Engine可能是目前最理想的应用构建与运行平台，因为其在用户与数据库之间使用相对更“薄”的代码层。(Snapchat就是目前最知名的App Engine成功案例之一。)某些应用任务可能非常害怕服务停机——例如将圆周率计算到小数点后一百万位。而通过强制用户使用其云存储服务，谷歌公司能够对负载保留更多控制肋条。谷歌方面会将用户的代码牢牢控制在“安全限度”之内，当然这一点也是可以具体磋商的——特别是在大家身为大型付费客户的情况下。

　　我们利用Cloud Engine进行数据存储时的首选方案就是使用BigQuery，这是一套采用类SQL接口的纯追加表。BIgQuery以日志为基础并对在线数据进行记录，也就是人们常说的“大数据”信息。谷歌公司正着手利用更多更为复杂的工具对这项功能进行强化，例如Datalab，旨在以BigQuery数据存储层为基础提供图形与分析层。大家将信息保存在BigQuery当中，接下来App Engine实例以运行Datalab代码。Datalab的设计目的在于鼓励不同用户间的合作流程，并允许我们通过笔记本实现登录。

　　最后，Google Cloud用户最感兴趣的另一大选项则是访问谷歌基础设施并通过多种API享受特殊服务。目前提供的超过100种不同API允许大家随意将负载交由谷歌资源打理。

　　举例来说，我们可以相对轻松地允许应用程序用户利用自己的谷歌ID实现登录。而翻译API则能够将文本内容在数十种自然语言之间随意转换。地图API允许我们在自己的网站上添加地理位置信息。另外还有着预测API甚至对应服务支持遗传研究人员在生物实验室内的工作。此类API选项还有很多很多。

　　我们可能最好把这些API视为独立于Compute Engine之外的方案。我们根本用不着利用这些API将自己的代码以本地方式运行在谷歌数据中心之内，当然这种作法能够有效降低响应时间。但需要强调的是，如果服务器端代码需要访问该API，那么代码必须在谷歌基础设施内运行。不过如果大家的客户端代码需要提取一份地图数据，那么即使将服务器代码托管在谷歌内部也不会带来更好的性能表现。

　　总之，选择权掌握在大家手中。谷歌公司几乎已经设计出每一项服务并使其拥有独立运行能力。如果大家希望使用一套Compute Engine虚拟机但又需要利用自有硬件承载某些更为敏感的数据，谷歌公司也乐于帮助各位通过其API采用部分强大服务。总而言之，长久以来支撑谷歌云顺畅运作的知识与经验如今已经可为大家所轻松利用。