根據IDC的分析報告，美國和中國雲計算產業發展差異巨大：美國以公有云為主，SaaS最大、IaaS最小；而中國截然相反，以私有云為主，IaaS佔了大約50%的份額。
究其原因，跟中美兩國雲計算產業發展的階段、成熟度有很大關係。
中國的公有云主要使用者是小微、創新企業等。我認為IaaS公有云已經或者將要巨頭化，PaaS還有機會，SaaS會是雲計算幾大分類中的爆發點，但是要看準行業。
在諸多產業中，中國雲計算私有云市場主要的客戶來自：通訊、金融、政府。金融行業受安全、政策、法規的約束，幾乎不會選擇公有云，大型國有銀行私有云的建設步驟也很謹慎、漸進式，會首先考慮遷移非核心應用；小金融相對對新技術比較開放，會實驗一些開源的技術，如Openstack、ceph等。
政府由於“十二五”、“十三五”政策持續推動、對於政務雲建設的現實需求、統一納管基礎設施資源、節省成本等考慮，對雲計算的投入較大。
因為政策持續推動、創新補助、領導要求（政績）等原因，需要上雲的企事業單位、行政機關。
不解釋，：）。
看見新技術的發展、成熟，希望在其中分一杯羹，也包括IDC之類的轉型企業。和上一類的區別一個是模糊的、被動的，一個是有自主想法、主動的。
因為業務發展規模（含彈性）、統一上收資源、成本等考慮雲。主要也分兩類大型互聯網企業和傳統大型企業。
前者因為業務發展需要考慮雲計算，從成本、技術可控性考慮，會採用大量的開源技術，同時會對硬件、軟件提出改造要求，大力發展分佈式、集群技術以適應其性能、可靠性等需求。典型的代表是阿里等。
而傳統大型企業走的是另一條路，相對穩健，會選用成熟可靠的商業化解決方案為主，如虛擬化選擇VMWare。另一方面，這類企業相對比較謹慎，會以規劃諮詢、POC、招標、建設、交付、運維相對固定的模式去建設雲。典型的代表是大型央企。
我把順序放過來，先說SaaS，再說PaaS，IaaS。
SaaS我認為主要會在三種情況下出現：
有行業屬性的SaaS，如教育、醫療、培訓等。
比如workday類似的管理工具、office365類似的文檔工具等。
有些企業內部，各地/部門業務類型相對一致，使用SaaS軟件統一上收權限，節省成本等。
如我之前所說，如果找準行業、方向，SaaS可能是創業的大風口。
PaaS的實現我認為有兩種：
大型企業考慮人員技能、維護成本、可靠性等要求，較多選擇類似方案。HP、IBM、BMC等都有類似的工具。自行實現的話，可以考慮流程引擎加上腳本執行器再加部署包。
選擇cloudfundry、openshift框架，加docker等技術，目前隨著相關技術的成熟，越來越受到關注。上述的幾個大外企實際上也有類似的實現。
IaaS的情況比較複雜，我認為難度主要在理清幾個頭緒：
聯想的架構師團隊正在做一件事情，就是梳理業界存在的十幾種主要的企業業務架構（如電商、搜索等等），分析和總結它們對於資源的各方面要求，如計算能力、IO等等。
需要從業務的承載要求、客戶消費方式、業務系統架構、部署方式、虛擬化方式、集群、資源類型做統一的規劃設計。根據對客戶現有情況的分析，尤其是IT系統現狀、痛點等，得出客戶的期望，進而設計出客戶需要的服務。
很多人搞不清楚什麼是服務，什麼是資源，甚至有個號稱雲架構師的人跟我說，他實習了對虛擬化的納管、資源調度，就是完整的雲。
資源（resource）：在系統中， 基礎設施、network設備，VM、host、OS、CPU、Memory、存儲、software等等都被視作可分配資源。
服務是雲計算的核心特徵，根據業務要求等可以編排服務，使之能讓客戶消費，通常會綁定價格、SLA等一些附帶屬性。
要想清楚，根據客戶現狀，組織與租戶怎麼對應，是1對1，1對多，還是多對多。
要考慮資源調度策略、資源類型、性能要求，同時要考慮彈性的時候如何伸縮。經常會有隻能scale out，不能scale in，或者頻繁scale out、in的情況出現。那麼在考慮彈性判斷條件、算法的時候，要綜合幾種監控告警數據，如業務、資源。
1. IaaS架構影響因素
如我之前在群裡所說的，個人認為很多因素都會影響企業IaaS架構的選擇，主要有以下一些：
a) 企業IT發展規劃
b) 企業組織架構
c) 企業管理制度
d) 業務類型
e) 應用層次
f) 人員技能
g) 技術成熟度
h) 成本
i) 週期
j) 運維體制
k) 。。。
如果不考慮其中的某個因素，都有可能導致項目的失敗。我曾經親身經歷過，因為管理和客戶組織架構原因導致的雲項目失敗。客戶在實施雲計算建設之前，業務部門是強勢部門，IT部門是支撐部門，而在規劃和建設中忽略了客戶組織架構的影響因素。IT部門變成了雲平臺的管理者，業務部門成為相對弱勢的雲服務消費者，導致客戶內部組織架構重組、項目停滯。
我這裡講的是廣義的雲平臺，我一般認為分成幾大部分：門戶（管理和自服務）、服務層、統一資源層（含適配器層）、基礎設施（含虛擬化），緊密相關的有BSS、OSS子系統；外部可能交互的系統有ITSM、CMDB、外部監控系統、4A系統和通知系統等。我畫了一個主要部件的草圖，方便大家理解：
a) 門戶分為管理和自服務，分別給管理員和普通用戶提供服務；用於展示基礎設施、平臺及軟件服務，並控制用戶接入方式，對用戶的訪問範圍、界面的展示方式做設定等。以便於管理員和普通用戶獲取服務的信息，申請並使用各類服務。
b) 服務層指服務構建與設計的邏輯組件，它負責定義服務的結構、流程等信息，組裝原子服務，生成業務服務，發佈到服務目錄，監控服務運行狀況等，形成完整的服務生命週期管理。業務用戶可以通過服務管理層獲取雲計算服務；管理員可以通過服務管理層監控所有服務實例的整體狀況；服務開發人員可以通過服務管理層定義和發佈服務。服務管理層將以業務服務的形式對外發布所有的服務操作接口。
c) 資源層指管理和調度軟硬件資源的邏輯組件，它負責構建資源池，生成簡單資源供應的技術服務（原子服務），定義資源運維的操作流程。為了組成資源池，一般將同質的設備集中安裝，相互連接，並通過一定的管理軟件來監管和配置。資源池由同質的一組資源組成，用戶可以通過資源管理層軟件從資源池中申請資源，指定該資源實例的配置，並管理其運行。管理員可以監控每個資源池的資源使用率，健康狀況和性能狀況。資源管理層將以技術服務的形式對外發布所有的資源操作接口。這一層要屏蔽掉虛擬化等的差異，使得上層無法感知。
d) 基礎設施包括計算、存儲、網絡，其中計算含各種異構虛擬化。
e) BSS和OSS源自電信行業的B和O，BSS負責營銷、結算等功能；OSS負責監控、安全等。不展開了。
能否支持X86虛擬化異構、異構的支持廣度是衡量一個雲資源管理平臺（區別與雲服務管理平臺）的一個重要標準。目前主流的虛擬化軟件有幾種：
a) Vmware
b) Hyper-v
c) Xen
d) Kvm
e) 在kvm和xen上演化的各種版本
在此不考慮lxc等。
主要的實現思路是在資源層做統一納管，用一套接口整合，也即適配器模式，每種使用一個適配器。在實際開發中，一般接口做二次抽象。
目前最常見的異構是VMWare和KVM（Openstack納管），目前有幾種途徑：
推薦使用這種方式。
如，mirantis、hp hellion os商業版、racespace等，基本上不盡成熟，或者高級功能有缺陷。
c) VIO（VMWare Intergrated Openstack）
很多人跟我推薦VIO，我反對，理由有幾點：
1. 遺產系統接管。如果對於已有的VMWare虛擬化，VIO無法接管
2. 性能。VIO部署在虛擬機上，作為vcenter插件，性能無法保障。
3. VIO本質上還是Openstack的一個實現，沒有高級功能。
4. 如果需要SDN，要集成NSX，成本等各方面都需要考慮。
除了X86虛擬化異構，還要考慮小機（主要是IBM power）、物理機、虛擬機的供應，這時也要考慮小機的納管需求。採用的方式也是在資源層統一納管，但接口會有獨特性，一般用流程引擎調HMC解決。
Openstack現在持續火熱，各大廠商都在積極參與，本人也參加過openstack峰會。結合工作中的實際，我認為Openstack長期來講是個好東西，適合一定場景的應用範圍，但並不普適。可以應用在：
我認為Openstack需要解決的問題有：
此外，我認為Openstack存在貪多求快的問題，面鋪的廣，不夠紮實，主要使用的還是那幾個核心模塊。
我曾經設計了一個集成SDN和NFV（部分功能，如SLB、VFW等）對的拓撲設計器，但在具體的企業級客戶中，並沒有太多客戶迫切需要SDN。都會提到、以後擴展到SDN的實現，而不是眼前。
我認為SDN主要應用在幾個場景：
b) 私有云，需要頻繁變更網絡拓撲的環境，如開發測試、科研等
雲管平臺的部署和普通的SaaS網站沒有什麼不同，都是SLB加HA，後端應用集群、數據庫集群，一般沒有很大的壓力。
三、 雲不一定節省成本（我知道我說在這個可能很多同行要扔搬磚，可是作為一個駕狗獅，雖千萬人吾往矣。。。）
1. 規劃、設計和建設週期長。雲平臺要承載所有準備上雲的業務系統，考慮因素較多，如前述。
2. 前期採購成本高，前期資源池建設採購的設備數量較多，佔用大量的機房、電源等資源，投資和運維成本均較高，一定時間內會閒置。前期規劃能力不足，也會造成資源浪費。
3. 對企業的組織管理制度可能會有調整、單體人員技能會有較高要求，造成行政和人員成本升高。
4. 管理維護成本高、維護力量無法分層：維護人員要分成不同的團隊，分別管理雲平臺和業務，必須熟悉平臺所涉及的所有的軟硬件資源，維護效率不高
5. 人云亦云，並不少見，尤其是資源池較小的情況下，純屬浪費。