閑扯設備廠商的轉型

（昨天看球，再加上自己一直在思考一個問題，根本停不下來，所以今天暫停更新「途客們的旅行夢」）

周三Juniper新CEO Shaygan訪問sale office，問了大家一個問題：如何double我們的revenue...這是個天馬行空的，CEO專屬的高大上問題，在憋了半個多小時後，程序君一時沒有抑制住，就blabla回答開來：

Lets ask ourselves - how others perceive Juniper? ...

我當時提了幾個點：

(1) 現在是互聯網時代，過去兩波浪潮：web2.0/mobile internet，現在正在開始的第三波intelligent hardware，Juniper的位置在哪？

(2) 三波浪潮產生的「新經濟」，從網路設備商的角度看，和運營商主導的「舊經濟」有何不同？

(3) 我們可以怎麼做？

後來回家又仔細想了想，覺得這作為一個思維訓練，紙上談兵一下也不錯。

沒能很好地從互聯網公司火爆增長帶來的新經濟中獲得同等規模的利益恐怕是所有網路設備廠商之痛 —— 否則你無法解釋為何NASDAQ的互聯網股票火得一塌糊塗，但cisco/juniper等vendor的股票在過去五年甚至更長的時間裡沒有太大起色（新IPO的PAN暫且不談）。本來，互聯網公司的興起給廣大的設備上一個新的，巨大的增長點 —— 大量的伺服器之間需要互通互聯，協同工作，所以需要成比例的網路設備 —— 無論是路由，交換，還是安全產品。但是，我們更多地看到一些本來該大量購買juniper設備的巨無霸，如google，amazon和facebook們更多地轉向了OEM網路設備，自己寫軟體，來支撐他們的infrastructure。這不啻於狠狠扇了設備廠商一個大耳光：「你們的系統做得又爛又貴，我們只好自己動手哩」。

如果想獲得新的利潤增長點，達到兩倍，甚至N倍的收益，設備廠商需要理解和追逐引領新經濟的互聯網公司 —— 由此，需要放低身段，重新學習。

無論你認可與否，互聯網公司正在以一種前所未有的速度衝擊各個行業，首當其衝的就是IT產業。過去那種一年多一個產品迭代，顧客被動地等待產品出爐的時代已經過去了，很多公司以月，甚至以周為單位更新他們的產品。這種速度讓傳統的IT公司，像Juniper很不舒服，因為無論從組織結構，go-to-market方式，員工心態等都無法與互聯網公司保持基調。所以，當我們把緊盯著AT&T，美林銀行這樣的金牌顧客身上的目光稍稍收回，投向一個更廣闊的市場時，我們發現，一切都那麼地不一樣，讓人手足無措。

我覺得，這種不一樣包括（但不限於）以下方面：

(1) 更快捷地響應變化 —— 產品更新的頻次

(2) 更「智能」的產品 —— 可以定製化的programmable network

(3) 更直接的生意 —— Developer to developer來達成銷售

拋開第一點不說，我談談後面兩點。

產品

設備廠商首先面臨的問題是自己對網路的理解已經落後於一些大型的互聯網公司了 —— 這是個不得不承認的，悲哀的事實。類似於google這樣的公司，已經使用其無與倫比的人才資源，開發滿足他們自己要求的網路系統多時了。Youtube上大概一兩年前有個視頻，google做SDN的VP說，他們有50%的網路流量已經跑在了自己構建的SDN系統之上。我想現在這一數字恐怕只會更高。由於 "scratch your own itch"，他們在這個過程中應該掌握了大量的與互聯網生產環境直接相關的網路知識。在這一點上，我們不得不承認自己的全面落後。雖然目前這樣的公司研發網路產品僅為滿足自己的需求，但有朝一日，他們將其獨立成一個事業部，把自己內部的需求泛化成一個business，就像現在Amazon AWS或Google Domain所為，那麼，即使不是對設備廠商的全盤顛覆，恐怕也是極其巨大的衝擊。

那麼，互聯網公司究竟需要什麼樣的網路設備？

過去兩年，人們一直在談論openflow和SDN —— 對設備廠商來說，硬體被弱化，成為啞終端，集中式的軟體成為網路的主導。跟隨也罷，不跟隨也罷，但朝著這個方向發展，設備廠商，尤其像Juniper這樣競爭優勢在硬體（或者說system）上的公司最終只會隔了自己的命：要麼被晶元廠商直接替代，要麼淪為一家提供廉價硬體的無足輕重的公司。

但幸好到目前為止，SDN還處在嚷嚷的階段，短期內看不出能夠顛覆行業格局的能力。如果我們拋開SDN的概念，拋開openflow的實現不談，光看背後的產品需求，那麼我覺得至少從互聯網公司的訴求來看，他們需要的是一個programmable network device —— 這包含兩個要素：1) 基於API而不是基於手工配置 2) 有能力深度控制網路。

第一點如果從devops的角度應該很好理解。對於互聯網公司，海量的伺服器不再需要專門的IT人員來維護，而是開發人員來管理。管理的方式不是手工配置，而是通過puppet，ansible等等工具通過撰寫各式各樣的腳本來完成。所以，網路設備通過類似的方式管理理所當然。

然而，所有設備廠商的設備都不具備通過腳本進行大規模管理的能力 —— 一來設備廠商的系統一般不開放，無法像對付伺服器那樣直接在其之上進行開發；二來這些系統也沒有真正的API/SDK，供二次開發之用。Juniper雖然有自己的SDK，也提供netconf API，可以通過python進行自動化配置，但我們將其和twitter的API/SDK對比一下，就會發現諸多問題：

1) SDK/API文檔不能讓開發者快速掌握。twitter的API一個工程師邊看文檔邊試用，半個小時就能大致掌握，但juniper的SDK可遠沒這麼容易上手。這大大限制了使用的人群。

2) SDK/API簡直不是給程序員設計的。這個不解釋。

3) SDK/API的可用性遠達不到「真正」的API的需求 —— 比如說threshold，performance等。使用netconf API 訪問某些配置，不管你訪問一次還是一萬次，速度永遠恆定在初始的速度 —— 對於這樣一段時間內容不會變化的api，連個起碼的cache都沒有。這樣的API其實還沒有脫離讓人執行，而不是讓機器執行的範疇。

如果說第一點還有挽救的餘地 —— 無需根本的改變就能做到，那麼第二點「深度控制網路」則需要從系統的基石其開始考慮。比如說對於防火牆，「深度控制」可能是這些內容（不限於）：

a. 是否可以通過api注入路由

b. 是否可以通過api訪問session table，甚至對session table進行微調

c. 是否可以通過api快速更新policy（防火牆策略） - 一小時變化數百次，甚至數萬次

...

有些東西，看上去像天方夜譚，似乎沒什麼大用，比如c —— 有什麼變態的業務會一小時成千上萬次改變policy？但互聯網告訴我們，如果你足夠穩定，簡單，大規模地提供了某項能力，則這能力最終提供的結果可能大大超出你的預期。

programmable network就如programmable internet一樣，會從根上改變很多行為。現在internet的協同性越來越好，很多原來一個個小團隊無法完成的項目，由於有了programmable internet，如雨後春筍一樣冒了出來。這極大地豐富了互聯網的體驗，反過來促進了整個行業的進一步發展。對於network行業來說，有理由相信programmable network的巨大潛力。

當然，由於我們自身思維的僵化，靠現有的人做這樣的產品是不夠的，所以在會上我提了一個觀點：三五年前google，facebook從juniper挖了些人過去 —— 他們需要了解如何做網路；現在是我們從他們的網路部門挖人的時候了 —— 我們需要了解互聯網公司如何做網路，需要什麼樣的網路。其實當時我特別想舉IBM做PC的例子 —— 如果你想做一個完全不同的市場，那麼需要使用了解那個市場的人。但是我忍住了。

生意

和互聯網公司做生意的方式應該和傳統IT公司不同，我猜。我們把產品賣給AT&T，或者工商銀行，銷售人員需要連接的對象一般是IT部門及其下屬的網路部門，系統工程師和網路工程師（JNCIE，CCIE們）會在其中參與決策。但是賣同樣的產品給互聯網公司，參與決策的可能是開發部門，devops會參與決策。這兩類人完全不同，需求也完全不一樣。

我們看如今IT人員角色的變遷 —— 首先是QA在往SDET（Software develop engineer for Test）上遷移；隨後是IT admin往devops上遷移；不久的將來，也許會是Network admin往devops上遷移。devops替換IT admin在若干人需要管理成千上萬的伺服器，而傳統的IT admin無法scale的背景下；那麼devops替換network admin也很可能發生在類似的場景下。

今後要把設備賣給互聯網公司，很可能sales打個前站，然後就是developer與developer（devops）間的交談。這兩類人之間交流沒有障礙。甚至，隨後的服務（售後），也會出現developer與developer的交流，因為對方需要了解api調用的細節，以及使用過程中出現的各種api調用問題。

歡迎訂閱公眾號『程序人生』（搜索微信號 programmer_life）。每篇文章都力求原汁原味，早8點與您相會。