过去几年,随着云原生应用普及与 Serverless 架构成熟,基础设施即代码(Infrastructure as Code,IaC)已经成为团队交付云端应用的标准实践。AWS CDK 与 CloudFormation 曾是很多团队的首选:它们把 AWS 资源的声明式配置和程序化组合能力带到了开发者手中。然而,当项目规模放大、复杂性上升、跨云或自定义需求增多时,CDK + CloudFormation 的许多设计弱点会逐渐显现。SST 团队最近宣布研发代号为 Ion 的新引擎,决定逐步从 CDK/CloudFormation 转向基于 Pulumi 和 Terraform provider 的实现,这背后反映出一系列值得每个工程团队关注的架构权衡与实践经验。以下从原理、实际问题、替代方案与迁移建议四个维度展开,帮助读者理解为何要"Moving Away from CDK",以及如何评估与执行类似的迁移决策。为什么要反思 CDK 和 CloudFormation 的组合?CDK 的出现给开发者带来了用熟悉语言构建云资源的便利,但它并不直接操作云 API,而是把代码转译为 CloudFormation 模板,然后交由 CloudFormation 服务在云端"黑盒"地执行。
这个二步模型产生两个核心后果:资源定义与部署执行被分离,部署的控制权和执行细节由 CloudFormation 掌握;CDK 在本质上是对 CloudFormation 的包装与 hack,很多语义实际上受制于 CloudFormation 的能力与限制。长期使用中,这些技术细节会演变成开发者和平台团队频繁面对的痛点。主要痛点与实践障碍首先是资源之间的链接和构建顺序问题。在 CDK/CloudFormation 模式下,许多资源的部署需要先生成并上传所需的资产(例如静态网站构建产物)。但如果资产的生成依赖其他尚未创建的云资源(例如 DynamoDB 表、配置参数等),就会陷入"先有鸡还是先有蛋"的两步部署困局,导致新环境初始化或跨环境部署需要多次推进,增加复杂度与出错率。循环依赖(cyclical dependencies)则是另一个典型问题。
某些场景看似可以在代码层面互相引用资源属性,但在 CloudFormation 的 JSON 模板表达能力下,这类互相引用会演变为无法解析的循环,部署失败。更麻烦的是,CDK 的抽象在不同场景下泄露 CloudFormation 的实现细节,例如对已有资源进行修改与新增资源之间的语义差异,令相似的代码在不同拆分成多栈(stack)时表现不同,引发难以直观理解的失败模式。另一个长期被抱怨的痛点是 CloudFormation 将部署过程做为一个黑箱服务运行,很多底层操作和错误信息被吞噬或模糊化。出现失败时,开发者常常只能从 CloudFormation 返回的笼统错误中猜测原因,或不得不跳到 CloudTrail 等审计日志中追溯原始事件,定位成本高、速度慢。为了解决 CloudFormation 无法在本地执行自定义逻辑的短板,社区大量使用自定义资源(Custom Resource)或 Lambda 驱动的"hack"来实现无法用 CloudFormation 模板表达的操作。尽管可行,这类做法带来新的问题:部署变慢、侧效应难以控制、回滚时容易陷入"回滚地狱",特别是自定义资源本身如果存在错误,会导致部署链路反复失败与停滞。
CloudFormation 的回滚机制初衷是保证资源一致性,但在实际生产更新中常常会导致长时间阻塞或无法自动恢复的怪异状态,这对连续交付和应急恢复非常不利。除此之外,CDK 试图在 CloudFormation 之上维护额外状态或上下文(例如 cdk.context.json),导致在 CI/CD 与多账户部署场景下出现双重构建、缓存失效与版本不一致的问题。模板里对资源数量的硬性限制、栈更名导致的"孤儿栈"与资源重建、以及将已有资源导入到 CloudFormation 中的复杂流程,都让大型团队在重构与扩展时付出很高的维护成本。为何现在要做出改变?这些问题并非一朝一夕,为什么 SST 团队选择在当前时点向外寻求替代?背后有几方面驱动因素。其一是生态与用户需求的演进。近年来除了 AWS,其他云和边缘 provider(如 Cloudflare)在性能与功能上快速进步,使得单纯依赖 CloudFormation 的方案在多云或混合云场景下成本高、灵活性差。
将所有外部 provider 凭借自定义资源集成到 CloudFormation 中往往是"墙上贴补丁"的做法,难以在长期维护与性能上令人满意。其二是产品化路径的推进。SST 随着 OpenNext 等工具成为 Next.js、Remix、SvelteKit 等前端框架在 AWS 上部署的重要路径后,资源链接、构建与即时开发体验的痛点从"偶发"变为"常见",直接影响用户体验与增长。其三是替代技术的成熟。Pulumi 与 Terraform provider 的组合提供了更直接的执行模型:Pulumi 的引擎可以运行在本地或 CI 中,并通过"bridged Terraform providers"直接调用已开源的 Terraform provider(这些 provider 基本就是对云 SDK 的封装)。与 CloudFormation 的黑箱式调用不同,这种模型在执行时直接调用 SDK,并在本地维护可控的状态文件,令调试、资源导入与错误可视化变得更直接。
Ion 是什么以及它如何解决问题Ion 是 SST 团队基于 Pulumi 引擎与 Terraform provider 的新一代部署引擎代号。它的核心思想是把"代码就是要直接被执行"的理念放回到 IaC 中:开发者写的 TypeScript 配置与组件直接驱动 Pulumi 引擎调用 Terraform provider,从而直接在 AWS(或其他 provider)上创建与更新资源,而不再经过先生成 CloudFormation 模板再由云端服务异步执行的中间步骤。这种方法带来若干关键优势。代码的执行顺序即为部署顺序,避免了资源依赖被模板"延迟解析"造成的隐性顺序错位问题。开发时可以更直观地控制资源创建、读取与修改的先后关系,减少两步部署与构建冲突。错误信息不再被 CloudFormation 模糊化,发生的异常可直接呈现在本地运行环境,研发与运维团队能更快地定位并修复问题。
自定义逻辑不再依赖云端 Custom Resource 的 Lambda 逃生舱,开发者可以在本地或部署 runtime 中运行动态 provider 或脚本,灵活性更高且更易测试。对资源导入、状态同步与多账户多区域部署的可控性显著提高。Ion 的实现细节也考虑到工程化的可行性:Pulumi 的 engine 嵌入到 SST CLI 中,无需用户额外安装 Pulumi 或 Terraform,部署时在本地生成状态文件并将其同步到 S3,以保证团队协作与 CI 的一致性。原有的 Terraform provider 是开源的,遇到 provider 局限可以通过提交 PR、临时 patch 或选择 fork 来进行修复或扩展,替代了面对 CloudFormation 黑箱无能为力的局面。迁移路径与实践建议把现有 CDK/SST 应用迁移到 Ion 并非零成本,SST 团队也清晰地划分了易迁移与难迁移的两类资源。低阶的 L1 CDK 构造(即以单一底层云资源为主的定义)通常可以在 Terraform provider 中找到相应的映射,迁移较为直接。
高阶的 CDK construct 或依赖大量自定义资源的方案则更复杂,这类抽象往往是基于 CloudFormation 的能力与黑魔法构建的,迁移时可能需要重新设计或放弃部分"不透明"的便利。如果团队大量依赖高阶 CDK 生态的现成组件,需要评估是否保留部分古老资源在旧体系中运行,或将它们拆分出可独立维护的模块逐步迁移。从工程实践层面,建议采取渐进式策略。首先将新项目或非关键路径的组件优先在 Ion 上试点,积累经验、补齐必要的 provider 补丁与部署脚本。对于核心生产环境,先在沙箱或预生产环境做一段时间双轨运行,验证状态同步、回滚行为与监控告警。迁移时重视资源导入流程:由于在 Ion 模式下可直接读取与控制状态,导入既有资源比 CloudFormation 更为可操作,但仍需做好校验与 drift 检查,避免意外替换或权限问题。
在组织层面,迁移还意味着团队需要提升对 provider 行为与 SDK 调用的理解,从而能快速定位问题并准备必要的 provider 补丁或临时 workaround。是否适合采用 Ion 与潜在风险Ion 不是万能灵药,也不是简单的"换引擎即解决所有问题"。对于明确全盘采用 AWS 且深度绑定 CDK 高阶构造、组织政策严格不允许引入外部 provider 行为的团队,短期内坚持 CDK + CloudFormation 依旧是可行的路径。另一类适合 Ion 的场景包括对部署速度、错误可见性、跨 provider 能力以及开发者本地体验有较高要求的团队,尤其是那些希望在同一配置文件中声明并链接多云资源的项目。技术风险方面,基于 Terraform provider 的实现仍然依赖于各 provider 的质量与维护度。遇到 provider bug 可能需要提交 PR、申请临时 patch 或 fork provider,团队需具备一定的维护与兼容工作能力。
Pulumi 与 Terraform 的许可、社区生态与未来演进也是需要关注的长期因素。最后,部署模型的改变会带来 CI/CD 管道、审计与合规流程的调整,合规团队需要评估本地状态文件、S3 同步与访问控制策略,以满足企业治理需求。结语:从黑箱到可控的演进是一场长期工程CDK 与 CloudFormation 在过去十年里为云平台普及做出了巨大贡献,但技术发展和用户需求推动了向更直接、更可控、更透明的部署模型演进。Ion 的出现代表一种理性的选择:放弃对 CloudFormation 黑箱的完全借用,回归到"代码直接执行、部署可观察"的IaC 本质。对于正在构建现代 Web 平台、追求更好开发者体验和多云能力的团队,了解这类替代路径并进行早期探索是有价值的。迁移不是一次性任务,而是一个分阶段、风险可控的工程。
通过小步试点、补丁贡献与团队能力提升,可以把优势最大化,同时把潜在风险降到最低。无论选择继续深耕 CDK 生态还是转向像 Ion 这样的新引擎,关键在于把团队的交付效率、故障恢复能力与长期可维护性作为决策的核心衡量标准。 。
