苹果|低代码/无代码,在国内还有多长的路要走?

“为什么我会关注 CSDN?因为我觉得 CSDN 是一个很好的生态 , 很多人去分享自己的知识 , 传播理念 。 相信在中国 , 像 CSDN 这样的开发者生态 , 未来是会让全球都瞩目和关注的一个技术交流平台 , 所以也希望能够与整个生态里面的开发者 , 从业人员多做深度交流 。 ”胡柏说 。
实现全民开发 , 是无代码/低代码平台的愿景和使命 。 数字化和网络化使得各行各业的客户对应用开发的需求更加个性化 , 期望的开发周期也越来越短 , 传统的开发方式已经难以满足客户的需求 。 而无代码/低代码平台可以通过总结现有的业务逻辑 , 标准化流程 , 使得非开发者也能在培训和学习之后从事开发工作 , 实现全民开发 , 在满足市场瞬息万变的需求的同时降低开发所需成本 。
近几年来 , 低代码领域发展迅速 , 知名企业 AWS、Google、Microsoft、Oracle、Gartner 在发布的报告中指出 , 到2024年四分之三的大企业将会使用至少4种低代码开发平台 , 用于信息化应用开发 。 届时 , 65%的应用开发将通过低代码完成 。
- 为什么低代码平台能够在众多开发平台中脱颖而出?
- 低代码平台实际应用有哪些优势和长处?
- 中国低代码领域的发展方向是什么?
- 低代码平台还有哪些问题亟待解决?
2019年12月 , 低代码平台领域创新企业 “ClickPaaS” 正式对外宣布分别完成晨兴资本领投的数百万美元 A 轮融资 , 以及明势资本领投的数百万美金A+轮融资 , 累计融资总金额约千万美金 。 今天就跟随我们 , 和胡柏先生深入分析中国低代码领域的发展历程和挑战 。 以下为采访精华 , 话不多说 , 让我们一起看看!
胡柏
开阔眼界、沉淀经验 , 只为一朝厚积薄发
CSDN:过去你一直是在国外工作 , 回国创业的契机和原因有哪些?
胡柏:我是交大计算机毕业 , 学习的方向是算法和理论 , 读书的一半时间在日本研究所研究企业应用软件算法和理论 , 做应用架构的技术开发跟研发 。
毕业之后因为家庭的原因加入了甲骨文 , 甲骨文当时有一个培训生计划(training program) , 会把销售、售前、技术 , 研发这些岗位都经历一遍 , 最后到了甲骨文的应用组 。 甲骨文分两条线 , Tech 和 Apps 。 TECK 是数据库 , APPS 是做各种各样应用产品 。
2010年 , 我加入了美国的另外一家公司 , 做跨国企业信息化架构的服务 。 2015年我回到中国做 ClickPaaS 的原因是:我们在美国看到 Salesforce一步一步占领了 Siebel 市场 , 原来这个领域最好的软件叫 Siebel , 完全占据头部市场 。 经历这个过程是非常震撼的 , 也引发了我的兴趣 。 Salesforce 取代 Siebel从商业上来看是因为:Siebel 当年被 Oracle 并购了 , Oracle 并购完之后消化不良 , 企业文化融合出现了问题 。
【苹果|低代码/无代码,在国内还有多长的路要走?】同时 , 美国的应用级软件都是先做应用技术层 , 再做应用层 , Siebel 有一个核心底层 Siebel Tools , 今天我们国家的电信的部分系统都还运行在 Siebel Tools 上面 。 Salesforce 把 Siebel 的 Siebel Tools(核心底层)云架构化了 , 就形成了 Force.com , 可以说是当年第一代应用 PaaS 平台 , 理念是相同的 , 但是它做了技术迭代和云架构化 , 采取了云原生的技术 。
我当时在美国花了一年时间不断去了解和学习 Force.com 的特点 。 深度的去分析和对比了 Oracle 和 Salesforce 的应用架构层的设计理念 。
2014年 , 很多国内朋友告诉我:国内头部市场数字化项目和数字资产大规模定制化的时间到了 。 我刚毕业的时候 , 国内头部企业用 Oracle、SAP 是想学欧美最佳实践 。 10年之后 , Oracle、SAP 被选择 , 因为它们是核心架构平台 , 大量的业务需求是基于 Oracle、SAP 的平台二次开发出来的 , 这里面有着巨大的市场需求 。
我原来做的工作是在这个领域 , 国内的朋友建议我们回来试一试 , 所以就回来了 。
以场景为核心的低代码平台 , 从非主流到主流之路CSDN:请大概介绍一下整体的技术架构或技术方案 , 及构想的技术演进路线 。
胡柏:2015年 , 我们要做的产品、功能、设计路径已经做了详细的规划 , 有80多个核心功能点 , 花了5年做产品路径演进图 , 因为这不可能一蹴而就 。 我们在早期完成了 MVP , 也完成了验证 , 做到了替换原来 Oracle、SAP 的开发方案 , 跟 Oracle、SAP 产品形成良性互补 。
Low code 和 No code 是一个比较宽泛的概念 , 在美国实际上是有两条路径的 。
第一条路径:表驱动路径 。 通过一张类似 excel 表来实现的一个轻应用的场景 , 本质来讲是一个 SaaS 工具 。
第二条路径:PaaS 类 。 叫 Model driven 或者 Domain model , 指领域模型驱动 , 我们不是有领域模型开发方法论吗 , Domain driven design and development , 我们做的就是这一类 。
我们先做了通用技术型 PaaS , 解决最基本元原生的诉求、基础架构 。 再往上做了高性能 PaaS(High Performance PaaS) , 高性能 PaaS 就是中间件 , 高性能、高平台、高扩展 , 比如说消息队列、缓存 , 做一个组合 。 解决的场景里面有大规模交易类场景 。
在此之上是 Model , 或者是 Domain Model , 一个领域模型 , 我们做的是让业务专家或者领域专家把领域模型画出来 , 然后转换成一个应用系统 , 通过解析元数据去运行领域模型构建出来的应用 。
当领域模型越复杂 , 运行效率的损失就越高 , 需要有方法去弥补性能的损失 。 比如用 C 语言写效率是最高的 , 你用 Java 写效率可能会损失一点 。 用更接近自然世界的语言写会更加损失效率 。 所以需要下面有一种方式去弥补 , 保证模型足够复杂的情况下能够稳定运行 。 这是一些必不可少的技术型工作 。
之后做了 aPaaS 层 , 也就是 Application PaaS , 通过领域模型的方式构建应用场景 , 通过画业务模型 , 把业务模型画出来 , 画完之后直接应用 。 第二个是 Click to Integrate 做了 iPaaS 层 , 即 intergration platform service , 应用集成 PaaS 层 , 通过建立集成模型来构建复杂的集成场景 。
我们做的其实是新一代更贴近自然现实的一种开发语言跟开发工具 , 它能够完成模型的构建、扩展跟运行 。 从开发角度来看 , 有点像 Java 语言 , Java 开发工具 JDK、Java 运行环境 JRE , 这样的组合是我们整个产品的大致形态 。
刚才提到模型驱动叫 Model driven design development 或者 DDD(Domain Driven Design evelopment) , 在应用开发领域逐渐变成主流 。 现在国内一线互联网公司都会采取这种领域模型开发的方式 , 不过有这方法论 , 但是没有真正固化的工具 。 美国把这做成了工具 , 我们 ClickPaaS 也是一样 , 把 MDD 或 DDD 系统化工具落地 , 然后完成基础的研发 。
CSDN:像游戏开发引擎当中有各种各样的小模块 , 可以直接去添加模块达成某种效果 , 低代码开发相当于把模块化开发放大 , 从单一的场景达到普适性可用的状态 , 是这样吗?
胡柏:是的 ,Model driven 或 Domain driven 模式是普适性的 , 像 Java 语言或者像 Oracle 数据库 , 本质是不分行业的 , 要做到普适性对技术要求是很高的 。
我们看数据的发展史 , 初期商业化数据库还没有成为主流 , 每个人设计的数据库都是场景相关的 , 最后无法达到普适性 , 但今天没有人再去依据自己的场景设计数据库了 , 而是采用通用的数据库来解决场景的问题 。 我们希望做一个普适性、抽象的、跨行业的开发平台 , 其中的挑战是需要一个行业一个行业验证 , 任何一个普适性的东西都是上限很高、落地很难 。
CSDN:一旦去做普适性、低代码的模型驱动平台可能会面临个性化的需求 , 千行百业都有不同的需求 , 怎么能保证做到像素级的程度?
胡柏:美国的应用 PaaS 公司在美国已经经历过差不多20年的痛苦 , 逐渐从玩具走向了工具 。 大家原来觉得这是非主流的 , 虽然认可软件的核心是在应用逻辑跟应用模型 , 而不在写代码 , 但实现起来太难落地 。
通过模型来做会有很多限制 , 很多细节的地方可能不便处理 , 这要求本身的平台能力要足够高 。 任何一个工具 , 任何一种语言或者任何一种开发方式 , 不可能“包治百病” , 一定是有边界的 。 我们可以做到尽量满足八二原则 , 80%的场景 , 通过定义的方法论、方式、工具集能够实现 , 会有20%场景可能实现不了 。 实现不了可以提供一个途径给他 , 所以我们做了自己的构建模型和扩展模型 。
关于扩展模型我们的做法是做自己的 WebIDE , 支持任何语言 , 可以使用 Java、Python、PHP 。 通过严格管理参数和测试 , 将用户自己的代码级函数、算法融入到平台里面去 , 保证平台应用逻辑层的能力可以无限往外拓展 ,。
关于 UI 层 , 整个 UI 组件库全部是开放的 。 明年年初会全部开放 , 现在逐步在开放给我们的伙伴 。
CSDN:之后是否会逐渐丰富让这些组件?
胡柏:对 ClickPaaS 来讲 , 主要竞争力是两点 。
第一点 , 产品足够强 , 能解决头部企业复杂应用场景的问题 , 这是核心 。
第二点 , 生态 。 生态一定是技术层面高度匹配的 , 在商业上能够彼此带来价值 。 我们现在的生态规模比较小 , 还没到大规模建设生态的阶段 。 我们选择把大量的价值传递给生态 , 我们只拿其中很小一部分 , 才能吸引更多用户 。
CSDN: 从某种程度上来讲 , ClickPaaS 这种低代码开发平台的用户群大概是跟小程序的无技术基础的用户群类似吗?
胡柏:背后的逻辑是相似的 , 但是我们解决的场景要进到企业核心业务系统 , 它的场景要更复杂 。 如果只是解决一个很轻量化应用的话 , 产品之间的区别较小 。 我们需要做成一个面向核心应用的工具 , 能解决客户的核心应用场景 , 这个挑战很大 。 但是背后的逻辑相同 , 降低使用的技能门槛 。 客户只要专注于本身业务场景同时对业务逻辑有足够的理解 。
小程序的业务逻辑比较简单 , 相对来说比较简化、直观 。 企业内部的应用逻辑实际上是很复杂的 , 美国公司一般会有业务分析员跟流程专家专门进行分析 。 国内企业通常是很难依靠业务用户抽象出企业业务模型 。 我们在很多场景里面是希望找到相关的咨询公司或者咨询顾问 , 帮客户梳理出复杂的业务模型 , 再进行落地 。
CSDN:能举一个例子吗?
胡柏:我们服务了一些制造型企业 , 原来用 Oracle 的 SAP 构建了自己的数字化平台 , 之后客户的业务模式变了 , 面临着信息系统的重新实施 。 原来 IT 的逻辑是这样的:规划好一个系统之后去选型 , 实施、开发、上线 , 上线的时候要求需求是必须要锁定的 , 稳定运行5年之后再做一次大规模的迭代升级 。 但现在前端的业务变化很快 , 没上线之前到上线之后 , 各种各样的业务需求爆发出来 , 原来设计的时候却并没有考虑到这些变化也无法考虑到这些变化 , 变成了 design thinking , 一边做一边想 , 一边想一边改 , 与原来做应用系统的逻辑完全不同 。
当时在那个场景里面 , 客户已经花了很多钱在 SAP、Oracle , 因为业务变了 , Oracle、SAP 得重新实施 , 所以在那个场景里面使用了 ClickPaaS 。
SAP 的内部核心稳定化的系统 , 比如说财务 , 不会随着业务变而变的 , 只是做一些微调 , 但是前面的业务系统一直在变 , 因此使用 ClickPaaS 搭建了一个类似中台的东西 , 核心业务系统 , 所有的订单、价格、 , 打样 , 服务全在一个更友好的平台里面去构建 , 且容易修改 。 所以我们很快就帮助客户替换了 Oracle , 然后替换了部分的 SAP , 只用了三个月的时间就完成了 , 客户满意度也很高 。
主导这个项目的不是我们 , 反而是客户自己 , 客户的 IT 来主导 , 他们很清楚 Oracle 能干什么 , SAP 能干什么不能干什么 , 哪些地方是好的 , 哪些地方是僵化的、有问题的 , 他们能够使用 ClickPaaS 平台进行自我延展 。
CSDN:用户在面对低代码平台做技术选型的时候 , 有哪些要考虑的因素 , 有什么建议吗?
胡柏:做任何一个选型 , 要根据客户的场景跟需求来看 , 要知己知彼 , 首先要知道自己要什么 。
低代码、无代码赛道现在很热 , 这里面大的方向有两类 , 第一类表单级应用 , 第二类是模型驱动这种模式 。 表单级应用是比较适合做轻应用的 , 场景简单 , 速度较快 。
场景比较复杂的情况下 , 企业已经做到业务系统甚至核心业务系统了 , 这个时候要选择能够完成你复杂要求具有相应能力的平台合作 。
低代码平台指向未来 , 先赶上再超越
CSDN:你觉得在应用基础平台领域 , 国内技术的发展跟国外技术的发展脉络一样吗?
胡柏:应用基础平台领域中国一直比较落后 , 它是一个基础型软件 , 像数据库、中间件层别 , 中国原来一直没有出现好的产品 。
中国有很好的应用软件 , 比如说用友 , 金蝶 , UI 做的比 SAP 好 , 但扩展能力远比不上 Oracle , SAP 。 美国在基础领域的软件积累的厚度目前来说要超过中国 。 比如说 Siebel 有 Siebel Tools , Peoplesoft 有 Peopletools 。 云时代之后 , Salesforce 首先做了 Force.com 。
这个赛道在美国已经发展了30多年了 , 不是突然之间出现的、从本地部署化的产品到云时代的产品 , 设计理念是一脉相承的 。 对中国的公司来讲也一样 , 不可能拍脑袋突然创新 , 一定是站在巨人肩膀上 。
当然国内有自己的优势——中国的互联网 , 2C 类的产品发展更快 , 比美国要好 , 比美国要进步 , 但是 2B 和 2C 还是有巨大鸿沟的 , 2B 的技术积累领域需要好好消化 , 至少在两到三年内 , 我们要虚心把 Oracle、SAP , 包括 Salesforce 产品的细节搞清楚 , 不用妄自菲薄 , 但是要非常虚心的把别人好的东西消化 , 只有先赶上再赶超 , 先消化再基于此进行大量的本地化创新 。
美国人在技术层面耐心更大一点 , 我们国家和市场的重视度也逐步开始从应用层深入到基础层 。
CSDN:怎样看待低代码开发领域的未来发展?
胡柏:模型驱动会慢慢变成主流 , 在美国已经逐渐形成主流的方案之一 , 原来没有共识 , 现在已经逐渐形成共识了 。
实际上它是有两个标志类的区别 。
第一类:表单应用的模式 , 拼的是销售跟覆盖度;
第二个是模型驱动类 , 技术通度很高 , 对产品的要求也非常高 , 头部项目的选择对产品本身的潜在破坏性也很大 , 需要在头部市场里面不断渗透 , 需要有足够的耐心跟定力 。
同时也需要建立真正的生态伙伴 , 生态伙伴不是简单帮你分成 , 而是与垂直行业的知识和技术平台结合 。
比如银行的应用 , Oracle 在下面 , 银行应用在上面 , 客户看到的是某一个银行的应用 , 下面的数据库则是 Oracle 的 , 要做到这种层级 , 需要真正跟伙伴结合 。
在大方向上来讲 , 企业应用系统本质上重在业务逻辑和业务模型 , 编程、运营程序的壁垒会越来越低 , 美国有一个定论 , 未来美国65%的新应用级开发会通过低代码实现 , 我认为中国慢慢也会这样 。 程序编程门槛降低 , 程序员会做两件事情 。
第一 , 更多程序员去做基础型软件的研发 。
第二 , 高级程序员写低代码平台当中的组件 , 每个行业、每个客户会有和场景相关的特定组件库 , 低代码平台本身和场景不相关 , 因此需要有这样一批人 , 对场景很懂 , 程序能力很强 , 来编写组件 , 把组件融到低代码平台里面 。 现在很多企业绝大多数的 IT 人员已经转变做应用级开发了 。
嘉宾简介:胡柏 , 上海交通大学计算机系硕士 , ClickPaaS 创始人兼 CEO。 首批获得 Salesforce 及 Force.com 高级认证 , 对新一代云架构技术深入理解与实践 。 曾加入甲骨文中国(Oracle)从事企业信息化架构咨询 , 2010 年赴美国从事大型跨国企业数字化转型项目的咨询、实施、落地 , 服务超过 20 家国内大型客户 , 是甲骨文云技术在中国落地推广的先行者 。 担任 IT Convergence 资深顾问经理并成功交付了 43 个跨国企业数字化转型项目 , 对企业信息化架构和应用构建有着丰富的经验积累和行业理解 。 2015 年回国创业 ClickPaaS , 深厚的技术背景与国际视野 , 对欧美及中国 Pass 技术的发展与应用有理解深刻 , 推动 PaaS 技术在中国企业数字化进程的落地 。
推荐阅读
- 减肥也能吃的小零食,营养美味,低脂低热量,多吃也不怕!
- 苹果蛋挞,香甜中淡淡的酸,香酥诱人!
- 春分前后,多吃1道碱性蔬菜,低脂不长胖,清脆爽口又下饭
- 低脂高蛋白的下饭菜,好吃到舔盘子,常做给孩子吃,补锌又补钙!
- 转基因|转基因背锅?去年已有不少弃种,如今产地低至3毛钱,果农愁销路
- 果园|果园植被多样性对虫害的控制
- 肝硬化|得了肝硬化,千万别大意!这样做,大大降低死亡率
- 《 苹果燕麦粥》的制作方法
- 解救馋嘴孕妇的低糖“甜品”,快来学学吧
- 怕胖的人主食别总吃米面了,多做这个吃,味道好,低热量高饱腹!
