云计算的三种服务模式
SaaS
Software-as-a-Service（软件即服务）提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户可以在各种设备上通过客户端界面访问，如浏览器。消费者不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等等；
PaaS
Platform-as-a-Service（平台即服务）提供给消费者的服务是把客户采用提供的开发语言和工具（例如Java，python, .Net等）开发的或收购的应用程序部署到供应商的云计算基础设施上去。客户不需要管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储等，但客户能控制部署的应用程序，也可能控制运行应用程序的托管环境配置；
在PaaS层有专门用来支持应用的云上开发、部署、运行的平台，称之为aPaaS(Application platform as a service)，在 aPaaS 基础上，提供 no-code & low-code 方式开发应用的平台称之为 hpaPaaS (High-productivity aPaaS)，提供快速应用研发能力，比如业务编排、逻辑编排、模型驱动、页面编排等。
IaaS
Infrastructure-as-a-Service（基础设施即服务）提供给消费者的服务是对所有计算基础设施的利用，包括处理CPU、内存、存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。
渐进式思路的研发体系
随着各行各业快速发展，高效的产业链，软件研发行业同样如此，国内的政策也在鼓励着中小企业的发展。这就促使我们用一些标准化模版通过无定制或低定制来完成需求
no-code
no-code是定制化的，是基于模型和标准化的模版，通过可视化建模、搭建等轻量级配置完成应用开发，主要针对标准化场景，不需要写代码
优点：上手快、交付快、犯错少、标准化、体验一致性
缺点： 定制性差，非标准化场景实现起来比较困难，依赖集体的aPaaS平台，移植性差
low-code
low-code是一种低定制的方式，low-code在no-code基础上，需要辅助写少量业务逻辑代码，比如关联数据字段、绑定自定义动作等，也会通过WebIDE去编辑更多源码，但理念上是通过基础设施提供尽量多的功能，让开发者对底层实现无感，以减少代码量。
优点：拥有订制性，开发者可以控制更多自己业务系统。
缺点：依赖具体的aPaaS平台，开发者效率很大程度受制于平台的操作和易用性
pro-code
使用WebIDE和DesktopIDE以源代码方式开发应用，不完全依赖具体平台，开发者需求关注更多底层实现
优点：专业程度高，灵活性大，移植性强
缺点：容易形成人力瓶颈，其它人需要培训才能上手。
实现hpaPaaS的能力
从no-code到pro-code，用一个简单的业务系统来看：
no-code
-
进行业务建模，配置业务规则
-
根据建好的模型选择标准化CRUD模版
-
预览、发布。
low-code
-
将标准化生成的产物，以可视化编辑打开；
-
修改关联字段时间的格式化方式、新增用户信息块；
-
保存、预览、发布。
pro-code
-
将标准化生成的产物在 WebIDE 中打开；
-
编辑视图，比如关联的动作，定位到对应动作代码，修改逻辑；
-
使用 WebIDE 提供的 git 功能，进行代码对比及代码提交；
-
保存、编译、预览、发布。
no-code 和 low-code 试错成本低，在创业时期我更希望使用这两种方式，随着我的业务的成长，价值逐渐被认可，对该产品的要求也变高，这时候我也愿意投入更多，这时候可以采用 pro-code 方式对我的项目进行精装修，这种渐进式交付能力将越来越多的被推崇。
在这过程中，有一个关键点，no-code 到 low-code 再到 pro-code 始终遵循的是一个标准，在我需要时可以被任意方式打开。
虽然我们期望未来业务研发只有很少的工作需要 pro-code 来完成，但 pro-code 的相关技术体系也是不可或缺的，它就是一个全功能开放的底层架构，no-code 和 low-code 在这之上做的更垂直化，所以并不是说不需要了，尤其在做企业级研发，pro-code 的存在更是一颗定心丸。
对于pro-code我们有3点要打通：
WebIDE：pro-code 环节设计上是可以使用桌面 IDE 的方式，但未来必定属于云开发时代，桌面 IDE 天然的和 PaaS 平台有割裂感，过去我们担心 WebIDE 技术不成熟，今天 vscode 引领了新一代的编辑器变革，带来诸如 coder、theia 等功能和性能都很完备的 WebIDE 技术储备，技术上没什么好担心的；
Git 打通：企业级产品，没有那么随意，一般需要强管控，其中版本控制尤为重要，不管是 pro-code 还是 no-code，最终形态都是一种代码形式的标准产物，都应该托管在 Git 仓库上，在必要的时候可以进行回溯和对比；
可视化编辑打通：可视化编辑是 low-code 和 no-code 的代表功能，通过 Recore （统一 DSL）的技术将可视化和 pro-code 打通，是 pro-code、low-code、no-code 三者之间形成互通的必要条件。
