挑战
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 人，其中只有少数人从事基础设施工作，而大多数是前端开发人员——Buffer 需要“一些强大的东西，让他们可以部署他们想要的任何东西，”Farrelly 说。 以前，“只有几个人知道如何以旧的方式设置所有东西。有了这个系统，很容易查看文档并极快地发布一些东西。它降低了我们将所有东西投入生产的门槛。我们没有像其他大型公司那样拥有构建所有这些工具或管理基础设施的大型团队。”
为了帮助解决这个问题，Buffer 开发人员编写了一个部署机器人，它封装了 Kubernetes 部署过程，并且每个团队都可以使用。“以前，我们的数据分析师会更新，比如说，一个 Python 分析脚本，并且必须等待该团队的负责人点击按钮来部署它，”Farrelly 解释说。“现在我们的数据分析师可以进行更改，输入一个 Slack 命令“/deploy”，然后它就会立即发布。他们不需要等待这些缓慢的周转时间。他们甚至不知道它在哪里运行；这无关紧要。”
该团队使用 Kubernetes 从头开始构建的第一个应用程序之一是一项新的图像调整大小服务。作为一款社交媒体管理工具，Buffer 允许营销团队协作发布帖子，并在多个社交媒体资料和网络上发送更新，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 团队无法想象以其他任何方式运行他们的基础设施，并且他们很乐意传播这一信息。Farrelly 说：“如果你想在生产环境中运行容器，并拥有几乎与 Google 内部使用的能力相当的能力，那么 [Kubernetes] 是一个很棒的选择。我们是一个相对较小的团队，实际上在运行 Kubernetes，而且我们以前从未运行过类似的东西。所以它比你想象的更容易上手。这是我告诉正在尝试使用它的人的最大一点。选择几个东西，部署它，测试几个月看看它能处理多少。你会通过这种方式学到很多东西。”