laf 的发展背景和方向讨论

[maslow]

背景

• 2019 年，因依赖上微信云开发的开发体验，开发了 less-api，支持在前端访问数据库，后并入 laf 名为 database-proxy
• 2020 年，因 less-api 还是传统的开发方式，不支持文件、登陆、支付等非数据库逻辑，实现 less-api-framework，在 less-api 的基础上增加了 web 控制台、云函数的能力
• 2021 年，因为 less-api-framework 是单应用版，每个项目都需要单独部署一次，将其实现为多租户多应用的云开发平台，命名为 laf

可以看出，laf 是「自下而上」设计出来的，laf 最初是在实际项目开发团队中孵化出来的，其中每个按钮都是项目团队「催」出来的。

laf 在并没有经历过「自上而下」的设计过程，其功能和架构的演化是同时进行的，好处是“需求驱动迭代“在前期可以快速匹配项目需求，坏处也很明显，完全没有顶层设计，不利于长期迭代，也不容易满足更广泛的场景。

laf 若要长期、广泛的使用和发展，就必须要更抽象、简单、轻量、灵活的设计。相反，仅针对具体的需求的设计往往只能满足阶段性、小范围的需求，未来迭代的过程会变得复杂、臃肿，直至被淘汰。

只有更加抽象、轻量、简单的设计，才能长期快速的迭代、满足更广泛的需求、满足未来的需求。

[maslow]

需求点

• 多语言支持（Node, Deno, Golang, Java, Golang, Python, Rust等）
• 多数据库种类支持（MongoDb, PG, MySQL等）
• 多中间件服务支持（Redis, MQ等）
• 应用多运行环境的支持（Docker, Kubernetes, VM，Bare Metal等）
• 数据库的多集群多可用区支持
• 应用集群的多可用区支持

这些需求点，不应该只能由 laf 本身来提供，应该从架构层面设计，实现为用户/生态可扩展的方式，比如：

• 用户可以自行扩展支持一门新语言
• 自行扩展支持一种新型数据库等
• 用户可以自行扩展决定一个 app 是调度在容器中，还是直接调度在公有云的云服务器上，或者某IDC机房的一台裸机上

laf 的设计，应该提供的是这种可扩展的能力，而非直接提供功能。

让 laf 本身保持最轻最小化，基于 laf 的部署版可配置、可拼装、可订制、可扩展。

[maslow]

产品目标变化

😣 当前

运营版：lafyun.com 虽是基于 laf 部署的，但还是扩展了一些功能，比如短信登录、实名认证等，未来还会有计量、订单、工单等功能，属于商业运营版。

开源版：过去对开源版的要求是，不要引入三方的接口或与商业运营有关的功能，保持 laf 本身代码的纯粹性。 开源版拥有 laf 完整的能力，定位是支持私有化部署的开源替代品，其开发功能可平替 lafyun.com，但并不具备商业运营相关的能力。

结果：lafyun.com 提供公有云服务， laf 为开发者提供私有部署替代方案。

⛅未来

laf 不会存在「运营版」和「开源版」，laf 的产品目标就是「人人可商业运营」的版本。

所有商业运营的功能，也都会在 laf 中实现， lafyun.com 将只是 laf 的一个普通的运营实例。

laf 希望，人人都可以到处运行云开发服务平台， 市场上应该存在其它 lafyun 的竞品服务，他们可以比 lafyun.com 更便宜、更专业、更受开发者支持。

市场上不应该只有一家腾讯云、阿里云、lafyun，应该有数家、数千家甚至数万家公有云，每个小公司都有能力为自己的客户提供自己的云。

这个目标只有开源生态能实现，我们相信也是未来的大趋势。

感性总结：市场不应该只有几朵大云，而是由无数大大小小的云点缀的天空。

[maslow]

罗列一个具体设计点

• 一切皆资源， 一个应用是一系列资源的集合
• laf core (laf sys)不负责具体资源的创建，只负责核心资源描述（元信息）的维护
• 资源由其对应的 controller 负责创建，controller 可自由定义、组合

如创建一个应用，包括的资源有：db, oss, instance(runtime), domain, ssl, network 等，对应的资源由 db-controller, instance-controller, gateway-controller 等控制器创建和维护。

这些 controller 是可自由拼装组合、可订制开发扩展。

[maslow]

多语言的支持

开发者创建一个应用，就是选择不同的资源，那么多语言的应用，就是选择不同语言的运行时。

如，对微信云开发迁移的场景，专门为微信云开发 提供一个 runtime（app-service），可命名为： app-service-tcb，
开发者在创建应用的时候，可选择不同的 runtime 及其配套资源的组合。

app-service-nodejs （default）
app-service-tcb
app-service-golang
app-service-java
app-service-python
app-service-deno

这个架构应该是可扩展的，在私有部署 laf 的场景下，用户还可以使用自己定制的 runtime。

[maslow]

可能的设计难点

• laf web 控制台，IDE 的支持需要到什么程序，是否要满足多语言的要求？ 如果设计出可扩展的架构？
  或者暂先不提供多语言的IDE, laf 未来也以本地开发的方式为主。

• laf-cli 若支持多语言、多环境、多种类服务，那么 laf-cli 的能力如何扩展扩充，或者 laf-cli 提供的功能只是管理“资源”。

[maslow]

补充几个 laf 的目标场景

1. 专业运营 laf 公有云平台，比如 lafyun.com，适合有云运维能力的团队，包括但不限于 七牛云、ucloud、dcloud、sealos cloud、IDC服务商等，向广大开发者提供 laf 云开发平台服务，开发者可根据自身需求选择任一方运营的 laf，比如价格更优惠的；

2. 软件开发公司，自运维一套 laf 平台，使用 laf 开发和交付应用给自己的客户，客户无需再购买服务器，托管到开发公司的 laf 平台即可。对项目（外包）公司，利用 laf 未来的应用生态，也可极大程度降低开发成本和交付周期。 laf 自带私有化的应用市场，可直接成为开发公司的产品中心。

3. 个人开发者，私有化部署属于自己的 laf 平台，将自己开发的小工具、小应用 上架到自己的应用店铺， 把 laf 应用市场当成个人应用店铺，可直接在个人专属的 laf 平台上开发、分发、交付、售卖自己的开发成果， 你的客户可一键订阅购买你的应用。

[skyoct]

建议首推官方应用市场，做个人应用市场很难做起流量。

[Dunqing]

如何参与开发？

[maslow]

可以预约 maslow laf 开发者同步会议：
https://calendly.com/laogen/laf-oh

或者浏览 issue 和 discussions 参与讨论和沟通

[Dunqing]

可以预约 maslow laf 开发者同步会议：
https://calendly.com/laogen/laf-oh

或者浏览 issue 和 discussions 参与讨论和沟通

好的

[ypjin]

你好！函数并发访问量有什么考虑吗？是否可以支持伸缩？

[maslow]

计划是基于 k8s replicaset 在应用实例层面上进行伸缩

[ypjin]

明白了，谢谢！
不考虑用一个FaaS框架吗？

[maslow]

有考虑过，一个是当前 laf 的使用场景，我还没有找到充分的理由 引入 faas ，目前有状态的常驻进程 能满足需求， 也有其特点（长连接、无冷启等）。 同时， laf 鼓励开发者私有化部署的场景，对于大众开发者， 使用 无状态单并发/实例 的 faas 部署成本比较高（偏重）。

在有更强烈需求的时候，会引入 faas 框架做为一个选项。

[ypjin]

感谢解释！我还在学习，有问题再请教！

[maslow]

后续进展更新：

• laf next 重构计划说明 #352
• laf 架构说明文档 #353
• laf product key & roadmap #354