3

十七年运维老兵万字长文讲透优维低代码~

 2 years ago
source link: https://blog.51cto.com/u_15605878/5523290
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

十七年运维老兵万字长文讲透优维低代码~

原创

优维科技EasyOps 2022-07-28 17:47:18 ©著作权

文章标签 表单 封装 商业模式 文章分类 Linux 系统/运维 阅读数282

十七年运维老兵万字长文讲透优维低代码~_表单

点开此文的小伙伴

不知道你有没有看

优维老王说「优维LowCode实践」的视频

十七年运维老兵万字长文讲透优维低代码~_商业模式_02

十七年运维老兵万字长文讲透优维低代码~_表单_03

共45分钟,分成12个视频片段

没看过没关系

鹿小U将这45分钟的视频内容整理成下面文字

让你系统的了解

优维低代码的整个框架


低代码,是今天比较热的一个词,其实我们都知道低代码今天的热,是有它自己的原因的。

从2015年创业开始,优维前后服务了很多传统企业的项目客户,我们在服务的过程中其实也发现了一些自己的问题,特别是2019年底,有一个KA的客户提出了一个个性化的需求,对我们带来的触动是蛮大的。

当时的背景就是我们有个项目,客户提出了一个个性化的需求,且必须按照客户要求的方式去实现,否则将无法完成项目结项。对于这个事情,我们当时内部研发评估的时候,如果真做了,需要考虑这个功能对其他项目客户的一个破坏性影响。

十七年运维老兵万字长文讲透优维低代码~_封装_04

我们知道在一个产品里面,其实真正的一个功能,它没办法去兼容很多其它场景,如果真要去兼容,你可能要么就是拉代码分支,要么就在产品版本里面去开特定开关,很明显这两种方式对我们服务的大量2B客户来说,都不是最优的解决方案。所以,在2019年底开始,我们就在寻求一些全新的解决方案,那个时候我们找到的就是LowCode的这种低代码模式。

当然优维的低代码模式在发展过程中,其实也经历了我们自己的一些思考,那我今天大概是从六个方面来讲一下优维低代码的整个框架。

1

低代码发展历史

首先我还是想带大家来看一看低代码的整个发展历史,这是我根据自己个人工作经历来总结的。低代码的发展其实是经过以下三个模式的转变:

1.C/S模式

第一个,低代码其实也不是一个所谓的新技术。我2005年毕业后也做过一些应用系统开发,不过那个时候的应用系统是在C/S的模式下面去做的开发。

当时,我们也有用一些代码工具,比如像Delphi,C++Builder等这类工具,来帮助我们快速的去构建应用程序。在那个时候,S的架构很简单,基本就是DB,然后通过数据库连接JDBC,或者是ODBC的模式来构建应用程序。那主要的低代码的框架,其实是聚焦在C端能力的解决,而LowCode的能力,基本上给我们提供了快速表单的构建模式,帮助我们去达到快速开发的效果。

2.B/S模式

后来2007年进入腾讯之后,当时明显感觉C/S架构模式已经不适用面向C端的2C互联网的应用架构,当时采用的是B/S的模式。

在B/S模式的开发过程中,其实当时大家是没怎么讲低代码开发模式的,更多的是讲前端开发框架,讲前端工程化,怎么去统一化封装。那今天重新回归到2C互联网,虽然整个前后端的工程技术越来越标准化,但是在服务2B的过程中,怎样更快的提升工程效能,那新一代LowCode的开发模式就越发重要。

3.LowCode开发模式

LowCode开发模式,其实还是基于B/S模式下,怎么把前后端的软件工程低代码化。

以上,低代码的整个发展历史大概就是这样一个过程。其实,就我自己来看的话,LowCode并不是一个新的技术,也并不是一个全新的软件工程,更不是用来去替代DevOps的。所以,在行业里面有些专家在谈LowCode的时候,我觉得也不能过度的放大这个技术的作用,也不能够去跟不同维度的其他的方面去对比,比如说软件工程,比如说DevOps等等之类,它仅仅是一个技术工具和手段来满足2B和2C各端应用的快速交付需求。

2

优维为什么要做低代码?

看完低代码发展历史后,回归到优维为什么要做低代码,主要有以下几个方面原因:

1.客户需求已经呈现出个性化趋势

我经常举例来讲,每个人都有穿衣服的一些颜色样式的差别,那对一个2B企业来讲更是如此。不同的行业、不同的企业客户,根据他们的IT架构、IT规模、行业属性、业务规模和业务形态的不同,引发出客户需求在上层的一些重要的差别和变化。

2.商业模式考量

这里浅显的谈谈对商业模式的一个理解。中国商业模式主要有项目制、订阅模式、SaaS模式三个类型。这三种模式,它的一些特点其实是不一样的,比如:

  • 项目制,在中国大部分其实基本上还是以项目制为主,特别是像后端的管理类的软件,基本上是以项目制为主。比如我们做DevOps运维,在进入传统企业的过程中,基本是以项目的形式展开的。那在项目进行的过程中,结合上面客户需求的一些变化,这里面就呈现出很多个性化的需求出来。
  • 订阅模式,其实就是类似于像过去Jira,像国外一些软件的销售模式,基本上是按年付费租约的模式去走的标准化产品交付,那种模式它的定制化需求相对来说少很多。
  • SaaS模式,在HR端、人事等领域相对已经比较成熟,但是在我们这类的管理端,特别是涉及到后端的核心系统,SaaS模式的成熟度,普及度还是非常低的。

在中国现在的商业模式里面,或者是在DevOps领域,面向客户的很多个性化的需求,如何去实现快速定制,决定了我们无可避免的要去寻求一个相应的解决方案。

3.产品工程体系拆解

对于产品,我们很难去做一个信息化的定义。以前我们讲做的是一个成熟的商业软件,今天又在讲我们做是一个产品,一个平台,我们今天在上面构建场景微应用等等之类的,它的说法变化非常多,那在产品工程架构上如何实现一个标准化的能力框架,这一点是非常重要的。

我今天没有去跟大家做一个清晰的定义和划分,什么是产品什么是产品工程,我们考虑的是这个能力体系框架,这个工程体系化如何敏捷性的去适应前端的客户业务需求的变化

4.多快好省满足2B客户服务需求

面向客户需求,如何能有一个敏捷适配的能力?

比如说优维公司EasyOps®平台包含九个产品能力,像CMDB、DevOps、自动化运维、监控等等这些产品,那这九个产品体系到真正以我们的服务方式Delivery到客户端的时候,怎么去Match到客户需求,那这一点,我们需要在客户满意度和成本之间找到一个平衡点

当客户提出一个需求,你越快的去实现,就能更快的满足客户。比如客户提了一个需求,两个月实现和两天实现,这个差别是非常大的,同时对成本要素影响也是非常大的,这里我们度量的一个核心点就是效率。那要又快又好的去满足客户需求,效率我觉得是2B服务里面一个关键的底层度量点,这个度量点如果在这个体系里面被突破了,那我觉得就显得相当的重要。

以上这四个方面,决定了优维选择做低代码是一个必然的趋势。通过对商业模式、客户需求、产品工程、客户满意度的整个考虑,希望构建一个标准化的能力架构,从而带来公司整个收益的增长。

3

关于做优维低代码的一些见解

优维在做低代码的时候,我们其实是有一些观点、见解和立场的,这个立场决定了我们自己要在低代码上做一些投入。

  1. 优维低代码一定是和垂直结合,解决自己领域内相关问题。比如优维低代码是不是用来去解决OA的一些问题,这不是我们去考虑的,我们只考虑在DevOps和运维领域里面的问题,其他领域我们是不看了。
  2. 产品和服务要做到应客户需求变,而低代码是一个最有效的手段。
  3. 在2B服务里面,在客户满意度和成本之间找到一个平衡点,其中核心的关键点就是服务效率。如何在软件工程上、交付手段上形成一些突破,从而真正的解决满意度和成本之间的平衡。

4

优维低代码的技术框架

优维低代码的技术框架由三个部分组成,我们称之为“铁三角”

十七年运维老兵万字长文讲透优维低代码~_商业模式_05

第一个部分是前端部分叫VisualBuilder

在上层要构建微应用时,微应用里面肯定会涉及到大量的页面UI的交付,那VisualBuilder就是主要聚焦在UI的能力上,包括页面的一些事件、数据......包括页面可视化的拖拽式操作,全部由VisualBuilder来封装实现。

第二部分是FlowBuilder流构件

flow其实是工作流,这一部分主要就是把API这一层,怎么去实现一个可视化的编排,可视化的构建。

第三部分是BataBuilder

微应用后端可能需要存储一些数据,那这部分会涉及到model,就是数据模型该怎么去可视化构建,数据怎么去可视化存储

5

优维低代码“铁三角”的技术特点

下面我们就一个个来看一下“铁三角”整个的技术特点。

1.VisualBuilder

业界讲的最多的是可视化编排,拖拽式操作,这是VisualBuilder的核心能力,这个能力其实是一种表单式的能力

在VisualBuilder这部分,为了解决表单的快速构建的问题,我们第一步是做了一个构件化库,从原子构件到业务构件,业务构件和原子构件以及他们之间的组合,我们进一步模板化,构成我们单页面的一个能力,再基于整个业务流和场景,我们进一步把Web化的页面进行组合封装,形成一个Theme的主题库,其业务性就更强了,业务场景性更强了。

十七年运维老兵万字长文讲透优维低代码~_商业模式_06

VisualBuilder它解决的就是整个表单复用性的问题,表单一旦复用性被稳定构建了之后,带来的好处就很大。特别是测试方面,大家都知道,如果页面端一改,你整个测试的模式,你都要去进行验证和回归,这个代价其实蛮高的,那一旦被构件化之后,就被四处复用,如果今天只是构件改了一下,那我仅仅就把构件的这块能力进行测试一下,整个页面端的可用性其实大大增强。

2.FlowBuilder

我们知道,低代码需要跟底下各个平台去打交道,那跟能力平台打交道时,我们必须要有一个API网关,我们称之为“统一服务层”。这一层要把底下的很多能力平台的API注册进来,形成一个API的集市。仅仅有这个API集市肯定还不够,因为这个API集市其实就像刚才讲的前端的页面端一样,它比较偏原生的。

因此,我们在“统一服务层”的上面又加了一个“编排层”。这个编排的原理,没什么特别,它其实有点像流程引擎,它就是把不同的API重新再组合。同时,还提供了整个API的自主式的开发注入。我们不再给大家提供源代码这一层的那个模式,就你还在底下写个服务,再把它注册进来,我们不会再这样做,我们在API自动注册时,我们直接提供了一个Faas网关,直接在上面你用写Function函数的模式去封装你的API能力,可支持Go、Rast,、Python、JavaScript等多种语言。我们基本上把这块就全部封装透明起来,不需要让程序员再去触碰底下复杂的技术。

3.BataBuilder

BataBuilder这个部分,相对来说就更简单一点。

因为图数据库,列式数据存储是自研的。所以,我们基本上就在这两个数据库上面,构建了一个可视化模型构建器,让你去建立整个偏静态的,用图来存储我们的数据模型,还有一个偏动态的列式数据存储模型。

从前到后,从页面端到流程端,到逻辑端以及到后端的数据层,我们把这层的各种能力可视化,低代码化。优维低代码的整个框架,它其实是有自己的一些特色的,它不是简单的BPM式的低代码框架,因为它是应对复杂场景的,有些复杂场景的业务逻辑不是流程流转就可以实现的。

优维研发的低代码,从自身的应用上来说,我们内部开发有200多个微应用,同时我们自己平台级的产品能力,上面讲到的优维EasyOps®的九个产品包含低代码,所有产品的能力,基本上全部迁移到低代码上面,全部低代码化了,大大提高了我们整个工程效率,包括整个产品的交付,高保真模型的构建,产品需求的开发、测试、交付,包括微应用的整个上架,这过程其实非常便捷了,不像以前我们要以传统的那个软件工程的模式去做。

6

优维低代码的核心能力差异点

  1. 全栈低代码化,从页面端到到后端数据存储,基本上是全栈低代码化。
  2. 多语言支持,在API网关,FlowBuilder上面,像GO、Rast等语言,我们都是全部支持的。
  3. 模型级驱动,我们其实没有把数据模型全部简单化、表单化,只是提供单一MySQL这种关系数据存储模型,根据图、列,支持全面存储。
  4. 全开源,低代码核心能力基本上开源出来,确保跟社区生态,更好的去联动。
  5. 我们的整个低代码体系能够对产品级功能进行注入

以上,就是对优维整个低代码体系的一个梳理,其实从2020年向外业界去推低代码至今,我们已经积累很多的客户,包括从行业的不同的客户属性以及场景上面,我们都有落地的一些经验,以及在落地的过程中,我们遇到的一些难点,带来的价值等等,我们都有一些经验积累,下回再跟大家详细的分享一下。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK