不管怎麼稱呼，基礎設施2.0時代終究是來了
多年前，當雲計算剛剛興起，DevOps還只是一個想法的時候，一個非常小但頗有遠見的小組聚在一起討論基礎設施的未來。基礎設施2.0工作小組囊括了很多互聯網傳奇人物：Greg Ness，Christofer Hoff，James Urquhart，Vint Cerf，Bob Grossman，Dan Lynch。基礎設施2.0工作組試圖預測基礎設施在自動化和編排網路中如何發展。
儘管我們進行了認證的嘗試，但最終時機不對，產業界還沒有準備好講基礎設施從次要角色推向主角的轉型。
十年後的今天，情況發生了變化，我們不再稱之為基礎設施2.0，業界現在的時髦的稱呼例如DevNetOps、NetOps 2.0或Super-NetOps，雖然有了時髦的稱呼，但是支持這一運動的技術仍然保持不變：通過支持API的基礎設施實現自動化，從而解決運營規模的不經濟問題。
雲計算教育業界關於規模經濟的問題，現在容器正在重新定義這一概念，它是網路設備或數據路徑的集合，以支持應用程序和服務的規模。
在該數據路徑中有很多網路和應用程序服務，它們提供了規模化的應用程序、安全性和速度。每一個都需要單獨配置和管理。2014年，Computer Economics網路設備與工程師的比例為37比1。一年後，設備與工程師的比例達到了59比1，增幅為60%。更多應用程序，更多設備，更多工程師？
這就是問題的根源，規模化之後帶來的效率下降。隨著通信變得越來越沉重，用戶的速度實際上是在不斷降低，不得不犧牲安全以保證速度和穩定性，同時收益也在降低。
這就有了基礎設施2.0——DevNetOps，NetOps 2.0，Super-NetOps的用武之地，因為這些技術的目的就是讓DevOps應用於網路。
這一概念包含了三個核心標準：可編程（支持API）基礎設施，基礎設施即代碼，集成。
可編程（支持API）基礎設施
API是新的命令行界面（CLI）。現在可以使用API實現自動化和編排，REST API可以從任何腳本或編程語言中訪問。通過API訪問可促進支持應用程序所需的網路和應用程序服務的集成和部署。從與應用程序所有者共享指標到配置新服務，用戶無法在沒有API的情況下實現有效自動化。
基礎設施即代碼
基礎設施2.0鼓勵使用配置的聲明性方式，而不是強制的API驅動的方式。如果我們要達到科幻電影中的自動化水平，並且在今天的廣告中推廣，我們首先必須轉向聲明性模型，以告知網路做什麼，而不是如何去做。
這需要轉變觀點，將網路設備（無論是硬體還是軟體）視為像應用程序基礎設施一樣可隨意使用。將配置文件和模板的集合視為網路架構的關鍵組件，而不是將布線視為關鍵組件。
集成
自動化是人工任務的彙集，編排是一個過程的自動化。進程需要有多個任務，這意味著集成是說明風格的必備條件。集成斌不容易，但由於HTTP和REST API的普遍性，集成並沒有以前那麼可怕。儘管如此，如果用戶要通過自助服務為開發人員提供負載均衡服務，仍然需要一種方式來加以啟動。大多數情況下需要票務系統，這意味著正在進行集成。
實現基礎設施2.0
基礎設施2.0背後的核心理念以及我們過去希望實現的理念依然如此。我們需要可編程基礎設施來支持聲明式管理方法，並且可以將其集成到自動化部署過程中。由於容器和雲計算帶來的壓力，自動化作為競爭優勢早已不復存在。
自動化不再是領先的先決條件，而是轉變成為企業必須跟上的行業發展腳步。
TAG:SDNLAB |