共计 2638 个字符，预计需要花费 7 分钟才能阅读完成。
LAF 是基于 serverless 架构来做的，如果说 serverless 是一种架构模式的话，那么对 LAF 来说，laf 就是「一个」开发方式。
对于商业化
免费是肯定要做的，然而免费是一个伎俩，而不是目标，是为了测验咱们产品的商业价值，同时能够为这个产品可能长期倒退提供能源。另外免费其实也是一种「责任」，用户因为信赖而付费，咱们应该为了这份信赖而做出更好的产品，提供更好的服务。
免费版怎么做？
见过很多产品，不免费把本人缓缓拖死，一免费就把本人搞死。
参考国外的很多产品，比方 figma、github、vercel 等，咱们还是须要收费模式的，收费模式提供的是最根底的用户应用，让用户能够尽早体验你的产品。
收费模式不能一上来就给很大的优惠力度，而是要循序渐进，按本人的能力去给到用户。为什么？因为如果刚开始就把收费福利提的很高，会有两个问题：
后续免费策略很难做，俗话说「由俭入奢易，由奢入俭难」，如果你收费都曾经无限度应用了，那我为什么还要付费呢？
如果你想先收费，而后再对原先收费的性能进行免费，或者变相免费，比方对收费版本进行阉割，都会引起用户极大的恶感和不信任感，因为这会让用户感觉本人就是刀板上的鱼肉，任人宰割。
不晓得为什么国内的产品都喜爱这么做，先用收费把你「圈」进来，而后等你用久了之后，产生依赖了，再给你缓缓的收割，仿佛是把 toC 的经营策略用到了 toB 上，更可耻的是，有些产品免费了，仍然还要挂广告。
我感觉 laf 不应该这样，这不是 laf 产品的价值观。
所以回到收费策略，我更心愿的是，首先咱们尽可能提供了一个可用的让用户能够测试应用的「收费版本」，比方对利用数、存储等做一些限度，然而可能保障用户比方日活在 1000 左右的齐全够用。
等 laf 团队有钱了，比方拿到了融资，或者商业化做的很给力，再缓缓晋升收费版本的福利，比方能够反对日活 10000 等。这种模式比拟像 github 的门路，以前 github 的收费用户只能创立公开仓库，只有企业版客户能力创立公有仓库，然而起初融资后，这个权限也缓缓放开给收费客户，我感觉这是一种比拟好的渐进策略。
免费模式怎么做？
说完了收费模式，再来说说免费模式怎么定的问题，当初的免费个别有两种
按月免费，企业版按人头免费，按年的话，能够打个折这样
按用量免费
第一种模式的益处是免费简略（我只须要对用户做管制就行），且会有较大的利润空间（长尾实践），且随着用户量的晋升，营收也会始终下来，我只有围绕用户增长去做就行。
然而这真的是一种好模式吗？其实从我集体的角度来讲，我是比拟排挤这样的做法的。因为这种做法可能会导致一些沉睡账户仍然在给你付钱，（想想你多久没去清理按月订阅的服务了），然而这些人并没有在应用你的服务，或者很低频的在应用你的服务，你却仍然在免费，我认为这种行为是不道德的。
我不想呈现说，我 laf 用户的业务还没做起来呢，就先被「咔咔咔」的付一堆费用。
所以我会更偏向于第二种模式，即「按量付费」，咱们的服务应该是跟水电煤一样，比方「用电」，我关上开关，开始计费，关掉开关，就进行计费。同时「电」也会分为「民用电」和「公业用电」，而后每个中央的「电」可能免费不一样。
这种模式也更贴近 serverless 云服务的理念。
同时这种模式，也更符合 laf 与用户共成长的「价值观」。
在你的利用还很晚期的时候，你能够用「收费版本」来做 poc，等开始有用户量了，切到「根底版」，如果倒退很好，再往上就切到「企业版」，「根底版」和「企业版」都是「按量付费」，不会在利用低谷的时候多收钱，甚至能够做到很好的升配和降配。「根底版」和「企业版」的惟一差异是在「并发量」等一些指标上，因为背地用的机器不一样。
laf 的劣势是什么？
绝对于一些私有云平台服务来说，必定是不受平台绑定。
同时 laf 是开源的，所有代码公开可见，不会偷偷摸摸做事件。
然而如果有同样一个产品，举个例子，比方字节的轻服务的团队进来做了一个同样的产品，而后也开源了，那咱们跟他们比起来，劣势是什么？
我感觉好的产品都应该有这样的文化自信，即：即便你把我的性能都抄去了，甚至短期内做的比我还好，我也不会放心，因为你学不到我的内核，竞争不能顺着对手去思考，而是应该立足于产品本身，想想怎么站在用户的角度去思考。
想想 figma 为什么胜利，sketch 为什么失败？
对于 laf 的用户画像
想了几个场景。
基于 laf 开发一些自动化工具的接口
比方每天早上 8:00 主动发送今日天气、穿褡倡议给微信。
比方有些 app 须要做签到工作等。
这个场景的衍生场景是：我能够把这些 api 进行对外开放，比方我做了一个 text to Image 的服务，我能够将这个服务封装为 api 接口进行对外，从而进行免费等。
基于 laf 开发 to C 的网站、小程序等
这个应该是 laf 的一个十分典型的场景了，用户画像是：集体开发者或者小团队。他们会本人开发利用而后经营，也可能是给他本人的客户开发了利用，而后交付给客户。
如何晋升这些开发者的体验，以及提供所须要的产品能力是以后的重点。
基于 laf 开发 SaaS 服务
应用 laf 构建了比方 CMS 这样的零碎
对于私有云
我感觉私有云应该分两个版本，「国内版」以及「海外版」，毕竟两地政策不一样，比方让海外版做「实名认证」或者「人脸识别」就是很奇怪的事件，海外版应该限度更小一些，然而从技术或者产品架构上怎么去做，须要思考。
对于私有云来说，「平安」和「稳定性」是底线，对于公有云来说，怎么让 laf 依赖更少须要去思考
对于一些根底应用用户来说，我心愿他不要本人去建 laf 的公有云，间接用私有云就好，因为老本更低，稳定性更好，但同时对 laf 私有云提出了一个要求，就是我得有很不便的导入导出性能，这样即便经验黑天鹅事件，我也能够让我的客户疾速部署到本人的公有云上。
对于插件
须要插件吗？目前看来仿佛是须要的，举个场景，用户须要「发送短信」的能力，当初的做法是须要本人去购买短信服务，而后通过 api 进行对接，如果 laf 提供了的话，用户能够间接通过比方 sdk.sms.send() 这样的形式来调用。
另外像 七牛云、mysql 这样的能力如何集成进来。甚至于下面提到的 AI 能力等，这些能力不是每个 app 都须要的，然而这些能力个别也不会收费应用，所以说这些是不是都能够形象到「插件市场」来扩大 laf 的生态。
sealos 以 kubernetes 为内核的云操作系统发行版，让云原生简略遍及
laf 写代码像写博客一样简略，什么 docker kubernetes 通通不关怀，我只关怀写业务！