挑战
作为全球最大的资产管理公司，贝莱德 采用了一种非常可控的静态部署方案，多年来，这种方案一直支持着公司的扩展。但在其数据科学部门，需要更动态地访问资源。“我们希望能够让每位投资者都能使用数据科学工具，这意味着要提供 Python 笔记本，甚至是更高级的工具，比如基于 Spark 的 MapReduce 引擎，”贝莱德产品集团（负责运营公司投资管理平台）的董事总经理 Michael Francis 说道。“管理用户桌面上的复杂 Python 安装非常困难，因为每个人的环境最终都会略有不同。我们有现成的环境可以做到这一点，但我们需要使其变得真实、可扩展且可伸缩。能够按需启动、关闭并使其更具动态性，这对我们来说成为一个关键的思考过程。与其说我们必须解决主要的生产问题，不如说我们该如何扩展？我们该如何发展？”
解决方案
Francis 从去年使用 Docker 环境进行试点中学到的经验出发，组建了一个由 20 人组成的跨部门团队，使用 Kubernetes 构建了一个投资者研究网络应用程序，目标是在一个季度内将其投入生产。
影响
“我们的目标是：如何在无需在用户桌面上安装工具的情况下快速为他们提供工具？”Francis 说道。该团队在 100 天内就实现了目标。Francis 对结果感到满意，他说：“随着时间的推移，我们将把这种基础设施用于许多其他应用程序工作负载。它不仅仅是数据科学；这种类型的应用程序需要动态性。但我认为距离做出[大规模]决定还有 6-12 个月的时间。我们需要积累在生产环境中运行系统的经验，我们需要了解故障模式以及如何最好地管理运营问题。有趣的是，仅仅拥有这项技术就改变了我们的开发人员对未来开发的思考方式。”
贝莱德产品集团员工在 2017 年的管理目标之一是“打造酷炫的东西”。在董事总经理 Michael Francis 的带领下，一个由 20 人组成的跨部门团队做到了这一点：他们在 100 天内推出了一个完整的 Kubernetes 生产环境，并在其上发布了一个新的投资者研究网络应用程序。
对于一家全球最大的资产管理公司来说，“仅仅是设备采购有时就需要 100 天，更不用说从构思到交付了，”高级系统管理员 Karl Wieman 说道。“这是一个紧迫的时间表。但它推动了进展。”事实上，该项目实现了两个目标：它解决了一个业务问题（创建所需的网络应用程序），并提供了 Kubernetes（一种公司渴望探索的云原生技术）的真实生产经验。“与其说我们必须解决主要的生产问题，不如说我们该如何扩展？我们该如何发展？”Francis 说道。除了交付应用程序之外，该项目的最终成功之处在于“我们成功地将一种全新的思维过程整合到我们不想改变的可控基础设施中。”
毕竟，在贝莱德存在的三十年中，“我们已经建立了一个非常完善的环境来管理我们的计算资源，”Francis 说道。“我们在机器上管理大型集群进程，因此我们以一种在概念上非常类似于云的方式对我们的主要生产流程进行大量编排和管理。我们能够以一种非常可控的静态部署方案来管理它们，这为我们提供了巨大的可扩展性。”
尽管这对于核心生产来说效果很好，但该公司发现一些数据科学工作负载需要更动态地访问资源。“这是一个非常突发的过程，”负责公司 Aladdin 投资管理平台部门数据的 Francis 说道。
Aladdin 将资金管理所需的人员、信息和技术实时连接起来，它在内部使用，也作为平台出售给其他资产管理公司和保险公司。“我们希望能够让每位投资者都能使用数据科学工具，这意味着要提供 Python 笔记本，甚至是更高级的工具，比如基于 Spark 的 MapReduce 引擎，”Francis 说道。但是“管理用户桌面上的复杂 Python 安装非常困难，因为每个人的环境最终都会略有不同。Docker 允许我们扁平化该环境。”
尽管如此，挑战依然存在。“如果你有一个共享集群，你会遇到这种蜂拥而至的问题，每个人都想同时做同样的事情，”Francis 说道。“你可以限制它，但你必须构建一个基础设施来为我们的流程定义限制，而 Python 笔记本并不是为此而设计的。我们有现成的环境可以做到这一点，但我们需要使其变得真实、可扩展且可伸缩。能够按需启动、关闭并使其更具动态性，这对我们来说成为一个关键的思考过程。”
Francis 的团队由来自技术、基础设施、生产运营、开发和信息安全的经理组成，他们能够全面地看待问题，并提出一个对贝莱德来说合理的解决方案。“我们最初的想法是，我们将使用 Ansible 构建所有东西，并在一些完全不同的分布式环境中运行它，”Francis 说道。“那绝对是错误的做法。如果我们作为开发团队独自行动并开发这个解决方案，那将是一个完全不同的产品。而且成本会很高。我们不会选择在我们现有的编排系统下运行。因为我们不了解它。这些[运营和基础设施]人员了解它。拥有多学科团队使我们能够找到正确的解决方案，这实际上意味着我们没有构建我们认为最终会构建的那么多东西。”
为了寻找一种可以逐个用户地管理使用情况的解决方案，Francis 的团队选择了 Red Hat 的 OpenShift Kubernetes 产品。该公司已经尝试过其他云原生环境，但该团队喜欢 Kubernetes 是开源的，并且“我们觉得从长远来看，Kubernetes 是大势所趋，”Francis 说道。“通常情况下，我们会选择我们认为在未来 5-10 年内会以某种形式存在的技术。而现在，在这个领域，Kubernetes 感觉像是会一直存在的那一个。”生产运营副总裁 Uri Morris 补充道：“当你看到 Kubernetes 的非 Google 贡献者超过了 Google 贡献者时，这就是发展势头的标志。”
一旦做出决定，主要的挑战就是弄清楚如何让 Kubernetes 在贝莱德的现有框架内工作。“除了将其添加到我们现有的技术平台之外，还要了解我们如何运营、管理和支持这样的平台，”项目经理 Michael Maskallis 说道。“我们现有的所有控制措施、变更管理流程、软件开发生命周期、入职流程——我们如何才能做到所有这些？”
第一个（预期的）障碍是解决贝莱德公司防火墙背后的问题。“我们面临的挑战之一是大多数开源软件都没有防火墙，”Francis 说道。“所以几乎所有的安装脚本都会以某种奇怪的方式失败，而且下载软件包也不一定有效。”该团队在使用 Minikube 时遇到了这类问题，并对开源项目进行了一些小的回馈。
还有一些关于服务发现的问题。“您可以将 Aladdin 视为一个服务云，服务之间通过 API 进行通信，这使我们能够快速构建应用程序，”Francis 说道。“它都在一个专有的消息总线上，这给了我们各种优势，但与此同时，它如何在第三方[平台]中发挥作用？”
他们必须解决的另一个问题是，在贝莱德的现有系统中，消息传递协议在不同的开发、测试和生产环境中具有不同的实例。虽然 Kubernetes 支持更 DevOps 风格的模型，但这对贝莱德来说没有意义。“我认为我们非常自豪的是，在这种[新的]基础设施中，我们投入生产的能力仍然非常快，但我们有适当的控制点，而且我们不必破坏一切，”Francis 说道。“这项开发的很多成本都在于思考如何最好地利用我们内部的工具。所以它的成本比我们预期的要低。”
例如，该项目利用了与消息总线相关的工具。Morris 说：“Kubernetes 集群将通过网关程序与我们的内部消息传递平台进行通信，而该网关程序已经内置了检查和限制功能。我们可以使用它们来控制和潜在地限制从 Kubernetes 高度弹性的基础架构到生产基础架构的请求。我们将继续朝着这个方向努力。它使我们能够从运营角度根据需要进行扩展。”
该解决方案还必须与贝莱德的集中式运营支持团队结构相辅相成。Morris 解释说：“Kubernetes 的核心基础架构组件已连接到我们现有的编排框架中，这意味着我们支持团队中的任何人都可以使用现有的运营工具对集群进行控制和查看。这意味着我不需要雇用更多的人。”
在确定了这些要点之后，团队为该项目创建了一个程序：Maskallis 说：“我们首先将此部署到开发环境中，然后转移到测试环境中，最后按顺序转移到两个生产环境中。这推动了我们的大量学习曲线。我们拥有所有这些活动部件，基础架构方面的软件组件，Kubernetes 本身的软件组件，与我们在贝莱德运营的其余环境的互连性，以及我们如何连接所有这些部分。如果我们遇到问题，我们会修复它们，然后转移到不同的环境中进行复制，直到最终进入我们的生产环境，而这个特定的集群应该存在于该环境中。”
该团队每周都会举行一次为期一小时的工作会议，所有成员（他们遍布世界各地）都会参加，还会举行规模较小的分组会议或深入探讨会议，重点关注具体的技术细节。可能的解决方案将报告给小组，并在下周进行辩论。“我认为，使它成为一个成功的实验的原因是，人们必须努力学习，并与他人分享他们的经验，”副总裁兼软件开发人员 Fouad Semaan 说。然后，Francis 说：“我们为我们的工程师提供了发挥他们所长空间。这不是自上而下的。”
他们遵循一个关键原则：保持专注并避免范围蔓延。这意味着他们不会使用 Kubernetes 和 Docker 核心之外的功能。但如果真的有需要，他们会自己构建这些功能。幸运的是，Francis 说：“由于开发速度很快，我们认为必须自己构建的很多东西都已经纳入了核心产品中。[软件包管理器 Helm就是一个例子]。人们有类似的问题。”
到 100 天结束时，该应用程序已启动并运行，供贝莱德内部用户使用。最初的 30 个用户容量在几小时内就达到了，并迅速增加到 150 个。Francis 说：“人们立即就对它产生了浓厚的兴趣。”在该项目的下一阶段，他们计划扩大集群规模以获得更大的容量。
更重要的是，他们现在拥有 Kubernetes 的生产经验，可以继续在此基础上发展，并且拥有推出新应用程序的完整框架。Francis 说：“随着时间的推移，我们将把这个基础架构用于许多其他应用程序工作负载。它不仅仅是数据科学；这种类型的应用程序需要动态性。它是将我们的核心生产流程迁移到的正确位置吗？也许是。我们还没有到可以给出肯定或否定答案的地步，但我们认为，在某种形式和规模上拥有像 Kubernetes 这样的实际生产经验将使我们能够理解这一点。我认为我们距离做出[大规模]决定还有 6-12 个月的时间。我们需要积累在生产环境中运行系统的经验，我们需要了解故障模式以及如何最好地管理运营问题。”
对于其他正在考虑进行此类项目的大公司，Francis 表示，承诺和奉献精神至关重要：“我们从第一天起就获得了[高级管理层]的批准，并承诺我们能够找到合适的人选。如果我必须找出是什么让像这样复杂的事情取得成功，我会说能够真正推动它前进的高级实践人员会产生巨大的影响。”在此基础上，他补充道：“我对像我们这样的其他企业的建议是，你们实际上可以将 Kubernetes 集成到现有的、精心编排的机器中。你不必抛弃你所做的一切。使用 Kubernetes 使复杂的问题变得简单得多。”