-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layotto项目规划和展望 #976
Comments
Hi @wenxuwan, |
我觉得应该优先做sdk模式,低开发成本,高回报:
运维标准化是terraform 之类的项目要解决的问题,不是layotto要解决的问题;diagrid 做 conductor 是因为它有自己的目标用户、商业逻辑,这套逻辑没法套到 layotto上 |
SDK模式的确可以让用户快速的跑起来,来检验接口的定义,Sidecar模式Layotto不需要做属于自己的Paas,只要能对接上公有云上常见的监控部署平台即可。两条路一起往前走 |
对于我们来说,重要的还是怎么将这些规划分为若干个任务来让大家参与。而这几个方面(部署运维建设、性能优化建设、接口标准和能力建设、SDK建设)又是很难一步一步建设的,更可能的是需要一起推进。 |
嗯,你说的对。首先得把任务拆分出来,然后落实到人,项目维护者也得投入更多了 |
马老师,还有资源隔离是也继续搞下? |
dapr 可观测性文档失效了 |
我后面可以尝试做一下组件的日志管理,这个跟我近期 pluggable component 有点关联,明天会上可以探讨一下。 |
|
Layotto的愿景
Layotto从诞生至今致力于解决跨云部署、多语言两个问题,时至今日,得益于社区同学的共建,开源Layotto已经支持了丰富的API接口,也提供了非常灵活的自定义插件能力。但作为一款“产品”来说,其仍有很长的路需要走。
Layotto当前困境
开源Layotto当前处在了“概念->产品”的关键状态,当前面临了缺少活跃的社区用户、没有明确的外部落地场景、能力无法满足生产需求。造成上述局面的主要原因,个人看来主要有以下几个方面:
部署形态。虽然Sidecar模式带来了一系列好处,但Sidecar模式下带来的部署运维成本、性能损耗、资源占用、开发模式等问题让用户望而却步。
运维体系缺失。衡量一个产品的很重要的指标就是是否有完善的部署运维体系,Diagrid Conductor 为Dapr提供了完整的paas管理平台,Layotto短期内无法做到,但需要对齐公有云上主流的部署运维体系。
标准化案列欠缺。Layotto的愿景中希望解决多语言的问题,但开源社区却没有一套标准的公有云部署方案,这让用户更加无法相信其商业化的能力。
Layotto下半年规划
随着云厂商的多样化,跨云部署的场景增加,目前Layotto缺少了一套标准的跨云部署方案,因此Layotto在下半年将会以打造开源产品为目标进行建设,完善开源Layotto的产品化能力。于此同时,鉴于当前Sidecar模式的复杂性,尝试提供轻量级SDK模式,通过动态库加载的方式,让不同语言的应用可以通过函数调用直接调用Layotto。整体路线如下所示:
写在最后
Layotto作为一款开源产品,需要更多的社区的声音,大家有任何想法和需求都可以在该Issue下面讨论,进一步明确Layotto的发展方向和规划。
相关链接
Dapr部署在Kubernetes
Dapr的可观测性
Dapr本地开发
Envoy支持golang插件拓展
The text was updated successfully, but these errors were encountered: