挑战
Zalando 是欧洲领先的在线时尚平台，自 2008 年成立以来，经历了指数级增长。在 2015 年，Zalando 计划进一步扩展其原有的电子商务站点，以扩展新的服务和产品，从而开始了彻底的变革，因此形成了自主的自组织团队。这次扩展需要可以随工程组织的增长而扩展的基础架构。Zalando 的技术部门开始重写其应用程序，使其能够在云端运行，并开始将其基础架构从内部数据中心迁移到云。虽然编排没有立即被考虑，因为团队迁移到亚马逊网络服务（AWS）：“我们体验过团队在 AWS 上进行基础设施架构和使用云资源时遇到的痛苦，”开发人员生产力主管 Henning Jacobs 说，“我们遇到了一些难题。对于团队和合规性来说，运营开销仍然过多。为了提供更好的支持，项目引入了集群管理。”
解决方案
该公司现在使用 Kubernetes 编排在 AWS 上运行的 Docker 容器。
影响
Jacobs 说，由于旧基础设施“很难正确采用新技术，而 DevOps 团队被视为瓶颈。”“现在，有了这个云基础架构，它们有了这种打包格式，可以包含任何在 Linux 内核上运行的东西。这使得很多人相当高兴。工程师喜欢自主。”
Zalando 的开发人员生产力主管 Jacobs 说：“它最初是一个 PHP 电子商务网站，很容易上手，但无法随业务需求扩展。”
当时，公司开始从 Germany 以外扩展到其他欧洲市场。快进到今天，Zalando 现在拥有超过 14000 名员工，2016 年收入为 36 亿欧元，业务遍及 15 个国家/地区。他表示：“这种全面快速的增长和不断扩展，一生只能有一次。”
能拥有像 Jacobs 这样的基础设施专家的机会是非常独特的。就在他加入公司后，公司开始在内部重写他们的所有应用。“这通常是我们的策略，”他表示。“例如，我们从我们自己的物流仓库开始，但起初不知道如何做物流软件，所以得用一些供应商软件。然后我们用自己的软件替换了它，因为使用现成的软件是没有竞争力的。需要根据特定业务需求优化这些流程。”
在重写其应用程序的同时，Zalando 设定了一个目标，即从基本电子商务扩展到一个提供多租户、大量增加的分类和样式、当天送达，甚至你自己个人在线造型师的平台。
扩展的需求最终引领了公司踏上云原生之旅。它采用基于微服务的软件架构，使工程团队拥有更多的项目自主权和所有权。“迁移到云是必要的，因为在数据中心中，团队不可能随心所欲。使用相同的基础架构，因此只能运行 Java 或 Python 应用，”Jacobs 说。
Zalando 开始将其基础架构从两个内部数据中心迁移到云，这需要迁移较旧的应用程序使其在云中准备就绪。“我们决定果断一些，” Jacobs 说。“我们的亚马逊网络服务基础设施是这样的：每个团队都有自己的 AWS 账户，该账户是完全隔离的，这意味着没有'提升和转移'。基本上必须重写应用程序，使其在云中准备就绪，甚至到持久层也是如此。我们勇敢地回到绘图板，重做一切，首先选择 Docker 作为通用容器化，然后从那里构建基础结构。”
公司最初决定推迟编排，但随着团队迁移到 AWS，“我们看到团队在 AWS 上的基础设施和使用云资源方面遇到了难题，” Jacobs 说。
Zalando 200 多人的自主工程团队研究使用哪些技术，并可以使用自己的 AWS 账户操作自己的应用程序。事实证明，此设置是一项合规性挑战。即使制定了严格的游戏规则和自动化的合规性检查，工程团队和 IT 合规性在解决合规性问题方面也负担过重。Jacobs 说："违规行为会出现，我们在扫描云基础架构时会检测到这些行为。“一切皆有可能，没有强制实施，因此你必须忍受违规行为（并解决它们），而不是一开始就防止错误。这些都会增加团队的开销，以及合规性和操作的开销。在 AWS 上启动新的 EC2 实例也需要时间，这会影响我们的部署速度。”
Jacobs 说，团队意识到他们需要“利用从集群管理中获得的价值”。当他们在 2015 年首次将平台视为服务（PaaS）选项时，市场是支离破碎的；但“现在似乎有一个明确的赢家。使用 Kubernetes 似乎是一个很好的尝试。”
Kubernetes 的过渡始于 2016 年 Zalando 的极客周期间，参与者将他们的项目部署到 Kubernetes 集群。60 名技术基础设施部门的成员开始使用这项技术，之后每次会加入一支工程团队。Jacobs 说：“我们总是从与他们交谈开始，确保每个人的期望都清晰。然后，我们进行一些 Kubernetes 培训，这主要是针对我们的 CI/CD 设置的培训，因为我们的用户界面主要通过 CI/CD 系统。但是他们必须知道 Kubernetes 的基本概念和API。之后每周与每个团队同步，以检查其进度。一旦出现什么状况，就可以确定我们所做的改进是否正常。”
目前，Zalando 正在运行最初的 40 个 Kubernetes 集群，并计划在可预见的将来进行扩展。一旦 Zalando 开始将申请迁移到 Kubernetes，效果立竿见影。“Kubernetes 是我们无缝端到端开发人员体验的基石。我们能够使用单一一致且声明性的 API 将创意运送到生产中，” Jacobs 说。“自愈基础架构提供了无摩擦体验，基于低级最佳实践构建了更高级别的抽象。我们设想所有 Zalando 交付团队都将在 Kubernetes 提供的最先进的可靠和可扩展集群基础架构上运行其容器化应用程序。”
Jacobs 说，使用旧的内部基础设施，“很难正确采用新技术，而 DevOps 团队被视为瓶颈。”“现在，有了这个云基础架构，它们有了这种打包格式，可以包含运行在 Linux 内核中的任何内容。这使得很多人相当高兴。工程师喜欢自主性。”
在 Zalando 的 Kubernetes 实施中出现了一些挑战。Jacobs 说：“我们是一支由七人组成的团队，为不同的工程团队提供集群，我们的目标是为所有团队提供坚如磐石的体验。”“我们不想要宠物集群。我们不想了解他们的工作量；它应该只是开箱即用。考虑到这一点，集群自动缩放非常重要。执行集群管理的方法有很多种，这不是核心的一部分。因此，我们创建了两个组件来预配集群，具有集群的注册表，并管理整个集群生命周期。”
Jacobs 的团队还致力于改进 Kubernetes-AWS 集成。“由于许多限制条件，需要通过基础设施来扩展每个自主团队的想法。”此外，“仍然缺少很多最佳实践，” Jacobs 说。例如，该团队最近解决了 pod 安全策略问题。“在 Kubernetes 已经有一个概念，但没有记录，所以有点棘手，”他说。大型的 Kubernetes 社区是解决这个问题的一大帮助。为了帮助其他公司走上同样的道路，Jacobs 在一份名为在生产中运行 Kubernetes 的文件中汇编了他的团队的经验教训。
最后，Kubernetes 使 Zalando 能够引进和维护公司为发展其平台而设想的新产品。Jacobs 说：“时尚咨询产品使用 Scala，而我们以前的基础设施也难以实现这一点。”这是一个解决方法，该团队需要平台团队提供越来越多的支持，只是因为他们使用了不同的技术。现在有了 Kubernetes，它就自主了。无论工作负载是什么，该团队都可以走自己的路，而 Kubernetes 可以防止其他瓶颈。
展望未来，Jacobs 将 Zalando 的新基础设施视为公司在进行的其他工程中的巨大推动因素，从新的物流软件到连接品牌的平台功能，以及数据科学家梦寐以求的产品。Jacobs 说：“一个愿景是，如果你看下一部 James Bond 的电影，看看他穿的西装，你就应该能够自动订购，并在一小时内把它送到你身边。”“这是关于连接整个时尚领域。如果你遇到瓶颈，因为每个人都在同一个数据中心运行，因此限制很大，则这绝对是不可能的。需要基础设施来扩展每个自主团队的想法。”
对于考虑这项技术的其他公司，Jacobs 说，他不一定建议像 Zalando 那样做。他表示：“如果你准备尝试失败，那么这样做是可以的。”“设定正确的期望是必须的。并不是一切都会起作用。重写应用和这种类型的组织更改可能会造成中断。我们移动的第一个产品至关重要。存在大量依赖关系，而且时间比预期长。也许我们应该从不那么复杂、不是业务关键的东西开始，只是为了开个好头。”
但是，一旦他们到了另一边，“每个人都很清楚，没有大的选择，” Jacobs 补充说。“Kubernetes API 允许我们以与云提供商无关的方式运行应用程序，这使我们能够在未来几年中自由访问 IaaS 提供商。Zalando 受益于迁移到 Kubernetes，因为我们能够利用现有知识创建工程平台，为我们的工程师提供灵活性和速度，同时显著降低运营开销。我们期望 Kubernetes API 成为 PaaS 基础设施的全球标准，并对未来的旅程感到兴奋。”