挑戰
Buffer 向經銷商和行銷人員提供社群媒體管理服務。其架構師 Dan Farrelly 表示，Buffer 的團隊雖小，但由 80 人組成，且完全分散在全球近十幾個時區工作，因此 Buffer 一直在尋求解決其「典型的單體式程式碼庫問題」。 「我們希望擁有那種流動的基礎架構，讓開發人員可以建立應用程式、部署應用程式，並在必要時進行水平擴展。」
解決方案
Buffer 擁抱容器化技術，將其基礎架構從 Amazon Web Services 的 Elastic Beanstalk 遷移到 AWS 上的 Docker，並使用 Kubernetes 進行協調。
影響
Farrelly 表示，新系統「提升了我們部署和推出新變更的能力」。 「在您的電腦上建構某些東西，並知道它將會運作，這縮短了很多時間。現在我們的回饋週期也快了很多。」
這位公司架構師說：「如果您自己製作桌子，那沒問題。」 「如果您找第二個人來一起製作桌子，也許這個人可以在您打磨桌面時開始打磨桌腳。但是當您找來第三或第四個人時，可能有人應該開始製作不同的桌子。」 需要製作越來越多不同的桌子，促使 Buffer 走上了微服務之路，而 Kubernetes 則使容器化成為可能。
自 2012 年左右以來，Buffer 就已經在使用 Elastic Beanstalk，這是 Amazon Web Services 提供的基礎架構部署協調服務。 Farrelly 說：「我們當時部署的是單個單體式 PHP 應用程式，並且在五到六個環境中都是相同的應用程式。」 「我們非常以產品為導向的公司。一切都是為了快速交付新功能並將產品推向市場，如果某些東西沒有壞掉，我們就不會花太多時間在上面。如果事情變得有點慢，我們可能會使用更快的伺服器，或者只是擴展一個執行個體，這樣就夠了。我們會繼續前進。」
但事情在 2016 年達到了臨界點。隨著員工中提交程式碼的人數不斷增加，Farrelly 和 Buffer 時任技術長 Sunil Sadasivan 決定是時候重新設計和重新思考他們的基础架構了。 Farrelly 說：「這是一個典型的單體式程式碼庫問題。」
該公司的一些團隊已經在其開發環境中成功使用 Docker，但唯一在生產環境中在 Docker 上執行的應用程式是一個行銷網站，該網站沒有真正的使用者流量。 他們希望在 Docker 上更進一步，下一步是研究協調的選項。
他們首先考慮了 Mesosphere、DC/OS 和 Amazon Elastic Container Service（他們的資料系統團隊已經在將其用於某些資料管道作業）。 雖然這些產品給他們留下了深刻的印象，但他們最終還是選擇了 Kubernetes。 Farrelly 說：「我們仍然在 AWS 上執行，因此無需手動設定即可按需啟動、建立服務和建立負載平衡器，這對我們的團隊來說是進入這個領域的好方法。」 「我們不需要弄清楚如何設定這個或那個，尤其是從以前的 Elastic Beanstalk 環境過來，它為我們提供了一個自動設定的負載平衡器。我真的很喜歡 Kubernetes 對命令列的控制。它只是處理了連接埠。它更加靈活。Kubernetes 專為它所做的事情而設計，因此它做得非常好。」
Kubernetes 的所有優點都非常符合 Buffer 的需求。 Farrelly 說：「我們希望擁有那種流動的基礎架構，讓開發人員可以建立應用程式、部署應用程式，並在必要時進行水平擴展。」 「我們很快地使用一些腳本設定了幾個測試叢集，我們在容器中建構了一些小型概念驗證應用程式，並且我們在一個小時內就部署了這些應用程式。我們在生產環境中執行容器的經驗非常少。 Kubernetes 讓我們能夠如此快速地掌握它，這真是太神奇了。」
最重要的是，它為該公司最顯著的特徵之一提供了強大的解決方案：他們的遠端團隊分佈在十幾個不同的時區。 Farrelly 說：「對我們的基礎架構有深入了解的人員居住的時區與我們的流量高峰時段不同，而且我們大多數產品工程師都住在其他地方。」 「因此，我們真的希望能夠讓任何人都能儘早掌握系統並加以利用，而不必擔心部署工程師正在睡覺。否則人們會為了某件事而坐等 12 到 24 小時。看到人們行動得更快，真是太酷了。」
Buffer 的工程團隊規模相對較小，只有 25 人，只有少數人從事基礎架構工作，大多數是前端開發人員，Buffer 需要「一些穩健的東西，讓他們可以部署任何他們想要的東西」，Farrelly 說。 以前，「只有少數人知道如何以舊的方式設定一切。使用這個系統，可以輕鬆查看文件並非常快速地推出產品。它降低了我們將所有東西投入生產的門檻。我們沒有大型團隊來建構所有這些工具或像其他大型公司那樣管理基礎架構。」
為了幫助實現這一點，Buffer 開發人員編寫了一個部署機器人，該機器人封裝了 Kubernetes 部署流程，並且每個團隊都可以使用。 Farrelly 解釋說：「以前，我們的資料分析師會更新，例如，一個 Python 分析腳本，並且必須等待該團隊的負責人點擊按鈕並部署它。」 「現在我們的資料分析師可以進行變更，輸入一個 Slack 命令 '/deploy'，它就會立即發布。他們不需要等待這些緩慢的周轉時間。他們甚至不知道它在哪裡執行；這都無所謂。」
該團隊使用 Kubernetes 從頭開始建構的第一批應用程式之一是新的影像調整大小服務。 作為一個社群媒體管理工具，它允許行銷團隊協作處理貼文並跨多個社群媒體個人資料和網路發送更新，Buffer 必須能夠根據需要調整照片大小，以滿足不同社群網路提出的不同大小和格式限制。 Farrelly 說：「我們一直都有這些拼湊起來的解決方案。」
為了建立這項新服務，一位資深產品工程師被指派學習 Docker 和 Kubernetes，然後建構服務、測試服務、部署服務和監控服務——他能夠相對快速地完成這些工作。 Farrelly 說：「在我們舊的工作方式中，回饋迴圈要長得多，而且很微妙，因為如果您部署了某些東西，則可能會破壞其他東西的風險很高。」 「透過我們圍繞 Kubernetes 建構的部署類型，我們能夠偵測錯誤並修復它們，並以超快的速度部署它們。一旦有人修復 [錯誤]，它就會立即發布。」
此外，與舊系統不同，他們可以使用一個命令水平擴展事物。 Farrelly 說：「當我們推出它時，我們可以預期並只需點擊一個按鈕。這使我們能夠應對使用者對系統提出的需求，並輕鬆擴展系統以處理它。」
他們以前無法做的另一件事是 Canary 部署。 Farrelly 說，這種新功能「讓我們在部署重大變更時更有信心」。 「以前，這需要大量的測試，這仍然很好，但也需要大量的『祈禱』。這是每天執行 80 萬次的服務，是我們業務的核心。如果它無法運作，我們的業務就無法運作。在 Kubernetes 世界中，我可以執行 Canary 部署來針對 1% 的流量進行測試，如果它無法運作，我可以非常快速地關閉它。這提升了我們快速部署和推出新變更的能力，同時降低了風險。」
到 2016 年 10 月，Buffer 54% 的流量都通過了他們的 Kubernetes 叢集。 Farrelly 說：「我們的許多舊版功能仍然可以正常運作，這些部分可能會遷移到 Kubernetes，也可能會永遠保留在我們的舊設定中。」 但該公司當時承諾，展望未來，「所有新開發、所有新功能都將在 Kubernetes 上執行。」
2017 年的計畫是將所有舊版應用程式遷移到新的 Kubernetes 叢集，並將他們從舊基礎架構中提取的所有內容，以及他們在 Kubernetes 中開發的新服務，在另一個叢集上執行。 Farrelly 說：「我希望將我們在早期服務中看到的所有好處帶給團隊中的每個人。」
空白畫布的一部分是 Kubernetes 提供的靈活性，如果 Buffer 將來想要或需要更換雲端，它可以提供這種靈活性。 Farrelly 說：「它是雲端不可知的，因此也許有一天我們可以切換到 Google 或其他地方。」 「我們在 Amazon 中投入了大量資金，但很高興知道如果我們需要，我們可以搬走。」
在這一點上，Buffer 團隊無法想像以任何其他方式執行其基礎架構，並且他們很樂意宣傳這一點。 Farrelly 說：「如果您想在生產環境中執行容器，並擁有幾乎與 Google 內部使用的功能相同的強大功能，那麼 [Kubernetes] 是一個很好的方法。」 「我們是一個相對較小的團隊，實際上正在執行 Kubernetes，而且我們以前從未執行過任何類似的產品。因此，它比您想像的更容易上手。這是我告訴那些正在試驗它的人們的一件大事。選擇幾件事，推出它，對它進行幾個月的測試，看看它可以處理多少。您會以這種方式開始學習很多東西。」