在Serverless领域，各个云厂商的一较高下还没有完全分出胜负，主观上来说AWS遥遥领先，其余的厂商都在争第二第三;此时此刻，工具链体系就又新开辟了战场。一方面是云厂商的产品纬度、产品能力、产品性能的战斗，另一方面是工具链体系的好用、易用与方便的战斗，两个层面的战斗，让Serverless在备受考验的同时却也依旧战况激烈，愈发的"好看了"。
现在Serverless怎么样了
Serverless的初级产品形态，自被抛出到现在，已经有数个年头了，在去年开始Serverless也逐渐了迎来了所谓的"发展元年"，一方面是各个厂商对Serverless不断更新迭代，甚至还有一些炒作成分;另一方面则是Serverless在一部分人眼中的担忧。
有人认为Serverless是未来，提出了All Serverless、Serverless First的一些说法，各个云厂商也是不遗余力的进行产品能力的拓展，以国内的云厂商阿里云和腾讯云为例，阿里云不断的在底层性能进行完善，在产品能力上进行创新，例如推出了性能实例，推出了容器镜像，推出了硬盘挂载，腾讯云则是在用户体验层面不断的前行，例如与Serverless Framework合作，提供在线安装依赖等。同时，两个云厂商在对外宣传和运营层面也是煞费苦心，阿里云一直在主打性能强，据信通院的最新报告显示，阿里云Serverless在国内占比超60%，远超国内其他云厂商总和，同时阿里云与腾讯云一样，也是信通院可信云评级中的先进级;腾讯则是在毫秒级计费与Serverless Framework的独家合作角度，逐渐的加强宣传，告诉大家，我们便宜好用。从国内排行第一第二的两个云厂商的产品建设力度，投入的力度以及宣传的角度，我们不难发现：云厂商们对Serverless依旧信心满满，随时随地"撸起袖子大干一翻";除了云厂商们的热情高涨之外，伯克利也断言说：Serverless将会引领下一个十年，无论是否真的能引领，至少现在趋势依旧很热。
但是在一部分开发者领域，态度则是孑然相反，InfoQ近日连续推出文章《无服务器已死?这项技术为什么变得人人嫌弃》和《Serverless“革命”为什么已停滞不前?》，尽管文章里面的内容很多是"没跟得上时代"的陈旧思路(例如文章中指出的"编程语言受限"，其实现在大部分厂商都推出了自定义Runtime，甚至阿里云还率先推出了自定义镜像等相关服务等)，但是毕竟是大佬所作，其很多思想也是很多开发者目前最关心和担忧的，例如厂商绑定研究，例如性能不理想等;
除此之外，在很多群里的一些开发者，对Serverless也是抱有不同的态度，有一群吃瓜的，哪里有讨论，就在那里放板凳，另外一群，则是分成了两部分，一部分是觉得Serverless很有趣，可以满足自己需求，乐于接受;另一部分则是觉得这就是炒作，每个"啥子用"，上了就等于被厂商绑架，一定不能上;
所以说现在的Serverless，真的是一个很有趣的现象，一方面是一部分权威人士，大佬对Serverless的看好期待，一堆云厂商的对Serverless狂热投入，一群开发者对Serverless的痴迷和信任;另一方面则是另一群权威人士，大佬对Serverless的不屑一顾，是一群开发者对Serverless的担忧和不看好。
但是无论如何，我相信，能产生这样的对等面也说明了Serverless的热度，否则谁会关注呢?毕竟当年云计算，也是一群人看好，一群人"要远离云计算"，虽然现在没有明确答案，但是我相信，"时间是检验真理的唯一标准"!
Serverless Devs是什么
今天是1024，程序员的节日，阿里云函数计算在昨天晚上，正式对外宣布1024给Servelress开发者的一个礼物：Serverless Devs，那么Serverless Devs是什么?为什么会被这么重视，被当作1024这个各个云厂商都在争相炒作的时间点当作礼物放出来?
其实看过文章的人都应该能知道了，Serverless Devs实际上是一个开发者工具体系，确切来说是一个平台，是一个开源开放的Serverless Cli平台，他无厂商绑定，支持多云配置，他支持可视化编辑，支持资源描述和行为描述，是一款可以在项目全生命周期发挥作用的工具链体系。
感觉有点蒙，还是搞不清楚，其实可以简单体验一下，按照教程来说，是可以先下载的：
npm install -g @serverless-devs/s
国内NPM可能比较慢，可以使用淘宝源：
npm install -g @serverless-devs/s --registry=https://registry.npm.taobao.org
可以s -v看一下版本：Serverless Tool Version: 1.0.0
这里要额外说一下，Serverless Devs的客户端工具实际上是s，单纯的一个字母，我个人感觉还是很不错，至少用起来比较简单，按照官方文档，迫不及待的尝试一下s gui:
稍等片刻，可以完成安装：
此时此刻，我们选择一个fc-poem的进行一下体验：
选择fc-poem
选择一个项目创建的目录
填写对应参数(我这里使用的默认的)
由于没有密钥信息，我这里选择创建密钥
完成之后点左下角的部署，稍等片刻
通过浏览器打开测试
官方提供的测试视频：
Serverless CLI：Serverless为你写诗案例实践
Serverless GUI：Serverless博客系统案例实践
Serverless Devs的优势是什么
官方文章给的是：
可支持主流 Serverless 服务/框架
Serverless Devs 是一个组件化与插件化的 Serverless 开发者平台，开发者可以在平台中可插拔式的使用不同 Serverless 的服务和框架，同时可参与组件和插件的开发。无论是工业级的 Serverless 服务，还是各类开源的 Serverless 框架，Serverless Devs 都可友好支持。开发者无需对市面上每一款 Serverless 工具进行研究和学习，只需通过 Serverless Devs ，就可以简单、快捷的“上手”主流 Serverless 服务和框架。
可视化编辑和部署
Serverless Devs 拥有可视化编辑和部署流程。在 Serverless Devs App Store 中，使用者可以通过关键词快速检索所需的应用案例或组件，并且通过可视化编辑完成项目配置，通过鼠标点击即可完成项目部署。无论是进行项目体验，还是进行项目开发、运维，在应用中心的加持下，在可视化编辑和部署的加持下，Serverless 项目的整体部署时间缩短了近 1 倍。同时，Serverless Devs App Store 也是一个开发者开源共建的平台，所有用户都可以在应用中心发布自己的组件和应用供更多人学习、参考以及使用。
灵活与开放的使用方法
与绝大部分的开发者工具不同的是，Serverless Devs 在进行项目描述时不仅仅可以对函数计算、API 网关、对象存储等资源进行描述，也可以通过 Serverless Devs 提供的插件以及 Hook 进行 Install、Build、Publish 等行为描述。与此同时 Serverless Devs 不会对每个组件的命令进行限制，而是鼓励开发者针对不同的组件，开发不同的能力来应对更多、更复杂的场景，以阿里云函数计算组件为例，它不仅仅支持函数的部署和移除这样的传统能力，还支持日志查询，指标查询，本地构建，依赖安装，调试等更多定制化的能力。
其实在我心中，Serverless Devs最重要的优点是1+3。
一种思路：站在开发者角度并非站在产品角度
首先，不可否定的是，无论是否支持多云，现在各种Serverless开发者工具真的并不是十分好用，我自己作为一个开发者，我较为深度用过很多厂商的开发者工具，也给一些厂商开发过开发者工具(包括参与阿里云的Funcruft工具，包括开发腾讯云的SCFCLI，也包括开发Serverless Framework的一些组件……)，诚恳一点说：每个工具可以说都有自己的优势，好处，也都有自己的劣势;激进一些说：这些开发者工具更多是功能的叠加，而不是产品的建设;再夸张一些的说：这些开发工具的人，可能都没有那些用工具的人熟悉serverless，更是很难站在真正业务角度去考虑问题。举几个个真实的例子：
在某公司，我说我们应该要有一些场景化的例子，融入到工具中，或者通过一种app store的形式，展示出来，让用户不仅仅会Hello world，更要让用户知道，在实际应用过程中，应该如何Serverless，但是却得到了产品的反对，产品说：这个东西没意义吧;后来有一次，一起和国外的一些大佬聊天的时候，大佬们说这些场景化的应用，非常重要，此时产品问我：我们为啥没有?
在某公司，我曾经问开发者，为什么要推广全栈应用的部署?因为很多全栈应用将很多规格不一样的接口，甚至静态文件都打到了函数计算中，我觉得这并不是很合理，当然没什么问题，但是这种不合理的操作会带来很多额外的问题，例如很多静态文件的增加会导致代码体积过大，加大冷启动效果;很多静态文件被访问，严重影响函数默认的最大并发值(至少目前很多厂商都是这了这个值)，不同规格的接口放在一起会导致成本的大规模的提升;但是我说出了我的疑问之后，得到的答复却是：让用户上来就行了。
在某公司，我曾经问某工具的开发者，为什么这个工具没有查看函数日志的能力?回答是：我也不清楚，应该没人需要吧;我再问，那么你们平时看日志怎么看?回答是：去控制台刷啊;但是作为一个Serverless的开发者，如果你真的用Serverless在开发项目，我相信，你很难接受，频繁的去控制台刷新日志的这个操作(最主要有时候刷不出来)…
其实说了这么多，并不是说我在解决什么问题，而是在用几个真实的例子说：我推动做的这个项目，是真真切切想站在用户角度、开发者角度去做，而不是像更多产品一样，站在“产品”角度去做;我不想有太多利益化，KPI化的导向，我不想有更多的产品怎么样的想法，我想的就是：在开发者角度去做一件对开发者更好的事情。
目前而言这个工具还没办法推进Serverless的标准的建立，不是还没办法，而是根本就不能推进，因为目前每个厂商的Serverless都有自己的玩法，都有自己的能力特性，他不想K8S这些东西，已经有了一套标准，各个厂商再去用，Serverless这个东西，纯粹是各个厂商已经开始玩了，才逐渐的想要标准，正如你所看到的CNCF的白皮书，貌似并没有起到更多的标准定制的作用，现在也没有一个组织敢于给Serverless定标准，甚至定义。但是我非常非常非常有信心的一件事，那就是体验层的标准，是可以尝试的，在我做这个工具之前，MidwayFaaS和Malagu等已经在尝试这件事情了，感觉效果也是不错的。其实这正是所想看到的结果，我心中的标准层规范，是说在大部分情况下，我们可以通过一些通用配置，配置各个厂商的某些资源，例如部署一个Express项目到函数计算上，那么可以通过一个固有的通用配置+细节化配置来进行配置。所谓的通用配置这一套可以跨平台来使用，其实就是通过组件化思路做适配层;细节配置这里就和云厂商深度定制化了。所以，这个工具所强调的体验层标准，并不是Serverless的标准，所说的体验层标准，只是希望可以让大家尽可能的有同样的体验;我相信，随着我们社区的庞大，爱好者们的不断涌入，这种体验层面的优化统一，是可以更加完善，完备的。期待ing
我认为，这个工具最主要的意义，并不是抹平云厂商差异，也不是定制Serverless规范(当然也没办法定制)，而是可以真正意义上，让Serverless开发者们自己来建设自己需要的工具链，也是真正意义上，希望有一款从开发者出发的工具：站在开发者角度，服务开发者的工具。
可以自己问自己：你在用Serverless么，你用了哪些Serverless工具，这个工具真的满足了你的需要么，你想过自己心中的Serverless工具样子么?
三个特点
第一个特点是，跨平台，我们提供足够强大的跨平台思路，怎么跨，跨到谁哪里，纯粹是开发者自己说了算的事情，通过插件化和组件化共同作用，我们提供的只是最外层的一个启动平台。换句话说，你可以认为我们提供了你一部手机和一个应用中心，你想玩手机，你要从应用中心下载APP，那么应用中心的APP哪里来的?是组件开发者们自己来开发，所以你说的感觉是让一群熟悉各个厂商serverless标准的人为了降低转移厂商的代价来形成这样的跨平台工具，这是很自然的。实际上可以认为是，不同的组件、应用开发者做一些有趣的事情。当然这种开放的思路，最主要的解的并非是多云，解多云只是顺便;
第二个特点是，可视化，这个平台有一套可视化的方案，当然不能说是终态，也不能说是很强大，但是至少他是一个非常有趣，非常简单方便的工具，通过这个工具，你可以像使用手机应用中心一样，快速的搜索应用，在线创建应用，以及在线对应用进行编辑(告别Yaml的格式，你可以选择Yaml，Json以及可视化编辑);这个点最主要是要解：案例放置在互联网的每个角落，难以归拢;Yaml格式并不是每个人都愿意都能接受的;更简单更快速的上手体验和进行项目描述;
第三个特点是，组件化和插件化以及资源描述和行为描述，这个部分的优势，我觉得在自动化的时候会表现的更加明显;通过组件化和插件化组合通过资源描述和行为描述组合，不仅仅可以说清楚一个项目的资源，更可以告诉大家我在项目创建前后还要做什么事情。
总结
Serverless Devs 实际上是一个Serverless工具链体系的雏形，他目前包括命令行工具和GUI可视化界面，无论是前者还是后者，这个工具链体系都是在努力的尝试去解这样几个问题：
厂商绑定严重，这个工具正在努力通过组件+插件方法，在体验层面，让厂商绑定的危险变小，顾虑变少;
项目描述复杂，目前大部分的Serverless开发者工具都是Yaml或者Json进行资源描述，其实这个是蛮复杂的，如果可以通过可视化的形式进行搜索、查询以及编写项目资源，这将会在使用的时候带来极大的便利;
实际使用过于复杂，Serverless很多时候会涉及到很多产品，在实际使用过程中，经常要执行很多指令或者做很多操作才能将项目部署到线上，但是Serverless Devs通过行为描述的引入，便于项目的自动化，例如部署前自动执行install、build，执行后自动执行publish等，这将会对自动化和项目的后期维护带来巨大的便利;
最后，引用官方的一句话做结：Serverless Devs可以让你像使用手机一样玩转 Serverless
标签： serverless
营业执照公示信息