挑戰
Buffer 擁有一個由 80 名員工組成的小型但完全分散式的團隊，工作在近十個時區。據架構師 Dan Farrelly 稱，這家為機構和營銷人員提供社交媒體管理的公司正在尋求解決其“經典的單體程式碼庫問題”。“我們希望擁有那種靈活的基礎設施，開發人員可以在其中建立應用程式並進行部署，然後根據需要進行水平擴充套件。”
解決方案
Buffer 採用容器化技術，將其基礎設施從 Amazon Web Services 的 Elastic Beanstalk 遷移到 AWS 上的 Docker，並由 Kubernetes 進行編排。
影響
Farrelly 說，新系統“提升了我們部署和推出新功能的能力”。“在你的電腦上構建東西，並知道它會正常工作，這大大縮短了開發時間。我們的反饋週期現在也快了很多。”
“如果你一個人建造一張桌子，沒問題，”公司架構師說。“如果你帶第二個人來做桌子，也許那個人可以在你打磨桌面的時候開始打磨桌腿。但當你帶第三或第四個人進來時，可能有人應該去製作另一張桌子。” 需要製作越來越多的不同桌子，這讓 Buffer 走上了微服務和容器化的道路，而 Kubernetes 使這一切成為可能。
自 2012 年左右以來，Buffer 一直在使用 Elastic Beanstalk，這是 Amazon Web Services 提供的用於部署基礎設施的編排服務。“我們當時部署的是一個單一的單體 PHP 應用程式，並且在五六個環境中都是同一個應用程式，”Farrelly 說。“我們非常注重產品驅動。一切都為了快速釋出新功能並將產品推向市場，如果某個東西沒有損壞，我們就不會花太多時間在其上面。如果速度有點慢，我們可能會使用更快的伺服器或只擴充套件一個例項，這也就足夠了。然後我們就會繼續前進。”
但在 2016 年，情況變得嚴峻。隨著員工中提交者數量的增加，Farrelly 和 Buffer 當時的 CTO Sunil Sadasivan 決定是時候重新架構和重新思考他們的基礎設施了。“這是一個經典的單體程式碼庫問題，”Farrelly 說。
公司的一些團隊已經在他們的開發環境中成功使用了 Docker，但在生產環境中唯一執行在 Docker 上的應用程式是一個沒有真實使用者流量的營銷網站。他們希望在 Docker 方面走得更遠，下一步是尋找編排選項。
他們首先考慮了 Mesosphere、DC/OS 和 Amazon Elastic Container Service（他們的資料系統團隊已經將後者用於一些資料管道任務）。儘管他們對這些產品印象深刻，但最終還是選擇了 Kubernetes。“我們仍然在 AWS 上執行，因此按需啟動、建立服務和建立負載均衡器，而無需手動配置它們，這對我們的團隊來說是一個很好的入門方式，”Farrelly 說。“我們不需要弄清楚如何配置這個或那個，尤其是我們以前使用的是 Elastic Beanstalk 環境，它為我們提供了一個自動配置的負載均衡器。我真的很喜歡 Kubernetes 的命令列控制。它解決了埠問題。它更加靈活。Kubernetes 的設計就是為了做它所做的事情，所以它做得非常好。”
Kubernetes 的所有優點都符合 Buffer 的需求。“我們希望擁有那種靈活的基礎設施，開發人員可以在其中建立應用程式並進行部署，然後根據需要進行水平擴充套件，”Farrelly 說。“我們很快使用一些指令碼設定了幾個測試叢集，我們用容器構建了一些小的概念驗證應用程式，並在一個小時內完成了部署。我們在生產環境中執行容器的經驗非常少。令人驚奇的是，我們能如此快速地掌握 [Kubernetes]。”
最重要的是，它為公司最顯著的特點之一提供了一個強大的解決方案：他們分佈在十幾個不同時區的遠端團隊。“我們基礎設施的深層知識擁有者生活在與我們流量高峰時區不同的時區，而我們大部分產品工程師生活在其他地方，”Farrelly 說。“所以我們真的希望有這樣一個系統，任何人都可以儘早掌握並使用它，而不必擔心部署工程師在睡覺。否則人們會因為某個問題等待 12 到 24 小時。看到人們的工作效率大大提高，這真的很酷。”
Buffer 擁有一支相對較小的工程團隊——只有 25 人，其中只有少數人從事基礎設施工作，大多數是前端開發人員——Farrelly 說，他們需要“一個健壯的系統，讓他們可以部署任何想要的東西”。以前，“只有幾個人知道如何用老方法設定一切。有了這個系統，查閱文件並極其快速地釋出新功能變得很容易。它降低了我們將所有東西投入生產的門檻。我們沒有像其他大公司那樣龐大的團隊來構建所有這些工具或管理基礎設施。”
為了幫助實現這一點，Buffer 的開發人員編寫了一個部署機器人，它封裝了 Kubernetes 的部署過程，可以供每個團隊使用。“以前，我們的資料分析師如果要更新，比如一個 Python 分析指令碼，必須等待該團隊的負責人點選按鈕才能部署，”Farrelly 解釋說。“現在我們的資料分析師可以進行更改，輸入一個 Slack 命令 '/deploy'，它會立即釋出。他們不需要等待漫長的週轉時間。他們甚至不知道它在哪裡執行；這不重要。”
團隊使用 Kubernetes 從頭開始構建的第一個應用程式之一是一個新的圖片調整服務。作為一個社交媒體管理工具，它允許營銷團隊協作釋出內容並在多個社交媒體個人資料和網路上傳送更新，Buffer 必須能夠根據需要調整照片大小，以滿足不同社交網路對大小和格式的各種限制。“我們以前總是使用拼湊起來的解決方案，”Farrelly 說。
為了建立這個新服務，一名高階產品工程師被指派學習 Docker 和 Kubernetes，然後構建服務、測試、部署和監控它——他相對較快地完成了這些工作。“在我們以前的工作方式中，反饋迴圈要長得多，而且很脆弱，因為如果你部署了某個東西，就有很高的風險可能會破壞其他東西，”Farrelly 說。“透過我們圍繞 Kubernetes 構建的部署方式，我們能夠檢測並修復錯誤，並以超快的速度進行部署。一旦有人修復 [一個錯誤]，它就能立即釋出。”
此外，與舊系統不同，他們可以透過一個命令進行水平擴充套件。“當我們推出它時，”Farrelly 說，“我們可以預見到並只需點選一個按鈕。這使我們能夠應對使用者對系統的需求，並輕鬆擴充套件以應對它。”
他們以前無法做到的另一件事是金絲雀部署。Farrelly 說，這項新功能“讓我們對部署重大變更更有信心”。“以前，需要進行大量的測試，這仍然是好的，但也有很多‘祈禱’的成分。而這是每天執行 80 萬次的業務核心。如果它不起作用，我們的業務就無法執行。在 Kubernetes 世界中，我可以進行金絲雀部署，以 1% 的流量進行測試，如果它不起作用，我可以很快將其關閉。這提升了我們快速部署和推出新功能的能力，同時降低了風險。”
到 2016 年 10 月，Buffer 54% 的流量都透過他們的 Kubernetes 叢集。Farrelly 說：“我們有許多遺留功能仍然執行良好，這些部分可能會遷移到 Kubernetes，也可能永遠留在我們舊的設定中。” 但公司當時承諾，未來“所有新開發、所有新功能都將執行在 Kubernetes 上”。
2017 年的計劃是將所有遺留應用程式遷移到一個新的 Kubernetes 叢集，並將他們從舊基礎設施中剝離出來的所有內容，以及他們正在 Kubernetes 中開發的新服務，執行在另一個叢集上。“我希望將我們早期服務中看到的所有好處帶給團隊中的每個人，”Farrelly 說。
這張空白畫布的一部分是 Kubernetes 提供的靈活性，以防 Buffer 某天可能想要或需要更換其雲服務。Farrelly 說：“它是雲無關的，所以也許有一天我們可以切換到 Google 或其他地方。” “我們對亞馬遜的依賴很深，但知道如果需要，我們可以遷移出去，這很好。”
在這一點上，Buffer 的團隊無法想象以任何其他方式執行他們的基礎設施——他們很樂意分享這一訊息。Farrelly 說：“如果你想在生產環境中執行容器，並且擁有幾乎與 Google 內部使用的功能相當的能力，那麼 [Kubernetes] 是一個很好的選擇。” “我們是一個相對較小的團隊，實際上正在執行 Kubernetes，我們以前從未執行過類似的東西。所以它比你想象的更容易上手。這是我告訴那些正在嘗試它的人的一件大事。選擇幾樣東西，推出它們，用幾個月時間對其進行測試，看看它能處理多少。你會透過這種方式學到很多東西。”