hpaPaaS

云计算主要分为三大类服务：软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)。在 PaaS 层有专门用来支持应用在云上开发、部署、运行的平台，称之为 aPaaS (Application platform as a service)，在 aPaaS 基础上，提供 no-code & low-code 方式开发应用的平台称之为 hpaPaaS (High-productivity aPaaS)，提供快速应用研发能力，比如业务编排、逻辑编排、模型驱动、页面编排等。

方式	描述	优点	缺点
no-code	基于模型和标准化的模板，通过可视化建模、搭建等轻量级配置完成应用开发，主要针对标准化场景，不需要写代码	上手快、交付快、犯错少、标准化、体验一致性	定制性差，非标准化场景实现起来比较困难，依赖具体的 aPaaS 平台，移植性差
low-code	在 no-code 基础上，需要辅助写少量业务逻辑代码，比如关联数据字段、绑定自定义动作等，也会通过 WebIDE 去编辑更多源码，但理念上是通过基础设施提供尽量多的功能，让开发者对底层实现无感，以减少写代码	相比 no-code 拥有更大定制性，开发者可以控制的更多一点	依赖具体的 aPaaS 平台，开发者效率很大程度上受制于平台易用性
pro-code	使用 WebIDE 和 DesktopIDE 以源代码方式开发应用，不完全依赖具体平台，开发者需要关注更多底层实现，比如调用远程服务等	专业程度高、灵活性大、移植性强	容易形成人力瓶颈，其它角色想帮忙也使不上劲

产品分析

Microsoft PowerApps 微软全家桶服务集成的非常好，比如 excel，全站写代码的地方都统一为 excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分强大，定位 hpaPaaS (low-code)；
Google AppMaker 谷歌产，谷歌全家桶服务集成的非常好，谷歌工程师文化在 SCRIPTS 体现的比较极致，无论是后端、前端都使用开发生态的 js 语法，代码提示十分友好，定位 hpaPaaS (low-code);
Salesforce SaaS 平台领头羊，集 IaaS、PaaS、SaaS 与一体的云平台，目前市值 1255 亿美元;
Sap 集 IaaS、PaaS、SaaS 与一体的云平台，相比 salesforce，使用的技术要新一些，体验上要好一些，目前市值 1577 亿美元；
OutSystems 提供桌面 IDE，最近提供的 OutSystems AI 能够辅助模型设计，定位 hpaPaaS (low-code)，作为后起之秀，表现不俗，已获得多轮融资，在 2018 年估值 10+ 亿美元，俨然成为下一个独角兽。

应用研发能力对比如下：

Core Ability	OutSystems	PowerApps	AppMaker	Sap	Salesforce
元数据 (Metadata)	✅	✅	✅	✅	✅
业务对象/实体定义 (Entity)	✅	✅	✅	✅	✅
实体关系维护 (Relations)	✅	✅	✅	✅	✅
业务规则 (Business Rules)	✅	✅	Code	✅	✅
统一的数据接入层	✅	✅	✅	✅	✅
云服务集成	✅	✅	✅	✅	✅
模型驱动开发 (Model Driven)	✅	✅	✅	✅	✅
UI 可视化编排 (Designer)	✅	✅	✅	✅	✅
动作流/逻辑编排 (Action/Logic Flows/Client)	✅	✅	Code	Code	✅
业务流/业务编排 (Business Process Flows/Server)	✅	✅	❌	✅	✅
可扩展的组件生态	✅	❌	❌	✅	✅
国际化(Localisation)	❌	✅	-	✅	✅
响应式 app 研发	✅	✅	✅	✅	✅
WebIDE	桌面集成式	❌	❌	✅	✅
版本记录/版本控制	✅	✅	✅	✅	✅
代码仓库集成	❌	❌	❌	✅	✅
运维	一键部署、一键上云	一键发布	一键发布	✅	✅

企业级 hpaPaaS

中后台业务大多是和表单、表格相关的，这对 hpaPaaS 平台来说是好事，但真正代表企业级场景特别是财务、法务等系统，涉及到的表单可以用魔鬼来形容，比如表单嵌套表格，表格再嵌套表格（存在必然有合理之处），无法使用一套规则来描述，强大如 AppMaker 或 PowerApps，对这类问题基本无解，主要是没有提供 backup 机制，企业级应用最初始状态大多是定制型应用，如何进化为标准化的配置型应用，进一步成为解决方案或商业能力，这是企业级 hpaPaaS 平台需要重点解决的。

将较年轻的产品 AppMaker 和 PowerApps 定义为商业级解决方案，将较成熟的 SAP 和 Salesforce 定义为企业级解决方案，商业级能解决大多数通用问题，而企业级是要能解决更多复杂性问题，面对复杂性企业级问题时，我认为最起码要做到俩点：

将不同场景所需要的能力进行分解、分层，最后通过能力的整合来应对，提升灵活变通能力；
同时有通用方案和兜底方案，多种方案之间应该遵循统一标准，是打通融合的。

我们的业务场景可以分为以下几类：

表单流程类型应用，模式较固定、通用。
数据报表类型应用，展示数据图表、报告，偏展示型。
C 端应用（移动端偏多），重视交互体验，优化信息流。
管理型后台应用，大量 CRUD 操作页面，主要逻辑在后端。
业务职能型，譬如财务、法务领域应用，业务流程、业务规则、业务逻辑、角色权限等要求高。

从 no-code 到 pro-code

迭代一（no-code 开发）最初比较简单，符合标准化的 CRUD：

进行业务建模，配置业务规则；
根据建立好的模型选择标准化 CRUD 模板，直接产出；
预览、发布。

迭代二（low-code 开发）但是有些地方需要稍作定制，比如时间戳的格式化、页面上需要额外展示用户详细信息：

将标准化生成的产物，以可视化编辑打开；
修改关联字段时间的格式化方式、新增用户信息块；
保存、预览、发布。

迭代三（pro-code 开发）随着业务复杂度变高，很多业务逻辑需要写更多代码，也希望代码被版本控制、进行 diff 等：

将标准化生成的产物在 WebIDE 中打开；
编辑视图，比如关联的动作，定位到对应动作代码，修改逻辑；
使用 WebIDE 提供的 git 功能，进行代码对比及代码提交；
保存、编译、预览、发布。

no-code 和 low-code 试错成本低，在创业时期我更希望使用这俩种方式，随着我的业务的成长，价值逐渐被认可，对该产品的要求也变高，这时候我也愿意投入更多，这时候可以采用 pro-code 方式对我的项目进行精装修，这种渐进式交付能力将越来越多的被推崇。在这过程中，有一个关键点，no-code 到 low-code 再到 pro-code 始终遵循的是一个标准，在我需要时可以被任意方式打开。

对于 pro-code 核心关键点有：

WebIDE：pro-code 环节设计上是可以使用桌面 IDE 的方式，但未来必定属于云开发时代，桌面 IDE 天然的和 PaaS 平台有割裂感，过去我们担心 WebIDE 技术不成熟，今天 vscode 引领了新一代的编辑器变革，带来诸如 coder、theia 等功能和性能都很完备的 WebIDE 技术储备，技术上没什么好担心的；
Git 打通：企业级产品，没有那么随意，一般需要强管控，其中版本控制尤为重要，不管是 pro-code 还是 no-code，最终形态都是一种代码形式的标准产物，都应该托管在 git 仓库上，在必要的时候可以进行回溯和对比；
可视化编辑打通：可视化编辑是 low-code 和 no-code 的代表功能，通过前端的工程化技术将可视化和 pro-code 打通，是 pro-code、low-code、no-code 三者之间形成互通的必要条件。

最近更新于 0001-01-01