Netflix Spinnaker：實現全局部署

Glover：社區對Spinnaker的接納程度令人震驚！這個平臺內置了對多個云提供商的兼容，并且能夠通過一種可擴展的模型接入其中。這意味著我們打造了一個大型社區，而不是一系列專注于不同分支的微型社區。這種方式的優勢在于社區中的每個人都可以利用各種創新的特性。我們已看到許多來自于新社區成員的pull request，并且我相信，隨著我們繼續提升項目的可適配性，將會看到越來越多的貢獻。

Glover：我知道有一家非常著名的公司已經在多個云提供商環境中進行部署了，不過他們希望我不要提起他們的名字。我覺得應該有其他用戶也會這樣做，并且隨著社區的發展，我們將進一步了解有哪些公司將采取多個云環境的策略。

Glover：我認為Spinnaker與Heroku的管道相比最大的區別在于：（1）Spinnaker支持多種可適配的部署端點，例如AWS、GCE、Pivotal CloudFoundry等等。（2）Spinnaker的管道模型非常之靈活，它支持多種不同類型的階段（stage），而且社區也可以自行開發各種管道并將其接入Spinnaker平臺。Heroku管道的設計目標是為了Heroku本身服務的，并且他們的管道模型非常僵化。另一方面，Heroku的管道是通過命令行驅動的。我們目前還沒有發布Spinnaker的命令行客戶端。

Berry：剛開始的時候是比較順利的。當我們在18個月之前啟動這個項目的時候，Angular表現得十分穩定。并且有大量的庫（UI Bootstrap、UI Router和 Restangular等等）讓UI能夠十分快速地進行創建與迭代。React也是一門非常激動人心的技術，但當時它才剛剛出現不久，而且它的規范與模式還沒有Angular那么充實。

但隨后這個開發過程逐漸變得令人痛苦起來。其中部分原因在于Netflix的規模很大，我們某些應用需要在一個屏幕中渲染上千種元素，而Angular 1.x在處理這種數量的DOM節點時性能跟不上。對于這些頁面，我們選擇以純JS進行重寫，再用一些比較粗糙的方式進行性能對比。最終發現純JS的結果能夠滿足性能的要求，即便一次性渲染幾千個實例也沒問題。但這種方式寫出來的代碼非常脆弱，畢竟Angular已經為你完成各種任務鋪平了道路。

另一個難題在于如何讓UI實現模塊化與可適配性，讓不同的云提供商能夠按照他們的需求創建UI模塊，并且讓外部用戶能夠創建自定義的管道組件。我們在這兩方面的工作做得還可以，它不算很差，但也絕對談不上出色。我們從UI Router中直接抄用了大量的代碼與概念，讓我們的代碼能夠運行起來，但除了我們團隊之外，我并沒有看到像Google、微軟和Pivotal嘗試開發任何自定義的實現。我想一定有某些人已經在做這件事了，只是我們還沒看到罷了。

以上這些并不是說我們對于選擇Angular 1.x感到后悔。在當時來說，它對于我們確實是正確的選擇。現在回過頭來看，如果我們能夠回到18個月之前，那我們或許會對代碼進行一些重寫，但大概還是會用Angular吧。

Berry：我們確實有進行遷移的打算，但估計要到5至6個月之后才會開始。畢竟Angular 2還只發布了beta版本，并且在工具方面也缺乏支持。那些編寫UI特性的非Netflix用戶有許多都不是專職的前端開發者，我們希望確保他們能夠輕易地找到構建特性的正確方式，并且在遇到問題時能夠方便地進行調試。

我很樂于看到Angular 2在明年的發展，并且想多了解一些從1.x遷移至2的案例。我們只是想對此采取一種相對謹慎的態度，并且從其他人身上多學習一點經驗。

Glover：首先，也是最重要的一點是它為所有人提供了一個標準的交付平臺。Spinnaker讓用戶能夠方便地進行交付，并且對于流程具備充分的信心，這正是團隊最需要的東西。通過這個平臺，整個Netflix服務能夠更頻繁地進行部署，并且在運維上具備更大的彈性。Spinnaker本身與來自Netflix的大量其他服務與工具進行了集成，使這些特性更易于為用戶所用。舉例來說，我們有一個名為ACA（Automated Canary Analysis —— 自動化金絲雀分析）的內部服務，這是由Netflix的另一個團隊所維護的。盡管如此，它也是一個原生的Spinnaker管道階段，能夠提供測試服務。在Spinnaker出現之前，如果有哪個團隊需要使用ACA，就不得不自行尋找將ACA集成進自己的管道的方式。如今隨著Spinnaker的出現，就為ACA的使用定義了一種標準方法，這也最終使ACA的使用得到了突飛猛進式的增長，這也提高了我們在AWS上的生產環境的可靠性。如果新創建的工具與服務能夠提供更好的測試、數據采集或運維的彈性，就可以將它們接入Spinnaker平臺，讓每個人都能夠充分利用這些工具與服務。

Glover：Spinnaker支持一種表達式語言，能夠讓用戶對管道進行參數化。它允許用戶創建一些非常復雜的管道，最重要的是還能夠進行重用。它們能夠在全球范圍內進行構建的提送（promote）、測試與部署。

Glover：雖然Spinnaker是由Netflix所開發的，但是這個項目的成功離不開與Google、微軟、Pivotal和Kenzan良好的合作與他們的貢獻。我們目前的良好發展狀況以及將來的發展前景讓我們非常振奮。我們目前正在開發的內容包括對容器更深層的支持、整體可適配性與靈活性的增長、以及UI和UX的改進。而Spinnaker社區的發展也讓我們覺得非常激動。

Turnquist：對于Cloud Foundry的支持是在Spinnaker的master分支中開發的，其中包括大量的特性。我們目前正在計劃通過活躍的客戶進行beta級別的測試。在我看來，這對于Cloud Foundry的用戶，無論是PCF、PWS還是其他CF的認證實例都已經成熟了。

如果你覺得目前手動將新的版本發布到CF的時間太長，而希望轉而使用管道進行部署、冒煙測試與驗證，那么現在正是使用Spinnaker，剔除你的發布流程中低效部分的時機。

Turnquist：我覺得“簡便”這種表述或許不夠準確，這個詞似乎暗示著整合這兩個平臺只需很少的工作。實際上我花了很多時間去學習Spinnaker的底層概念，并將這些概念與Cloud Foundry的概念進行一一對應。隨著經驗的積累，我開始認識到Cloud Foundry能夠完美地與Spinnaker平臺進行配合。我需要學習大量CF的API方面的知識（實際上我是在Spring團隊工作，而不是在CF團隊中工作），但我學到的東西越多，這兩者的結合就做得越好。

Cloud Foundry與Spinnaker兩者都支持將應用的多個版本進行分組以進行統一的升級或回滾、在新版本與舊版本之間實現負載均衡，并且支持開發實例、預發布實例與生產環境的實例。它展現了Spinnaker架構的長處與靈活性，并且也展現了Cloud Foundry這個平臺強大的能力。

Turnquist：當我談到這個平臺的時候，給我最多驚喜的是UI的管道編輯器，它讓我能夠進行各種隨意的變更。在“ Cloud Foundry After Dark ”這個webcast中，我設計了一個簡單的管道，其中只包含一個步驟： 部署至生產環境 。在我進行描述的同時，主持人Andrew要求我進行一些調整，讓它能夠實現 部署至預發布環境 、 進行冒煙測試 以及 部署至生產環境 。每當他話音剛落，我就已經完成了調整。隨后我們開始運行管道并通過一個對用戶十分友好的界面閱讀它的輸出。這個平臺讓用戶能夠隨意塑造流程，這是我們不應低估的一個強大特性。