684
為什麼說產品化是私有IaaS的唯一出路？
本文根據DCOS聯盟第5期線上分享整理而成
講師介紹
張鑫
ZStack總架構師、聯合創始人
-
《係統虛擬化》主要作者，曾任職Intel開源軟件技術中心，負責Xen虛擬機開發；
-
曾任Citrix CloudStack核心開發人員，負責Oracle VM、Barematel、Barematel VPC等核心功能。
主題簡介：
-
服務與產品化——矽穀的選擇
-
為什麼IaaS產品化如此重要
-
IaaS產品化的難點
-
ZStack如何做產品化
一、服務與產品化——矽穀的選擇
大家好，今天我跟大家分享的題目是《產品化是私有IaaS的唯一出路》。在分享之前，先簡單自我介紹一下。
我06年加入Intel開源技術中心，從事XEN內核開發，是世界最早一批硬件虛擬化工程師。2010年到矽穀加入CloudStack，是CloudStack早期核心開發人員，經曆了CloudStack從初創到被收購的整個過程，所以從業經曆可以說一直在2B這個行業。去年回國創業，創立開源IaaS項目ZStack。
剛回國創業時，跟很多投資人和2B的前輩聊，說ZStack是一家做產品的公司。得到的大部分反饋是說做產品的觀點已經落伍了，現在做服務才是2B的出路。所以曾經一段時間我感到很困惑，覺得國內對2B創業的看法跟矽穀不太一樣，因為在矽穀創業，絕大部分人是選擇做產品公司，很少一部分才會去做服務型公司。
創業公司應該做產品還是服務，這個其實在矽穀是個熱門話題。總的來說，傾向於做產品的創業公司更多。這個跟產品公司和服務公司的成長曲線有關，簡單來說可以從5個方麵來對比。
第一是進入市場的時間。服務型公司要遠遠快於產品公司。因為服務型創業公司通常是創始團隊基於本身已有的經驗給客戶提供解決方案，這些經驗在過去是驗證過的，能夠很快出成果。而產品公司從0開始打磨一款產品，周期非常長，通常要半年到一年才能有一些概念性的原型推向市場，並且是沒有經過驗證的，要找到product market fit的周期很長。
第二是商業化的風險。服務型公司的商業化風險是比較低的，首先這類公司的經驗得到過驗證，往往在初期就能獲客，甚至獲得一些大客戶，產生現金流。而且在提供服務的過程中可根據客戶的反饋迅速調整方向。而產品公司由於打磨產品的時間很長，在產品打造過程中更多是由創始團隊的經驗和眼界來決定產品的形態，產品推向市場是否被市場接受還尚未可知，有著非常大的風險。一旦產品不受市場歡迎，掉頭的代價也很高。
從這兩個特點來看，服務型公司相對於產品公司，起步快、風險低，初期優勢比較明顯。
第三是擴展性。當服務型公司發展到一定階段，由於商業模式的限製，為客戶提供解決方案（往往是定製化的），對每個客戶的cost也比較高，比較難規模化複製。而產品公司一旦產品找到product market fit，規模化複製成本很低，能夠快速地擴張。
第四點和第五點是複用性和控製力，就一起說。複用性方麵跟第三點擴展性類似，服務型公司基於客戶需求提供解決方案，複用性是比較差的，很難說一個客戶的經驗可以完全、直接地複製到其他客戶上。在控製性方麵也比較差，因為服務的邊界比較模煳，服務型公司需要盡力跟客戶溝通，滿足客戶的各種需求，控製性比較差。產品公司的邊界比較清晰，因為產品本身就定義了什麼事可以做，什麼事做不了，控製力比較好，並且產品本身可以複用。
二、為什麼IaaS產品化如此重要
基於這幾點的比較，服務型公司是先易後難，產品公司的曲線是先難後易。在矽穀大部分公司選擇的是後者，但國內大部分公司選擇的是前者。回到我們所從事的私有雲行業，我堅定地認為我們應該選擇產品化的道路。這有幾點考慮：
首先是處於一個願景。我們認為IaaS未來會成為企業軟件分發的入口，隻有產品化的IaaS才可以做到這一點。
大家經常把IaaS比喻成數據中心操作係統。一個操作係統應該是高度標準化、產品化的。很難想象一個操作係統是通過服務的方式堆疊而成。隻有標準化的IaaS，才能像操作係統一樣大規模廣泛部署，企業軟件才能圍繞標準化的IaaS開發，讓IaaS成為分發入口。
在雲計算的三個層次裏麵：IaaS/PaaS/SaaS，IaaS是跟硬件打交道的，提供資源。跟硬件打交道的部分是最容易標準化、產品化的，因為我們在跟機器打交道，而不是跟發散的業務打交道。如果從IaaS層就開始大量地定製，那麼整個 IT係統就很難標準化，同時很難把一個企業的經驗複製到其它企業。
我們說雲計算的出現是要革傳統IT基礎設施的命。很大一點就是要依托IaaS層麵的標準化、產品化，來解決IT基礎設施層麵長期碎片化、孤島化的現象，讓每個企業都能按照標準的方式去構建IT基礎設施。而不是接著雲計算的浪潮，把傳統的IT集成重新做一遍，製造大量相互孤立又不兼容的IT基礎設施。
要達到這個目的，IaaS層麵必須首先標準化、產品化。
從美國回來後，我深刻地感覺到在雲計算領域，我們有彎道超車的機會。因為歐美的2B領域雖然非常發達，可也有有大量的傳統IT的曆史包袱，要實現雲化的阻力還是蠻大的。但國內不一樣，去IOE的浪潮已經給我們帶來重構整個IT基礎設施的機會，如果我們能夠依托標準化的產品，快速實現雲化，就能在IT基礎設施領域超越歐美，實現彎道超車。
很可惜的是，目前國內大部分私有雲、私有IaaS，仍然走的是係統集成的老路，雲計算廠商慢慢成為了新一代的係統集成商，並沒有產品化的基礎設施出現。
這跟我們長期的係統集成慣性有關係。大部分客戶的IT運維水平偏低，又長期依賴於集成商，在做IT設施雲化時，傳統係統集成的思維仍然很濃重。中國有很多優秀的服務型公司，例如神州數碼，但卻缺乏像微軟、VMWare這樣的標準化產品的公司。這是我們的缺陷，也是我們的機遇。
三、IaaS產品化的難點
IaaS產品可以產品化，是我們應該抓住的機遇。但IaaS產品化也存在很多難點：
首先是IaaS產品的涵蓋麵太廣，它覆蓋計算、網絡、存儲、租戶管理幾個大部分。每個部分都是一個非常深的領域，需要IaaS提供商有非常強的整合能力。這種整合能力通過服務的方式去做是相對比較容易的，簡單的說，就是技術解決不了的問題，可以通過鋪人，以人工的方法去解決。
但產品化強調的是高度自動化，甚至是完全自動化，無人工幹預。這就對廠商技術能力要求非常高，在這個領域沒有數年甚至10年的的耕耘，很難做出標準化的IaaS產品。
產品化的第二個難點是用戶教育問題。前麵說了，國內的2B客戶是長期被集成商服務，定製化的氛圍非常濃。客戶自己提出的一些需求，其實本身並不需要，或者說在雲計算時代並不適合。例如雲計算本身提倡一個自服務的思想，但很多客戶受傳統IT思維影響，要求把各種傳統IT審批的功能都做到雲計算產品裏去，這個跟自服務本身就是衝突的。但廠商在集成的過程中，為了迎合客戶，或者受自身水平限製，很難對客戶做出正確引導，轉而做大量集成的工作，致使產品化的IaaS很難出現。
最後在技術方麵，IaaS產品本身是一個大型的分布式的集成係統，需要把用戶數據中心各種異構的物理資源都管理起來，讓產品化的門檻非常之高。典型的有部署難、升級難、運維難幾個問題。
大家如果對IaaS產品有過接觸，就會知道，往往部署一個IaaS產品需要熟練的技術團隊花費數周或者上月的時間，一旦部署起來，升級幾乎變成了不可完成的任務，在運維的過程中也是小毛病天天有，大毛病偶然發生。
但是否因為存在這麼多難題，我們就放棄產品化的路線，轉而走傳統的服務型方式，以鋪人的問題解決這些問題？答案是否定的。
前麵講到，我們堅信IaaS將來一定會成為企業軟件的入口，未來的企業軟件不再會以操作係統為中心設計，而是以IaaS為中心設計，直接在IaaS平台上分發。用戶也不再需要先裝操作係統，再手動安裝各種軟件，而是直接用預裝好企業軟件的鏡像在IaaS 上批量創建虛機集群，實現企業軟件部署的完全自動化。
四、ZStack如何做產品化
所以，為了這個夢想，我們從一開始就堅定地走產品化的路線，基於過去長期在這個領域的經驗，我們在技術上做出了幾點努力：
首先要解決部署難的問題。一個產品化的軟件，一定是用戶可直接從官網下載，並根據官方的手冊，直接部署試用的，這個過程應該是半個小時甚至更短的時間就能完成。
為此，我們采用了“進程內微服務架構”、“Anisble無縫集成”等多種技術，讓用戶可以通過API或者UI，在5分鍾內能自己構建部署一套私有雲環境。並且能夠根據手冊完成一些典型雲場景的搭建。通過產品化，我們賦予了用戶自己構架IaaS環境的能力。
其次是解決升級的問題。ZStack是唯一提供一鍵、5分鍾在線升級的產品。我們每一個半月就會迭代一個新的版本，用戶可直接下載新版本一鍵升級，升級過程不影響業務係統。升級功能是產品化的一個標誌，不能升級的產品一定是項目製的。大家用的國外很多成熟的2B產品，都是提供升級能力的。隻有這樣，用戶才能在第一時間獲取bug修複，以及新功能的迭代。
最後就是運維難的問題。以服務提供的項目型IaaS中，運維是最大的問題。因為大量的工作，在部署階段需要通過廠商的人員手工完成。當項目一旦交付給用戶後，出現的任何問題用戶都無法解決，需要廠商協助。歸根到底，是因為沒有實現產品化，沒有實現完全的自動化。
我們提倡完全自動化，所有的操作、配置完全由API交付，不存在手工環節。用戶可以完全通過界麵和API就能實現IaaS的自動化運維。例如添加新的計算節點、存儲節點，用戶隻需要在UI上操作，或者調用API，就能全自動地完成，無需廠商協助。
這所有的努力，最終目的是提供一個產品化的IaaS，能夠被成千上萬家客戶所使用，而不是通過服務的方式，隻能讓一小部分客戶使用。當產品化的IaaS被部署到成千上萬的用戶的機房，就形成了入口能力，就可以基於這樣的IaaS提供企業軟件分發的渠道，讓用戶的業務軟件能夠全自動化地分發和升級，這樣用戶就獲得了從基礎設置到上層業務係統的全自動化的一個閉環，從而避免構建碎片化的IT基礎設施。
中國的2B市場才起步，跟歐美相比，仍有著巨大的發展潛力。隻有走上了標準化、產品化的道路，我們才能超車，並在未來將我們的技術輸出到歐美。產品是沒有國界的，標準化的產品可以輸出到世界任何地方，但服務很難跨國界，要跨國定製服務就更難了。這也是為什麼我說產品化才是私有IaaS的唯一出路。
Q&A
Q1：ZStack如何去響應客戶定製化問題？
A1：這是個好問題，也是國內產品化的過程中無法回避的問題。我們的觀點是跟集成商、服務商合作。國內其實是存在有大量有經驗的服務商的，他們也希望進入私有雲這個行業，但缺乏標準的產品為他們降低提供服務的門檻。
ZStack提供的標準IaaS產品就可以為集成商解決這個問題。通過跟集成商合作，解決客戶在現階段要求的定製化需求。
Q2：ZStack如何提升自身產品的厚度，如何規劃後續的產品線？
A2：我們還是會專注在IaaS這個領域。前麵說了，IaaS相當於數據中心操作係統，要把它做到高度產品化，其實還有非常多的問題要解決，也需要很多時間。對於IaaS之上的一些產品部分，我們選擇跟這些領域的廠商一起合作，推出解決方案，更多的是把ZStack打包到這些廠商中的產品中去，形成完整解決方案。
Q3：一鍵升級隻適用部分場景，如OS版本升級恐怕避免不了數據遷移？
A3：這要分為兩個層麵。第一是管控麵的升級，第二是數據麵的升級。管控麵的升級就是IaaS本身的升級，這個ZStack通過一鍵升級已經解決了，不論是管理一台物理機，還是一萬台物理機，管控麵都是一鍵升級的。數據麵的升級就是你提到的操作係統升級。相對於管控麵，數據麵的升級不頻繁，通常的安全升級都可以通過包升級的方式解決。
當涉及到重大問題，需要對操作係統內核升級的時候也有兩個方法可以解決。一是通過將物理機設置到維護模式，虛機遷移走，然後對操作係統進行冷升級。二是通過內核熱補丁的方式，對操作係統進不停機升級。因為最早就是在Intel OTC從事虛擬機內核開發，我們團隊裏麵也有不少10年前就在這個領域工作的牛人，所以這個問題我們也是可以解決的。明年ZStack會發布自己的發行版，裏麵就會支持這些技術。
Q4：現在SDN比較火，ZStack有無集成SDN計劃？
A4：對於SDN方麵，如果是比較簡單的用戶場景，我們有自己的軟件解決方案。2010年，我在CloudStack做的第一件事就是跟Nicira的工程師基於Openvswitch為godaddy提供SDN方案，那個時候它都還沒被VMware收購。
對於需求複雜的SDN場景，特別是要接入硬件SDN方案的，我們有完整的網絡插件體係，從2層到7層都是插件式的，可以通過插件的方式在不修改已有代碼的基礎上實現無縫集成。
Q5：ZStack大規模部署方案思路是怎樣的？是否存在管理數據庫、消息隊列等瓶頸？比如千台宿主機規模。
A5：不存在。我們單管理節點的核定規模是 10萬台物理主機、百萬級虛擬機、同時響應數萬並發API。具體實現的技術細節可參考我們官網blog裏的技術文章，這裏我可以跟大家share一個客戶測試的ZStack並發能力的數據，750個並發沒有測試ZStack，因為隻給了我們4個計算節點，而計算節點資源不足。
Q6：針對某些行業對資源強管控需求，有無對應資源審批開通機製？
A6：這個我們沒有，這方麵的定製需求我們有合作夥伴做，合作夥伴提供的BOSS係統，整個解決方案是有的。
Q7：ZStack著重解決IaaS層問題，您對PaaS層服務怎麼看？比如DB、Big Data、Container等。
A7：這些我們都跟合作夥伴一起做的，正好你提的這三個方麵我們都有完整的解決方案。這個也是因為ZStack的輕量級的特性，合作夥伴集成起來非常容易而且可控。
原文發布時間為：2016-12-26
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-13 08:42:30