既要馬兒跑得快又要馬兒不吃草，高性能、低成本是網絡架構師、互聯網服務提供商天天需要考慮的。

再說一下我們對于SONiC評估是怎么看的，我們兩年前評估SONiC的時候，非常高興的看到，像微軟這樣的大的互聯網公司的看法跟我們一樣。很多問題他們都考慮到了，比如說我們如何支持多廠商芯片，微軟花了很多精力定了一個標準，白盒支持多芯片的話過去可能需要兩年，如果目標芯片的SDK是支持SAI這套標準的話，現在花一周、一個月就把基本功能跑起來。同時SONiC是基于一個非常現代的軟件思想設計出來的，有很多對于交換機來說非常關鍵模塊的解耦，能夠更好的滿足數據中心網絡的需求，這些都是我們想要的。

第三個階段，到大規模的時候，可能你在小規模的時候完全碰不到的問題，就會變成非常大的問題，這種問題很多時候都是硬件的穩定性導致的，這時候定制硬件就成了我們必然的選擇。

接下來我再說一下，除了這些功能開發之外，我們要讓它能像一個廠商設備一樣上線，需要多個場景的測試回歸。

最后做一個總結，首先我們認為自研的目的是為了更好的滿足大規模對數據中心網絡的要求，開放的數據中心軟硬件生態為自研提供了很好的條件，作為互聯網提供商要結合自己的業務需求、網絡架構去評估選擇一個合適的開源NOS。同時完備的測試和非常完備的引入策略才是自研設備部署的關鍵，最后對我們來說體會最大的，這不僅僅是一個技術的變化，而是運維模式的變革。從過去我們保證廠商設備的穩定性采取保守策略，到我們為了穩定會快速升級、快速迭代，真正的穩定性是靠敏捷、迭代做出來的，而不是靠保守升級來達到的。

大規模數據中心對底層網絡有有哪些具體需求呢？我歸納下來就是三點：

具體到今天說的重點，在數據中心網絡里，軟硬件的生態可以看到哪些東西呢？這張從底層芯片到支撐數據中心網絡的硬件，和上層的應用軟件做了一個梳理。今天的生態已經是非常豐富和非常健康的狀態了。

我們基于前面的評估和社區緊密合作，我們對于SONiC的架構和社區有一些非常緊密的討論和提出了不少改進的建議。最開始的SONiC配置管理都是基于minigraph文件去配置的，但是隨著我們和社區的共同努力，對于配制管控的需求，很快分階段支持了ConfigDB、gRPC結構化管控，取得了很好的效果。

第一個階段，考慮做自研的時候沒有太多選擇，那時候已經感覺到數據中心開放和網絡開放會給我們帶來好處。大家抱著因為相信可以看見的態度，就走上了這條自研的道路。第一代我們采用的是第三方的軟件和白盒子硬件，就可以把它部署在數據中心里。但是限于軟件的擴展性和本身我們對于白盒子這條路往前走，我們積累了更多運維的經驗。在做白盒子的過程中，你要了解需求是非常非常重要的，我們不是要拿著錘子去找一個釘子，首先要了解清楚數據中心網絡的需求在哪里，哪些東西是必須的，哪些東西是不需要的。