摘要

  • Deutsche Telekom 计划在 T Cloud 上运行 Codesphere，并选择兼具主权要求与较大算力、存储需求的应用进行测试。
  • 基础设施可以更换，不代表共同软件层的许可、维护和业务依赖随之消失。

客户敢不敢把业务放进一朵新云，有时取决于以后能否离开。Deutsche Telekom 与 Codesphere 的合作，提供的正是这样一种进入理由：先把应用与底层基础设施之间的联系变得不那么专属，再争取客户把适合的工作负载交给 T Cloud。它改变的是采购中的承诺程度，而不是宣布依赖已经消失。

Deutsche Telekom 在9 月 10 日发布、由 Public Technologies 分发的公告中表示，Codesphere 将运行于 T Cloud，作为连接主权基础设施、现有超大规模云环境及本地数据中心的共同技术层。双方下一步要识别适合的应用，并在 T Cloud 上测试，优先考虑主权要求高、计算与存储需求也大的工作负载。这里的时间顺序很重要：这是面向客户项目的计划，不是已完成迁移的客户案例；公告也未给出通用套餐价格或完整兼容清单。

这并非 T Cloud 第一次接纳多云。Deutsche Telekom 的2025 年 9 月介绍已经把自身基础设施、超大规模云服务及迁移咨询放进同一个生态。新合作的意义在于，计划用一个共同的应用运行方式来衔接这些不同环境，而不是重新发明“欧洲云对抗外国云”的二选一叙事。

Codesphere 的技术说明把应用置于工作空间中，以资源池和网络存储组织运行，并列出受管 Kubernetes、虚拟机、裸金属等部署环境。平台还提供不同程度的托管方式，部分托管服务建立在开源框架和抽象层之上。这说明供应商打算如何减少环境差异，却不能替代本次合作中某个具体业务的迁移测试。

企业真正要搬走的，也不是一份能启动的代码。数据库状态、身份权限、网络连接、监控与恢复流程共同构成可用的业务。统一部署方式可能减少接入另一家基础设施供应商的工作量，但如果周边服务仍依赖原环境，应用“跑起来”与业务“搬过去”就是两件事。试点的价值，在于把这些差别暴露出来，而不是只展示一个成功启动的界面。

软件许可又是另一层问题。Codesphere 在数字主权说明页中称，其长期支持版本采用 Source Available License，并把相关功能开源列为未来计划。因此，不能因为底层用了开源组件，就把整个平台称为已经开源；也不能仅凭“源码可用”这几个字，推断客户拥有怎样的修改、再分发或独立维护权利。这些问题仍需由适用许可与支持安排回答。

对 T Cloud 而言，降低客户的进入顾虑，可能比要求客户一次性替换整个技术环境更有吸引力。对客户而言，选择增加是有价值的，但前提是知道哪些部分能够移动，哪些部分仍由共同平台组织，以及供应商关系变化后谁能继续把业务运行下去。