本文根據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