開始之前

開始之前請(qǐng)先鑒賞各家公有云的函數(shù)計(jì)算（自行鑒賞，筆者不發(fā)表任何評(píng)論）

阿里云：

騰訊云：

Laf:

函數(shù)計(jì)算價(jià)值

每個(gè)企業(yè)都應(yīng)該標(biāo)配一個(gè)函數(shù)計(jì)算平臺(tái)，不管是直接使用公有云還是涉及敏感數(shù)據(jù)需要私有部署，因?yàn)楹瘮?shù)計(jì)算可以為企業(yè)夸張的節(jié)省大量成本，極大效率的提升業(yè)務(wù)更新迭代速度，幫助企業(yè)更快發(fā)展。

應(yīng)用開發(fā)周期

比如我司開發(fā)一些功能模塊很多真的就是分鐘級(jí)，而且復(fù)用性極強(qiáng)，比如各種三分鐘系列：

• 三分鐘實(shí)現(xiàn)注冊(cè)登錄
• 三分鐘接入微信支付
• 三分鐘實(shí)現(xiàn) chatGPT

這里不是寫個(gè) demo 玩玩，而是真的可以提供線上服務(wù)的能力，最重要這三分鐘不是寫完代碼，而是包含了代碼在線上運(yùn)行！寫完即發(fā)布，點(diǎn)擊保存，關(guān)機(jī)走人。

所以基于函數(shù)計(jì)算去開發(fā)應(yīng)用，開發(fā)周期的單位都是以分鐘/小時(shí)/天來(lái)計(jì)算。我的合伙人馬斯洛同學(xué)經(jīng)常在和別人開會(huì)教別人怎么做時(shí)就把東西給寫完了，效率高到夸張。

這很像一個(gè)完全可定制化的業(yè)務(wù)中臺(tái)，不是簡(jiǎn)單拿到一個(gè)業(yè)務(wù)接口，而是拿到之后很方便就可以定制。比如給你個(gè)微信支付接口 不如給你個(gè)微信支付 function, 有了 function 你就很輕松加自己的支付邏輯了。

參與人員

使用函數(shù)計(jì)算一個(gè)人頂一個(gè)團(tuán)隊(duì)絲毫不夸張，首先就是運(yùn)維人員在這個(gè)模型中是不存在的，連運(yùn)維的動(dòng)作都不存在，就像你發(fā)布一篇博客需要運(yùn)維動(dòng)作或者運(yùn)維人員幫你嗎？既然發(fā)布博客可以不需要為什么發(fā)布業(yè)務(wù)代碼需要？

其次什么 devops 什么容器 kubernetes，對(duì)不起老夫只會(huì)一把梭，k8s 單詞怎么拼老夫都不知道，也不需要知道。

函數(shù)計(jì)算理想情況下又順便干掉了企業(yè)內(nèi)部的 devops 團(tuán)隊(duì)。所以理想的情況是企業(yè)只需要保留少量的開發(fā)人員，他們只關(guān)心業(yè)務(wù)邏輯，這剩下來(lái)的人力成本是夸張的，這樣玩大多數(shù)企業(yè)都可裁員 50%，需要是私有云可能需要額外投入 1 個(gè)人來(lái)維護(hù)這個(gè)函數(shù)計(jì)算的平臺(tái)即可。

最理想的情況是開發(fā)人員也不需要了，會(huì)寫需求即可，AI 全部生成代碼，這一天肯定不遠(yuǎn)了（筆者也是開發(fā)者，美團(tuán)外賣賬號(hào)都注冊(cè)好了，AI 短期還沒法送外賣）

人一多必然增加溝通協(xié)調(diào)這些隱性成本，這是不太能看的到但是巨高成本。

人員要求

以前需要月薪大幾萬(wàn)才能寫出安全穩(wěn)定高并發(fā)的程序，現(xiàn)在月薪 3k 的人真能寫，函數(shù)計(jì)算平臺(tái)解決其它問(wèn)題，什么高并發(fā)橫向伸縮平臺(tái)全解決了。

AI 又進(jìn)一步降低了對(duì)人的要求，我其實(shí)不怎么會(huì)寫 typescripts，當(dāng)前在 AI 的幫助下寫出生產(chǎn)可用的代碼幾乎沒問(wèn)題。關(guān)鍵是 AI 還在進(jìn)化，技術(shù)爆炸式進(jìn)化，三年之內(nèi) AI 的編碼能力會(huì)讓人類望塵莫及，人類更多是給 AI 打打雜，AI 是主程。

資源要求

但凡資源利用率在 30% 以下的，都有非常大的降本空間，使用函數(shù)計(jì)算的降本可不是降一點(diǎn)點(diǎn)，而是成本“腳脖子斬”。

比如一個(gè)場(chǎng)景需要部署 5000 個(gè)小應(yīng)用，傳統(tǒng)方式怎么的得搞 500 臺(tái)虛擬機(jī)，一臺(tái) 10 個(gè)密度不低了，10個(gè)還有很麻煩的管理問(wèn)題了，應(yīng)用之間還要求不能打架。

而用函數(shù)計(jì)算，可以夸張的塞到 10 臺(tái)服務(wù)器上。低頻應(yīng)用一個(gè)節(jié)點(diǎn)跑個(gè) 500 個(gè)函數(shù)很正常。 還完全不用關(guān)心應(yīng)用的管理和隔離高可用等問(wèn)題。

對(duì)于高并發(fā)的應(yīng)用無(wú)非就是多跑一些函數(shù)副本而已，也就是整體利用率沒到達(dá)水位的時(shí)候就可以一直塞滿為止。

其實(shí)很多企業(yè)超過(guò) 100 人的研發(fā)團(tuán)隊(duì)用傳統(tǒng)方式運(yùn)行應(yīng)用的都在很大程度上浪費(fèi)資源，即便使用了容器等技術(shù)相比函數(shù)計(jì)算還有很大的提升空間。

我們自己跑了 1000 多函數(shù)就只用了 10 臺(tái)低配虛擬機(jī)。業(yè)務(wù)增長(zhǎng)時(shí)簡(jiǎn)單加服務(wù)器就好。

函數(shù)計(jì)算不出圈的三座大山

函數(shù)計(jì)算都這么厲害了，那豈不是人人都該用，應(yīng)該早就火爆了才對(duì)，為啥現(xiàn)在來(lái)看整個(gè)市場(chǎng)依然沒有出圈？

我總結(jié)主要有以下三點(diǎn)：

• 大眾市場(chǎng)很難接受變化，熟悉的開發(fā)方式難以轉(zhuǎn)變，即便新的方式有很多優(yōu)勢(shì)，對(duì)于破壞性創(chuàng)新的天生拒絕。
• 大部分應(yīng)用無(wú)法在 function 中全部閉環(huán)掉，導(dǎo)致還是需要依賴其它的開發(fā)方式。圖方便的人又需要因?yàn)橐徊糠菪⌒枨蠡貧w到老的方式上。
• 先進(jìn)的非 serverless 框架的競(jìng)爭(zhēng)與挑戰(zhàn)。（比如用 java 做 fun, 必然會(huì)被 spring cloud 挑戰(zhàn)，用了 function 可能就得丟掉其它框架的優(yōu)越特性。）

開發(fā)方式的割裂

絕大多數(shù)函數(shù)計(jì)算都是需要改代碼的，沒有辦法和以前的代碼保持兼容，也不太容易把代碼復(fù)制到傳統(tǒng)的環(huán)境中去運(yùn)行，這樣導(dǎo)致已有的業(yè)務(wù)都需要改代碼才能享受巨大的好處，所以雖然利益很大改造成本也很高。

而大眾市場(chǎng)對(duì)于變化是天生拒絕的，絕大多數(shù)公司的口號(hào)都是擁抱變化，但是變化真的來(lái)的時(shí)候又都變成了保守主意。

而且你不能確定今天改完了代碼明天又出來(lái)個(gè)更先進(jìn)的技術(shù)。

非 serverless 框架的挑戰(zhàn)

還有就是面臨其他優(yōu)秀編程框架的挑戰(zhàn)，比如你做 java 的 function，但是主流的方式是 spring cloud，你如果兼容 srping cloud 框架那你可能就不是 function，如果你不兼容那就得在編程體驗(yàn)上做的比 srping cloud 做的更好。

你絕對(duì)很難在各種編程語(yǔ)言中把你的 function 框架做到最流行。所以絕大多數(shù)人不愿意從那些優(yōu)秀并且用的很熟悉的框架中遷移。

部分需求無(wú)法滿足

函數(shù)計(jì)算的尷尬地方就在于總有那么點(diǎn)場(chǎng)景無(wú)法滿足，舉個(gè)例子很多的 function 不支持常駐進(jìn)程，這樣就沒法做長(zhǎng)鏈接（當(dāng)然有些已經(jīng)支持了），這樣開發(fā)者又得搞個(gè)傳統(tǒng)的方式來(lái)支持這一個(gè)小特性，筆者最開始時(shí)就是遇到這個(gè)情況，本想 all in function 來(lái)省事的，結(jié)果為了長(zhǎng)鏈接又得搞臺(tái)虛擬機(jī)，讓事變得更復(fù)雜需要維護(hù)兩套，所以后來(lái)索性拋棄了 function。

長(zhǎng)鏈接只是個(gè)例子，還有其他 n 個(gè)需求滿足不了導(dǎo)致用 function 的尷尬境地。比如 function 的冷啟動(dòng)，有調(diào)用時(shí)還會(huì)消耗資源，這聽起來(lái)好性感，但是業(yè)務(wù)跑起來(lái)想吐血，比如這樣連一個(gè) chatGPT 的會(huì)話保持都做不了。

所以這個(gè)技術(shù)不夠通用導(dǎo)致用起來(lái)尷尬。

函數(shù)計(jì)算如何才會(huì)流行

所以 函數(shù)計(jì)算要出圈，就必須解決掉上面三大核心問(wèn)題。

我們首先要把門檻降低再降低，編程體驗(yàn)優(yōu)化再優(yōu)化。比如 laf 在 40s 就能體驗(yàn)開發(fā)上線全流程，整個(gè)過(guò)程無(wú)門檻，我們非技術(shù)背景的投資人都很簡(jiǎn)單的搞定了整個(gè)上線過(guò)程。

這個(gè)初次體驗(yàn)的過(guò)程但凡有一點(diǎn)點(diǎn)障礙或者體驗(yàn)不好的地方，讓用戶無(wú)所適從的地方都會(huì)直接勸退 90% 的人。

不僅產(chǎn)品要簡(jiǎn)單，計(jì)費(fèi)方案也要簡(jiǎn)單，現(xiàn)在很多廠商的計(jì)費(fèi)方案講真的，你花一周時(shí)間去算都算不明白，形同虛設(shè)的價(jià)格方案設(shè)計(jì)，鬼知道我的函數(shù)調(diào)用時(shí)長(zhǎng)有多長(zhǎng)，花一周去研究怎么收費(fèi)的，這不是太可笑了嘛。

一定要開源，因?yàn)橛脩舳疾恢滥氵@個(gè) function 明天還在不在肯定用起來(lái)非常忌諱，即便大廠也有下架服務(wù)例子（這里不點(diǎn)名了），還有隨意提價(jià)格的例子（也不點(diǎn)名了）。還有就是很多場(chǎng)景客戶需要源碼交付的也都無(wú)法支持。 開源的好處是最壞情況就是提供服務(wù)的公司涼涼了，用戶還是可以自己部署和使用。

面對(duì)非 serverless 的優(yōu)秀框架的挑戰(zhàn)，這里唯一的辦法就是自己成為優(yōu)秀的流行框架，laf 開源以來(lái)發(fā)布過(guò)兩次文章，兩次都實(shí)現(xiàn)了爆發(fā)式增長(zhǎng)，也在 github 趨勢(shì)榜上待了一周，發(fā)布當(dāng)天每天有 400 多應(yīng)用被創(chuàng)建，付費(fèi)上線 6 小時(shí)營(yíng)收過(guò)千，每日 star 增長(zhǎng) 50+，這只是個(gè)開始，laf 成為流行的 function 指日可待。

對(duì)于部分需求無(wú)法滿足這個(gè)情況，一定要注意不要去追求高大上的技術(shù)，而要想業(yè)務(wù)到底需要啥，就以冷啟動(dòng)為例技術(shù)方案搞得天花亂墜，業(yè)務(wù)上直接進(jìn)一步加深了割裂感，因?yàn)楸緛?lái)絕大多數(shù)業(yè)務(wù)都是在跑常駐進(jìn)程的。你可以說(shuō)冷啟動(dòng)節(jié)省成本節(jié)省資源，那恭喜你成功每個(gè)月為企業(yè)節(jié)省了 15元！保持少量存活容器花不了幾個(gè)錢的。 那種請(qǐng)求來(lái)了創(chuàng)建容器掙了一大堆預(yù)熱快速啟動(dòng)的方案等等堆了一堆技術(shù)專家才是真的成本。laf 就選擇了常駐進(jìn)程，這樣基本核心解決的是屏蔽掉寫業(yè)務(wù)邏輯之外的其他事，而對(duì)原生的運(yùn)行方式不作改變，這樣割裂自然就小，而且能滿足絕大多數(shù)需求。 還有個(gè)非常重要的一點(diǎn)就是 laf on sealos 所有的擴(kuò)展都可以在 sealos 云操作系統(tǒng)中進(jìn)行，比如在 sealos 上跑 AI 引擎使用 laf 去調(diào)用，完美結(jié)合。

最后一點(diǎn)就是時(shí)機(jī)，functions 是新的東西，所以更適合在新的浪潮中爆發(fā)，也就是 AI 的崛起，這個(gè)大浪潮下必然會(huì)有很多新的應(yīng)用需要被開發(fā)出來(lái)，而選擇函數(shù)去開發(fā) AI 應(yīng)用的公司必然在競(jìng)爭(zhēng)中勝出，因?yàn)檫@個(gè)浪潮中兵貴神速，他們開發(fā)按照分鐘小時(shí)計(jì)，而傳統(tǒng)的公司還在慢慢迭代上線必然在競(jìng)爭(zhēng)中失敗。比如我們開發(fā)的 chatmind AI 生成腦圖的應(yīng)用就用了一天，上線當(dāng)天就有 10000 注冊(cè)用戶，這是傳統(tǒng)方式絕對(duì)做不到的。所以函數(shù)計(jì)算會(huì)隨著 AI 共同崛起。
sealos 以kubernetes為內(nèi)核的云操作系統(tǒng)發(fā)行版，讓云原生簡(jiǎn)單普及

laf 寫代碼像寫博客一樣簡(jiǎn)單，什么docker kubernetes統(tǒng)統(tǒng)不關(guān)心，我只關(guān)心寫業(yè)務(wù)！