挑战
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 说。“以前，需要进行很多测试，这仍然很好，但也需要很多‘祈祷’。而这东西每天要运行 800,000 次，是我们业务的核心。如果它不起作用，我们的业务就无法运作。在 Kubernetes 世界中，我可以进行金丝雀部署，以 1% 的流量进行测试，如果它不起作用，我可以快速关闭它。这提高了我们快速部署和推出新更改的能力，同时降低了风险。”
到 2016 年 10 月，Buffer 的 54% 的流量都通过了他们的 Kubernetes 集群。“我们还有很多遗留功能，这些功能运行良好，这些部分可能会迁移到 Kubernetes 或者永远保留在我们旧的设置中，”Farrelly 说。但该公司当时承诺，今后“所有新的开发，所有新的功能都将在 Kubernetes 上运行。”
2017 年的计划是将所有遗留应用程序迁移到一个新的 Kubernetes 集群，并将他们从旧基础设施中提取的所有内容以及他们在 Kubernetes 中开发的新服务运行在另一个集群上。“我想将我们在早期服务中看到的优势带给团队中的每个人，”Farrelly 说。
这块空白画板的一部分是 Kubernetes 提供的灵活性，如果有一天 Buffer 想要或需要改变其云，就可以使用它。“它是云无关的，所以也许有一天我们可以切换到 Google 或其他地方，”Farrelly 说。“我们在 Amazon 投入了很深，但知道我们可以根据需要迁移，这很好。”
在这一点上，Buffer 团队无法想象用其他方式运行其基础设施——他们很乐意宣传它。“如果你想在生产环境中运行容器，并且想要获得与 Google 内部使用的几乎相同的强大功能，那么 [Kubernetes] 就是一个绝佳的选择，”Farrelly 说。“我们是一个规模相对较小的团队，实际上在运行 Kubernetes，我们以前从未运行过任何类似的东西。所以它比你想象的更容易上手。这是我告诉那些正在尝试使用它的人的一件重要的事情。选择一些东西，把它部署出去，试用几个月，看看它能处理多少。这样你就能学到很多东西。”