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