挑战
在 2015 年从 Rackspace 迁移到 AWS 之后，VSCO 开始构建 Node.js 和 Go 微服务，并运行其 PHP 单体应用。该团队使用 Docker 对微服务进行了容器化，但“它们都在单独的 EC2 实例组中，这些实例组专门用于每个服务，”机器学习团队的工程经理 Melinda Lu 说。社区团队的高级软件工程师 Naveen Gattu 补充说：“这导致了大量资源浪费。我们开始寻找一种方法来整合资源，并在 AWS EC2 实例中提高效率。”
解决方案
该团队开始探索调度系统的想法，并研究了 Mesos 和 Swarm 等多种解决方案，最终决定使用 Kubernetes。VSCO 还在其云原生堆栈中使用 gRPC 和 Envoy。
影响
以前，部署需要“大量手动调整，我们编写的内部脚本，并且由于我们分散的 EC2 实例，运营团队必须从头到尾照看整个过程，”高级软件工程师 Brendan Ryan 说。“我们实际上没有一个关于以系统化方式进行测试，以及以标准化方式使用可重用容器或构建的故事。”现在，入职流程更快了。以前，首次部署需要两天的动手设置时间；现在只需两个小时。通过迁移到持续集成、容器化和 Kubernetes，速度显著提高。从代码完成到在真实基础设施上进行生产部署的时间从一到两周缩短到典型服务的两到四个小时。Gattu 补充说：“在工时方面，这相当于一个人与一名开发人员和一名 DevOps 人员同时工作。”由于单个部署在生产环境中发生的耗时减少了 80%，因此部署次数也增加了，从每年 1200 次增加到每年 3200 次。此外，也实现了真正的美元节省：使用 Kubernetes，VSCO 的 EC2 效率提高了 2 倍到 20 倍（取决于服务），总计为公司节省了约 70% 的 EC2 账单。Ryan 指出，公司能够从管理一个大型单体应用程序转变为管理 50 多个微服务，“开发团队规模大致相同。我们之所以能够做到这一点，是因为我们对工具的信任度更高，灵活性也更强，因此无需再雇用 DevOps 工程师来调整每个服务。”有了 Kubernetes、gRPC 和 Envoy，VSCO 的总停机时间减少了 88%，这主要归功于消除了 JSON 架构错误和特定于服务的基础设施配置错误，以及加快了故障排除速度。
在 VSCO 于 2015 年迁移到 AWS 并且用户群超过 3000 万之后，该团队很快意识到这种设置不再适用。开发人员开始构建一些 Node 和 Go 微服务，该团队尝试使用 Docker 对其进行容器化。但“它们都在单独的 EC2 实例组中，这些实例组专门用于每个服务，”机器学习团队的工程经理 Melinda Lu 说。社区团队的高级软件工程师 Naveen Gattu 补充说：“这导致了大量资源浪费。我们开始寻找一种方法来整合资源，并在 EC2 实例中提高效率。”
在考虑了易用性和实施、支持级别以及是否是开源软件等因素之后，该团队评估了一些调度解决方案，包括 Mesos 和 Swarm，最终决定使用 Kubernetes。“Kubernetes 似乎拥有最强大的开源社区，”Lu 说。此外，“我们已经开始在很大程度上标准化 Google 堆栈，使用 Go 作为语言，并使用 gRPC 作为数据中心内部几乎所有服务之间的通信方式。因此，选择 Kubernetes 对我们来说似乎很自然。”
当时，托管的 Kubernetes 产品很少，生态系统中的工具也比较少，因此该团队建立了自己的集群，并为其特定的部署需求构建了一些自定义组件，例如自动入口控制器和用于金丝雀部署的策略结构。“我们已经开始拆分单体应用，因此我们逐个迁移，从一些很小、低风险的服务开始，”Lu 说。“每个新服务都部署在那里。”第一个服务是在 2016 年底迁移的，一年后，整个堆栈的 80% 运行在 Kubernetes 上，包括单体应用的其余部分。
影响非常大。部署过去需要“大量手动调整，我们编写的内部脚本，并且由于我们分散的 EC2 实例，运营团队必须从头到尾照看整个过程，”Ryan 说。“我们实际上没有一个关于以系统化方式进行测试，以及以标准化方式使用可重用容器或构建的故事。”现在，入职流程更快了。以前，首次部署需要两天的动手设置时间；现在只需两个小时。
通过迁移到持续集成、容器化和 Kubernetes，速度显著提高。从代码完成到在真实基础设施上进行生产部署的时间从一到两周缩短到典型服务的两到四个小时。此外，Gattu 说，“在工时方面，这相当于一个人与一名开发人员和一名 DevOps 人员同时工作。”由于单个部署在生产环境中发生的耗时减少了 80%，因此部署次数也增加了，从每年 1200 次增加到每年 3200 次。
此外，也实现了真正的美元节省：使用 Kubernetes，VSCO 的 EC2 效率提高了 2 倍到 20 倍（取决于服务），总计为公司节省了约 70% 的 EC2 账单。
Ryan 指出，公司能够从管理一个大型单体应用程序转变为管理 50 多个微服务，“开发团队规模大致相同。我们之所以能够做到这一点，是因为我们对工具的信任度更高，而且在系统出现压力点时，我们的灵活性也更强。你可以提高服务的 CPU 内存需求，而无需启动和关闭实例，也无需阅读 AWS 页面来熟悉大量术语，这对我们这个规模的公司来说是不可行的。”
Envoy 和 gRPC 也对 VSCO 产生了积极影响。“我们从 gRPC 中获得了许多开箱即用的好处：跨多种语言的类型安全，使用 gRPC IDL 定义服务的简便性，内置的架构（如拦截器），以及与 HTTP/1.1 和 JSON 相比的性能提升，”Lu 说。
VSCO 是 Envoy 的首批用户之一，在 Envoy 开源后五天就将其投入生产。“我们希望通过我们的边缘负载均衡器直接将 gRPC 和 HTTP/2 提供给移动客户端，Envoy 是我们唯一的合理解决方案，”Lu 说。“默认情况下，能够跨所有服务发送一致且详细的统计数据，使可观察性和仪表盘标准化变得更加容易。”Envoy 中内置的指标也“极大地帮助了调试，”DevOps 工程师 Ryan Nguyen 说。
有了 Kubernetes、gRPC 和 Envoy，VSCO 的总停机时间减少了 88%，这主要归功于消除了 JSON 架构错误和特定于服务的基礎设施配置错误，以及加快了故障排除速度。
鉴于其在使用 CNCF 项目方面的成功，VSCO 开始尝试其他项目，包括 CNI 和 Prometheus。“有一个大型组织支持这些技术，我们更有信心尝试这种软件并将它部署到生产环境，”Nguyen 说。
该团队已经为 gRPC 和 Envoy 做出了贡献，并希望在 CNCF 社区中更加活跃。“我非常印象深刻地看到我们的工程师如何通过简单地组合大量 Kubernetes 原语来想出创造性的解决方案，”Lu 说。“将 Kubernetes 结构作为服务公开给我们的工程师，而不是公开更高级别的结构，这对我们来说非常有效。它让你能够熟悉这项技术并用它做更多有趣的事情。”