2013年，我在《程序員》雜志發(fā)表了“ 對國內云計算三個現(xiàn)象的思考”，文章中分析了國內云計算的三個現(xiàn)象：
- 現(xiàn)象一：沒有API 的公有IaaS服務
- 現(xiàn)象二：鮮有成功的Cloud-Native應用
- 現(xiàn)象三：對PaaS的理解較單一
而在過去一年多的時間里，國內的云計算領域發(fā)生了很多重大事件，比如：AWS入華、Azure正式商用、阿里云強勢爆發(fā)、UCloud/青云等獨立第三方云服務廠商獲得大筆風險投資等等，種種跡象都表明云計算在國內已經(jīng)步入加速發(fā)展階段。對于上述三個現(xiàn)象，我目前的看法是：
IaaS API方面：主流的公有云IaaS廠商都提供了API。但是，有了API并不代表其堅持API優(yōu)先的原則。API優(yōu)先要求云服務提供者“Eat your own dog food”，即通過調用基礎服務的API來構建各種上層服務，同時給生態(tài)圈合作伙伴提供平等的機會。
原生云應用方面：云的成功案例越來越多，但是大部分集中在游戲等行業(yè)，對傳統(tǒng)行業(yè)的滲透才剛剛開始。另外，我們還缺少像Netflix這樣毫無爭議的示范案例。
PaaS方面：Cloud Foundry開始偏向企業(yè)私有云領域。由于大部分的公有云用戶對云服務器的需求仍在個位數(shù)級別范圍內，因此他們對第三方自動化管理部署工具、應用生命周期管理、混合云管理工具的需求仍不強烈。
成本費用（Cost）和安全（Security）一直以來都是公有云的兩個焦點問題。本文的主旨就是討論云服務的計費模式。下面是筆者觀察到的國內公有云計費方面的兩個現(xiàn)象，主要涉及計算資源的計費模式。
現(xiàn)象一：包年包月
包年包月對服務提供者和消費者都有好處。云服務提供者可以將包年包月類型的虛機集中起來管理，可提高虛機密度，進而提高資源使用效率；云消費者可以降低使用成本。 包年包月計費方式看似和AWS的預留實例類似，但是實質上有許多不同之處。
1.AWS預留實例不影響用戶使用EC2的方式，只是在計費時價格不同而已。當用戶創(chuàng)建虛機時，無論用戶是用管理控制臺、CloudFormation、OpsWorks、命令行工具、還是第三方管理工具，其計費結果都是一樣的。但是對目前國內云服務商比如阿里云， 用戶只能通過管理控制臺才能訂購包年包月虛機，用戶無法通過API訂購包年包月虛機。
2.按量計費啟動的虛機無任何折扣，其價格比包年包月貴很多。如果用戶訂購的是按量付費類型虛機，無論其訂購多少、使用時間多長， 用戶都無法享受到任何折扣。任何云服務都是可編程的資源（API），Cloud-Native云應用會充分利用這些API來實現(xiàn)高可用、可擴展、安全的分布式應用。按量計費的虛機將會是未來的主流，云服務商應該想辦法降低按量計費的虛機的使用成本。
從目前看，降低用戶使用計算資源費用的辦法主要有三個：AWS的預留實例方式、Google的階梯使用折扣方式（Sustained Use Discounts，對于一個虛機，單價在一個計費周期內是隨著運行時間的增加而反向下降的）和國內特色的包年包月方式。它們各自的特點和區(qū)別是：
1. AWS預留實例方式不會影響用戶的使用方式，但是AWS預留方式幫助用戶省錢的前提是用戶必須能夠準確預測未來計算資源使用量。 由于業(yè)務的不可預測性，準確預測未來資源使用量是很難的。AWS預留實例采購方式通常是1年或者3年，這使得預測變更加困難。
2. Google的階梯使用折扣方式不會影響用戶的使用方式，同時用戶也不需要預測未來資源使用量，最為簡單直觀。
3. 國內的包年包月和按量計費是互相排斥的方式，影響用戶的使用方式，而且按量付費方式無任何折扣。
本文的重點不是關注云服務商的絕對價格。下表列出了國內外典型云服務廠商一款相似虛機類型（2核8G內存Linux虛機）的月平均費用對比，主要是想讓大家對各廠商計費方式有個直觀的認識。
| 類別 | 月平均費用 | 備注（2014/08/06的價格） |
| 青云按量 | 0.774 * 720 = 557 | 北京2區(qū)（PEK2）， 青云不提供包年包月，也不提供其他折扣 |
| 阿里云包年 | （374 × 10）/12 = 312 | 青島數(shù)據(jù)中心， 假設使用滿一年 |
| 阿里云包月 | 374 | 青島數(shù)據(jù)中心，假設使用滿一月 |
| 阿里云按量 | 1.368 × 720 = 985 | 青島數(shù)據(jù)中心，假設使用滿一月 |
| 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 ，假設使用滿一月 |
現(xiàn)象二：秒級計費
一些國內新興的云服務公司把秒級計費做為其特性之一進行宣傳，取到非常好的效果。這是因為Google的計費最小單位是10分鐘， 而AWS/阿里云等的最小單位更是高達1個小時，和秒級計費單位有很大差距。
但如果用戶使用云服務達到一定的量，則最小計費單元對用戶使用云服務總費用的影響是微乎其微的。從上述的對比表格中我們可以看出， 假如用戶使用一個月的時間， 青云的費用并不比其他云服務低。這和電信運營商對語音通話的計費單位是按照分還是按照秒的道理是一樣的。整體性降價對用戶更有實質意義。
秒級計費更多還是反映了云服務的使用哲學，即根據(jù)業(yè)務的變化，用戶可以通過API（或者是基于API的管理工具）動態(tài)調整資源的使用量， 由此來節(jié)省費用。 比如， 晚上的時候，業(yè)務量都比白天小，用戶可以設定自動伸縮來動態(tài)調整資源的使用量。 阿里云的問題在于其提供的包年包月計費方式限制了用戶的使用方式（只能從管理控制臺啟動），限制了用戶充分利用云的可編程特性；另一方面，其對按量付費的使用方式不提供任何折扣，用戶使用按量付費虛機的成本很高。
總結
在國內，人們熱衷于比較各個云服務廠商的價格，卻忽略了云服務的計費模式。我認為計費模式將對國內云計算生態(tài)圈的發(fā)展和促進用戶構建云應用的方式轉變會起到非常重要的作用。 云服務的定價體系和計費系統(tǒng)是一個系統(tǒng)工程，每個廠商、每個服務有自己的計費方式。但是公有云服務本質上是Utility服務，無論是哪個廠商，其計費背后的原則應該是一致的，這些原則包括：
1. 按使用量計費。任何云服務都是可編程的資源（API），用戶可以非常方便的使用這些資源，按照使用量的多少來計費。
2. 使用越多、需求越穩(wěn)定，價格則越便宜。
3. 規(guī)模越大，價格越便宜：隨著云服務商規(guī)模的擴大，其運營成本會下降，這時應該降價讓利于云消費者。
4. 無差別原則：用戶創(chuàng)建的資源，無論是通過AWS管理控制臺還是第三方管理工具，其價格是一樣的。
5. 費用可視化、可跟蹤原則：云服務廠商提供了費用查詢接口，讓費用可視化、可跟蹤成為可能，從而幫助用戶優(yōu)化、降低成本費用。
6. 定價依據(jù)的是消耗的計算/存儲/數(shù)據(jù)傳輸?shù)瘸杀尽１热纾珹WS提供了很多免費的服務，這些服務之所以免費是因為其是管理服務，本身不消耗資源，比如Autoscaling服務、OpsWorks、Beanstalk、IAM、CloudFormation。
作者簡介
阮志敏， AWS認證架構師（專業(yè)級別）， 長期關注于如何使用云服務進行業(yè)務創(chuàng)新， 對云服務生態(tài)圈有較深入的思考。
