低代码！解锁运维开发新姿势，人人都是OpsDev

“ 低代码开发模式绝不是一个页面设计工具，而是一种“所见即运行”的应用开发交付新模式。Who Design，Who Build，Who Run！”

这几年运维能力平台化发展得特别快，基本上摆脱了过去的脚本时代和手工作业时代，大部分的工作都是依赖运维平台进行。无论是自建还是共建，都能看到运维能力平台化，逐渐成为主流。但我们不得不正视几个现实：IT变化特别快，业务所依赖的新技术不断涌现，由此运维平台的演进也要快速跟上，如监控领域的工具变化；运维平台的碎片化已经成为传统企业的痛点之一，能否提供技术解决方案实现能力的快速整合，挑战和必要性相伴相随；历史遗留平台不能直接废弃，如何把它们的能力糅合到整体体系中。

本文是作者过去十几年来运维工作经历（包括五年多的创业），糅合对运维的业务理解，以及运维开发的手段，提出了一个新的解决方案：低代码开发模式。低代码的更大价值，是需要和垂直平台进行结合，这一点和大数据平台的作用类似。来，一起看看什么是运维低代码开发模式！

01

运维开发的困境

从开发语言的角度来说，运维开发OpsDev也经历过几个阶段：

• shell脚本时代 shell编程是运维从业者的最基本要求，届时shell脚本满天飞。配合expect，实现远程操作，那是家常便饭。

• Python时代 shell脚本无法应对复杂的事务操作，python编程因为入门快，模块丰富，编程容易，成为运维人员的必备语言。此时配合上层一个工具流程编排，基本上实现了各种运维复杂操作。OS上开始出现运维Agent，Agent承担起文件通道、命令通道、数据通道的作用。
• 多语言时代，特别是Go 运维平台覆盖的范围越来越广，涉及到的组件和框架也越来越多，面对的性能挑战也越来越大，Python、Java、GO、Rust等开始逐步进入到运维平台之中。

我们可以看到运维要掌握的语言越来越多，包括前端的Vue、React等框架，对于一个运维开发没有太多积累的团队来说，是个巨大的挑战。

今天大家非常强调平台的开放性，Restful API越来越多，OpenAPI成为开放标准（我们平台有上千个）。但我们不得不问，如何把这些API的能力转换成前端onsole能力？这依然还有不小的距离要走。回到前端开发，我想这更是运维的短板，虽然有一些前端模板提供，但是复杂的交互设计逻辑还是让运维望而却步。

还有很多细节层面上的问题，比如说前后端开发的沟通协作、API文档更新不及时、一个功能交付参与的IT角色非常的多（产品/交互/前端/后端/测试）、测试验证等等，毕竟复杂系统最后都要面临一个挑战——它本质上是个技术工程问题。

为了有效解决以上遇到的挑战，能否把门槛降低到人人都可以成为运维开发者？低代码！低代码！低代码！。

02

何为低代码

关于低代码，Wiki上给出的定义：A low-code development platform (LCDP) is software that provides a development environment used to create application software through graphical user interfaces and configuration instead of traditional hand-coded computer programming，A low-code model enables developers of varied experience levels to create applications。

但我觉得这份表述不好，没有道出低代码开发模式的本质，它依然围绕的是开发者，其实不然，来看下一段?

Low-code is a visual development approach to application development. Low-code enables developers of varied experience levels to create applications for web and mobile, using drag-and-drop components and model driven logic through a graphic user interface. Low-code platforms relieve non-technical developers from having to write code while still supporting professional developers by abstracting tedious plumbing and infrastructure tasks required in application development. Working together, developers in the business and IT create, iterate, and release applications in a fraction of the time it takes with traditional methods. This low-code application development enables production of a full range of app types for disparate use cases. These app types range from upgrading legacy applications to IoT-enabled smart apps.

低代码是用可视化开发方法来开发应用程序。低代码使不同经验水平的开发人员能够通过图形用户界面使用拖放构件和模型驱动逻辑为 Web 和移动创建应用程序。低代码平台通过抽象应用程序开发中所需的繁琐管道和基础架构性任务，使非技术开发人员不必编写代码，同时仍支持专业开发人员。业务和 IT 开发者协同工作，相对于传统方法，只是它时间的一小部分，就能创建、迭代和发布应用程序。低代码应用程序开发支持各种应用类型开发，包括升级旧版应用程序到新型 IoT 的智能应用。

那它和过去RAD（Rapid Application Develop，快速应用开发）有什么不同呢？

我们都知道在C/S时代，RAD的模式大行其道，Delphi、C++Builder等等，完全是可视化编程。可视化编程平台都提供了大量的控件，可以快速复用，可以说，它们是C/S时代C端的主要编程工具。后来随着互联网应用B/S架构的兴起，这些开发工具都退出了历史舞台，逐步由网页端开发工具（早期网页制作三剑客）。到后来出现的各种前端开发框架、JS/CSS等框架所替代，此时几乎看不到任何可视化编程的影子。但最近几年低代码又重新兴起。其实核心原因还是很多应用逐步切换到B/S模式下，特别是管理软件，个性化需求特别多，需要有更高效的解决方案。总结来说，核心的差别，其实就是不同应用架构下的开发模式。

据说微软公司内部有10万员工每天在使用低代码平台Power Platform，有超过8万个员工在使用Power Apps写基本的APP应用。Power Platform面向所有用户提供服务，无论是企业用户还是员工本人都能快速上手。

03

低代码平台的核心技术栈

低代码开发模式绝不是一个页面设计工具，而是一种“所见即运行”的应用开发交付新模式。为了实现这一目标，运维的低代码平台是如何保证的？从技术角度来说，一个完整的低代码开发模式包含四个核心能力模块：

• 统一数据模型（Data Model） 在低代码开发模式下，数据模型的设计细节要对非专业人员屏蔽，首先要屏蔽的能力是数据库能力要求，因此必须提供的统一数据模型。 统一的数据模型首先必须要要求统一的数据库平台，数据库底层要支持分布式和高可用，对上层设计透明。在模型设计之后，进入运行态遇到的挑战是索引的问题。我们不知道上层应用如何去使用数据库，很容易遇到数据库性能问题。 所谓的统一数据模型，资源实体模型统一可视化设计，由一个统一的数据库来存储，我们建议使用非关系数据库，Nosql。我们选型是图数据库，第一建模简单，第二，实体关系查询简单，容易转换成Graph查询语言。
• 统一服务网关（Common Services Gateway） 在一个大的运维体系中，对外开放的API越来越多，需要有一个统一服务网关来做接入，它承担如下职责： a、API统一注册与发现。所有的API统一注册到服务网关，同步和异步机制全部封装起来。 b、统一认证与鉴权。API授权认证全部由网关来完成，前端调用透明 c、服务编排。对不同平台的API可以做服务编排 d、服务路由。实现API服务调用到后端的透明 服务网关的API管理，使用YAML文件定义，可读性强，最终要界面化管理。
• 统一构件平台（Data Providers） Provider 构件是一种特殊类型的构件，它不提供任何界面展示的能力，仅提供数据处理的能力。 数据更新提供了两种机制：定时更新和主动更新。该构件是封装了方法和事件，后端的核心组件：

作为一个数据提供者，从后端获取数据的模式就是API调用，但我们知道API经常变化，如何来协调前后端调用行为一致？此时必须借助一个API契约网关来完成：

• 微应用开发平台（Next Builder） 后端的API和数据准备好了，接下来进入到真正的前端低代码可视化编排了。其实我们都知道，页面是可被拆解的，是由一个个构件（Component）组成的，基本上可以分成两类构件：原子构件和业务构件。原子构件是一种无状态构件，比如说界面所需要的按钮，消息框等等；业务构件是和业务相关的，比如说获取CMDB主机列表、应用部署等等。最终会形成一个丰富的构件库：

利用这些构件，我们就可以做页面可视化编排了，路由、构件编排，最终生成一个应用，直接Build 发布，下图是一个完整应用的访问关系。

构件化开发的核心是设计、构建、运行等可视化！决不能变成简单的界面设计器。

04

低代码如何与垂直中台结合

在前面的一篇文章中介绍了【运维遇上中台，送分或送命？而我理解的运维中台是这样】，运维中台是把一个公司所需要的运维平台体现建设起来，但业务部门需求千变万化，个性化与快速交付只能由低代码来保证。运维平台Platform（中台）+Plugin（构件化平台）整体架构如下：

• 中台层 按照业务域划分的原则，构建各个能力平台。对于这个复杂体系，在之前的文章中，我从运维生命周期的角度分了九个能力域。
• 低代码开发平台 低代码开发中心就是把中台的能力整合起来，然后二次开发定制，实现用户的个性化需求。

这个机制带来很多好处，比如中台能力保持稳定，不被个性化需求冲击；中台可以快速延伸，只要确保API开放就好；低代码开发能够弹性适应用户各类需求，以【微应用】的形式对外体现。

05

低代码模式带来的变化

低代码开发模式绝不是一个页面设计工具，而是一种“所见即运行”的应用开发交付新模式（第二遍）。模式变化了之后，有几个变化是自然而然的：

• 组织架构 业务构件谁来封装提供？低代码开发者是谁？MicroAPP谁来实现？一个产品架构调整必须要有匹配的组织架构。为此我们单独一个构件开发组，让他完成后端中台很多能力构件化封装，到Data Providers这一层。构件开发出来后，再交给微应用开发组，可视化编排。 这个地方要注意，内外开发的模式要一致，不能两个标准。内外流程不一致，很容易弱化低代码开发模式的效果。
• 研发模式 采用低代码开发模式，大大简化了开发交付过程，特别是对于低代码平台的使用者来说，可以完全忽略前端和后端的人员储备，“人人都是产品经理”“Who Design，Who Build，Who Run”。

• 效率与质量 在质量和效率方面，我们能看到诸多收益和价值，核心点是低代码让交付成本变得足够的低，从容应对需求变化。可复用的大量构件，从原子化角度保证了平台的交付质量。从产品交付链分析来看，对于产品流水线的每一个环节，低代码开发模式的好处也非常明显：

经过我们实际生产验证，一个微应用的开发，如果走传统模式估计要15天，而采用低代码开发模式则只需要3天左右的时间。需求响应从2-3天左右，缩短到3个小时以内。关键是一个交付工程师独立完成，而不是之前要依赖一个多角色完整的团队！

06

低代码真的是未来么？

低代码开发模式绝不是一个页面设计工具，而是一种“所见即运行”的应用开发交付新模式（第三遍）。“天下武功，唯快不破”！如若把产品放到更长的时间维度去看，需求错误是不可避免，而更重要的是如何错了快速调整。在DevOps里面有个重要的探讨课题——需求一致性，需求一致性就是不断快速迭代方能一致。甚至说需求在VUCA时代，变化和调整成为必然，前端变，后端IT变化如何快速跟上？今天的管理软件或者类解决方案软件，低代码开发模式才能在质量和效率、成本三者之间取得平衡。

低代码超出了语言、超出了工具，可以成为运维开发的新选择！实现每个运维人员的快速转型。