翻译自 ING on Building a Cloud Native Bank 。
以下是 KubeCon 会议之前关于荷兰国际集团（ING）“无服务器” Kubernetes 命名空间即服务（“NaaS”）交付模型的预览，该模型为其开发人员提供了自己的命名空间。
这篇文章是 4 月 18 日至 21 日在阿姆斯特丹举行的 KubeCon + CloudNativeCon Europe 2023 预览系列文章之一。加入我们，了解更多关于云原生应用程序和开源软件的变革性质。
在当今世界，客户期望获得卓越的体验。这意味着技术现在比以往任何时候都更成为提供那些始终在线的无缝数字服务的重要环节，使我们的客户能够保持安全。
荷兰国际集团（ING）是一家拥有超过 3700 万客户的全球银行，由于其具有适应变化的历史，我们始终致力于领先一步。要在银行科技环境中保持领先，您需要对如何应用信息技术（IT）有很强的见解。
但在我们所依赖的更广泛的技术生态系统中，情况并非总是如此，该生态系统有许多其他利益相关者需要满足，因此，安全性（更不用说合规性）往往是事后才想到的。
因此，我们希望员工通过展示在安全性和合规性方面可以实现更好的表现，来挑战这个科技生态系统。我们不是通过跟随他人的脚步成为今天的我们。
我们的客户（以及他们选举的政治人物和他们设立的监管机构）依赖荷兰国际集团（ING）实现我们所作出的承诺；信任是我们运营的许可证。
我们非常努力地避免任何可能破坏这种信任的服务中断。当然，任何服务中断都可能对我们的专业自豪感造成打击。
可以肯定地说，作为 ING 的技术员工，我们有足够的动力为 ING 建立更好的技术生态系统。
让我更详细地分享一下从技术角度来看“成为一家银行”意味着什么。
尽管 ING 在过去几年中备受瞩目，但有时我们的形象比我们的实际交付更高大。是的，在 DevOps 和敏捷开发的早期阶段，我们敢于迈出一些大步，并从中获得了积极和消极的后果。
相反，这也是真实的：在银行工作有一定的形象，虽然这当然有其合理的原因，但人们并不总是意识到银行科技系统仍然是世界上最复杂的科技系统之一。如果这是一个缺点或美德，您可以有理由挑战银行。
无论好坏，事实是通过几十年的运营，银行已经积累了大量关于如何在大规模安全运营复杂系统的机构知识，即使是当今的超大规模互联网公司也追不上（因为世界上规模较大的银行至少有 25 年的领先优势）。
这意味着大多数银行都可以为个人、开源社区和其他合作伙伴提供一些东西。因此，ING 决定更加活跃于技术社区：
- 鼓励员工充分发挥潜力（例如，通过在会议上发言和撰写技术博客）；
- 使部门能够开放为 ING 内部使用而开发的源代码，或者回馈给我们消费和使用的开源项目；
- 赞助会议、组织聚会和其他活动。
但请不要误解我们开放是为了提倡复杂性。相反，我们绝对希望简化我们的技术生态系统。
我们通过吃亏的方式吸取了教训，并且确定我们想要降低复杂性，摆脱紧密耦合的系统、难以管理的供应商锁定、过时的（有时甚至是自维护的）组件等等 - 最好是今天而不是明天。但现实最终会来到， IT 转型确实需要时间。
尽管如此，就像这个世界上任何其他公司的任何其他技术部门一样，最终，我们仍在一天天地学习和改进。
这些改进的一部分是将我们的遗留系统重建为云原生系统。这是荷兰国际集团（ING）的一段旅程，我们从2015年开始，通过企业架构部门思考我们当时下一代基础设施方案的概念。我们如何使荷兰国际集团（ING）更快速、更容易地适应新技术呢？
有一件事很明显：我们需要拆除金库的围墙，打开我们的系统，并建立数字平台。
说实话，我们当时正在研究将运行时托管与数据服务分离的概念。（基于 12 factor 范式，以及 Kolb＆Wirtz 的研究：Towards Application Portability in Platform as a Service, University of Bamberg。这很快在内部被称为“ Bamberg 模型。”）我们还考虑了为我们的开发人员提供“ API-PaaS ”交付（类似于 Cloud Foundry ）的方案。
然后我们在荷兰国际集团（ING）的基础设施部门经历了敏捷革命，我们保护开发人员的想法通过限制自由度和规定基础设施模式被推翻了。这些修正洞察的结果是一个“无服务器” Kubernetes 命名空间即服务（“NaaS”）交付模型，在其中开发人员对其命名空间内的所有操作负完全责任。这个 NaaS 是一个全局可用的构建块，提供了一个模块化和可扩展的基础架构来托管 ING 的不可变工作负载。它是由 ING 的波兰、德国和荷兰工程师的合作而诞生的。
因此，一些构建和管理 ING 应用程序的 DevOps 团队蓬勃发展，而其他团队则在这些自由和责任的认知负荷下苦苦挣扎。可悲的是，这种学习经历确实给我们造成了一些事后看来本可以避免的中断。
即使在这种 NaaS 运营模式下，仍然存在希望获得专用 Kubernetes 集群的群集级别特权来运行其应用程序的团队和发现难以使用和操作命名空间，更倾向于 API-PaaS 风格交付或 Functions as a Service 的团队之间的辩论。
这里我们必须要应对的另一个现实是工程资源的短缺。我们不可能同时开发和维护 “API-PaaS” 和 “NaaS” 这两种模式（更不用说其他提到的模式了），尤其是在起初没有大量需求的情况下无法做出商业案例。
最终，每个人都有一点正确和一点错误。这里最重要的教训是，一种适用于所有情况的运营模式只有在周围组织与其对齐并支持其开发人员在该运营模式下工作时才能奏效。
快进到今天：
ING 正在寻求通过提供标准化服务来帮助开发人员使用私有云，例如前面提到的 Kubernetes NaaS 。该 NaaS 由 ING 的第二代容器托管平台（ICHPv2）提供。 ING 构建了 36 个 ICHPv2 组件来创建该 NaaS 并使其完全自动化。
我们称 ICHPv2 背后的架构为“零特权”，它将在 2023 年 4 月 19 日至 21 日在 ING 的公司总部阿姆斯特丹举行的 KubeCon + CloudNativeCon EU 大会上公开展示。在同一次会议上，ING 将在其展位上发布前三个 NaaS 组件的开源版本，品牌名称为 Neoria（“Dockyard”）：
- Neoria Skavos：基于观察者设计模式的 Python Operator 框架
- Neoria Orchestration Package：集群编排，与私有云编排器接口
- Neoria Quota AutoScaler：根据部署限制设置命名空间配额
这些组件使 ING 能够显着减少我们的 CPU 使用率，从而减少我们的二氧化碳排放量。由于 ING 将可持续性作为我们工作的核心，我们将此代码提供给世界其他地方，这样可以节省更多的 CPU 周期并避免相应的 CO2 排放。
但我们才刚刚开始。
伴随“零特权架构”的演讲，将有第二场 ING 演讲，“Kubernetes：抵抗是徒劳的”，来自一位实际使用这个私有云生态系统的演讲者。
在各种会前会议期间，ING 演讲者还将与听众分享他们的专业知识：
- Observability Day（“大规模银行可观测性”）
- OpenShift Commons（“工作负载部署质量”）
- Data-on-Kubernetes（“ING 中大规模数据服务的本地持久性”）
在 ING 展台，我们有许多有趣的“展台谈话”，从基于 NaaS（“King's Road”）的工作负载配置模板服务和 ING 专有的 Service Mesh（“Touch Mesh”）到 ING 的未来混合云（“Public Cloud Foundation/Paved Roads”）等等。
还将安排来自 KubeCon 及其会前会议的所有 ING 演讲者的访问。如果您在演讲后没有提问或完全错过了演讲而后悔，这是您的第二次机会！
最后但同样重要的是，ING 开源委员会主席将在 ING 展台分享 ING 如何从生态系统中的消费者演变为贡献者。
我们希望这篇文章和我们在 KubeCon 上的演讲能够让您深入了解银行技术环境中的意义以及如何转变为云原生银行。
显然，要分享的内容远远超出本文的篇幅。
如果您有机会前往阿姆斯特丹，我们希望在 KubeCon EU 期间与您交谈并听取您的反馈。即使您不在银行工作，也可以随时联系我们并学习如何总体上改进技术（安全）生态系统，无论您在哪里工作。
本演示文稿中的插图（“开放”和视觉云原生生态系统 Kube）来自我尊敬的同事 Theo Sommer。