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在大家都希望看到的”极简开发“上，似乎没有什么建树，也没有什么好的产品出现。

其实，除了架构&运维外，更多的其实是开发过程的复杂。、

现在开发一个项目/产品的复杂在哪里呢？举个例子来说，如果我们开发一个企业内部管理系统，我们需要

1. 项目/产品经理与企业内部人员讨论需求

2. 将需求与研发人员讨论，拿出业务流程与数据流程设计报告（或概要设计，详细设计）。

3. 项目/产品经理与客户确认需求

4. 开发人员开始开发，完成后提交给相关人员

5. 项目/产品经理拿着第一版产品与客户确认，客户可能提出各种问题，再转给开发人员。

6. 研发人员再进行开发 再来确认。。。

7. 4 - 6这个流程，可能重复几轮。

这当中，还可能出现一系列的问题，比如：

1. 客户不满意，认为做的不是他想要的

2. 研发不满意，认为需求变化过大，很难跟的上

3. 项目/产品经理不满意，感觉两头受气

4. 老板不满意，因为项目赔钱。

极简开发更重要

极简开发是什么？极简开发说大白话就是让开发更简单。

让开发更加简单最直接的思路是

让产品/项目经理在与客户沟通的过程中，把用户需要的业务流程和页面直接配置出来，拿着能运行的产品与客户沟通，快速的多轮沟通完成后进行一些测试，就可以直接上线。

这里面有几个重点

• 业务流程可以可视化配置，并支持各种灵活设置。（毕竟企业服务的要求各种可能性都有，工具有局限性会让使用场景局限很多）。

• 页面可以灵活配置，没有局限性。

• 企业内部的术语，可以配置。（企业做定制化的系统就是为了符合自己的业务流程，所以这个很关键）

• 有移动端的支持，同时能提供移动端的API。

• 能够通过简单的配置方式整合其它平台/系统的数据（企业内部数据打通未来将会越来越重要，很多公司接项目时遇到困难也是在这方面）

这样，有了这样的工具后：

• 如果企业对前端UI风格没有特殊的要求，”配置“出的产品，就可以直接交付使用。

• 如果企业对前端UI风格有要求，则后台逻辑全配置出来，通过提供的API，自己开发前端UI，满足客户要求。

相信有了这样的工具，才会让我们的开发更加容易，更加快速的满足客户要求，更加灵活的适应市场的变化。

下面是我们打算于2017年10月下旬开源的一款针对于上面所讨论的想法的Serverless引擎，如果大家有兴趣，请关注。

http://git.oschina.net/yanglf...