挑战
AppDirect 提供一个端到端商务平台，用于处理基于云的产品和服务。软件开发总监 Pierre-Alexandre Lacerte 在 2014 年开始在那里工作时，公司使用一个部署在 "tomcat 基础设施上的单体应用，整个发布流程本应更简单，但他表示实际情况很复杂。流程中涉及大量手动步骤，一名工程师构建一个功能，然后另一个团队接收变更。因此，在将功能交付生产环境的流水线中存在瓶颈。" 同时，工程团队不断壮大，公司意识到需要更好的基础设施来支持这种增长并提高速度。
解决方案
Lacerte 说："我的想法是：创建一个团队可以更快部署其服务的环境，然后他们就会说，'好的，我不想再在单体应用中构建了。我想构建一个服务。'" 他们在 2016 年初决定采用 Kubernetes 之前，考虑并原型开发了几种不同的技术。Lacerte 的团队还将 Prometheus 监控集成到平台中；接下来是跟踪。如今，AppDirect 有 50 多个微服务在生产环境运行，并在全球的 AWS 和本地部署了 15 个 Kubernetes 集群。
影响
Kubernetes 平台在过去几年里帮助支持了工程团队实现 10 倍的增长。Lacerte 表示，再加上他们不断添加新功能，"我想如果我们没有这种新的基础设施，我们的速度会慢很多。" 迁移到 Kubernetes 和服务意味着部署速度大大加快，因为减少了对使用 SCP 命令定制的易碎 shell 脚本的依赖。部署新版本的时间从 4 小时缩短到几分钟。此外，公司投入大量精力为开发人员提供自助服务。"接入一个新服务不需要创建 Jira 工单或与三个不同的团队开会，" Lacerte 说。如今，公司每周看到 1,600 次部署，而之前是 1-30 次。公司通过将 Marketplace 和 Billing 的单体应用从老旧的 EC2 主机迁移到 Kubernetes，以及利用自动扩缩容功能，也实现了成本节约，因为业务时间流量更高。
软件开发总监 Pierre-Alexandre Lacerte 在 2014 年开始在那里工作时，公司使用一个部署在 "tomcat 基础设施上的单体应用，整个发布流程本应更简单，但他表示实际情况很复杂。流程中涉及大量手动步骤，一名工程师构建一个功能然后创建 Pull Request，QA 或另一名工程师验证该功能。然后合并代码，由其他人负责部署。因此，在将功能交付生产环境的流水线中存在瓶颈。"
同时，当时有 40 名工程师的团队不断壮大，公司希望为其产品添加越来越多的功能。作为平台团队的一员，Lacerte 开始听到多个团队希望使用不同框架和语言部署应用程序，从 Node.js 到 Spring Boot Java。他很快意识到，为了支持增长并提高速度，公司需要更好的基础设施，以及一个让团队能够自主、自行部署并对生产环境中的服务负责的系统。
Lacerte 说，从一开始，"我的想法是：创建一个团队可以更快部署其服务的环境，然后他们就会说，'好的，我不想再在单体应用中构建了。我想构建一个服务。'"（Lacerte 于 2019 年离开了公司。）
Lacerte 的团队与运维团队合作，获得了对其 AWS 基础设施更多的控制和访问权，并开始原型开发了几种编排技术。"当时，Kubernetes 有点默默无闻，不太为人所知，" 他说。"但我们查看了社区、Pull Request 的数量、GitHub 上的活跃度，我们看到它正在获得关注。我们发现它比其他技术更容易管理。"
他们使用 Chef 和 Terraform 配置在 Kubernetes 上启动了最初的几个服务，随着更多服务的添加，自动化程度也越来越高。Lacerte 说："我们在世界各地都有集群——韩国、澳大利亚、德国和美国。自动化对我们至关重要。" 他们现在主要使用 Kops，并且正在考虑多个云提供商的托管 Kubernetes 服务。
今天，尽管单体应用仍然存在，但提交的代码和功能越来越少。所有团队都在新基础设施上进行部署，服务已成为常态。AppDirect 现在有 50 多个微服务在生产环境运行，并在全球的 AWS 和本地部署了 15 个 Kubernetes 集群。
Lacerte 的策略最终奏效，因为 Kubernetes 平台对部署时间产生了实实在在的影响。由于减少了对使用 SCP 命令定制的易碎 shell 脚本的依赖，部署新版本的时间从 4 小时缩短到几分钟。此外，公司投入大量精力为开发人员提供自助服务。"接入一个新服务不需要创建 Jira 工单或与三个不同的团队开会，" Lacerte 说。如今，公司每周看到 1,600 次部署，而之前是 1-30 次。
此外，Kubernetes 平台在过去几年里帮助支持了工程团队实现 10 倍的增长。"所有权是 AppDirect 的核心价值，它体现在我们独立于单体代码库发布服务的能力上，" 与 Lacerte 一起参与该倡议的资深软件开发工程师 Alexandre Gervais 说。"小型团队现在负责我们业务领域模型的关键部分，他们在解耦的专业领域内运作，对整个代码库的了解有限。这减少并隔离了部分复杂性。" Lacerte 表示，再加上他们不断添加新功能，"我想如果我们没有这种新的基础设施，我们的速度会慢很多。"
公司通过将 Marketplace 和 Billing 的单体应用从老旧的 EC2 主机迁移到 Kubernetes，以及利用自动扩缩容功能，也实现了成本节约，因为业务时间流量更高。
AppDirect 的云原生技术栈还包括 gRPC 和 Fluentd，团队目前正在努力设置 OpenCensus。平台已经集成了 Prometheus，所以 "当团队部署他们的服务时，他们会有自己的通知、警报和配置，" Lacerte 说。"例如，在测试环境中，我希望在 Slack 上收到消息，在生产环境中，我希望收到 Slack 消息，并且还希望收到寻呼。我们与 pager duty 进行了集成。团队对其服务拥有更多所有权。"
当然，这也意味着更多的责任。Gervais 说："我们要求工程师们拓宽视野。我们从一种仅限于‘将代码推送到分支’的文化转变为代码库之外令人兴奋的新责任：部署功能和配置；监控应用和业务指标；以及在发生故障时提供值班支持。这是一次巨大的工程文化转变，但在规模和速度方面的益处是不可否认的。"
随着工程人员队伍的不断壮大，平台团队面临着新的挑战，即确保 Kubernetes 平台对每个人都易于访问和使用。Lacerte 说："我们如何确保在团队增加更多人手时，他们能高效、富有成效，并且知道如何在平台上快速上手？" 因此，我们有布道者、文档、一些项目示例。我们做演示，举办 AMA 活动。我们正在尝试不同的策略来吸引大家的关注。"
投入 Kubernetes 之旅三年半后，Gervais 觉得 AppDirect "在正确的时间做出了正确的决定，" 他说。"Kubernetes 和云原生技术现在被视为事实上的生态系统。我们知道将精力集中在哪里，以应对在规模扩展过程中面临的新挑战浪潮。社区非常活跃且充满活力，这对我们出色的内部团队是一个很好的补充。展望未来，我们的重点将真正放在从生态系统中获益，在我们的日常运营中提供额外的商业价值。"