云计算的"乐高困境"：一个老极客的图式突围

想象一下：你手里有340个Lambda函数，107种拓扑结构，三种编程语言混跑——而你的团队只有几个人。这不是技术炫耀，是真实的技术债地狱。

作者David Pollak在Informed的经历，戳中了无数Serverless团队的隐痛：我们明明在写代码，却80%时间在"手工接线"。

一张图看懂"云函子"的野心

Pollak抛出的核心概念叫tc Cloud Functors——名字听着唬人，本质是一次思维换底。

传统云架构是资源清单思维：我要一个S3桶、一个Lambda、一段IAM策略，像超市购物单一样逐项勾选。CloudFormation和Terraform都是这个路数，区别只是"谁更不难用"。

tc Cloud Functors换了个视角：把云当成一张可编程的图。

节点是计算单元（Lambda、容器、 whatever），边是事件流（SQS、EventBridge、直接调用）。整个系统不是"我有什么资源"，而是"数据怎么流动、在哪变形"。

这个切换的妙处在于：Serverless的本质就是事件驱动的图，但我们的工具还在用服务器时代的脑回路。

Pollak打了个比方——用CloudFormation像"用低级脆弱的骨头造高性能引擎"，Terraform" suck得少一点"，但阻抗不匹配。这里的"阻抗"是电气工程借来的词：你的工具和工作对象的内在结构不对频，每一下操作都是摩擦损耗。

从"接线工"回到"程序员"

Informed的真实困境很有代表性。

他们处理美国8%的汽车贷款，面对银行级合规和"无限PII"的恐怖约束。技术栈却是经典创业公司的随机漫步产物：巨型Ruby on Rails居中，通过Elastic Beanstalk对接几乎所有AWS服务，Postgres数据库兼职消息总线。

Pollak说得很实在——"这不是鄙视，它确实能跑，服务了顶级银行，还盈利了。"

但添加一个功能像"移山"。团队80%时间花在手工接线上，只有20%写业务逻辑。

tc的设计目标很直接：把云当作一台单一计算机来编程。不是管理资源，而是描述计算。

这里的"函子"（Functor）借自范畴论——一种研究"结构映射结构"的数学工具。对程序员更友好的理解是：一个带"管道"的计算单元，输入输出类型明确，可以安全地拼接组合。

每个云函子封装了：运行环境（Lambda/容器）、触发条件、输出目标、错误处理、权限边界。开发者声明"我要这个形状的计算"，底层自动展开成具体的AWS资源。

为什么是"图优先"而不是"代码优先"

Serverless领域有个常见误区：以为问题只是"基础设施即代码"不够好用，所以造更好的DSL。

tc的洞察更深一层：Serverless系统的复杂度不在代码量，在拓扑复杂度。

340个Lambda单独看都不复杂，但它们的连接方式——谁触发谁、失败怎么重试、死信队列去哪、跨账户权限怎么透传——构成了一个动态演化的网络。这个网络才是理解系统的关键，代码只是节点的局部实现。

图优先意味着：你第一眼看到的是数据流的全貌，可以追问"这个异常从哪来、会波及哪"，而不是在CloudFormation模板里跳转到第47行找SQS队列定义。

Pollak的背景很有意思——从迷你计算机时代一路走过来，ISDN ISP、国际服务器农场、早期电商、2008年就玩AWS。这种跨度让他对"技术轮回"格外敏感。

他注意到一个模式：每次计算范式转移，初期工具总是模仿旧范式。虚拟机刚出来时，人们还在按物理机的方式管理；Serverless早期，工具也在按服务器的方式编排。

tc Cloud Functors是他认为的"正确抽象层级"——不是更薄的包装，而是匹配Serverless内在结构的建模方式。

这玩意儿能成吗？

说实话，现在还早。Pollak明说这是系列文章的第一篇，具体实现细节还没展开。

但有几个信号值得关注：

第一，问题真实。80/20的接线/编码比例不是Informed独有，是Serverless规模化后的普遍痛点。AWS自家工具（SAM、CDK）也在试图解决，但"云厂商视角"和"开发者视角"始终有张力。

第二，抽象层级的选择很刁钻。太低（CloudFormation）累死人，太高（某些低代码平台）丧失控制力。tc卡在中间：保留对执行模型的精确控制，但把连接逻辑提升为一级公民。

第三，图模型有网络效应。一旦团队用图的方式描述系统，可视化、调试、变更影响分析都变得更自然。这是结构决定功能的路子。

Pollak没说的是：这个思路对AI时代的架构尤其有趣。大模型应用正在催生更极端的Serverless场景——推理任务高度突发、流水线步骤多变、成本敏感。传统工具在这种弹性面前更显笨拙。

如果tc能把"编程云"的体验做到接近"编程单机"，它解决的就不只是Informed的340个Lambda问题，而是下一代应用的基础设施工具链。

当然，前提是它真的好用。Pollak的下一篇文章，估计要亮代码了。