Canonical Targets Hyperscaler Lock-In With Sovereign Open-Source Stack

Monarchs in the Sky: Building Sovereign AI Clouds with Open Source Tools With Canonical — Ai4

Ai4

Building an enterprise sovereign AI cloud requires enterprise-hardened open-source tools to guarantee compliance and code ownership without succumbing to the integration failures of DIY maintenance.

AI-assisted summary of Monarchs in the Sky: Building Sovereign AI Clouds with Open Source Tools With Canonical — original source. Check the original for full context.

Source published: 2025-08-24

Detailed notes

## Background Published on YouTube by the Ai4 channel on August 24, 2025, this keynote features Stefano Fioravanzo, AI Product Manager at Canonical. The presentation outlines how organizations can construct sovereign AI clouds and manage end-to-end MLOps pipelines using Canonical's open-source infrastructure stack to ensure data sovereignty, compliance, and freedom from vendor lock-in.

## TL;DR Stefano Fioravanzo examines the industry transition from cost-driven cloud repatriation to sovereign AI clouds built for regulatory compliance, security, and strategic IP control. He walks through the complete open-source AI architecture—spanning hardware virtualization, Ceph storage, Kubernetes, and data tools like Kubeflow and Spark—exemplified by the European Space Agency's mission-critical ground operations. Finally, he outlines the severe maintenance, integration, and security hurdles of do-it-yourself open source, presenting Canonical's hardened upstream distributions and enterprise support as the solution for production-grade sovereign AI.

## Atmosphere & style The session maintains a pragmatic, engineering-focused tone, deliberately bypassing market hype to dissect the technical realities of infrastructure ownership. Fioravanzo delivers a calm, authoritative presentation that feels like an architectural strategy briefing tailored for enterprise leaders. The narrative moves smoothly from high-level regulatory motivations down into tangible open-source friction points, offering a grounded and realistic perspective on scaling production AI.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=4s) Evaluating open-source software for AI infrastructure is a pragmatic operational decision focused on lifecycle management, control, and architectural tradeoffs rather than ideology. - [01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) The conversation around cloud repatriation has evolved into the sovereign AI cloud, driven by regulatory compliance, IP ownership, and security rather than cloud costs alone. - [01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) A sovereign AI cloud guarantees that an organization retains full governance and control over its training datasets, model weights, pipelines, and inference endpoints. - [03:03](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=183s) AI infrastructure stacks must be architected top-down, using application workloads to dictate compute scheduling, orchestration, and storage requirements. - [03:03](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=183s) While open-source tools exist for every layer of the AI stack, integrating them cleanly both horizontally across workloads and vertically down to hardware remains a critical challenge. - [06:15](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=375s) Adopting open-source foundations provides deep code transparency, regulatory auditability, cost predictability, and access to rapid community innovation. - [07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) Mission-critical deployments, such as the European Space Agency's ground operations, require sovereign infrastructure built for zero downtime, full code auditability, and multi-decade longevity. - [07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) ESA's production sovereign stack combines Kubernetes and Ceph at the infrastructure level with Kubeflow, Apache Spark, Kafka, and PostgreSQL for MLOps and telemetry processing. - [11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) DIY open-source architectures face severe operational hurdles, including integration friction, continuous CVE tracking and patching, tool fragmentation, and a lack of enterprise support SLAs. - [13:30](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=810s) Canonical bridges the DIY open-source gap by delivering enterprise hardening, security patching, and full-stack support from bare-metal provisioning and Kubernetes up to MLOps platforms. - [15:29](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=929s) Successfully running sovereign AI at scale requires solving foundational engineering hurdles in distributed storage throughput, cluster observability, and dynamic GPU fleet scheduling.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=4s) Rethinking the AI Stack: Beyond Ubuntu and Hype

Stefano Fioravanzo introduces himself as an AI Product Manager at Canonical. While Canonical is universally recognized as the publisher of Ubuntu—one of the world's most widely adopted open-source operating systems—the scope of its engineering spans far deeper across the modern infrastructure stack. Setting aside high-level analyst reports, market forecasts, and generalized AI hype, Fioravanzo frames the discussion around a practical technical question: how organizations should evaluate open-source software when architecting their core AI infrastructure.

Building an AI cloud requires balancing technological autonomy against operational reality. Evaluating open source is not merely an ideological preference, but a pragmatic calculation of architectural tradeoffs, lifecycle management, and infrastructure control.

[01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) From Cloud Repatriation to the Sovereign AI Cloud

Over the past several years, the concept of "cloud repatriation"—migrating workloads, models, and data back from hyperscalers into an organization's private "inner garden"—gained significant traction, initially driven by unpredictable and escalating cloud bills. However, cost is no longer the sole or even primary catalyst for infrastructure shifts. The industry conversation has matured toward the broader paradigm of the "sovereign AI cloud."

```mermaid flowchart TD accTitle: Drivers of Sovereign AI Cloud Adoption A["Sovereign AI Cloud"] --> B["Regulatory Compliance (Data residency, ethics, AI acts)"] A --> C["Strategic Independence (No hyperscaler lock-in, long-term asset ownership)"] A --> D["Security & Artifact Control (Full ownership of data, models, & endpoints)"] A --> E["Cost Predictability (Elimination of runaway multi-tenant cloud fees)"] ```

Fioravanzo defines a sovereign AI cloud as an infrastructure environment where "data workloads and governance remain fully under the control of the organization align with the national industry or corporate sovereignty rules." This shift is propelled by three major forces:

- **Evolving Global Regulations:** Stringent mandates governing data residency, user privacy, and ethical AI operations require organizations to prove where data resides and how automated systems process it. - **Strategic Asset Ownership:** Relying entirely on proprietary cloud vendors creates long-term operational dependency, whereas sovereign stacks guarantee that models, pipelines, and underlying IP remain organizational property. - **Security and Governance:** Complete control over the entire lifecycle of model artifacts, training datasets, and inference endpoints prevents unauthorized upstream telemetry or black-box data handling.

[03:03](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=183s) Architecting from Use Cases to Infrastructure Layers

Designing an AI cloud requires starting from the top of the stack: the specific organizational use cases determine the architectural requirements of every underlying tier. Whether an enterprise is running traditional machine learning, large-scale streaming data pipelines, or distributed generative AI applications, each workload imposes distinct demands on compute scheduling, storage throughput, and orchestration.

```mermaid flowchart TD accTitle: Layered Sovereign AI Cloud Architecture UC["Use Cases & Applications (GenAI, LLMs, Traditional ML, Big Data Analytics)"] MLOPS["MLOps & Data Pipelines (Kubeflow, MLflow, Spark, Kafka)"] ORCH["Container & Cluster Orchestration (Kubernetes)"] INFRA["Cloud Infrastructure & Virtualization (OpenStack, Bare-Metal Provisioning)"] HW["Hardware, Storage & Compute Fleet (Ceph, High-Speed Networking, GPUs/Accelerators)"]

UC --> MLOPS MLOPS --> ORCH ORCH --> INFRA INFRA --> HW ```

From a high-level architectural view, open source can supply robust, production-grade tools for every layer of this stack. However, the operational challenge lies in ensuring that these independent software layers integrate cleanly both horizontally (across workloads) and vertically (from bare metal up to the data science workbench).

[06:15](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=375s) The Strategic Advantages of Open Source Adoption

Adopting an open-source foundation yields specific architectural and operational benefits that proprietary platforms cannot match:

- **Total Code Transparency and Visibility:** Teams possess unhindered visibility into how software runs, how it handles data, and how components interface across the stack. - **Deep Auditability and Compliance:** Organizations can introspect and audit every line of source code, which is essential for regulated industries requiring proof of algorithmic and data integrity. - **Cost Efficiency:** Replacing proprietary multi-vendor licensing models with open platforms removes compounding software tax across scaling environments. - **Uncapped Community Innovation:** Open source enables organizations to incorporate cutting-edge advancements engineered across the broader global developer ecosystem without waiting for single-vendor roadmaps.

[07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) Case Study: European Space Agency (ESA) Ground Operations 2030

To illustrate open-source sovereignty in mission-critical environments, Fioravanzo highlights the European Space Agency (ESA). ESA manages hundreds of satellites, ground radio stations, and complex telemetry networks, with a strategic mandate to double its ground operations throughput by 2030. Powering infrastructure spanning from orbit to ground stations requires an architecture engineered around three non-negotiable pillars:

```mermaid flowchart LR accTitle: ESA Sovereign Stack Architecture subgraph Storage & Base Infrastructure K8s["Kubernetes (Container Orchestration)"] Ceph["Ceph (Distributed Object/Block Storage)"] end subgraph Data & Message Brokering Spark["Apache Spark (Big Data Processing)"] Kafka["Apache Kafka (Event Streaming)"] PG["PostgreSQL (Relational State)"] end subgraph MLOps KF["Kubeflow (ML Pipelines & Lifecycle)"] end

K8s --> KF Ceph --> KF Ceph --> Spark Kafka --> Spark PG --> KF ```

- **Continuous High Availability:** Mission systems cannot tolerate instability or dropped telemetry: "you cannot definitely... take the rug from under a satellite—that needs to work constantly." - **Full Code Auditability:** For national security and scientific integrity, ESA must maintain complete ownership and transparency over every binary running across its ground stations. - **Decade-Scale Longevity:** Space infrastructure must operate reliably across 10, 15, or 20-year operational horizons without facing forced vendor deprecations or sudden paradigm shifts.

To meet these requirements, ESA built its internal cloud entirely on open-source foundations. The agency deployed Kubernetes for container orchestration and Ceph for distributed, multi-tier storage. At the application and data layers, ESA runs Kubeflow for end-to-end MLOps pipelines, Apache Spark for large-scale distributed data processing, Apache Kafka for real-time telemetry streaming, and PostgreSQL for relational databases.

[11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) The Reality Check: Hidden Challenges of DIY Open Source

While an open-source architecture looks clean on a design diagram, attempting a do-it-yourself (DIY) assembly in production introduces severe friction points:

- **Integration Complexity:** Disparate open-source projects are rarely designed out-of-the-box to interface seamlessly with one another, requiring significant custom glue code and maintenance. - **Security Vulnerability Management:** Rapid upstream open-source innovation creates continuous security maintenance burdens. Organizations must independently track, patch, and verify zero-day CVEs across dozens of decoupled projects. - **Enterprise Support Deficits:** In the event of a cluster failure or software regression impacting live systems, community forums cannot replace strict SLA-backed support: "who am I going to call so that the issue gets fixed within an hour or within a day?" - **Choice Overhead and Ecosystem Fragmentation:** With hundreds of overlapping open-source tools across the MLOps and data landscapes, selecting, vetting, and maintaining the right components incurs massive operational overhead.

[13:30](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=810s) Canonical's Approach: Full-Stack Upstream Hardening and Support

Canonical addresses the operational complexity of open-source architectures by providing enterprise packaging, security patching, and lifecycle support across the entire software delivery pipeline. Rather than limiting its scope to the operating system, Canonical maintains an integrated ecosystem that spans:

- **Infrastructure and Storage:** Bare-metal provisioning with MAAS, cloud infrastructure virtualization with OpenStack, and distributed software-defined storage via Ceph. - **Orchestration:** Production-grade, upstream-aligned Kubernetes distributions. - **Data and MLOps Applications:** Hardened, supported distributions of Kubeflow, Spark, Kafka, and PostgreSQL.

Canonical delivers these solutions directly aligned with upstream codebases while guaranteeing long-term security maintenance, automated updates, and 24/7 enterprise support SLAs. This eliminates the traditional compromise between open-source flexibility and enterprise reliability.

[15:29](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=929s) Key AI Infrastructure Pillars and Canonical at Booth 353

Designing a sovereign, production-grade AI cloud requires solving complex infrastructure challenges across several core engineering domains:

- High-throughput, distributed storage architectures optimized for parallel training datasets. - End-to-end observability and telemetry across heterogenous clusters. - GPU fleet management, dynamic accelerator slicing, and advanced workload scheduling.

Fioravanzo concludes by inviting engineering leaders and architects to visit Canonical at booth 353 to discuss real-world strategies for architecting compliant, scalable, and sovereign AI platforms using hardened open-source tools.

## Notable quotes > [01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) data workloads and governance remain fully under the control of the organization align with the national industry or corporate sovereignty rules. — Stefano Fioravanzo

> [07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) you cannot definitely... take the rug from under a satellite—that needs to work constantly. — Stefano Fioravanzo

> [11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) who am I going to call so that the issue gets fixed within an hour or within a day? — Stefano Fioravanzo

## Mentioned Stefano Fioravanzo, Canonical, Ubuntu, European Space Agency (ESA), Kubernetes, Ceph, Kubeflow, MLflow, Apache Spark, Apache Kafka, PostgreSQL, OpenStack, MAAS

## Video description Stefano Fioravanzo, AI Product Manager, Canonical

Abstracts

As AI workloads scale and regulations tighten, organizations are under pressure to deploy machine learning with full control over data, infrastructure, and compliance. In this keynote, discover how to build a sovereign AI cloud using Canonical’s open-source MLOps platform and infrastructure stack. Learn how to orchestrate end-to-end ML pipelines, integrate secure container technologies, and automate operations across hybrid and multi-cloud environments. We’ll dive into real-world strategies for achieving data sovereignty, eliminating vendor lock-in, and running production-grade AI at scale with open source at the core.

[Source](https://www.youtube.com/watch?v=OMUWD4KbnOk)

中文简报

Canonical推出主权开源技术栈，直击超大规模云厂商锁定构建企业主权AI云需要经过企业级加固的开源工具，以确保合规性与代码所有权，同时避免陷入自行维护所导致的集成失败。 Stefano Fioravanzo 分析了行业从成本驱动的云回迁向为监管合规、安全和战略性知识产权控制而构建的主权AI云的转变。他详细梳理了完整的开源AI架构——涵盖硬件虚拟化、Ceph存储、Kubernetes以及Kubeflow和Spark等数据工具，并以欧洲航天局的关键任务地面操作为例。最后，他概述了自行维护开源软件所面临的严重维护、集成与安全难题，指出Canonical经过加固的上游发行版和企业级支持是实现生产级主权AI的解决方案。评估用于AI基础设施的开源软件是一项务实的运营决策，重点在于生命周期管理、控制力与架构权衡，而非意识形态。 (0:04) 围绕云回迁的讨论已演变为主权AI云，其驱动因素是监管合规、知识产权所有权和安全性，而不仅仅是云成本。 (1:18) 主权AI云可确保组织对其训练数据集、模型权重、流水线和推理端点保留完全的治理与控制权。 (1:18) AI基础设施栈必须自顶向下设计架构，由应用工作负载来决定计算调度、编排和存储需求。 (3:03) 尽管AI栈的每一层都存在开源工具，但在横向跨工作负载和纵向深入硬件两方面将它们干净整洁地集成起来，仍是一项严峻挑战。 (3:03)

Reading summary

Canonical AI Product Manager Stefano Fioravanzo argues that enterprises are moving beyond basic cloud repatriation toward sovereign AI clouds built on open source to protect core intellectual property, satisfy regulations, and curb costs. However, capitalizing on open source requires addressing the severe operational, integration, and security hurdles of do-it-yourself infrastructure. Drivers Behind the Sovereign AI Cloud Shift (1:18) While cloud repatriation initially emerged as a reaction to unpredictable cloud bills, Fioravanzo emphasizes that the broader transition toward sovereign AI clouds is propelled by strategic necessity rather than cost alone. He defines a sovereign AI cloud as an infrastructure where data, workloads, and governance remain completely under the organization's control, adhering directly to national, industry, or corporate mandates. This shift is catalyzed by three major priorities: complying with evolving global privacy and ethical AI regulations, preventing long-term operational dependency on proprietary hyperscalers, and maintaining full governance over data pipelines, model artifacts, and inference endpoints without upstream telemetry leaks. Full-Stack Architecture and Open-Source Strategic Value (3:03) Architecting an AI cloud requires designing downward from specific use cases to determine the underlying orchestration, virtualization, and hardware tiers. Fioravanzo notes that open-source software provides enterprise-grade tooling across every layer, including bare-metal provisioning, Ceph storage, Kubernetes orchestration, and data frameworks such as Kubeflow, Apache Spark, and Kafka. According to Fioravanzo, open source delivers strategic advantages proprietary platforms cannot match: complete code visibility, deep auditability for regulated environments, the elimination of compounding licensing taxes, and immediate access to community-driven innovation without dependence on single-vendor roadmaps. Mission-Critical Validation: ESA Ground Operations 2030 (7:39) To demonstrate open-source sovereignty in high-stakes settings, Fioravanzo highlights the European Space Agency (ESA), which operates hundreds of satellites and plans to double its ground operations throughput by 2030. Operating space systems demands non-negotiable standards: uninterrupted high availability, total code auditability for scientific and national security, and 10- to 20-year operational longevity without vendor-enforced deprecation. To fulfill these demands, ESA deployed an internal cloud using Kubernetes and Ceph for container orchestration and distributed storage, layered with Kubeflow, Apache Spark, Apache Kafka, and PostgreSQL to manage live telemetry streams and machine learning workflows. Operational Hurdles of DIY Open Source (11:01) Despite the conceptual strength of open-source architectures, Fioravanzo warns that do-it-yourself (DIY) deployments face severe production friction. Organizations often struggle with significant integration overhead to glue disparate projects together, intense security maintenance to patch upstream zero-day CVEs, and decision fatigue stemming from ecosystem fragmentation. A primary vulnerability is the absence of enterprise support during critical outages, where community forums cannot substitute for contractual service-level agreements. Fioravanzo explains that Canonical counters these risks by delivering enterprise-hardened, upstream-aligned distributions with automated patching and 24/7 SLA-backed support across the entire stack, from bare metal up to MLOps tooling. Fioravanzo concludes that achieving true technological sovereignty requires solving low-level engineering challenges, such as high-throughput storage, dynamic GPU scheduling, and cross-cluster telemetry. While open source offers the only viable path away from vendor lock-in, long-term success hinges on enterprise-grade maintenance and hardening rather than unmanaged DIY assembly.

精炼阅读摘要

Canonical 的 AI 产品经理 Stefano Fioravanzo 指出，企业构建主权 AI 云的核心驱动力已从单纯削减云支出的“云遣返”转向对合规性、资产所有权与安全治理的长期战略掌控；尽管开源技术为全栈自主权提供了可行路径，但企业必须在架构控制与运维现实之间权衡，化解自主拼装带来的复杂性与支持缺失挑战。从成本控制到数据主权与治理驱动 (1:18) 过去几年中，将工作负载与数据从超大规模公有云迁回本地的“云遣返”现象，最初主要由不可预测且持续攀升的云账单推动。然而 Fioravanzo 强调，成本不再是驱动架构转型的唯一或首要诱因，产业关注的焦点已演化为范围更广的“主权 AI 云”。根据其定义，主权 AI 云是指数据、工作负载与治理权完全由组织掌控，并严格契合国家、行业或企业自身主权监管规则的基础设施环境。推动主权 AI 云落地的三大核心支柱包括合规性、资产所有权与安全治理。在全球层面，日益严苛的数据驻留、隐私与伦理法规要求机构能够清晰证实数据流向与算法处理机制；在战略层面，完全依赖闭源云厂商会导致长期的运营绑定，而自主堆栈能确保模型、处理管道及底层知识产权归组织所有；在安全层面，全面掌控模型产物、训练集与推理端点的生命周期，可从底层规避未授权的上游遥测与黑盒数据风险。分层架构设计与开源软件的战略价值 (3:03) 主权 AI 云的工程设计必须自顶向下展开，由具体的业务用例决定底层每一层技术架构的配置标准。无论是传统机器学习、大规模流式数据分析还是分布式生成式 AI，不同场景对底层硬件加速、算力调度和存储吞吐量均有异构需求。完整的技术栈自底向上涵盖底层硬件与 Ceph 分布式存储、OpenStack 与裸机虚拟化基础设施、Kubernetes 容器编排层、Kubeflow 与 Spark 等 MLOps 及数据处理管道，并最终承载顶层模型与应用。在整体架构中，开源软件在每一层级均具备达到生产级标准的成熟工具。相较于专有闭源方案，采用开源技术能为企业带来特定的战略优势：代码完全透明使团队对数据交互和系统运行拥有全方位的可视性；开放源码为强监管行业提供了深度审计算法与数据完整性的手段；开源架构消除了随规模扩大而累积的多厂商商业软件许可税；此外，组织可直接融入全球开发者社区的前沿创新成果，摆脱受制于单一厂商产品路线图的被动局面。欧洲航天局案例：长周期与高可用验证 (7:39) 为阐明开源方案在严苛关键任务中的应用成效，Fioravanzo 以欧洲航天局（ESA）地面运营 2030 计划为例进行了剖析。ESA 负责管理数百颗在轨卫星、地面无线电基站及遥测网络，其战略目标是在 2030 年前将地面运营吞吐量翻倍。支撑这一跨越轨道与地面的系统依托于三大核心指标：其一为极致的高可用性，卫星通信系统无法承受任何遥测中断或系统停机；其二为全代码可审计性，基于科研与安全考量，地面站运行的每行二进制程序均需具备完全所有权；其三为跨越 10 年至 20 年的超长生命周期，必须防范专有软件商业策略变化带来的强制下线风险。为达成上述技术指标，ESA 完全基于开源组件搭建了其内部云平台。在底层调度与存储方面，该机构部署了 Kubernetes 进行容器集群编排，并利用 Ceph 支撑多层分布式存储；在数据流与模型生命周期管理方面，ESA 采用 Apache Kafka 处理实时遥测数据流，使用 Apache Spark 运行大规模分布式计算，借助 PostgreSQL 维护关系型状态，并通过 Kubeflow 驱动全生命周期的 MLOps 流程，成功验证了开源技术在关键科学工程中的承载力。自主组装的现实挑战与企业级加固路径 (11:01) 尽管全开源架构在技术图纸上表现优异，但企业若尝试以纯自主（DIY）模式在生产环境中组装，将面临严峻的工程壁垒。各类独立的开源项目缺乏开箱即用的协同设计，横向与纵向集成往往需要消耗海量的定制化胶水代码；上游社区的快速迭代带来了沉重的安全修补负担，维护团队必须自行跟踪并修复数十个解耦项目中的零日漏洞（CVE）；当核心生产集群出现故障时，缺乏商业 SLA 保障的社区支持无法满足紧急恢复的时效需求；此外，海量重叠的 MLOps 工具也造成了沉重的选型开销与生态碎片化。针对此类运维痛点，Canonical 提出的应对路径是在严格遵循上游代码的前提下，提供贯穿整个交付链条的企业级打包、安全加固与全周期运维支持。其支持矩阵涵盖 MAAS 裸机配置、OpenStack 云化、Ceph 存储、生产级 Kubernetes，以及经过加固的 Kubeflow、Spark、Kafka 和 PostgreSQL 发行版。通过将上游创新与 24/7 企业级 SLA 结合，企业得以在保留开源技术主权的同时，规避自主搭建带来的运维脆弱性。构建生产级主权 AI 云需要解决高吞吐分布式训练存储、全链路异构集群遥测以及 GPU 算力动态切分调度等具体工程课题。Fioravanzo 认为，主权 AI 并非一种意识形态倡导，而是一系列具体的架构权衡；开源技术提供了摆脱云厂商锁定的路径，但企业若要确保生产可用性与合规寿命，必须跨越未受保障的 DIY 模式，转向经过企业级加固与长期维护的技术体系。

Detailed notes — zh

## Background 该内容由 Ai4 频道于 2025 年 8 月 24 日发布在 YouTube 平台上。页面描述指出，Canonical 的 AI 产品经理 Stefano Fioravanzo 在本次演讲中探讨了如何利用 Canonical 的开源 MLOps 平台与基础设施技术栈构建主权 AI 云，以实现端到端机器学习流水线编排、数据主权保障并规避供应商锁定。 ## TL;DR 演讲围绕“主权 AI 云”的定义与核心驱动力展开，分析了企业在面对公有云成本失控与合规监管趋严时转向自主可控基础设施的必然性。Stefano 系统梳理了从硬件裸机、Kubernetes/Ceph 基础设施层到 Kubeflow 等 MLOps 层的全栈开源架构设计，并以欧洲航天局（ESA）构建长期高可靠基础设施的真实案例验证了纯开源方案的可行性。最后，他客观指出了开源生态碎片化与安全维护等工程挑战，并介绍了 Canonical 如何通过精选上游组件并提供企业级安全加固与技术支持，帮助组织落地自主可控的 AI 云。 ## Atmosphere & style 整场演讲呈现出务实、清晰且极具工程理性的专业技术风格。讲者摒弃了浮夸的行业黑话与市场宣发套路，以平静稳重且条理分明的语调，将抽象的架构设计与现实中的权衡取舍层层拆解。在分享 ESA 实战案例与直面开源技术缺陷时，展现出严谨求实的态度，给观众带来一种高度可信、聚焦生产落地实践的专业研讨体验。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=4s) 企业规划与设计 AI 技术栈时，开源软件在掌握控制权、成本效益与长期演进中起到决定性作用。 - [01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) 从早期的“云遣返”演进至“主权 AI 云”，核心要求是组织对数据、工作负载与治理体系保持完全掌控，并符合国家与行业法规。 - [02:05](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=125s) 公有云成本失控、全球合规与数据驻留监管收紧，以及避免超大规模云厂商锁定的长期战略，是推动主权 AI 云发展的核心驱动力。 - [04:33](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=273s) 现代开源生态已经具备覆盖从底层裸机、存储（Ceph）、虚拟化/编排（OpenStack/Kubernetes）到数据平台与 MLOps（Kubeflow）的全栈能力。 - [06:12](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=372s) 开源技术栈能够赋予企业源码级透明度、彻底的代码合规审计能力，并免除层层专有商业授权费用的束缚。 - [07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) 欧洲航天局（ESA）以始终可用、完全可审计与数十年长期扩展性为核心支柱，采用全套开源栈成功重构了支持数百颗在轨卫星的地面操作云平台。 - [09:20](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=560s) ESA 实战采用 Kubernetes、Ceph、Kubeflow、Spark、Kafka 和 PostgreSQL 等纯开源组件，实现了跨组件的大规模互联与自主掌控。 - [11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) 直接拼装开源软件面临多组件集成摩擦、安全漏洞时效不稳定、生态碎片化以及缺乏企业级紧急 SLA 生产支持的重大挑战。 - [13:30](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=810s) Canonical 不仅提供 Ubuntu，还通过 MAAS、OpenStack、Ceph 及上游对齐的 Kubeflow 等工具，为企业提供从裸机到底层存储再到 MLOps 的端到端安全加固与商业支持。 - [15:29](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=929s) 构建生产级主权 AI 云是涵盖算力调度、统一存储底座与全栈可观测性的系统工程，借助成熟开源方案可在不牺牲控制力与安全性的前提下实现生产级扩展。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=4s) 开场与主旨：构建主权 AI 云的关键考量 Canonical 公司的 AI 产品经理 Stefano Fioravanzo 登台开场。他提到许多人熟知 Canonical 是因为其推出了广受使用的开源操作系统 Ubuntu，但其实 Canonical 在 Ubuntu 之外还涵盖了非常丰富的技术版图。Stefano 表示，本次演讲不打算引用花哨的市场数据或冗长的新技术趋势报告，因为大家齐聚一堂的目的显而易见——都是为了利用 AI 构建令人兴奋的应用与技术。这次演讲的核心聚焦于：在规划与设计企业的 AI 技术栈时，评估开源软件（Open Source）究竟有多关键。他将围绕基于开源构建 AI 云（AI Cloud）所带来的核心优势、权衡取舍以及架构考量展开系统梳理。 ### [01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) 从“云遣返”到“主权 AI 云”的定义与驱动因素回顾过去几年的行业趋势，Stefano 指出“云遣返（Repatriation）”曾是一个高频词汇，即企业将工作负载、数据与模型从公有云迁回内部花园（On-Premises / 私有基础设施）。虽然“遣返”这个词在今年听起来已经不再那么时髦，但取而代之的是一个更加核心的概念——**主权云（Sovereign Cloud）**。 Stefano 给出了他对主权 AI 云的定义：“主权 AI 云是一种 AI 基础设施，其中数据、工作负载与治理机制完全保留在组织的掌控之下，并与国家、行业或企业自身的自主权规则保持一致。”（"a sovereign AI cloud is an AI infrastructure where data workloads and governance remain fully under the control of the organization align with the national industry or corporate sovereignty rules."）驱动组织走向主权 AI 云的因素主要包括： - **成本控制失衡**：过去公有云是主要选择，但随着实验和团队规模扩大，公有云的支出估算与管理往往失控。 - **全球合规与监管收紧**：近几年全球各地密集出台政策法规，对数据安全、数据驻留（Data Residency）以及 AI 系统的伦理规范提出了严苛要求。 - **长期战略与所有权**：与超大规模云厂商（Hyperscalers）或闭源供应商绑定的架构，决定了未来模型和数据的归属权。 - **端到端安全性与控制力**：组织需要对数据生命周期、模型工件（Artifacts）以及端点服务拥有完全的控制与安全保障。 ### [04:33](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=273s) 俯瞰 AI 云架构的分层与开源全栈覆盖在规划 AI 云时，必须从实际业务用例（Use Cases）出发反推架构设计。无论是传统的机器学习（Traditional ML）、大数据流处理（Big Data Streaming），还是新兴的生成式 AI（GenAI）应用，不同的场景都会深刻影响底层到上层的架构选型。从万英尺高空（10,000-foot view）俯瞰，AI 云可以划分为一个清晰的分层体系。Stefano 强调，幸运的是当今的开源生态已经能够覆盖技术栈中从底层到上层的每一个层级。 ```mermaid flowchart TD accTitle: AI Cloud Layered Architecture subgraph AppLayer ["应用与业务层 (Use Cases)"] A["传统机器学习 / 大数据 / 生成式 AI (GenAI)"] end subgraph MLOpsLayer ["MLOps 与数据平台层"] B["MLOps 管道 (Kubeflow)"] C["分布式计算与消息队列 (Spark / Kafka / Postgres)"] end subgraph InfraLayer ["基础设施与编排层"] D["容器编排 (Kubernetes)"] E["虚拟化与基础设施管理 (OpenStack)"] F["统一存储底座 (Ceph)"] end subgraph HardwareLayer ["硬件与裸机底座"] G["裸机网络 / GPU 集群调度 / 存储硬件"] end AppLayer --> MLOpsLayer MLOpsLayer --> InfraLayer InfraLayer --> HardwareLayer ``` 采用开源构建技术栈的核心价值包括： - **代码完全透明与控制权**：不仅能掌握每一行代码的运行逻辑与交互方式，还能在水平跨组件与垂直跨层级间获得绝对的升级与集成主导权。 - **合规审计能力**：支持对源代码进行彻底的代码审计（Audit）与内省剖析。 - **规避高昂授权成本**：摆脱来自不同专有供应商层层叠加的昂贵 License 授权费。 - **全球社区的持续创新**：借助广泛的开源社区力量，快速吸纳前沿技术。 ### [07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) 实战案例：欧洲航天局（ESA）的主权 AI 基础设施重构为了证明开源主权云的可行性，Stefano 分享了欧洲航天局（ESA，相当于欧洲的 NASA）的真实案例。ESA 设定了一个雄心勃勃的目标：到 2030 年将其地面操作（Ground Operations）处理能力翻倍。ESA 需要统一管理数百颗在轨卫星与庞大的地面无线电台网络，要求支撑天地互联的基础设施具备极致的扩展性。在重构内部云平台时，ESA 确立了三大核心支柱： 1. **始终可用与高可靠性（Always Available）**：地面系统绝对不能掉链子，卫星运行容不得任何服务中断。 2. **完全可审计与代码掌控（Fully Auditable）**：ESA 必须对运行的每一个比特和底层代码拥有 100% 的掌控力。 3. **长期可扩展性（Scalable for Decades）**：架构必须能够支撑未来 10 至 20 年的平滑演进，无法承受每隔几年就推翻重写流程或更换核心软件。最终，ESA 采用了一套纯开源的技术栈落地： - **容器编排**：Kubernetes - **统一存储**：Ceph（满足多种存储形态诉求） - **MLOps 平台**：Kubeflow - **大数据与数据流**：Apache Spark、Apache Kafka - **关系型数据库**：PostgreSQL 通过这种架构，ESA 成功在不同规模下互联各组件，完全满足了合规、长期演进与全自主掌控的需求。 ### [11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) 开源的“另一面”：碎片化、安全性与企业级支持挑战 Stefano 话锋一转指出，构建主权云并非“平台工程师在白板上画个架构图、把开源组件拼在一起就能直接上线生产”。开源在带来自由的同时，也伴随着显著的工程挑战与权衡： - **集成摩擦**：许多开源项目在初始设计时并未考虑过彼此之间的协同工作，缝合多组件往往存在阻碍。 - **安全漏洞与补丁时效**：开源社区虽然迭代极快，但也带来了漏洞不稳定性，企业难以单靠社区连续修复 Day-0 / 0-Day CVE 漏洞。 - **生产支持缺失**：在支撑航天或关键任务场景时，一旦发生系统崩溃或 Bug，社区无法承诺“1 小时或 1 天内必须修复解决”的企业级 SLA 支持。 - **选择过载（Choice Overhead）与生态碎片化**：仅在 MLOps 或数据领域，市面上就有上百种开源选项，选型与维护成本极高。 ### [13:30](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=810s) Canonical 的角色：从裸机到 MLOps 的端到端开源支撑 Canonical 在 ESA 等客户的转型过程中扮演了关键支撑角色——帮助组织挑选最适配的开源组件，并提供开箱即用、安全加固（Security Hardened）且具备全生命周期支持的上游对齐版本（Upstream Flavor）。 Stefano 澄清，Canonical 的业务版图早已深入软件交付链的每一个环节： - **裸机配置与基础设施**：MAAS（裸机编排）、OpenStack（私有云虚拟机状态管理）。 - **底层网络与存储**：Ceph 等企业级软件定义存储与网络。 - **编排与运行环境**：Kubernetes 容器环境。 - **数据与 MLOps 软件**：主流的数据库、消息队列、数据流处理工具以及 Kubeflow。基础设施层（K8s、OpenStack、Ceph）的开源格局相对稳固，但应用层的软件种类繁多。Canonical 的策略是精选最广泛使用的优质开源软件，在尽可能保持贴近上游（Upstream）原生形态的前提下，为企业提供工业级的安全加固与长期商业支持。 ### [15:29](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=929s) 总结与展台互动构建生产级主权 AI 云是一项高度复杂的系统工程，涵盖了从存储底座、全栈可观测性（Observability）、GPU 集群算力调度与管理（GPU Fleet Management & Scheduling）等诸多细分领域。每一个子话题都足以支撑一场独立的演讲主题。 Canonical 致力于帮助企业在不牺牲可控性、安全合规与可扩展性的前提下，利用纯开源技术构建面向未来的主权 AI 基础设施。演讲最后，Stefano 邀请现场观众在会后直接交流，或前往展区 353 号展位（Booth 353）深入探讨开源 AI 云的架构设计与落地实践。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=4s) 许多人熟知 Canonical 是因为其推出了广受使用的开源操作系统 Ubuntu，但其实 Canonical 在 Ubuntu 之外还涵盖了非常丰富的技术版图。 — Stefano Fioravanzo > [00:04](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=4s) 本次演讲不打算引用花哨的市场数据或冗长的新技术趋势报告，因为大家齐聚一堂的目的显而易见——都是为了利用 AI 构建令人兴奋的应用与技术。 — Stefano Fioravanzo > [01:18](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=78s) a sovereign AI cloud is an AI infrastructure where data workloads and governance remain fully under the control of the organization align with the national industry or corporate sovereignty rules. — Stefano Fioravanzo > [04:33](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=273s) 幸运的是当今的开源生态已经能够覆盖技术栈中从底层到上层的每一个层级。 — Stefano Fioravanzo > [04:33](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=273s) 不仅能掌握每一行代码的运行逻辑与交互方式，还能在水平跨组件与垂直跨层级间获得绝对的升级与集成主导权。 — Stefano Fioravanzo > [07:39](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=459s) ESA 设定了一个雄心勃勃的目标：到 2030 年将其地面操作（Ground Operations）处理能力翻倍。 — Stefano Fioravanzo > [11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) 构建主权云并非“平台工程师在白板上画个架构图、把开源组件拼在一起就能直接上线生产”。 — Stefano Fioravanzo > [11:01](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=661s) 在支撑航天或关键任务场景时，一旦发生系统崩溃或 Bug，社区无法承诺“1 小时或 1 天内必须修复解决”的企业级 SLA 支持。 — Stefano Fioravanzo > [13:30](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=810s) Canonical 的策略是精选最广泛使用的优质开源软件，在尽可能保持贴近上游（Upstream）原生形态的前提下，为企业提供工业级的安全加固与长期商业支持。 — Stefano Fioravanzo > [15:29](https://www.youtube.com/watch?v=OMUWD4KbnOk&t=929s) Canonical 致力于帮助企业在不牺牲可控性、安全合规与可扩展性的前提下，利用纯开源技术构建面向未来的主权 AI 基础设施。 — Stefano Fioravanzo ## Mentioned Stefano Fioravanzo, Canonical, Ubuntu, 欧洲航天局 (ESA), NASA, Kubernetes, Kubeflow, Ceph, OpenStack, MAAS, Apache Spark, Apache Kafka, PostgreSQL ## Video description Stefano Fioravanzo, AI Product Manager, Canonical Abstracts As AI workloads scale and regulations tighten, organizations are under pressure to deploy machine learning with full control over data, infrastructure, and compliance. In this keynote, discover how to build a sovereign AI cloud using Canonical’s open-source MLOps platform and infrastructure stack. Learn how to orchestrate end-to-end ML pipelines, integrate secure container technologies, and automate operations across hybrid and multi-cloud environments. We’ll dive into real-world strategies for achieving data sovereignty, eliminating vendor lock-in, and running production-grade AI at scale with open source at the core. [Source](https://www.youtube.com/watch?v=OMUWD4KbnOk)

Source quotes

[0:04] Stefano Fioravanzo: 许多人熟知 Canonical 是因为其推出了广受使用的开源操作系统 Ubuntu，但其实 Canonical 在 Ubuntu 之外还涵盖了非常丰富的技术版图。 [0:04] Stefano Fioravanzo: 本次演讲不打算引用花哨的市场数据或冗长的新技术趋势报告，因为大家齐聚一堂的目的显而易见——都是为了利用 AI 构建令人兴奋的应用与技术。 [1:18] Stefano Fioravanzo: a sovereign AI cloud is an AI infrastructure where data workloads and governance remain fully under the control of the organization align with the national industry or corporate sovereignty rules. [4:33] Stefano Fioravanzo: 幸运的是当今的开源生态已经能够覆盖技术栈中从底层到上层的每一个层级。 [4:33] Stefano Fioravanzo: 不仅能掌握每一行代码的运行逻辑与交互方式，还能在水平跨组件与垂直跨层级间获得绝对的升级与集成主导权。 [7:39] Stefano Fioravanzo: ESA 设定了一个雄心勃勃的目标：到 2030 年将其地面操作（Ground Operations）处理能力翻倍。 [11:01] Stefano Fioravanzo: 构建主权云并非“平台工程师在白板上画个架构图、把开源组件拼在一起就能直接上线生产”。 [11:01] Stefano Fioravanzo: 在支撑航天或关键任务场景时，一旦发生系统崩溃或 Bug，社区无法承诺“1 小时或 1 天内必须修复解决”的企业级 SLA 支持。 [13:30] Stefano Fioravanzo: Canonical 的策略是精选最广泛使用的优质开源软件，在尽可能保持贴近上游（Upstream）原生形态的前提下，为企业提供工业级的安全加固与长期商业支持。 [15:29] Stefano Fioravanzo: Canonical 致力于帮助企业在不牺牲可控性、安全合规与可扩展性的前提下，利用纯开源技术构建面向未来的主权 AI 基础设施。

Source quotes

[1:18] Stefano Fioravanzo: data workloads and governance remain fully under the control of the organization align with the national industry or corporate sovereignty rules. [7:39] Stefano Fioravanzo: you cannot definitely... take the rug from under a satellite—that needs to work constantly. [11:01] Stefano Fioravanzo: who am I going to call so that the issue gets fixed within an hour or within a day?

Original transcript

[0:04] I'm Stephano. I'm a product manager at [0:05] Canonicle. You might know Canonicle [0:08] because we're uh the publishers of [0:10] Ubuntu, uh one of the most widely used [0:14] open-source operative systems. I hope by [0:16] the end of this presentation, you'll [0:18] also appreciate uh that we do many other [0:21] things at Canonical besides uh [0:23] publishing Auntu. Next slide, please. [0:28] Um so I don't want to give you fancy [0:32] numbers [0:34] uh um big uh you know uh uh reports on [0:40] AI and how much it is trending the new [0:43] technologies. Um it's obvious we're all [0:46] here because uh we want to build some [0:48] new exciting uh technologies with AI, [0:51] some new exciting applications. So the [0:53] focus of uh today's talk will be to kind [0:57] of evaluate how much opensource is [1:00] important and critical for you to think [1:03] about about and evaluate when designing [1:06] uh your AI stack. So we'll be looking at [1:08] some of the benefits, some of the [1:10] tradeoffs, some of the considerations [1:12] when building an AI cloud with open [1:16] source. [1:18] So during the last few years um I've [1:22] been hearing a lot about repatriation [1:25] um which probably is something you've [1:27] also been hearing about this concept of [1:30] moving away from the public cloud um [1:33] moving the workloads the data the models [1:37] um towards you know an uh inner garden [1:42] within your organization. Um probably [1:44] that term is not as sexy as it used to [1:46] be. this year. Um but um uh next slide [1:51] please. Um I've been also I've been [1:55] hearing more about the term sovereign [1:57] cloud. Um this is kind of a definition I [2:00] put together. It's not an official uh [2:03] definition. I think it's uh um fairly [2:06] accurate. If you don't agree with it, uh [2:08] we can discuss afterwards as well. To [2:10] me, a sovereign AI cloud is an AI [2:13] infrastructure where data workloads and [2:15] governance remain fully under the [2:17] control of the organization align with [2:19] the national national industry or [2:21] corporate sovereignty sovereignty rules. [2:25] Um, so that's quite a mouthful of a of a [2:29] definition. [2:31] I think there are um quite some quite a [2:35] few let's say driving factors that are [2:38] pushing organizations to think about [2:40] this. Um it used to be like the primary [2:43] factor used to be cost. Public cloud uh [2:46] can uh often time um be difficult to [2:50] manage in terms of cost estimate as [2:53] experiments and teams grow uh that gets [2:55] out of gets out of control. But there [2:58] are more uh driving factors. Uh next [3:02] slide. [3:03] Um starting from the regulations uh [3:07] you've all been you've all seen how in [3:09] the last couple of years um a lot of [3:13] political uh regulation have been [3:17] designed born um like around the globe [3:20] in terms of uh what you should think [3:23] about in terms of data security where [3:25] data lives or [3:28] um in terms of ethical ethical [3:31] considerations uh when designing ing a [3:34] an AI systems what you should you should [3:38] do about what you what you can do with [3:40] it what you do with user data uh how the [3:42] system should behave and things like [3:44] that in terms of strategy um how um [3:51] how you design your cloud in partner [3:54] with vendors or the hyperscalers define [3:58] um your long term long-term strategy who [4:01] will eventually uh own your data, your [4:04] model. Security in terms of and again [4:08] that concept of ownership and security [4:10] as well terms of who owns your data, who [4:14] has control over uh the life cycle of [4:18] your artifacts, the models, the [4:19] endpoint. So all of these factors kind [4:22] of are uh pushing all u to kind of uh [4:26] reconsider where uh the workloads run. [4:30] Next slide please. [4:33] So [4:35] when thinking about an AI cloud, I try [4:38] to take a step back and start from the [4:41] use cases [4:43] because the use cases define what you [4:46] eventually how your stack looks like. [4:48] you might depending on uh what your [4:51] organization needs could be traditional [4:54] machine learning um big data streaming [4:58] these new gen AI use cases and [5:01] applications [5:03] all of these have an influence into how [5:06] you design the layers uh of your stack [5:10] next slide please [5:13] and um [5:16] probably some of the lines are missing [5:17] here I see them. Um, so the way I like [5:22] to look at an AI cloud from a 10,000 [5:24] foot view, this is of course an overly [5:27] simplified uh version of of a stack, but [5:31] I think uh splitting it into a few [5:34] layers [5:36] uh kind of helps us figuring out like [5:39] reasoning about what are the various uh [5:43] uh building blocks and how then those [5:45] building blocks need to fit together. Of [5:48] course, each one of these lines um could [5:51] be addressed by one or many uh open- [5:55] source solutions. [5:56] Fortunately, today open source can [5:58] really address each and every one of [6:00] these layers. But there is complexity uh [6:03] in all of those both like at the lower [6:06] level and at the lower higher level in [6:08] terms of use cases and ML life cycle. [6:11] Next slide please. [6:15] So when adopting open source uh there [6:17] are several benefits um to doing that. [6:21] The first h the um first consideration [6:24] is when you adopt open source you have [6:26] full transparency over the code that [6:29] you're running how it is running. you [6:31] have the full visibility into how that [6:35] piece of software uh works and that [6:38] gives you a lot of control in terms of [6:41] how it behaves, how it works, how you're [6:44] upgrading it, how you make it work with [6:46] other um components both uh horizontally [6:51] across the stack but also uh vertically [6:54] in terms of uh how the various layers of [6:56] the stack uh work together. Open source [6:59] gives you um [7:03] more compliance benefits in terms of um [7:07] how you can audit the code. Look at it, [7:09] introspect it, uh break it down, cost [7:13] efficiency because you don't have to [7:14] rely on expensive vendor license fees [7:18] coming from all over the place from all [7:20] of the different components you've uh [7:22] pieced together in your stack. And of [7:24] course the community innovation because [7:26] uh uh open source is built by everyone [7:30] uh and that of course brings uh a lot of [7:33] benefits in terms of uh um innovation. [7:36] Next slide please. [7:39] So I want to bring you a real world [7:40] example before diving into a little bit [7:43] more details. So I is the European Space [7:47] Agency is the European counterpart to [7:50] NASA here. [7:53] um they have a very ambitious goal that [7:57] is to double their uh ground operations [8:01] uh by 2030. So ISA manages hundreds of [8:05] satellites, radio stations. [8:08] I know they do a bunch of very difficult [8:10] stuff. I'm not an aerospace engineer so [8:14] um I'll stop at that. Um but to power [8:18] all of that infrastructure [8:20] infrastructure from space to ground and [8:22] those all those interconnected pieces [8:24] they need infrastructure that can scale [8:27] that can support uh their needs. Next [8:31] slide please. So part of their [8:34] requirement when they started this uh [8:38] innovation process to rearchitect their [8:41] uh internal cloud was to build something [8:43] that would be on the one hand always [8:45] available because you can cannot [8:47] definitely put uh uh um take the rug [8:51] from under a satellite like that needs [8:53] to work constantly. Uh you can't have a [8:56] system that fails from time to time. It [8:58] needs to be always available and [9:00] reliable, fully auditable. Well, for the [9:03] same reasons, if you're ISA, uh you want [9:07] to have 100% [9:10] uh ownership of every last bit of code [9:13] that you're running. You want to really [9:16] be able to look down to the stock at the [9:18] every last uh line of code and really [9:21] have full control over it. And scalable. [9:23] Scalable in many ways. scalable in in [9:26] the sense that um ISA might want to [9:28] extend their data science teams. They [9:30] might want to include new technologies [9:32] over time and they need to have a system [9:35] that will work for 10, 15, 20 years down [9:39] the line. You cannot expect to start [9:41] changing processes and software that are [9:43] running uh on these large scale uh [9:46] interconnected systems uh three or four [9:49] or five years from now. Next, please. [9:54] So what is um to accommodate all of [9:58] these requirements what ISA decided to [10:00] do was uh to um approach uh the entire [10:05] um um software stack with open source [10:07] technologies. [10:09] They ended up using Kubernetes for [10:11] container orchestration, Seph for [10:14] various types of uh storage use cases [10:17] and on top of those Qflow for their MLOP [10:20] stack, Spark for big data and Kaf [10:24] posgress uh to handle the message cues [10:27] the relational databases [10:30] these components they've deployed these [10:32] components at various different scales [10:35] and inter connecting them in a way that [10:39] uh addresses their particular needs and [10:43] they could do that with the confidence [10:45] of respecting those three pillars that I [10:47] mentioned before and with the confidence [10:49] of being able to extend two additional [10:52] technologies to additional scale uh in [10:55] the future. Next please. [10:59] So [11:01] probably um or rather if um a [11:08] uh you might say okay this is just open [11:09] source probably um one is a platform [11:14] engineer at some point started drawing [11:16] uh some architecture diagram on a [11:18] whiteboard and they decided to deploy uh [11:20] bunch of open source components together [11:22] and call it a day production ready right [11:24] well not so fast next please Because [11:29] open- source although it has a lot of [11:32] benefits comes also with a bunch of uh [11:35] challenges and trade-offs. Well, [11:38] starting from [11:40] uh integrating [11:42] many different projects together that [11:44] maybe weren't designed to work together [11:46] in the first place or maybe just to some [11:48] extent but not exactly the way you [11:50] wanted them to. Um in terms of security, [11:54] unfortunately, uh open source is very [11:56] fast at innovating. there are a lot of [11:58] people contributing but that also brings [12:01] um a certain level of uh instability [12:04] from a vulnerability point of view. You [12:06] won't have people fixing uh day zero [12:10] CVES one day after the other. Um that [12:13] has repercussions also in terms of who's [12:15] going to support you when something [12:16] breaks. If I'm deploying something on a [12:19] satellite or a or a ground system that's [12:21] supporting satellite operations and I [12:24] have a bug or I have an instability [12:26] issue, who am I going to call so that [12:28] the issue gets fixed within an hour or [12:30] within a day? That's a problem. and the [12:36] wide variety of options that exist out [12:38] there bring also uh some let's say [12:41] fragmentation or choice overhead as I [12:44] call it because if I need a data [12:48] solution or an envelope solution what am [12:50] I going to pick from from the 100 [12:52] different options to leave out there [12:55] next please. [12:58] So going back to the previous diagram, I [13:00] added a few logos of popular open source [13:04] applications that uh are probably the [13:08] most widely used for those particular [13:12] uh use cases. Of course, this is not [13:14] comprehensive. There's a hundred times [13:16] more than that, but this these are just [13:19] uh uh some of the ones that Eza picked [13:21] and some of the ones that al also are [13:24] other customers we've we've seen they [13:26] prefer and like. Next, please. And what [13:30] we've been doing with with EZA was [13:31] exactly this uh supporting them in their [13:34] journey to choosing the right open [13:37] source technologies to use and providing [13:40] them with the version of these open [13:42] source technologies that are secure and [13:45] that are supported from the ground up. [13:48] Next, please. Because going back to my [13:52] first slide, that's what we do at [13:53] Canonical. We don't just distribute [13:55] Ubuntu but we tipped our toes into the [13:59] entirety of uh the software uh delivery [14:03] chain from uh bare metal provisioning to [14:07] VM state management to storage [14:10] networking [14:11] um data applications MLOps applications [14:15] we pick and choose the best open-source [14:18] software that is out there and then [14:21] provide support and uh security for that [14:26] in a in a flavor that is as close to the [14:28] upstream as possible. So that's why our [14:30] our customers choose us when they want [14:32] to operate open source in a production [14:35] way. Next please. [14:39] And that's also true for the [14:42] applications which if you look at [14:44] infrastructure management probably [14:46] that's a little bit easier because the [14:48] landscape is a little bit more [14:50] consolidated. Kubernetes for uh uh [14:53] container orchestration, open stack for [14:56] uh your infrastructure estate, seph for [14:59] storage among a few others. When it [15:02] comes to applications, it's hundreds, [15:06] thousands. So what we do is we pick the [15:10] most widely used but we continue [15:12] extending the portfolio [15:14] and supporting those upstream flavors [15:17] while guaranteeing the support and the [15:22] uh security hardening on that open [15:25] source. Next please. [15:29] So um going back to thinking about the a [15:32] the AI clouds [15:36] what I went through so far it's just [15:38] some of the considerations that you need [15:40] you need to think about when designing [15:43] uh your uh um your AI cloud. These are [15:48] let's say some very broad categories [15:51] from storage observability [15:54] GPU fleet management scheduling. Each [15:57] one of these items could probably [15:59] deserve its own uh keynote talk and [16:02] there are a lot of considerations in [16:03] terms of how you run these with open [16:05] source technologies and then how you [16:07] stack them all together uh so that you [16:09] can have uh a production grade uh [16:13] design. Um next please. And uh and [16:17] that's what we are here for. uh where um [16:20] you'll find us after the conference, [16:22] after the talk or um at the booth [16:26] showcase uh to discuss about open [16:28] source, discuss about these challenges, [16:30] the benefits and how you can think about [16:32] designing [16:34] for the future, for your data, for your [16:37] AI in a way that's compliant, that's [16:39] secure, that's scalable while using [16:42] open-source software and retaining the [16:44] control uh over uh your infrastructure. [16:48] Next, please. [16:50] So, yeah, booth 353. If you want to [16:53] discuss more about open source, you'll [16:55] find us there or right outside here [16:57] after the talk. Thank you.