函数计算导论 - AI 时代助燃剂

开始之前

开始之前请先鉴赏各家公有云的函数计算（自行鉴赏，笔者不发表任何评论）

阿里云：

腾讯云：

Laf:

函数计算价值

每个企业都应该标配一个函数计算平台，不管是直接使用公有云还是涉及敏感数据需要私有部署，因为函数计算可以为企业夸张的节省大量成本，极大效率的提升业务更新迭代速度，帮助企业更快发展。

	传统方式	函数计算	价值
应用开发周期	以月为单位	天/小时/分钟	应用迭代速度是企业高速发展的灵魂
参与人员	开发/运维	开发&AI	原先需要一个组做的事，借助函数计算可能只需要若干开发人员，借助 AI 能力甚至只需要懂需求的人参与
人员要求	专业要求高	专业要求低	能写业务逻辑的就行，不需要太专业的知识。
资源要求	浪费资源/利用率低	资源利用率极高	资源平均利用 30% 以下的基础设施借助函数计算都可降本 50% 以上。

应用开发周期

比如我司开发一些功能模块很多真的就是分钟级，而且复用性极强，比如各种三分钟系列：

• 三分钟实现注册登录
• 三分钟接入微信支付
• 三分钟实现 chatGPT

这里不是写个 demo 玩玩，而是真的可以提供线上服务的能力，最重要这三分钟不是写完代码，而是包含了代码在线上运行！写完即发布，点击保存，关机走人。

所以基于函数计算去开发应用，开发周期的单位都是以分钟/小时/天来计算。我的合伙人马斯洛同学经常在和别人开会教别人怎么做时就把东西给写完了，效率高到夸张。

这很像一个完全可定制化的业务中台，不是简单拿到一个业务接口，而是拿到之后很方便就可以定制。比如给你个微信支付接口 不如给你个微信支付 function, 有了 function 你就很轻松加自己的支付逻辑了。

参与人员

使用函数计算一个人顶一个团队丝毫不夸张，首先就是运维人员在这个模型中是不存在的，连运维的动作都不存在，就像你发布一篇博客需要运维动作或者运维人员帮你吗？既然发布博客可以不需要为什么发布业务代码需要？

其次什么 devops 什么容器 kubernetes，对不起老夫只会一把梭，k8s 单词怎么拼老夫都不知道，也不需要知道。

函数计算理想情况下又顺便干掉了企业内部的 devops 团队。所以理想的情况是企业只需要保留少量的开发人员，他们只关心业务逻辑，这剩下来的人力成本是夸张的，这样玩大多数企业都可裁员 50%，需要是私有云可能需要额外投入 1 个人来维护这个函数计算的平台即可。

最理想的情况是开发人员也不需要了，会写需求即可，AI 全部生成代码，这一天肯定不远了（笔者也是开发者，美团外卖账号都注册好了，AI 短期还没法送外卖）

人一多必然增加沟通协调这些隐性成本，这是不太能看的到但是巨高成本。

人员要求

以前需要月薪大几万才能写出安全稳定高并发的程序，现在月薪 3k 的人真能写，函数计算平台解决其它问题，什么高并发横向伸缩平台全解决了。

AI 又进一步降低了对人的要求，我其实不怎么会写 typescripts，当前在 AI 的帮助下写出生产可用的代码几乎没问题。关键是 AI 还在进化，技术爆炸式进化，三年之内 AI 的编码能力会让人类望尘莫及，人类更多是给 AI 打打杂，AI 是主程。

资源要求

但凡资源利用率在 30% 以下的，都有非常大的降本空间，使用函数计算的降本可不是降一点点，而是成本“脚脖子斩”。

比如一个场景需要部署 5000 个小应用，传统方式怎么的得搞 500 台虚拟机，一台 10 个密度不低了，10个还有很麻烦的管理问题了，应用之间还要求不能打架。

而用函数计算，可以夸张的塞到 10 台服务器上。低频应用一个节点跑个 500 个函数很正常。 还完全不用关心应用的管理和隔离高可用等问题。

对于高并发的应用无非就是多跑一些函数副本而已，也就是整体利用率没到达水位的时候就可以一直塞满为止。

其实很多企业超过 100 人的研发团队用传统方式运行应用的都在很大程度上浪费资源，即便使用了容器等技术相比函数计算还有很大的提升空间。

我们自己跑了 1000 多函数就只用了 10 台低配虚拟机。业务增长时简单加服务器就好。

函数计算不出圈的三座大山

函数计算都这么厉害了，那岂不是人人都该用，应该早就火爆了才对，为啥现在来看整个市场依然没有出圈？

我总结主要有以下三点：

• 大众市场很难接受变化，熟悉的开发方式难以转变，即便新的方式有很多优势，对于破坏性创新的天生拒绝。
• 大部分应用无法在 function 中全部闭环掉，导致还是需要依赖其它的开发方式。图方便的人又需要因为一部份小需求回归到老的方式上。
• 先进的非 serverless 框架的竞争与挑战。（比如用 java 做 fun, 必然会被 spring cloud 挑战，用了 function 可能就得丢掉其它框架的优越特性。）

开发方式的割裂

绝大多数函数计算都是需要改代码的，没有办法和以前的代码保持兼容，也不太容易把代码复制到传统的环境中去运行，这样导致已有的业务都需要改代码才能享受巨大的好处，所以虽然利益很大改造成本也很高。

而大众市场对于变化是天生拒绝的，绝大多数公司的口号都是拥抱变化，但是变化真的来的时候又都变成了保守主意。

而且你不能确定今天改完了代码明天又出来个更先进的技术。

非 serverless 框架的挑战

还有就是面临其他优秀编程框架的挑战，比如你做 java 的 function，但是主流的方式是 spring cloud，你如果兼容 srping cloud 框架那你可能就不是 function，如果你不兼容那就得在编程体验上做的比 srping cloud 做的更好。

你绝对很难在各种编程语言中把你的 function 框架做到最流行。所以绝大多数人不愿意从那些优秀并且用的很熟悉的框架中迁移。

部分需求无法满足

函数计算的尴尬地方就在于总有那么点场景无法满足，举个例子很多的 function 不支持常驻进程，这样就没法做长链接（当然有些已经支持了），这样开发者又得搞个传统的方式来支持这一个小特性，笔者最开始时就是遇到这个情况，本想 all in function 来省事的，结果为了长链接又得搞台虚拟机，让事变得更复杂需要维护两套，所以后来索性抛弃了 function。

长链接只是个例子，还有其他 n 个需求满足不了导致用 function 的尴尬境地。比如 function 的冷启动，有调用时还会消耗资源，这听起来好性感，但是业务跑起来想吐血，比如这样连一个 chatGPT 的会话保持都做不了。

所以这个技术不够通用导致用起来尴尬。

函数计算如何才会流行

所以 函数计算要出圈，就必须解决掉上面三大核心问题。

我们首先要把门槛降低再降低，编程体验优化再优化。比如 laf 在 40s 就能体验开发上线全流程，整个过程无门槛，我们非技术背景的投资人都很简单的搞定了整个上线过程。

这个初次体验的过程但凡有一点点障碍或者体验不好的地方，让用户无所适从的地方都会直接劝退 90% 的人。

不仅产品要简单，计费方案也要简单，现在很多厂商的计费方案讲真的，你花一周时间去算都算不明白，形同虚设的价格方案设计，鬼知道我的函数调用时长有多长，花一周去研究怎么收费的，这不是太可笑了嘛。

一定要开源，因为用户都不知道你这个 function 明天还在不在肯定用起来非常忌讳，即便大厂也有下架服务例子（这里不点名了），还有随意提价格的例子（也不点名了）。还有就是很多场景客户需要源码交付的也都无法支持。 开源的好处是最坏情况就是提供服务的公司凉凉了，用户还是可以自己部署和使用。

面对非 serverless 的优秀框架的挑战，这里唯一的办法就是自己成为优秀的流行框架，laf 开源以来发布过两次文章，两次都实现了爆发式增长，也在 github 趋势榜上待了一周，发布当天每天有 400 多应用被创建，付费上线 6 小时营收过千，每日 star 增长 50+，这只是个开始，laf 成为流行的 function 指日可待。

对于部分需求无法满足这个情况，一定要注意不要去追求高大上的技术，而要想业务到底需要啥，就以冷启动为例技术方案搞得天花乱坠，业务上直接进一步加深了割裂感，因为本来绝大多数业务都是在跑常驻进程的。你可以说冷启动节省成本节省资源，那恭喜你成功每个月为企业节省了 15元！保持少量存活容器花不了几个钱的。 那种请求来了创建容器挣了一大堆预热快速启动的方案等等堆了一堆技术专家才是真的成本。laf 就选择了常驻进程，这样基本核心解决的是屏蔽掉写业务逻辑之外的其他事，而对原生的运行方式不作改变，这样割裂自然就小，而且能满足绝大多数需求。 还有个非常重要的一点就是 laf on sealos 所有的扩展都可以在 sealos 云操作系统中进行，比如在 sealos 上跑 AI 引擎使用 laf 去调用，完美结合。

最后一点就是时机，functions 是新的东西，所以更适合在新的浪潮中爆发，也就是 AI 的崛起，这个大浪潮下必然会有很多新的应用需要被开发出来，而选择函数去开发 AI 应用的公司必然在竞争中胜出，因为这个浪潮中兵贵神速，他们开发按照分钟小时计，而传统的公司还在慢慢迭代上线必然在竞争中失败。比如我们开发的 chatmind AI 生成脑图的应用就用了一天，上线当天就有 10000 注册用户，这是传统方式绝对做不到的。所以函数计算会随着 AI 共同崛起。 sealos 以kubernetes为内核的云操作系统发行版，让云原生简单普及

laf 写代码像写博客一样简单，什么docker kubernetes统统不关心，我只关心写业务！