ServerLess -- 除了极简架构和极科运维外，更应该多考虑一下极简开发
文章开头，我向所有喜欢ServerLess的人们说一声对不起先，ServerLess我个人觉得是个好东西，但今天文章中会主要谈谈不足。
Serverless的初衷
极简架构：不需要考虑消息，缓存，数据库分库分表，并发等等问题。
极简运维：云服务器，不需要专门的运维人员。
Serverless的分类
BaaS（Backend as a Service）即后台即服务
FaaS（Function as a Service）即函数即服务
ServerLess的批评声音都有哪些
“运行时间受限的函数是巨大的挑战。而是否需要如此细粒度的拆分是需要回答的第一个问题。有些问题或许变成无解难题又或成本极高，例如分布式数据库事务。”
”Serverless将无状态进行的更加彻底，在不同的调用之间无法共享内存状态，这让复杂业务逻辑代码编写变得更加困难。“
”作为一个新的技术，Serverless还面临着集成测试困难、Vendor Lock-in、调试监控困难、版本控制等诸多不足“
Serverless架构不会成为复杂应用的架构首选，相反，它应该是后端小程序的未来
软件企业技术负责人们如何看Serverless
最近在一个技术论坛，和很多企业技术负责人讨论serverless的时候，大家普遍的表示是serverless和目前的主流技术圈子感觉还很遥远，主要观点有如下：
极简架构：想法是好，但现在的产品局限性很强，与现有的系统整合也是个困难，而且生态不成熟，很容易反而增大了开发成本。MVP阶段弄个即用即扔的试验性产品，到是不错，但在国内，还是很少。
极简运维：现在本身运维成本也是逐年降低的，而且随着技术的进一步成熟，现有的云产品运维成本也不高，而且还能支持未来业务逻辑越来越复杂。
所以，给人的感觉很鸡肋。
同时，Serverless在大家都希望看到的”极简开发“上，似乎没有什么建树，也没有什么好的产品出现。
其实，除了架构&运维外，更多的其实是开发过程的复杂。、
现在开发一个项目/产品的复杂在哪里呢？举个例子来说，如果我们开发一个企业内部管理系统，我们需要
项目/产品经理与企业内部人员讨论需求
将需求与研发人员讨论，拿出业务流程与数据流程设计报告（或概要设计，详细设计）。
项目/产品经理与客户确认需求
开发人员开始开发，完成后提交给相关人员
项目/产品经理拿着第一版产品与客户确认，客户可能提出各种问题，再转给开发人员。
研发人员再进行开发 再来确认。。。
4 - 6这个流程，可能重复几轮。
这当中，还可能出现一系列的问题，比如：
客户不满意，认为做的不是他想要的
研发不满意，认为需求变化过大，很难跟的上
项目/产品经理不满意，感觉两头受气
老板不满意，因为项目赔钱。
极简开发更重要
极简开发是什么？极简开发说大白话就是让开发更简单。
让开发更加简单最直接的思路是
让产品/项目经理在与客户沟通的过程中，把用户需要的业务流程和页面直接配置出来，拿着能运行的产品与客户沟通，快速的多轮沟通完成后进行一些测试，就可以直接上线。
这里面有几个重点
业务流程可以可视化配置，并支持各种灵活设置。（毕竟企业服务的要求各种可能性都有，工具有局限性会让使用场景局限很多）。
页面可以灵活配置，没有局限性。
企业内部的术语，可以配置。（企业做定制化的系统就是为了符合自己的业务流程，所以这个很关键）
有移动端的支持，同时能提供移动端的API。
能够通过简单的配置方式整合其它平台/系统的数据（企业内部数据打通未来将会越来越重要，很多公司接项目时遇到困难也是在这方面）
这样，有了这样的工具后：
如果企业对前端UI风格没有特殊的要求，”配置“出的产品，就可以直接交付使用。
如果企业对前端UI风格有要求，则后台逻辑全配置出来，通过提供的API，自己开发前端UI，满足客户要求。
相信有了这样的工具，才会让我们的开发更加容易，更加快速的满足客户要求，更加灵活的适应市场的变化。
下面是我们打算于2017年10月下旬开源的一款针对于上面所讨论的想法的Serverless引擎，如果大家有兴趣，请关注。