项目的意义 about serverless-devs HOT 3 CLOSED

感谢大佬的Issue，对于项目的意义其实是我在推动这个项目之前一直在考虑的：那就是我们为什么做这样一个项目以及做这样一个项目的意义是什么？

首先，不可否定的是，无论是否支持多云，现在各种Serverless开发者工具真的并不是十分还用，我自己作为一个开发者，我较为深度用过很多厂商的开发者工具，也给一些厂商开发过开发者工具（包括参与阿里云的Funcruft工具，包括开发腾讯云的SCFCLI，也包括开发Serverless Framework的一些组件......），诚恳一点说：每个工具可以说都有自己的优势，好处，也都有自己的劣势；激进一些说：这些开发者工具更多是功能的叠加，而不是产品的建设；再夸张一些的说：这些开发工具的人，可能都没有那些用工具的人熟悉serverless，更是很难站在真正业务角度去考虑问题。举几个个真实的例子：

• 在某公司，我说我们应该要有一些场景化的例子，融入到工具中，或者通过一种app store的形式，展示出来，让用户不仅仅会Hello world，更要让用户知道，在实际应用过程中，应该如何Serverless，但是却得到了产品的反对，产品说：这个东西没意义吧；后来有一次，一起和国外的一些大佬聊天的时候，大佬们说这些场景化的应用，非常重要，此时产品问我：我们为啥没有？
• 在某公司，我曾经问开发者，为什么要一直全栈应用的部署？因为很多全栈应用将很多规格不一样的接口，甚至静态文件都打到了函数计算中，我觉得这并不是很合理，当然没什么问题，但是这种不合理的操作会带来很多额外的问题，例如很多静态文件的增加会导致代码体积过大，加大冷启动效果；很多静态文件被访问，严重影响函数默认的最大并发值（至少目前很多厂商都是这了这个值），不同规格的接口放在一起会导致成本的大规模的提升；但是我说出了我的疑问之后，得到的答复却是：让用户上来就行了。
• 在某公司，我曾经问某工具的开发者，为什么这个工具没有查看函数日志的能力？回答是：我也不清楚，应该没人需要吧；我再问，那么你们平时看日志怎么看？回答是：去控制台刷啊；但是作为一个Serverless的开发者，如果你真的用Serverless在开发项目，我相信，你很难接受，频繁的去控制台刷新日志的这个操作（最主要有时候刷不出来）...
  其实说了这么多，并不是说我在解决什么问题，而是在用几个真实的例子说：我推动做的这个项目，是真真切切想站在用户角度、开发者角度去做，而不是像更多产品一样，站在“产品”角度去做；我不想有太多利益化，KPI化的导向，我不想有更多的产品怎么样的想法，我想的就是：在开发者角度去做一件对开发者更好的事情。

其次，我想说的是，这个工具他有几个特点：
第一个特点是，跨平台，我们提供足够强大的跨平台思路，怎么跨，跨到谁哪里，纯粹是开发者自己说了算的事情，通过插件化和组件化共同作用，我们提供的只是最外层的一个启动平台。换句话说，你可以认为我们提供了你一部手机和一个应用中心，你想玩手机，你要从应用中心下载APP，那么应用中心的APP哪里来的？是组件开发者们自己来开发，所以你说的感觉是让一群熟悉各个厂商serverless标准的人为了降低转移厂商的代价来形成这样的跨平台工具，这是很自然的。实际上可以认为是，不同的组件、应用开发者做一些有趣的事情。当然这种开放的思路，最主要的解的并非是多云，解多云只是顺便；
第二个特点是，可视化，这个平台有一套可视化的方案，当然不能说是终态，也不能说是很强大，但是至少他是一个非常有趣，非常简单方便的工具，通过这个工具，你可以像使用手机应用中心一样，快速的搜索应用，在线创建应用，以及在线对应用进行编辑（告别Yaml的格式，你可以选择Yaml，Json以及可视化编辑）；这个点最主要是要解：案例放置在互联网的每个角落，难以归拢；Yaml格式并不是每个人都愿意都能接受的；更简单更快速的上手体验和进行项目描述；
第三个特点是，组件化和插件化以及资源描述和行为描述，这个部分的优势，我觉得在自动化的时候会表现的更加明显；通过组件化和插件化组合通过资源描述和行为描述组合，不仅仅可以说清楚一个项目的资源，更可以告诉大家我在项目创建前后还要做什么事情。

最后，看到大佬的不能推动标准的建立真的太难了，我深表痛心，是的这个工具还没办法推进Serverless的标准的建立，不是还没办法，而是根本就不能推进，因为目前每个厂商的Serverless都有自己的玩法，都有自己的能力特性，他不想K8S这些东西，已经有了一套标准，各个厂商再去用，Serverless这个东西，纯粹是各个厂商已经开始玩了，才逐渐的想要标准，正如你所看到的CNCF的白皮书，貌似并没有起到更多的标准定制的作用，现在也没有一个组织敢于给Serverless定标准，甚至定义。但是我非常非常非常有信心的一件事，那就是体验层的标准，是可以尝试的，在我做这个工具之前，MidwayFaaS和Malagu等已经在尝试这件事情了，感觉效果也是不错的。其实这正是所想看到的结果，我心中的标准层规范，是说在大部分情况下，我们可以通过一些通用配置，配置各个厂商的某些资源，例如部署一个Express项目到函数计算上，那么可以通过一个固有的通用配置+细节话配置来进行配置。所谓的通用配置这一套可以跨平台来使用，其实就是通过组件化思路做适配层；细节配置这里就和云厂商深度定制化了。所以，这个工具所强调的体验层标准，并不是Serverless的标准，所说的体验层标准，只是希望可以让大家尽可能的有同样的体验；我相信，随着我们社区的庞大，爱好者们的不断涌入，这种体验层面的优化统一，是可以更加完善，完备的。期待ing

我认为，这个工具最主要的意义，并不是抹平云厂商差异，也不是定制Serverless规范（当然也没办法定制），而是可以真正意义上，让Serverless开发者们自己来建设自己需要的工具链，也是真正意义上，希望有一款从开发者出发的工具：站在开发者角度，服务开发者的工具。

可以自己问自己：你在用Serverless么，你用了哪些Serverless工具，这个工具真的满足了你的需要么，你想过自己心中的Serverless工具样子么？

欢迎加入Serverless Devs，如果你觉得某个组件不好，某部分能力有问题，期待与你共建，只要是站在开发者角度，就是站在了这个平台的战略角度。

from serverless-devs.

大佬的见解真是鞭辟入里、发人深省。

from serverless-devs.

没有没有，只是发自肺腑说一些自己心中的事情，其实做这个项目，真的是想站在开发者角度去解决一些开发者的问题。

from serverless-devs.