歡迎來到「不可變基礎設施」時代

伴隨着最近的「容器革命」，一種新概念變得流行起來：不可變基礎設施。事實上，「不可變基礎設施」這一律念不是剛剛冒出來的，它也不是必須須要容器技術。然而，經過容器，它變得更易於理解，更加實用，並引發了業內普遍注意。

什麼是不可變基礎設施？

我將其定義爲在生產環境中僅經過替換組件而不是修改組件來更改基礎設施。具體地說，這意味着一旦咱們部署了一個組件，咱們就不會再修改它了。這並非說組件沒有任何狀態變化（畢竟絲絕不變也就意味着它不是一個很是實用的軟件組件），而是說運維人員無須在程序的原始API /設計以外引入任何改變。

這種狀況並不罕見，舉例來講，假設咱們想要更改某一配置文件，而該配置文件又正在被某些應用程序使用，若是是動態基礎設施，咱們可能須要使用一些腳本或配置管理工具來進行這種更改。它會對有問題的服務器進行網絡調用，而後執行一些代碼來修改文件。它還可能瞭解並修改該文件的依賴關係（好比須要重啓的程序）。隨着時間的推移，這些關係可能會變得愈來愈複雜，這就是爲何許多CM工具都有一個資源依賴模型來幫助管理它們。

動態基礎設施VS.不可變基礎設施

動態基礎設施與不可變基礎設施之間的權衡其實很是簡單。使用網絡和磁盤IO等資源，動態基礎設施效率更高。在這種效率下，傳統上它的速度要比不可變快，由於它不須要像許多版本的組件那樣須要推送那麼多的比特或存儲。回到咱們更改文件的例子。傳統上，比起更換整個服務器，更換單個文件無疑更快。

另外一方面，不可變的基礎設施爲結果提供了更強有力的保障。不可變的組件能夠在部署以前預先構建，生成一次，而後重複使用，這與動態基礎設施不一樣，後者的邏輯須要在每一個實例中進行評估。這就可能形成意料以外的結果，由於您的某些環境可能處於您指望的不一樣狀態，致使部署出現錯誤。您可能只是在配置管理代碼中犯了某個錯誤，但您又沒法在本地複製生產環境的情況，所以可能很難測試該結果並發現錯誤所在。畢竟，這些配置管理語言自己很複雜。

在「計算機協會」（ACM）雜誌ACM Queue的一篇文章中，Google的工程師清楚地闡述了這一挑戰：

結果是，人們試圖經過消除應用程序源代碼中硬編碼的參數來避免這種神祕的「配置」。它不會下降操做複雜性或使配置更容易調試或更改；它只是將計算從真正的編程語言轉移到特定於領域的編程語言，而這個領域一般具備較弱的開發工具（例如調試器、單元測試框架等）。

容器時代的變局

效率的權衡一直是計算機工程的核心。然而，隨着時間的推移，這些決策的經濟學（包括技術和金融層面）都在改變。

在編程的早期，開發人員被教導使用簡短的變量名，以犧牲可讀性爲代價來節省幾字節的寶貴內存。爲了解決早期硬盤驅動器的空間限制，開發了動態連接庫，以便程序能夠共享公共的C庫，而不是各自須要本身的副本。

而在過去的十年裏，因爲計算機系統的強大功能的改變，這兩種狀況都發生了變化。如今，開發者的時間比咱們經過縮短變量節省的成本要昂貴得多。像Golang和Rust這樣的新語言甚至帶來了靜態編譯的二進制文件，由於若是發生錯誤的DLL，將沒法處理平臺兼容性問題。

基礎設施管理正處於相似的十字路口。公有云和虛擬化不只使得服務器（虛擬機）的速度快了幾個數量級，並且像Docker這樣的工具已經建立了易於使用的工具，來處理預先構建的服務器運行時，來經過層緩存和壓縮來實現高效的資源使用。這些功能使得不可變的基礎設施變得實用，由於它們是如此的輕量級和無摩擦。

Kubernetes在不久以後也進入了這一領域，接過這一火炬並繼續朝着目標，建立了一個「雲原生」原語的API，它假定並鼓勵了一種不可改變的哲學。例如，ReplicaSet假設在咱們的應用程序生命週期的任什麼時候候，咱們均可以(而且可能須要)從新部署咱們的應用程序。爲了平衡這一點，Pod Disruption Budgets（Pod應急預算）將指導Kubernetes應用程序如何從新部署。

以上種種進步的融合使咱們進入了不可改變的基礎設施時代。並且隨着更多的公司參與進來，這個數字還會增長。今天的工具使咱們比以往更容易接受這些模式。那麼，你還在等什麼？