挑战
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，我们以前从未运行过类似的东西。所以它比你想象的更容易上手。这是我告诉那些正在尝试它的人的一件大事。选择几样东西，推出它们，用几个月时间对其进行测试，看看它能处理多少。你会通过这种方式学到很多东西。”