先自我介紹下，sina微博北京-小武，《云計算網絡珠璣》作者，現就職于華為IT產品線云計算網絡架構與設計部。

OpenStack現在非常火熱，社區也集聚了大量的開發人員，各家廠商包括通信設備商、運營商、互聯網公司、電商/店商(包括寶馬、沃爾瑪、蘇寧等)都有參與，用其搭建公有云或私有云平臺。那么我們如何將OpenStack的代碼變成一份產品呢?

玩過OpenStack的人相信都對剛接觸OpenStack有很深的印象，最開始真是迷茫一片，感覺是螞蟻嘴啃天，既不知道如何下嘴，也更有一種遙不可及的高度;熟悉之后會感覺相對簡單些;如果僅僅將OpenStack運行起來做個demo，已經非常不容易，做成產品更是要費很多功夫。

所以把OpenStack代碼變成產品首先需要幾個稱職的程序員，如果按照分工至少需要多少人呢?這個話題最早個人討論要追溯到上年和陳沙克老師的一次QQ聊天;現在應該需要14個人，具體是怎么安排計算出來的?

將整個OpenStack玩熟，需要部署、管理端、計算、存儲、網絡、運維等方面的職位需求，僅從開發的角度來列舉下需求人及負責工作內容(不是熟悉特性，而是大部分問題能通過代碼層面搞定)：

• 計算2人：負責虛擬化、linux內核系統相關、集群、NTP、消息隊列(rabbitmq、zeromq、activemq、qpid)、Nova代碼，Glance、Keystone代碼;
• 存儲2人：所用存儲商家存儲設備及driver(包括開源的ceph等)，mariadb， Cinder/Swift代碼，Hadoop及Sahara(原來叫Savanna)、部署等等;
• 網絡3人：所用網絡商家設備(switch、router、、NGFW/F5)及Plugin或driver，linux協議棧(tcp /ip，tap/tun，linux bridge，ovs，iptables)，物理組網結構，Neutron代碼及所用相關開源代碼(keepalived/haproxy/lvs)，網絡安全設計等等;
• 管理端2人，熟悉OpenStack API和其他云平臺API，熟悉公司IT流程，熟悉管理平臺架構和業務設計能力。

重復下，這些人不是說只熟悉特性，而是從代碼到產品過程中的大部分問題都能通過代碼層面搞定。

每個領域應加一名人員，一方面防止人員流動帶來的損失，再一方面就是因為每個層面需要的人才都是通才的專家，多增加一個人力給組建團隊減少困難，會很大程度上通過人員組合達到集齊所需技能的要求。

最后加上一名足夠優秀的領導，當然也可以是CTO來兼任;需要其對云計算市場有足夠深刻的認識、對客戶需求有足夠的積累、對技術人員有足夠的了解、對技術方向和深度足夠的把控等;但是這個人一定要有產品的思維，而不是僅僅懂技術和代碼，不懂得如何為客戶做產品的CTO不是好CTO。

如果需要程序員鼓勵師就是福利了，節省成本角度，是不是可以考慮從HR或行政這塊兼職下?

人有了，下面就是一步步代碼來實現了：

首先要做個云平臺的管理端來管理云平臺，說白了，OpenStack的定位是云平臺管理端，還需要Horizon來做OpenStack的管理端，通常是一個web portal;這個平臺管理端的功能一方面體現了云計算商家做產品的思路，也體現了云計算商家產品的定位是哪一層(IAAS/PASS/SAAS)。

注：這里需要說明五點：

1. OpenStack通常商家來做IAAS，但是OpenStack自己并沒有這么定位，Sahara即是PAAS的一個體現，而且經過OpenStack定制化，完全可以做到SAAS的需求;
2. 管理端對接OpenStack，也可以對接AWS或阿里云，所以云平臺管理端本身就可以做成一個產品;這個也可以是某些公司的主打;
3. 云平臺本身只是個管理端，技術含量也并沒有底層這么高，就像互聯網的APP理念反而顯得重要得多也高大上的多，自然如果底層不支持，管理端做的再好也不頂事;所以OpenStack自身、一些閉源或在OpenStack基礎之上修改稱之為自研的廠商，如果底層技術沒有什么創新，云平臺管理端也只能在業務編排上進行點更改，并不是什么技術革命，好比汽車的發動機原理甚至原料沒有改變，只是可以調整下位置或形狀讓汽車的外觀變得漂亮些;這點上講，將來OpenStack會不會只剩下北向API也未可知;
4. 結合第三點，云平臺管理端是云平臺的入口，固然重要而且也很專業，但這還并不是各家云計算廠商技術的差距體現;美觀的頁面往往對設計進行外包即可擁有;但是體現的云計算平臺設計理念卻需要人員的精髓外漏;
5. 云平臺管理端需要集合企業流程IT來做，尤其是私有云的需求，畢竟很多客戶企業的內部流程已經用了很多年，對云平臺的定制化需求是Horizon在很多情況下被客戶或云計算廠商所拋棄的一個很大原因。

現在結合OpenStack的社區代碼開發現狀來說下一些注意點：

第一，OpenStack的整體代碼較多，因為為了獲取較多廠家的支持，采用了分布式架構上的 plugin/driver模式來支持，所以有很多層封裝，導致了整體效率的低下;Nova和cinder基本是Driver的形式，但是Neutron 社區卻是五花八門的plugin和driver，還有很多私有的廠家自己維護的plugin和driver，尤其是最近出現了很多SDN支持的 plugin，比如ODL等。如Neutron：Neutron有L2的core plugin(如現在常用的ML2)，L3有router的，通常是用linux的namespace實現(已有ML3的BP);L4-L7的 plugin幾乎是一個功能對應一個;OpenStack原生態代碼只保證功能可用，附帶的test文件夾代碼居然有人作為自建云平臺的測試標準工具也是醉了;

面對如此多的plugin和driver如何選擇?有錢怎么玩都成，沒人可以招聘，有人自己做一款都沒有問題;沒錢有能力的可以選擇 OpenStack的公有ML2等plugin自己優化，沒有能力也沒錢的的自己整兩臺PC搭建個demo看看就好了;其實一條路，自己能搞定的選擇自己搞定的那款plugin或合作方提供的plugin，自己搞不定的跟著大眾走，因為這個plugin用的人多，相當于被測試的比其他充分，這樣自己用著有了問題能提出來，總有人來回答或解決，說不定別人都已經解決了;core plugin ML2使用ovs做租戶vxlan之間的隔離是現在大家用的最多的。

這里單獨提下Open vSwitch的子項目OVN，這個項目體現了老外一貫的開源思路，自己具備核心模塊的掌控能力，其他商家的邊緣參與建立生態圈;(支持自己的 ovsdb，無礙其他廠家設備的邊緣支持)，新出現的OVN開源有目標來將L2-L7的plugin統一，但是道路還很漫長可能會錯過商機;社區的政治也是很深。

公司參與開源可以拉投資，但對于求職者不能認為公司采用了開源，老板或公司就會很Open;個人參與開源能提高知名度，但是也并沒有因為做了開源而提升程序員的人格或逼格，所以對做閉源的同學相比也沒有什么高級的;這些都充分體現了忍狠滾里面的忍字訣，無他耳，參與社區開發的技術能力和水平也不見得都很高，但總有幾個大牛在;很多人認為自己能看代碼什么都能做，不就是幾行代碼么?如果僅是代碼的話的確誰都可以做，但看得懂if else不一定能理解else之外還有沒有else?業務技能和場景遠比代碼重要。

OpenStack的整體架構是網絡的架構的設計，建議讓做網絡的人來做主(不是只懂tcpdump和ping命令的，而是參與過網絡設備研發、設計過數據中心架構方面有經驗的人)，做存儲和系統的同事參與就行了，因為OpenStack的設計每一步考慮都涉及到網絡的內容;

第二，OpenStack的開源代碼質量真是不堪，僅僅是一個功能可用的狀態，對于性能、架構等方面的優化還差很多，直接拿開源給客戶搭建產品基本都是找死的節奏，所以需要有這么幾個小觀點：

a)云計算廠商的角色基本都是集成商，無論是有能力開發網絡、存儲或虛擬化底層的，還是沒有能力的創業公司，都離不開這幾個角色;所以想做full stack的公司需要看下自己真有這個必要和力量嗎?希望大家多多繼續發揮硬件的力量，僅僅是系統工程師從軟件來實現的角度會讓性能大打折扣，使用硬件也會加快項目進度，建立更好的生態圈;這一點有幾家公司已經意識到做的很不錯;

b)云計算廠商做OpenStack產品有兩個方式，有關系來解除根據客戶需求定制化產品，或者有經驗理解客戶痛點能夠直接用于開發產品;但是僅僅靠云計算的情懷基本是走向末路;有些云計算創業公司剛起步對客戶還挑揀，沒有搭建過10臺計算節點服務器的經驗，卻非要1000臺以下計算節點的單子不接，除非你有很硬的關系信任你，不然只能靠雙色球一等獎的概率了;

c)云計算做的好不好，和是否開源關系不大;一個事實是，UCloud的閉源卻是創業公司中云計算做的最好的(個人觀點，不喜勿噴)，AWS和 Azure是公有云的大哥大，卻也是閉源(最近有AWS和OpenStack合作的消息);基于OpenStack的大量創業公司反而多是在整玄乎的概念，真正拿得出手的產品或商業案例卻不多;很多公司宣揚的對社區貢獻可能為爭取公司融資方面做的貢獻更多些;大公司開源貢獻比如Redhat對于 Linux的產品化方面，有三方面做法：優化參數提升產品性能、掌控開源趨勢降低客戶成本、快速的Bug fix和版本回合能力;這點也是開源公司招聘開源達人的原因，但是對于小公司來說還無法一步到位的采用這種模式;

d)很多做開源的同學往往對政府意見都比較大(無論國內外)，一方面開源需要open這點政府確實很多時候做不到，另一方面其實是開源社區也有政治，只是這里的政治問題往往掩蓋了經濟利益問題;開源也是各大相關參與廠商利益競爭的過程;還有一點很多人都認為很使用了開源軟件的公司都會很開放的原因;

e)畢竟OpenStack是開源代碼，客戶用的時候也會調研，包括架構和代碼;但是不是因為他問的問題深入就能說明他很強，可能某些方面他們經驗積累確實很豐富，但是如果他能搞得定還找你干嗎?所以很可能他不如你但是接觸商家多所以問的問題看起來很專業，如果你能問他問題，可能分分鐘就能問倒他們(這就好比面試學習，很多情況下面試者和被面試者，都會有把對方問倒的交集知識點，知識場景限制雙方的說話內容和方式)，你得忍，給他們講懂，那才能說明你真懂，否則很難拿到單子，縱然你公司技術也很牛。這樣客戶見了很多商家，每個商家學一點，幾乎說起來都很懂，但是動手能力就是上不去。

f)OpenStack也是軟件開發方面的，和其他軟件架構和代碼方面沒有什么差別，也需要從架構和性能方面不斷優化，可以從以前的軟件開發上吸取很多經驗;從代碼到產品，先是功能開發，然后是規模上去，接著就會性能下降，然后再優化，周始輪詢，最終又比較良好的產品級實現;說白了，都是為了底層數據轉發面功能，通過管理層來實現;為了實現大規模，通過管理層集群來實現管理層高性能，往往是犧牲了管理面的一致性;CAP這里依然存在;華為在社區提出了OpenStack級聯方案，就是通過管理面的努力擴大數據層面的規模;

第三，OpenStack的部署、升級和運維都是大問題;首先說部署和升級，主要是OpenStack的版本快速發展，支持特性不斷完善;所以客戶的需求也是要跟隨的上，僅僅是普通bug修復部署工具基本都能搞定，大的升級影響就會比較大，甚至會導致云平臺底層管理網絡和業務網絡的重大變更;拿OpenStack的I到J舉例，如果開啟了DVR，想業務不中斷只能是跨集群業務遷移;運維來說是云計算商家招牌之一，可以明確的說，OpenStack不會消滅運維，只會導致運維人員的技術要求提高和不努力運維的淘汰;對于OpenStack來說會導致其運維承包團隊的出現，也會對OpenStack的培訓及運維培訓有很大需求，畢竟客戶的運維人員對于OpenStack的理解都還不是很深入;某些公司說云平臺基本沒有運維，那么可以說有可能兩點原因，是只有兩個機架的設備不需要運維，另一個就是運維外包并且將升級擴容和災備的事劃到運維工作之外;完全沒有一個運維這話，真正懂行的沒一個敢這么給客戶說的。

第四，簡單說下SDN和OpenStack的結合;現在出現了很多SDN的plugin，大部分Neutron 是作為SDN控制器的APP或SDN 控制器的的一部分來使用，暫時還未看到第三種形態——作為SDN控制器的Underlay網絡層面;對SDN的理解我也只有一種，不認為有狹義和廣義之分，所謂云計算廠商說自己天然的云平臺是廣義SDN的，個人認為這都是對SDN沒有理解透徹;SDN應用不僅僅是云計算或數據中心，企業網也可以有很多點，這里不多提了;但是隨著各家SDN控制器的出現，SDN的網絡開放之路似乎又到了收窄的方向上;希望SDN能盡快走過優勝劣汰的過程，減少中間的無謂成本，多多服務于需求;順便說下，很多理解我是做SDN的，其實我是做云計算的，只是做網絡出身，一直在跟SDN而已;

和自己原來很多技術出現一樣，同樣的功能各個商家都會取一個自己的名字，換湯不換藥;但是說自己家名字的功能是業界第一或第一家實現的就不要這么理直氣壯了，畢竟你家名字的功能只有你自己家這么叫，當然是業界第一或第一家嘍!其實底層技術都是集成了第三方或開源的，別人家也都實現啦;只是名字不同而已。

其實挺佩服Intel的，無論是其有意為之還是偶然天成，總之現在你做云計算都不得不買Intel的CPU，存儲設備，計算設備，甚至交換機現在的 CPU都很多是Intel的(順便說下Intel也收購了交換芯片商開始做交換機);云計算如此，SDN的控制器也離不開，還有NFV甚至直接被人誤解為就是基于X86的虛機，可見Intel在這些新興領域的影響力。

最后就是希望再云計算領域里，希望大家都踏實些，少些“語不驚人死不休”，喬布斯也只有一個，商業推廣的那一套來用到技術上，就真的沒品了;狂妄的預測誰都可以說來博取眼球，不過仔細想想真的可能嗎?OpenStack都被拋棄了才有可能將來實現的技術現在不提也罷。

原文鏈接：http://www.sdnlab.com/14573.html

關于OpenStack

OpenStack是一個由NASA(美國國家航空航天局)和Rackspace合作研發并發起的，是一個開源的云計算管理平臺項目，由幾個主要的組件組合起來完成具體工作。OpenStack支持幾乎所有類型的云環境，項目目標是提供實施簡單、可大規模擴展、豐富、標準統一的云計算管理平臺。

OpenStack除了有Rackspace和NASA的大力支持外，還有包括戴爾、Citrix、Cisco、Canonical等重量級公司的貢獻和支持，致力于簡化云的部署過程并為其帶來良好的可擴展性。