挑战
Buffer 是一家为代理商和营销人员提供社交媒体管理服务的公司，其架构师 Dan Farrelly 表示，该公司拥有一个由 80 人组成的小型但完全分布式的团队，分布在近 12 个时区，他们正在寻求解决“典型的单体代码库问题”。“我们希望拥有一种灵活的基础架构，开发人员可以在其中创建应用程序并根据需要进行部署和水平扩展。”
解决方案
Buffer 采用容器化技术，将其基础架构从 Amazon Web Services 的 Elastic Beanstalk 迁移到 AWS 上的 Docker，并使用 Kubernetes 进行编排。
影响
Farrelly 表示，新系统“提升了我们部署和推出新变更的能力”。“在你的计算机上构建一些东西，并且知道它能够正常工作，这大大缩短了时间。我们的反馈周期现在也快了很多。”
“如果你一个人做一张桌子，那就没问题，”该公司的架构师说。“如果你再找一个人来做桌子，也许那个人可以在你打磨桌面的时候打磨桌腿。但当你再找第三个或第四个人来的时候，就应该有人去做另一张桌子了。” 需要做越来越多的不同的桌子，这使得 Buffer 走上了由 Kubernetes 实现的微服务和容器化之路。
大约从 2012 年开始，Buffer 就一直在使用 Elastic Beanstalk，这是 Amazon Web Services 提供的用于部署基础架构的编排服务。“我们当时部署的是一个单体的 PHP 应用程序，并且在五六个环境中都是同一个应用程序，”Farrelly 说。“我们当时是一家非常注重产品的公司。一切都以快速发布新功能和推出产品为中心，如果有什么东西没有坏，我们不会在上面花太多时间。如果事情变得有点慢，我们可能会使用更快的服务器，或者只是扩展一个实例，这样就足够了。然后我们会继续前进。”
但事情在 2016 年发生了转机。随着员工中提交代码的人数越来越多，Farrelly 和 Buffer 当时的首席技术官 Sunil Sadasivan 决定是时候重新架构和反思他们的基础架构了。“这是一个典型的单体代码库问题，”Farrelly 说。
公司的一些团队已经在他们的开发环境中成功地使用了 Docker，但在生产环境中，唯一运行在 Docker 上的应用程序是一个没有实际用户流量的营销网站。他们希望在 Docker 方面走得更远，下一步是寻找编排方案。
他们首先考虑了 Mesosphere、DC/OS 和 Amazon Elastic Container Service（他们的数据系统团队已经在将它用于一些数据管道作业）。虽然他们对这些产品印象深刻，但最终还是选择了 Kubernetes。“我们仍然在 AWS 上运行，因此能够按需启动、创建服务和创建负载均衡器，而无需手动配置它们，这对我们团队来说是一个很好的入门方式，”Farrelly 说。“我们不需要弄清楚如何配置这个或那个，尤其是考虑到我们之前使用的是 Elastic Beanstalk 环境，它为我们提供了一个自动配置的负载均衡器。我真的很喜欢 Kubernetes 对命令行的控制。它可以自动处理端口。它更加灵活。Kubernetes 的设计目标就是做它现在做的事情，所以它做得非常好。”
Kubernetes 所做的一切都非常适合 Buffer 的需求。“我们希望拥有一种灵活的基础架构，开发人员可以在其中创建应用程序并根据需要进行部署和水平扩展，”Farrelly 说。“我们很快使用了一些脚本建立了几个测试集群，在容器中构建了一些小型概念验证应用程序，并在一个小时内完成了部署。我们在生产环境中运行容器的经验非常少。令人惊讶的是，我们能够如此迅速地掌握它 [Kubernetes]。”
最重要的是，它为公司最显著的特点之一提供了一个强大的解决方案：他们的远程团队分布在 12 个不同的时区。“对我们的基础架构有深入了解的人所在的时区与我们的流量高峰时区不同，而且我们的大多数产品工程师都生活在其他地方，”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 集群。“我们有很多遗留功能仍然运行良好，这些部分可能会迁移到 Kubernetes，也可能会永远保留在我们的旧设置中，”Farrelly 说。但该公司当时承诺，未来“所有新的开发、所有新的功能都将在 Kubernetes 上运行”。
2017 年的计划是将所有遗留应用程序迁移到一个新的 Kubernetes 集群，并将他们从旧基础架构中剥离出来的所有东西，以及他们正在 Kubernetes 中开发的新服务，都运行在另一个集群上。“我希望将我们在早期服务中看到的所有好处都带给团队中的每个人，”Farrelly 说。
Kubernetes 的灵活性是其空白领域的一部分，如果 Buffer 将来想要或需要更换云服务，这种灵活性就会派上用场。Farrelly 说：“它与云无关，所以也许有一天我们可以切换到谷歌或其他地方。我们现在深度使用亚马逊云服务，但很高兴知道我们可以在需要时更换。”
目前，Buffer 的团队无法想象以任何其他方式运行他们的基础设施，他们也很乐意分享他们的经验。Farrelly 说：“如果你想在生产环境中运行容器，并希望拥有接近谷歌内部使用的能力，那么 Kubernetes 是一个很好的选择。我们是一个规模相对较小的团队，但我们实际运行着 Kubernetes，而且我们以前从未运行过类似的东西。所以它比你想象的更容易上手。这是我告诉那些正在尝试使用它的人最重要的一点。选择一些东西，把它部署出来，试运行几个月，看看它能处理多少东西。你会通过这种方式学到很多东西。”