译者：根据个人的过往经验，在企业中，当开发连LB、容器编排、安全组的概念都不太明白的时候，企业里让开发来写IaC，风险是极高的。
对于“部署”，怎样才叫快速？我们是不是把安全审计、测试覆盖率、容量评估、网络隔离、On-call、Secret安全控制、成本评估等软件工程流程全移除，然后只剩下构建和部署时，就算快速了？
Vercel等平台有意无意的让把这些耗时的约束给删除了，所以给人“快速”的感觉。
我相信在企业中，最终方案不是把这些约束删除，而是加快通过约束的速度。
另一方面不得不承认，我写IaC的代码速度，因为有了AI而快了很多。

原文作者Matt Rickard 简介

Matt Rickard 是一位活跃的工程师、博客作者和创业者,长期在博客 mattrickard.com 上撰写关于工程、创业和 AI 的文章。

工程背景

• • Google(前) —— 曾在 Google 担任软件工程师,从事开源 Kubernetes 相关工作。他参与构建并维护了多个广为人知的 Kubernetes 开发者工具,包括:

• • • minikube —— 在本地运行 Kubernetes 集群的标准工具,几乎是每个 K8s 开发者入门时都会接触到的项目;

  • • skaffold —— 用于 Kubernetes 应用持续开发的命令行工具;

  • • Kubeflow —— 机器学习流水线项目,他曾任维护者之一。

• • The Blackstone Group(更早) —— 在加入 Google 之前,他曾在纽约黑石集团工作。

以下是正文：

开发者应当自己部署自己的代码,但今天通常做不到这一点。不过,AI 也许会改变这种局面。

基础设施即代码(IaC),将不会再由人来编写。 云工程师们为"基础设施即代码"寻找一种完美抽象,已经折腾了将近十年了(Terraform 于 2014 年发布)。尽管取得了一些成功,但在采用层面仍然存在明显的鸿沟。大多数团队使用的是那些专注于开发者体验的更高层服务——Vercel、Railway、Render、Fly,以及其他一众 PaaS。原因很简单:这样更轻松。那些真正采用基础设施即代码的团队,通常必须配有专门的 DevOps 或平台团队,专职来编写这类代码。这些团队由此获得了资产的可复现性和安全性,但很少能享受到那种"用 IaC 快速推断并部署应用"所带来的提速效果或开发者体验。平台团队往往会向应用团队暴露非代码形式的接口(即使底层用的还是 IaC)。

但 AI 将会改变这一切。AI 将编写绝大部分的基础设施即代码。这些 IaC 可能会被即时推断(just in time)生成。它甚至可能在不同云厂商之间自动转换基础设施——哪怕并不存在一一对应的映射(比如 AWS 与 GCP 之间互转)。

关于 IaC + AI 的一些设想:

为应用代码自动推断基础设施组件。 给定一个函数、一个服务端组件,或某个待运行的"应用",自动生成部署它所需要的基础设施。这件事已经被尝试过很多次了,但对于基于规则的引擎来说,这是一道无法逾越的难题。需要自动推断的配置实在太多了,这要求引擎同时掌握应用框架、云厂商以及部署模式方面的知识。

在不同云厂商之间转换基础设施。 把一份 AWS 的 Terraform 模板转换成 Google Cloud 的 Terraform(反之亦然)。由于不存在一对一的映射,任何基于规则的自动化方案都会失败。这种映射本身就必须是"模糊"的——而这恰好是当今 LLM 所擅长做的事情。AI 可以不去映射资源,而是去映射意图(例如:"通过容器部署一个支持自动伸缩的 Web 服务器")。

问题的核心在于:任何中间件库,最终都要受制于底层的云 API。(在 AWS 这里,也就是 CloudFormation。)任何凌驾在这些 API 之上的抽象,本质上都是"有漏抽象"(leaky abstraction)。更糟的是,云厂商有强烈的动机去阻止自家的 API 与竞争对手的 API 互相兼容或等价。因此,IaC 最终就变成了与厂商强绑定的东西,这从根本上限制了它能做到多简单。

但 AI 能够解决这个问题(而且不是那种"挥挥手"式的口头解决)。云 API 必须保持稳定,并且要长期支持。EC2 的 API 不会每个月都发生实质性变化,甚至每一年都不会。同样地,让云服务如此赚钱的"规模经济"效应也意味着:每一个 API 都有大量的用户,从而能产生充足、高质量的训练数据。

帮助开发者自己编写 IaC。 已经有很多产品向开发者承诺过——你只管"写你的代码",基础设施会被神奇地准备好。但到目前为止,这些尝试都没有兑现承诺。把基础设施描述放在代码旁边并不容易,把 DevOps 那一套抽象转化为应用开发者愿意(也能够)学习的形式同样困难。

开发者应当自己部署自己的代码,但今天这件事并不容易。AI 也许有能力在这些"模糊层"之上构建出新的东西。给定一段代码,把它部署到云上的最佳方式是什么?一旦基础设施被推断出来,生成一份供开发者在部署前进行核验的声明式模板,应当就相对容易了。

为复杂模板生成变更集(Changeset)。 服务商很容易就把一份 Helm Chart 或一长串 Kubernetes 配置丢给客户去部署。而且它一开始确实管用——直到用户需要配置任何"黄金路径"(golden path)之外的东西。那时候,翻阅几千行配置的痛苦就开始了。这正是为什么"模板"只是把复杂性推迟,而不是真正解决了它。但 AI 可以深入审视大段的配置内容,为一次配置变更建议出正确的变更集。这样虽然并不能完全掩盖复杂性,但它把这种复杂性推得更远了一些(也许已经足够让开发者走得更远)。

---

译注: 原文链接 https://mattrickard.com/infrastructure-as-code-will-be-written-by-ai,作者 Matt Rickard,发布于 2023 年 10 月 28 日。

往期推荐：

• GUI 型 DevOps 平台的天花板，Ashby 在 1956 年就画好了

• DevOps平台两种实现模式