挑战
Buffer 拥有一支由 80 人组成的小规模但完全分布在全球近十几个时区的团队，其为代理机构和营销人员提供社交媒体管理服务。正如架构师 Dan Farrelly 所说，他们当时正寻求解决其“经典的单体代码库问题”。“我们希望拥有那种流动性基础设施，开发人员可以在需要时创建并部署应用，并进行横向扩展。”
解决方案
拥抱容器化后，Buffer 将其基础设施从 Amazon Web Services 的 Elastic Beanstalk 迁移到 AWS 上的 Docker，并使用 Kubernetes 进行编排。
影响
Farrelly 表示，新系统“极大地提升了我们在部署和推出新变更方面的能力”。“在自己的电脑上构建某物并知道它将正常工作，这大大缩短了流程。我们的反馈周期现在也快了很多。”
“如果你一个人造桌子，那没问题，” 公司架构师说。“如果你再找一个人来造桌子，也许你磨桌面时，那个人可以磨桌腿。但如果你找来第三个或第四个人，那可能就有人需要去造另一张桌子了。” 需要处理越来越多不同的“桌子”，这促使 Buffer 走向了微服务和由 Kubernetes 实现的容器化。
大约从 2012 年开始，Buffer 就一直在使用 Elastic Beanstalk，这是由 Amazon Web Services 提供的基础设施部署编排服务。Farrelly 说：“我们当时部署的是一个单体 PHP 应用，它在五六个环境中的应用都是同一个。我们当时非常注重产品驱动。一切都是为了快速推出新功能并尽快上线，如果某个东西没有坏，我们不会花太多时间在其上。如果速度有点慢，我们可能会用更快的服务器，或者只扩展一个实例，这就足够了。然后我们就继续。”
但在 2016 年，情况变得严峻起来。随着员工中提交者数量的增加，Farrelly 和 Buffer 当时的 CTO 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 小时。看到大家行动快了很多，真是太棒了。”
Farrelly 说，Buffer 拥有一支相对较小的工程团队——只有 25 人，其中只有少数人负责基础设施，大部分是前端开发人员——他们需要“一些强大的工具来部署他们想要的任何东西”。以前，“只有少数几个人知道如何用老方法设置一切。使用这个系统，查看文档并快速推出新东西变得很容易。它降低了我们将所有东西部署到生产环境的门槛。我们不像其他大公司那样，有庞大的团队来构建所有这些工具或管理基础设施。”
为了帮助解决这个问题，Buffer 的开发人员编写了一个部署 Bot，它封装了 Kubernetes 部署流程，并且可以供每个团队使用。Farrelly 解释道：“以前，我们的数据分析师更新一个 Python 分析脚本后，必须等待该团队的负责人点击按钮进行部署。现在我们的数据分析师可以进行更改，输入一个 Slack 命令 '/deploy'，它就能立即部署上线。他们不再需要等待这些漫长的周转时间。他们甚至不知道它在哪里运行；这并不重要。”
团队使用 Kubernetes 从零开始构建的首批应用之一是一个新的图像缩放服务。作为一款社交媒体管理工具，Buffer 允许营销团队协作处理帖子，并在多个社交媒体账号和网络上发送更新。因此，Buffer 需要能够根据需要调整照片大小，以满足不同社交网络对尺寸和格式的各种限制。Farrelly 说：“我们以前总是有这些临时拼凑的解决方案。”
为了创建这个新服务，一位高级产品工程师被指派学习 Docker 和 Kubernetes，然后构建、测试、部署并监控这个服务——他相对较快地完成了这些工作。Farrelly 说：“在我们的旧工作方式中，反馈回路长得多，而且很脆弱，因为如果你部署了什么，就有很高的风险可能会破坏其他东西。通过我们围绕 Kubernetes 构建的部署方式，我们能够快速检测和修复 bug，并超快速地完成部署。一旦有人修复了 [bug]，它就能立即上线。”
此外，与旧系统不同的是，他们可以使用一个命令进行横向扩展。Farrelly 说：“在我们推出它时，我们可以预测并只需点击一个按钮。这使我们能够应对用户对系统提出的需求，并轻松地进行扩展来处理这些需求。”
另一个他们以前做不到的事情是金丝雀部署。Farrelly 说，这项新能力“让我们对部署重大更改更加有信心”。“以前，需要大量的测试，这虽然仍然很好，但也有很多时候是在‘祈祷顺利’。而这是一天运行 80 万次的东西，是我们的核心业务。如果它不工作，我们的业务就无法运行。在 Kubernetes 的世界里，我可以做一个金丝雀部署，测试 1% 的流量，如果它不工作，我可以很快地停掉它。这提升了我们快速部署和推出新变更同时降低风险的能力。”
到 2016 年 10 月，Buffer 54% 的流量已经通过他们的 Kubernetes 集群运行。Farrelly 说：“我们有很多遗留功能仍然运行良好，这些部分可能会迁移到 Kubernetes，也可能永远保留在我们的旧配置中。” 但公司当时承诺，今后“所有新的开发、所有新功能都将在 Kubernetes 上运行。”
2017 年的计划是将所有遗留应用迁移到一个新的 Kubernetes 集群，并将从旧基础设施中剥离出来的所有内容，加上他们正在 Kubernetes 中开发的新服务，在另一个集群上运行。Farrelly 说：“我想把我们在早期服务中看到的所有好处带给团队中的每个人。”
这个空白画板的一部分是 Kubernetes 提供的灵活性，以便将来 Buffer 可能需要或想要更改其云服务提供商。Farrelly 说：“它是云无关的，所以也许有一天我们可以切换到 Google 或其他地方。我们现在非常依赖亚马逊云服务，但很高兴知道如果需要，我们可以迁移出去。”
Farrelly 说：“如果你想在生产环境中运行容器，并且拥有接近 Google 内部使用的强大能力，那么 [Kubernetes] 是一个很好的选择。我们是一个相对较小的团队，正在实际运行 Kubernetes，而且我们以前从未运行过类似的东西。所以它比你想象的更容易上手。这是我告诉那些正在尝试使用它的人的一个重要建议。选择几样东西，推出它，试用几个月，看看它能处理多少。这样你就能学到很多东西。”