來源：蔣清野
借國慶長假的機會寫了這篇長文，全面地整理了個人從虛擬化到雲端計算各個層面的看法。主要的內容涉及虛擬化、虛擬化管理、資料中心虛擬化、雲端計算、公有云與私有云、以及開放原始碼。本文的全部內容均屬於作者的個人觀點，而不代表任何公司的觀點。歡迎討論。
A、虛擬化
虛擬化是指在同一臺物理機器上模擬多臺虛擬機器的能力。每臺虛擬機器在邏輯上擁有獨立的處理器、記憶體、硬碟和網路介面。使用虛擬化技術能夠提高硬體資源的利用率，使得多個應用能夠執行在同一臺物理機上各自擁有彼此隔離的執行環境。
虛擬化的也有不同的層次，例如硬體層面的虛擬化和軟體層面的虛擬化。硬體虛擬化指的是通過模擬硬體的方式獲得一個類似於真實計算機的環境，可以執行一個完整的作業系統。在硬體虛擬化這個層面，又有Full Virtualization（全虛擬化，幾乎是完整地模擬一套真實的硬體裝置。大部分作業系統無須進行任何修改即可直接執行在全虛擬化環境中。）、Partial Virtualization（部分虛擬化，僅僅提供了對關鍵性計算元件或者指令集的模擬。作業系統可能需要做某些修改才能夠執行在部分虛擬化環境中。）和Paravirtualization（半虛擬化，不對硬體裝置進行模擬，虛擬機器擁有獨立的執行環境，通過虛擬機器管理程式共享底層的硬體資源。大部分作業系統需要進行修改才能夠執行在辦虛擬化環境中。）等不同的實現方式。軟體層面的虛擬化，往往是指在同一個作業系統例項的基礎上提供多個隔離的虛擬執行環境，也常常被稱為容器技術。
在硬體虛擬化的層面，現代的虛擬化技術通常是全虛擬化和半虛擬化的混合體。常見的虛擬化技術例如VMWare、Xen和KVM都同時提供了對全虛擬化和半虛擬化的支援。以硬體虛擬化的方式所提供的虛擬機器，通常都在執行一個完整的作業系統，在同一臺宿主機上存在大量相同或者相似的程式和記憶體頁，從而導致明顯的效能損耗。目前，通過KSM等技術可以識別與合併含有相同內容的記憶體頁，但是還沒有對大量相同或者相似的程式進行優化處理的有效手段。因此，硬體虛擬化也往往被稱為重量級虛擬化，在同一宿主機上能夠同時執行的虛擬機器數量是相當有限的。在軟體虛擬化的層面，同一宿主機上的所有虛擬機器共享同一個作業系統例項，不存在由於執行多個作業系統例項所造成的效能損耗。因此，軟體虛擬化也往往被稱為輕量級虛擬化，在同一宿主機上能夠同時執行的虛擬執行環境數量是比較寬鬆的。以Solaris作業系統上的Container為例，一個Solaris作業系統的例項理論上可以支援多達8000個Container（實際能夠執行的Container數量取決於系統資源和負載）。與此類似，Linux作業系統上的LXC可以輕鬆地在同一宿主機上同時支援數量可觀的虛擬執行環境。
在虛擬化這個領域，國內的公司對硬體虛擬化的興趣較大，在研發和生產環境中也大都採用硬體虛擬化技術。淘寶是國內較早地研究並應用軟體虛擬化技術的，他們在淘寶主站的實踐經驗表明使用cgroup替代Xen能夠提升資源利用率。至於在一個實際的應用場景中到底應該選擇硬體虛擬化還是軟體虛擬化，則應該重點考慮終端使用者是否需要對作業系統的完全控制權（例如升級核心版本）。如果終端使用者僅僅需要對執行環境的控制權（例如PaaS層面的各種App Engine服務），軟體虛擬化可能價效比更高。對於為同一應用提供橫向擴充套件能力的應用場景，軟體虛擬化也是比較好的選擇。
對於需要深入瞭解虛擬化技術的技術人員來說，VMWare發表的白皮書《Understanding Full Virtualization, Paravirtualization, and Hardware Assist》是一份很好的參考資料。
通常來講，能夠直接使用虛擬化技術的使用者數量是比較少的。以Linux作業系統為例，能夠進行虛擬機器生命週期管理的使用者，一般就是具有訪問libvirt許可權的使用者。在一個公司或者其他實體中，這些使用者通常是系統管理員。
B、虛擬化管理
早期的虛擬化技術，解決的是在同一臺物理機上提供多個相互獨立的執行環境的問題。當需要管理的物理機數量較小時，系統管理員可以手動登入到不同的物理機上進行虛擬機器生命週期管理（資源配置、啟動、關閉等等）。當需要管理的物理機數量較大時，就需要寫一些指令碼／程式來提高虛擬機器生命週期管理的自動化程度。以管理和排程大量物理／虛擬計算資源為目的軟體，稱為虛擬化管理工具。虛擬化管理工具使得系統管理員可以從同一個位置執行如下任務：（1）對不同物理機上的虛擬機器進行生命週期管理；（2）對所有的物理機和虛擬機器進行查詢甚至監控；（3）建立虛擬機器命名與虛擬機器例項直接的對映關係，使得虛擬機器的識別和管理更加容易。Linux作業系統上的VirtManager是一個簡單的虛擬化管理工具。在VMWare產品家族中，VMWare vSphere是一個功能強大的虛擬化管理工具。
虛擬化管理工具是虛擬化技術的自然延伸。簡單的虛擬化管理工具，解決的是由於物理機數量增多所導致的工作內容繁雜問題。在這個層面，虛擬化管理通常和叢集的概念同時出現。一個虛擬化管理工具，往往需要獲得各臺物理機上的虛擬機器生命週期管理許可權（例如具有訪問libvirt許可權的使用者名稱和密碼）。在同一個叢集當中，為了方便起見，可能需要設定一個在整個叢集層面通用的管理使用者。可以認為，虛擬化管理為系統管理員提供了便利，但是並沒有將虛擬機器生命週期管理的許可權下放給其他使用者。
C、資料中心虛擬化
在資料中心的層面，系統管理員需要面對大量不同型別的硬體和應用。與小型的叢集相比較，資料中心的系統複雜度大大提高了。這時簡單的虛擬化管理工具已經無法滿足系統管理員的要求，因此在虛擬化管理工具的基礎上又發展出各種資料中心虛擬化管理系統。在硬體層面，資料中心虛擬化管理系統通過劃分資源池（一個資源池通常是一個叢集）的方式對硬體資源進行重新組織，並以虛擬基礎構架（Virtual Infrastructure）的方式將計算資源暴露給使用者。在軟體層面，資料中心虛擬化管理系統引入系統管理員和普通使用者兩種不同的角色，甚至是基於應用場景的需要設定顆粒度更細的基於角色的許可權控制（Role Based Access Control，RBAC）。系統管理員對整個資料中心的物理機和虛擬機器擁有管理許可權，但是一般不對正常的虛擬機器進行干涉。普通使用者只能在自己具有許可權的資源池內進行虛擬機器生命週期管理操作，不具有控制物理機的許可權。在極端的情況下，普通使用者只能夠看到分配給自己的資源池，而不瞭解組成該資源池物理機細節。
在資料中心虛擬化之前，建立虛擬機器的動作是需要系統管理員來完成的。在資料中心虛擬化管理系統中，通過基於角色的許可權控制，虛擬機器生命週期管理的許可權被下放給所謂的“普通使用者”，在一定程度上可以減輕系統管理員的負擔。但是，出於系統安全的考慮，並不是公司裡所有的員工都能夠擁有這樣的“普通使用者”賬號。一般來說，這種“普通賬號”只能夠分配給某個團隊的負責人。可以認為，一直到資料中心虛擬化這個層面，虛擬機器的生命週期還是集中式管理的。
資料中心虛擬化管理系統是虛擬化管理工具的進一步延伸，它所解決的是由於硬體和應用規模上升所帶來的系統複雜度問題。具體的物理裝置被抽象成資源池之後，公司高管只需要瞭解各個資源池的規模、負載和健康狀況，終端使用者只需要瞭解分配給自己的資源池的規模、負載和健康狀況。只有系統管理員還需要對每一臺物理裝置的配置、負載和故障瞭如指掌，但是資源池的概念也從邏輯上對所有的物理裝置進行了重新整理和分類，使得系統管理員的工作變得更加容易了。
現代的資料中心虛擬化管理系統，往往提供了大量有助於運維自動化的功能。這些功能包括 （1）基於模板快速部署一系列相同或者是相似的執行環境；（2）監控、報表、預警、會計功能；和（3）高可用性、動態負載均衡、備份與恢復等等。一些相對開放的資料中心虛擬化管理系統，甚至以開放API的方式使得系統管理員能夠根據自身的應用場景和流程開發額外的擴充套件功能。
在VMWare產品家族中，VMWare vCenter是一個資料中心虛擬化管理軟體。其他值得推薦的資料中心虛擬化管理軟體包括Convirt、XenServer、Oracle VM、OpenQRM等等。
D、雲端計算
雲端計算是對資料中心虛擬化的進一步封裝。在雲端計算管理軟體中，同樣需要有云管理員和普通使用者兩種（甚至更多）不同的角色以及不同的許可權。管理員對整個資料中心的物理機和虛擬機器擁有管理許可權，但是一般不對正常的虛擬機器進行干涉。普通使用者可以通過瀏覽器自助地進行虛擬機器生命週期管理 ，也可以編寫程式通過Web Service自動地進行虛擬機器生命週期管理。
在雲端計算這個層面，虛擬機器生命週期管理的許可權被徹底下放真正的普通使用者，但是也將資源池和物理機等等概念從普通使用者的視野中遮蔽了。普通使用者可以獲得計算資源，但是無需對其背後的物理資源有任何瞭解。從表面看，雲端計算似乎就是以與Amazon EC2/S3相相容的模式提供計算資源。在實質上，雲端計算是計算資源管理的模式發生了改變，終端使用者不再需要系統管理員的幫助即可自助地獲得獲得和管理計算資源。
對於雲管理員來說，將虛擬機器生命週期管理許可權下放到終端使用者並沒有降低其工作壓力。相反，他有了更加令人頭疼的事情需要去處理。在傳統的IT架構中，往往 是一個應用配備一套計算資源，應用之間存在物理隔離，問題診斷也相對容易。升級到雲端計算模式之後，多個應用可能共享同一套計算資源，應用之間存在資源競 爭，問題診斷就相對困難。因此，雲管理員往往希望選用的雲端計算管理軟體能夠有相對全面的資料中心虛擬化管理功能。對於雲管理員來說，至關重要的功能包括 （1）監控、報表、預警、會計功能；（2）高可用性、動態負載均衡、備份與恢復等等；和（3）動態遷移，可以用於區域性負載調整以及故障診斷。
顯而易見，從虛擬化到雲端計算，對物理資源的封裝程度不斷提高，虛擬機器生命週期的管理許可權逐步下放。
在VMWare產品家族中，VMWare vCloud是一個雲端計算管理軟體。其他值得推薦的雲端計算管理軟體包括OpenStack、OpenNebula、Eucalyptus和CloudStack。雖然OpenStack、OpenNebula、Eucalyptus和CloudStack都是雲端計算管理軟體，但是其功能有較大的差別，這些差異源於不同 的軟體具有不同的設計理念。OpenNebula和CloudStack最初的設計目標是資料中心虛擬化管理軟體，因此具有比較全面的資料中心虛擬化管理 功能。雲端計算的概念興起之後，OpenNebula增加了OCCI和EC2介面，CloudStack則提供了稱為CloudBridge的額外元件 （CloudStack從 4.0版本開始預設地包含了CloudBridge元件），從而實現了與Amazon EC2的相容。Eucalyptus和OpenStack則是以Amazon EC2為原型自上而下地設計成雲端計算管理軟體的，從一開始就考慮與Amazon EC2的相容性（OpenStack還增加了自己的擴充套件），但是在資料中心虛擬化管理方面的功能尚有所欠缺。在這兩者當中，Eucalyptus專案由於起步較早，在資料中心虛擬化管理方面的功能明顯強於OpenStack專案。
E、私有云與公有云
如D 所述的雲端計算，僅僅是一種狹義上的雲端計算，或者是與Amazon EC2相類似的雲端計算。 廣義上的雲端計算，可以泛指是指各種通過網路訪問物理／虛擬計算機並利用其計算資源的實踐，包括如D 所述的雲端計算和如C 所述的資料中心虛擬化。這兩者的共同點在於雲端計算服務提供商以虛擬機器的方式向使用者提供計算資源，使用者無須瞭解虛擬機器背後實際的物理資源狀況。如果某個雲平臺僅對某個集團內部提供服務，那麼這個雲平臺也可以被稱為“私有云”；如果某個雲平臺對公眾提供服務，那麼這個雲平臺也可以被稱為“公有云”。一般來說，私有云服務於集團內部的不同部門（或者應用），強調虛擬資源排程的靈活性（例如終端使用者能夠指定虛擬機器的處理器、記憶體和硬碟配置）；公有云服務於公眾，強調虛擬資源的標準性（例如公有云服務提供商僅提供有限的幾個虛擬機器產品型號，每個虛擬機器產品型號的處理器、記憶體和硬碟配置是固定的，終端使用者只能夠選擇與自身需求最為接近的虛擬機器產品型號）。
對於公有云服務提供商來說，其業務模式與Amazon EC2相類似。因此，公有云服務提供商通常應該選擇如D 所述的雲端計算管理軟體。對於私有云服務提供商來說，則應該根據集團內部計算資源的管理模式來決定選用的軟體。如果對計算資源進行集中式管理，僅僅將虛擬機器生命週期管理的許可權下放到部門經理或者是團隊負責人這個級別，那麼就應該選擇如C 所述的資料中心虛擬化管理系統。如果要將虛擬機器生命週期管理的許可權下放到真正需要計算資源的終端使用者，則應該選擇如D 所述的雲端計算管理軟體。
傳統上，人們認為私有云是建立在企業內部資料中心和自有硬體的基礎上的。但是硬體廠商加入雲端計算服務提供商的行列之後，私有云與公有云之間的界限變得越來越模糊。Rackspace推出的私有云服務，客戶可以選擇使用自有的資料中心和硬體，也可以選擇租用Rackspace的資料中心和硬體。Oracle最近更進一步提出了“由Oracle擁有並管理”（ Owned by Oracle, Managed by Oracle）的私有云服務。在這種新的業務模式下，客戶所獨享的私有云是僅僅是雲服務提供商的公有云當中與其他客戶相對隔離的一個資源池（you got private cloud in my public cloud）。而對於雲服務提供商來說，用於提供公有云服務的基礎構架可能僅僅是其自有基礎構架（私有云）中的一個資源池，甚至是硬體廠商自有基礎構架（私有云）中的一個資源池（you got public cloud in my private cloud）。
對於客戶來說，使用基於雲服務提供商的資料中心和硬體的私有云服務在財務上是合理的。這樣做意味著自建資料中心和採購硬體裝置的固定資產投入（CapEX）變成了分期付款的運營費用（OPEX），寶貴的現金則可以作為用於擴充業務的週轉資金。即使長期下來擁有此類私有云的總體費用比自建資料中心和採購硬體裝置要高，但是利用多出來的現金進行業務擴充所帶來的回報可能會超過兩個方案之間的費用差額。在極端的情況下，即使企業最終沒有獲得成功，也無需心疼新近購置的一大堆硬體裝置。除非是房地產市場在短時間內有較大的起色，一家瀕臨倒閉的公司通常是不會為沒有自建一個資料中心而感到後悔的。（需要指出的是，對於一家能夠長時間運作的公司來說，通過房地產來盈利是完全有可能的。在Sun 公司被Oracle公司收購之前，就曾經通過變賣祖業的方式使得財報扭虧為盈。）
那麼，硬體廠商在這場遊戲裡面扮演的是什麼角色呢？當使用者的固定資產投入（CapEX）變成了分期付款的運營費用（OPEX）時，硬體廠商難道不是需要更長的時間才能夠收回貨款嗎？
1865年，英國經濟學家威廉傑文斯（Willian Jevons，1835-1882）寫了一本名為《煤礦問題》（The Coal Question）的書。傑文斯描述了一個似乎自相矛盾的現象：蒸汽機效率方面的進步提高了煤的能源轉換率，能源轉換率的提高導致了能源價格降低，能源價格的降低又進一步導致了煤消費量的增加。這種現象稱為傑文斯悖論，其核心思想是資源利用率的提高導致價格降低，最終會增加資源的使用量。在過去150年當中，傑文斯悖論在主要的工業原料、交通、能源、食品工業等多個領域都得到了實證。
公共雲端計算服務的核心價值，是將伺服器、儲存、網路等等硬體裝置從自行採購的固定資產變成了按量計費的公共資源。虛擬化技術提高了計算資源的利用率，導致了計算資源價格的降低，最終會增加計算資源的使用量。明白了這個邏輯，就能夠明白為什麼HP會果斷加入OpenStack的陣營並在OpenStack尚未成熟的情況下率先推出基於基於OpenStack的公有云服務。固然，做雲端計算不一定能夠拯救HP於搖搖欲墜之中，但是如果不做雲端計算，HP恐怕就時日不多了。同樣，明白了這個邏輯，就能夠明白為什麼Oracle會從對雲端計算嗤之以鼻搖身一變稱為雲端計算的實踐者。收購了Sun 公司之後，Oracle一夜之間變成了世界領先的硬體提供商。當時雲端計算的概念剛剛興起，Oracle不以為然的態度說明它尚未充分適應自身地位的變化。如今雲端計算已經從概念炒作進入實戰演習階段，作為主要硬體廠商之一的Oracle如果不打算從雲端計算中分一杯羹的話，那就是真正的反射弧過長了。
根據傑文斯悖論，對於使用者來說，價格降低是用量增加的前提。那麼，應該如何給雲端計算資源定價呢？
目前，大部分公有云服務提供商的虛擬機器產品都是按照配置定價的。以Amazon EC2為例，其中型（Medium）虛擬機器（3.75 GB記憶體，2 ECU計算單元，410 GB儲存，0.16美元每小時）的配置是小型（Small）虛擬機器（1.7 GB記憶體，1 ECU計算單元，160 GB儲存，0.08美元每小時）的兩倍，其價格也是小型虛擬機器的兩倍。新近推出的HP Cloud Services，以及國內的盛大雲和阿里雲，基本上都照搬Amazon EC2的定價方法。問題在於，虛擬機器的配置提高之後，虛擬機器的效能並沒有得到同比提高。一系列針對Amazon EC2、HP Cloud Services、盛大雲和阿里雲的效能測試結果表明，對於多種型別的應用來說，隨著虛擬機器配置的提高，其價效比實際上是不斷降低的。這樣的定價策略，顯然不能達到鼓勵使用者使用更多計算資源的目的。
按照虛擬機器的效能來定價可能是一個更加合適的做法。舉個例子說，某個牌子的肥皂有大小兩種包裝，小包裝有一塊肥皂而大包裝有兩塊肥皂。使用者願意花雙倍的錢購買大包裝，往往是因為大包裝能夠洗兩倍的衣服而不是因為它看起來更大。同理，來自同一公有云服務提供商的不同虛擬機器產品，應該儘可能使其價效比維持在同一水平線上。問題在於，不同型別的應用對處理器、記憶體和儲存等計算資源的需求存在較大差異，其“效能–配置”變化曲線也各有不同。因此，在公有云服務領域需要一個對虛擬機器效能進行綜合評估的框架，通過該框架獲得的評估結果可以表示一臺虛擬機器的綜合處理能力，而不僅僅是處理器、記憶體和儲存當中的任何一項。基於這樣一個測試框架，不僅可以對同一公有云服務提供商的產品進行比較，還可以對不同公有云服務提供商的產品進行比較。
F、開放原始碼
近些年來，我們在資訊科技領域觀察到一個規律。當一個閉源的解決方案在市場上取得成功時，很快就會出現一個甚至是多個提供類似功能（或者服務）的開源或者閉源的追隨者。（首先出現開源軟體，然後出現與之競爭的閉源軟體的案例比較少見。）在作業系統領域，Linux逐漸達到甚至是超越了Unix的技術水平，進而取代Unix的市場地位。在虛擬化領域，Xen和KVM緊緊跟隨VMWare的技術發展並有所突破，逐步蠶食VMware的市場份額。在雲端計算領域，Enomaly率先推出了以Amazon EC2為藍本的閉源解決方案，緊跟著又出現了以Eucalyptus和OpenStack為代表的開源解決方案。與此同時，傳統意義上的閉源廠商對開源專案和社群的態度也在發生轉變。例如，多年來對開源專案持敵視態度的微軟於今年四月組建了一家名為“微軟開放技術”（Microsoft Open Technologies）的子公司，其目標是推進微軟向開放領域的投資，包括互操作性、開放標準和開源軟體。
我們今天所處的商業環境，與上個世紀80年代自由軟體運動（Free Source Movement）剛剛興起的時候已經有了較大的不同。自1998年NetScape第一次提出開放原始碼（Open Source）這個術語起，開放原始碼就已經成為一種新的軟體研發、推廣與銷售模式，而不再是與商業軟體相對立的替代品了。與傳統的閉源軟體商業模式相對比，基於開放原始碼的商業模式具有如下特點：
（1）在專案萌芽階段，通過開源軟體或者自由軟體等關鍵詞吸引潛在客戶以及合作伙伴。對於潛在客戶來說，選擇開源軟體能夠免費或者是低價獲得閉源軟體的（部分）功能。對於合作伙伴來說，其興趣點可能在於銷售基於開源軟體的增強版本（例如企業版），提供基於開源軟體的解決方案，或者是該開源軟體的成功可能對其自身的產品的銷售有促進作用。
（2）在專案成長階段，主要的研發人員來自發起專案的企業以及該專案的企業合作伙伴。雖然也有一些單純出於興趣而向開源專案貢獻程式碼的個人開發者，但是其數量相對較少。我們在開源軟體的宣傳資料當中經常會見到類似於“由某某社群開發”的描述。最近10年來，各種“社群”中的主要研發力量始終來自數量極為有限的企業合作伙伴。但是有些開源專案在宣傳中通常會有意無意地淡化企業合作伙伴的重要性，甚至是誤導受眾以為社群的主要成分是個人開發者。
（3）在專案收割階段，專案發起者以及主要合作伙伴可以通過銷售增強版本或者是提供解決方案獲取財務回報。雖然其他廠商也可以提供類似的產品或者服務，但是開源專案的主要參與者往往在市場上擁有更大的話語權和權威性。關於開源專案的盈利問題，Marten Mickos（Eucalyptus的CEO）在擔任MySQL公司CEO期間曾指出：“如果要在開源軟體上取得成功，那麼你需要服務於：（A）願意花費時間來省錢的人；和（B）願意花錢來節約時間的人。”如果說一個公司在開源方面取得了成功，那麼它從開源軟體的銷售和服務方面獲得的回報至少應該大於在研發和推廣方面的投入。顯而易見，某些使用者之所以能夠免費使用開源軟體，一方面固然是因為他們的參與降低了開源軟體在研發和推廣方面的投入，另一方面則是因為付費使用者為開源軟體付出了更多的錢。
那麼，為什麼基於開源軟體的解決方案通常要比其閉源的競爭對手更便宜呢？通常來說，閉源軟體作為一個領域的開創者，在市場研究、產品設計、研發測試、推廣銷售等等環節都面臨很大的挑戰。開源軟體作為閉源軟體的追隨者，在市場研究方面有閉源軟體作為成功案例，在產品設計方面有閉源軟體作為參考模板，在推廣銷售方面也得益於閉源軟體的市場擴充。在研發方面，開源軟體出現的時間要稍晚於閉源軟體，在這個時間段裡發生的技術進步會明顯降低開源軟體進入相關領域的門檻。除此之外，開源軟體可能在某些特性方面超越閉源軟體，但在總體水平上其功能的完備性、易用性、穩定性、可靠性會稍遜於閉源軟體。因此，基於開源軟體的解決方案通常會採取“以閉源軟體30%的價格提供閉源軟體80%的功能”這樣的營銷思路。除此之外，基於開源軟體的解決方案的可定製性對於某些客戶來說也有特別的吸引力。
在中國的商業環境中，IT公司（或者說網際網路公司）通常是願意花費時間來省錢的，而非IT公司（或者說傳統行業）通常是願意花錢來節約時間的。需要指出的是，中國的非IT公司往往不在乎軟體是否開源，但是非常注重開源軟體的可定製性。
開放原始碼作為一種新的商業模式，並不比傳統的閉源模式具有更高的道德水準。同理，在道德層面上對不同的開放原始碼實踐進行評判也是不合適的。在OpenStack專案的萌芽階段，Rackspace公司的宣傳文案聲稱OpenStack是“世界上唯一真正開放原始碼的IaaS系統”。CloudStack、Eucalyptus和OpenNebula等具有類似功能的開源專案由於保留了部分閉源的企業版（2012年4 月以前，CloudStack專案和Eucalyptus均同時釋出完全開源的社群版和部分閉源的企業版。2012年4 月之後，Eucalyptus專案宣佈全面開源，CloudStack專案被Citrix收購併捐贈給Apache基金會後也全面開源。）、或者是僅向付費客戶提供的自動化安裝包（OpenNebula Pro是一個包含了增強功能的自動化安裝包，但是其全部元件都是開放原始碼的。）而被Rackspace歸類為“不是真正的開放原始碼專案”。類似的宣傳持續了接近兩年時間，直到Rackspace公司推出了基於OpenStack專案的Rackspace Private Cloud軟體 — 一個性質上與OpenNebula Pro類似的自動化包。OpenNebula Pro是一個僅向付費使用者提供的軟體包，但是任何使用者都可以免費地下載與使用Rackspace Private Cloud軟體。問題在於，當使用者所管理的節點數量超過20臺伺服器時，就需要向Rackspace公司尋求幫助（購買必要的技術支援）。這裡我們暫且不討論將節點數量限制為20臺伺服器這部分程式碼是否開源的問題。開源專案的發起者和主要貢獻者在其重新打包的發行版中新增了限制該軟體應用範圍的功能，從道德層面來看很難解釋，但是在商業層面來看就很正常。在過去兩年中，OpenStack專案在研發、推廣、社群等領域所採取的種種措施，都堪稱是基於開放原始碼的商業模式的經典案例。
前面我們提到，在同一領域往往存在多個相互競爭的開源專案。以廣義上的雲端計算為例，除了我們熟悉的CloudStack、Eucalyptus、OpenNebula、OpenStack之外，還有Convirt、XenServer、Oracle VM、OpenQRM等等諸多選擇。針對一個特定的應用場景，如何在眾多的開源方案中進行選型呢？根據我個人的經驗，可以將整個方案選型過程分為需求分析、技術分析、商務分析三個階段。
（1）在需求分析階段，針對特定的應用場景深入挖掘該專案採用雲端計算技術的真正目的。在中國，很多專案決策者對雲端計算的認識往往停留在“提高資源利用率、降低運維成本、提供更多便利”的階段，並沒有意識到這個列表已經是大部分開源軟體均可提供的基本功能。除此之外，很多專案決策者預設地將VMWare vCenter提供的全部功能作為對開源軟體的要求，而沒有考慮特定專案是否需要這些功能。因此，非常有必要針對特定的應用場景進行調研，明確將其按照資料中心虛擬化和狹義上的雲端計算歸類，並進一步挖掘專案在功能上的具體要求。在很多情況下，資料中心虛擬化和狹義上的雲端計算均能夠滿足客戶的總體需求，那麼銷售的任務就是將客戶的具體需求往有利於自身的方向上引導。這個技巧，我們稱之為客戶期望值管理（Expectation Management）。通過需求分析，明確特定應用場景的分類，可以過濾掉一部分選項。
（2）在技術分析階段，首先比較各個開源軟體的參考架構，重點考慮在特定應用場景下按照參考構架進行實施所面臨的困難。其次在功能的層面對各個開源軟體進行對比，並將必須具備的功能（Must Have）和能夠加分的功能（Good to Have）區別對待。除此之外，還可以對安裝配置的難易程度、具體功能的易用性、參考文件的完備性、二次開發的可能性等等進行評估。通過技術分析，可以給各個開源軟體打分排名，在此基礎上可以淘汰掉得分最低的選項。
（3）在商務分析階段，必須明確決策者是否願意為開源的解決方案付費。如果決策者不願意為付費，那麼該專案就屬於“願意花費時間來省錢”的場景，反之則屬於“願意花錢來節約時間”的場景。對於願意花費時間來省錢的應用場景，主要依賴於開源社群獲得技術支援，可以將開源專案的社群活躍度作為重要的參考資料。對於願意花錢來節省時間的應用場景，主要依賴於服務提供商獲得技術支援，應該重點考察服務提供商在業界的影響力以及在本地的服務能力，開源專案的社群活躍度則顯得無關緊要了。
在中國（狹義上）的雲端計算市場， 對於願意付費的客戶來說，CloudStack和Eucalyptus是值得優先考慮的選項。這兩個專案的啟動時間比較早，具有更好的穩定性和可靠性，在業界有較大的影響力，並且在國內有團隊可以提供支援和服務。與此同時，國內一些創業團隊開始提供基於OpenStack的解決方案，但是在短時間內很難積累必要的實戰經驗，而具備豐富經驗的新浪SAE團隊尚未開拓對外提供技術支援的業務。國內雖然也有一些單位在使用OpenNebula，但是在近期內很難形成對第三方提供技術服務的能力。對於願意花時間的客戶來說，CloudStack和OpenStack的優勢較為明顯，因為兩者的社群活躍度相對較高。在這兩者當中，CloudStack的功能更加豐富，也有更多的企業級客戶以及成功案例，可能是短期內的更佳選擇。從長遠來看，基於OpenStack的解決方案會越來越流行，但是其他解決方案在技術和市場上也都在不斷取得進步，因此在未來三年內很難形成一統天下的局面。單純從商業上考慮，CloudStack和Eucalyptus獲得成功的機率可能會更大一些。
G、其他
有些朋友希望我補充一些雲端計算在中國的現狀。坦率地說，目前我尚不掌握充足的資料，在這裡暫不展開論述。劉黎明（新浪微博@劉黎明3000）最近釋出了一篇題為《點評阿里雲盛大雲代表的雲端計算IaaS產業》的文章，值得參考。
關於不同開源專案的社群活躍度比較，可以參考我最近的一篇部落格文章《CY12-Q3 OpenStack, OpenNebula，Eucalyptus，CloudStack社群活躍度比較》。另外，我在《HP Cloud Services效能測試》一文中，也初步提出了一個對公有云進行效能評測的方法。
本文中的所有插圖，全部來自Google搜尋。除此之外，部分概念性內容參考了維基百科的相關條目進行了改寫。