挑战
Zalando 是欧洲领先的在线时尚平台，自 2008 年成立以来经历了指数级增长。2015 年，为了进一步扩展其原始电子商务网站，纳入新的服务和产品，Zalando 开始了一项根本性转型，最终形成了自主自组织的团队。这种变化需要一种能够随着工程组织的发展而扩展的基础设施。Zalando 的技术部门开始重写其应用程序以使其适应云，并开始将其基础设施从本地数据中心迁移到云。尽管最初没有考虑编排，但随着团队迁移到 Amazon Web Services (AWS)，“我们看到了团队在使用 AWS 上的基础设施和 Cloud Formation 时遇到的难题，”开发人员效率主管 Henning Jacobs 说。“对于团队和合规性而言，仍然有太多的运营开销。”为了提供更好的支持，集群管理开始发挥作用。
解决方案
该公司现在使用 Kubernetes 编排在 AWS 上运行其 Docker 容器。
影响
Jacobs 说，在旧的基础设施下，“很难正确地拥抱新技术，而 DevOps 团队被认为是瓶颈”。“现在，有了这种云基础设施，他们有了这种包装格式，其中可以包含任何在 Linux 内核上运行的东西。这让很多人非常高兴。工程师喜欢自主性。”
Zalando 开发人员效率主管 Jacobs 说：“它最初是一个 PHP 电子商务网站，很容易上手，但无法随着业务需求进行扩展。”
当时，该公司开始超越其德国起源，扩展到其他欧洲市场。快进到今天，Zalando 现在拥有超过 14,000 名员工，2016 年的收入为 36 亿欧元，业务遍及 15 个国家。“随着所有维度的增长和持续的扩张，这是一生难得的经历，”他说。
更不用说对于像 Jacobs 这样的基础设施专家来说，这是一个独特的机会。他加入后不久，该公司开始内部重写所有应用程序。“这通常是我们的策略，”他说。“例如，我们从自己的物流仓库开始，但起初你不知道如何制作物流软件，所以你有一些供应商软件。然后我们用自己的软件替换了它，因为使用现成的软件你没有竞争力。你需要根据你的具体业务需求优化这些流程。”
在重写其应用程序的同时，Zalando 设定了一个目标，即从基本的电子商务扩展到一个提供多租户、大幅增加商品种类和款式、当日送达甚至您的专属在线造型师的平台。
扩展的需求最终促使该公司走上了云原生之旅。它也拥抱了基于微服务的软件架构，该架构为工程团队提供了更多的自主权和项目所有权。“这种向云的迁移是必要的，因为在数据中心你无法拥有自主团队。你拥有相同的基础设施，它非常同质化，所以你只能运行你的 Java 或 Python 应用程序，”Jacobs 说。
Zalando 开始将其基础设施从两个本地数据中心迁移到云，这需要迁移旧应用程序以使其适应云。“我们决定彻底中断，”Jacobs 说。“我们的 Amazon Web Services 基础设施是这样设置的：每个团队都有自己的 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 能够引入并维护公司为发展其平台而设想的新产品。“时尚建议产品使用了 Scala，并且在我们的旧基础设施上实现这一点很困难，”Jacobs 说。“这是一种权宜之计，而且该团队需要平台团队越来越多的支持，仅仅因为他们使用了不同的技术。现在有了 Kubernetes，它是自主的。无论工作负载是什么，该团队都可以按照自己的方式进行，而 Kubernetes 可以防止其他瓶颈。”
展望未来，Jacobs 认为 Zalando 的新基础设施为公司正在进行的其他工作（从新的物流软件到连接品牌的平台功能，再到数据科学家构思的产品）提供了强大的支持。“一个愿景是，如果你观看下一部詹姆斯·邦德电影并看到他穿的西装，你应该能够自动订购它，并在一个小时内送到你手中，”Jacobs 说。“这是关于连接整个时尚领域。如果每个人都在同一个数据中心运行，从而受到很大限制，这绝对是不可能的。你需要基础设施来扩展每个自主团队的想法。”
对于其他正在考虑这项技术的公司，Jacobs 说他并不一定建议他们完全按照 Zalando 的方式去做。“如果你准备好在某些事情上失败，那么这样做是可以的，”他说。“你需要设定正确的期望。并非一切都会奏效。重写应用程序和这种类型的组织变革可能会带来破坏。我们迁移的第一个产品至关重要。有很多依赖关系，而且花费的时间比预期的要长。也许我们应该从一些不那么复杂、不那么关键的业务入手，只是为了试水。”
但一旦他们到达了另一边，“每个人都清楚，没有其他更好的替代方案，”Jacobs 补充说。“Kubernetes API 允许我们以与云提供商无关的方式运行应用程序，这使我们能够在未来几年重新评估 IaaS 提供商。Zalando 技术受益于迁移到 Kubernetes，因为我们能够利用我们现有的知识创建一个工程平台，为我们的工程师提供灵活性和速度，同时显著降低运营开销。我们期望 Kubernetes API 成为 PaaS 基础设施的全球标准，并对持续的旅程感到兴奋。”