我不会花这整篇文章 做通常的无服务器争论。
是的,管理的基础设施是有用的。
是的,自动缩放不错。
是的,不需要补丁服务器是胜利。
是的,事件驱动的架构可以非常适合现代的网络应用.
所有这一切都是真的,但这不是我想在这里集中关注的问题。
更有趣的是,无服务器会改变代理编码的用处.
它为AI编码代理提供了更好的工作环境.
这并不是因为特工们突然变得更聪明,而是因为他们正在工作的系统变得更加明确,更加受约束,更容易检查.
这比我想象的更重要 当您构建一个网络应用程序时,最终需要托管到某个地方.
您可以把它放在 VPS 上,配置 nginx, 用系统或进程管理器运行您的应用程序, 添加一个数据库, 在队列上螺栓, 并窃听您需要的其他设备 。
这是完全有效的软件运行方式。
大量认真的生产系统是这样工作的。
但一旦开始使用编码代理,就出现了问题.
代理商可能会理解您的应用代码,但不会理解周围的环境.
它可能不知道您的反向代理如何配置 。
它可能不知道背景工作者是如何开始的。
它可能不知道部署期间运行的是哪个脚本,哪些环境变量存在于生产中,哪些假设生活在README中,或者哪些部分设置只是部落知识.
所以当你要求它做一个有意义的建筑改变时,它必须猜测.
有时候这些猜测是好的。
有时不是。
代理人可以发明一种与你部署方式不符的工人流程.
它可能到达Redis,因为这是一个常见的排队答案,尽管你系统的其余部分并不使用Redis.
它可能假设本地文件存储可用 。
它可能增加一个调度器,而不知道该调度器将实际运行在哪里.
这就是无服务器开始感觉不像部署选择,而更像一种方便代理的发展模式.
在良好的无服务器应用程序中,基础设施不会被隐藏在代码之外.
功能,队列,桶,调度,事件源,权限,以及环境变量都是应用程序定义的一部分.
它们是可见的。
可以审查。
它们可以随商业逻辑而改变。
这让代理商有了更好的工作材料。
A.
背景情况 是真正的博特伦克 编码代理的限制性因素往往不是它们能否写出代码.
他们可以整天写代码。
限制因素是他们是否有足够的正确上下文来写出正确的代码.
具有隐蔽基础设施假设的大型应用程序对于代理人来说是难以解释的。
它可能完全理解一个操作员,同时误解了操作员所居住的系统.
无服务器有帮助,因为很多系统形状可以简洁地描述.
一个没有服务器的.yml文件可以告诉代理存在什么功能,什么触发它们,它们依赖什么资源,它们得到什么环境变量,以及它们拥有什么权限.
这不是整个系统,它并不总是漂亮的,但它是一个有用的地图。
该地图往往比散开的部署脚本集,服务器配置,进程管理器文件,和无记录的运行时间假设更容易为代理工作.
另一个上下文胜出的是,无服务器应用程序往往使用管理服务,而不是自定义代码来处理基础设施问题.
如果您使用 SQS, 代理不需要理解您的自定义队列执行 。
如果您使用 S3, 它不需要理解一个本土文件存储层 。
如果使用 EventBridge,它不需要逆向编程器.
如果您使用 API 网关, 它不需要在边缘创建请求的路由层 。
管理服务变成原始服务.
代理仍然需要理解你的应用是如何使用原始的,但它已经不是了