ServerLess -- 除了极简架构和极科运维外,更应该多考虑一下极简开发

flyingnet 2019-06-21

文章开头,我向所有喜欢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...

相关推荐