谷歌公司精心構建的Cloud Platform使用戶能夠更為輕松地啟動實例或者在必要時隨時使用Google API。

如果要說哪家企業真正拿出了以云為核心的計算體系，那么勝出者非谷歌莫屬。自發展之初開始，谷歌公司就建立起一套立足于深邃互聯網環境的業務定位，而其搜索引擎目前仍然是現代世界上最為強大的工程奇跡之一。大家是否還記得，谷歌搜索引擎上一次停機事故出現在哪一年?

[[160961]]

很明顯，每一家企業都希望能夠建立起像谷歌這樣以信息為基礎且跨越整個互聯網的業務體系，并借此積累豐富的技術經驗。作為這一領域的先驅者，如果谷歌公司需要某些技術方案，那么其工程師必須自行著手開發，而后完成相關部署。如今，每個人都能夠借此獲得谷歌技術的收益，意味著以每小時或者每次點擊為基礎建立起谷歌級別的系統并獲得谷歌級別的可靠性水平。

使用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采用部分強大服務。總而言之，長久以來支撐谷歌云順暢運作的知識與經驗如今已經可為大家所輕松利用。

原文鏈接：Review: Google Cloud flexes flexibility