平台式建站,一台服务器如何做两个网站,金融行业网站制作,多个织梦dedecms网站怎么做站群简介#xff1a; 低代码将成为B端服务领域的基础设施#xff0c;必将颠覆传统开发方式#xff0c;未来可期。
作者#xff1a;天晟
前言 大家好#xff0c;我是钉钉宜搭前端一个小团队的负责人天晟#xff0c;在阿里做了五年的低代码。今天的分享我们不讲技术细节…简介 低代码将成为B端服务领域的基础设施必将颠覆传统开发方式未来可期。
作者天晟
前言 大家好我是钉钉宜搭前端一个小团队的负责人天晟在阿里做了五年的低代码。今天的分享我们不讲技术细节主要会分享下我们这五年的探索过程和当前的市场分析希望能给大家带来一个对低代码搭建不一样视角的认识。 什么是低代码 说起低代码Low-Code这个词是在 2014 年Forrester Research 第一次正式使用低代码来描述这个市场。国内也就是近几年开始流行的以前我们这边叫「可视化搭建」可视化搭建讲起来有个很大的缺点就是很容易和数据可视化傻傻分不清楚。我还记得2018 年的时候当时做一个分享主题是 「泛可视化搭建的解决方案」我老板的老板说建议我把「泛可视化」改为「低代码」我当时回复说不改低代码听着有点 low「泛可视化」高大上些。后来也不知道什么时候开始习惯了一口一个低代码而且衍生了 Node-Code/Pro-Code。现在回想起来当时是自己 low。 看下业界领军者对低代码的定义 outsystems: 「低代码是一种软件开发方法可以更快地交付应用程序并且只需很少的手工编码。低代码平台是一组工具这些工具可以通过建模和图形界面来可视化应用程序开发。可以使开发人员可以跳过手工编码从而加快了将应用程序投入生产的过程。」mendix: 「低代码开发是一种可视化应用开发方法。通过低代码开发不同经验水平的开发人员能够通过图形用户界面使用拖放式组件和模型驱动逻辑来创建 Web 和移动应用。低代码开发平台减轻了非技术开发人员的压力帮其免去了代码编写工作同时也为专业开发人员提供了支持帮助他们提取应用开发过程中的繁琐底层架构与基础设施任务。业务和 IT 部门的开发人员可以在平台中协同创建、迭代和发布应用而所需时间只是传统方法的一小部分。这种低代码应用开发方法可针对不同用例开发各种类型的应用包括将原有应用升级为支持 IoT 的智能应用。」可以提炼出几个词模型/建模、图形界面、拖放组件、加快、减轻。连起来就是通过模型/建模、图形界面拖放组件可以加快应用开发减轻了非技术开发人员的压力。其实从前端的角度看低代码的鼻祖应该是它 从我目前阶段的理解低代码是这个 当前市场分析 市场规模 根据 Forrester 的报告2019 年该领域的规模估计为 38 亿美元预计在 2021 年这一赛道的市场规模将增长到 152 亿美元75 的应用程序将在低代码平台中开发。到 2022 年该市场规模将达到 212 亿美元。 根据 Gartner 预测到 2021 年应用开发需求的市场增长将至少超过企业 IT 交付能力的 5 倍。到 2024 年全球约有 65 的应用程序都将涉及低代码开发Forrester 、Gartner 全球最具影响力的独立研究咨询公司。 1、领导者行业领导者既要表现出超强的执行能力好的产品与良好的销售业绩相匹配又要表现出具有远见产品创新和相称的营销策略的战略计划。LCAP 的领导者主要包括云 SaaS 提供商Microsoft、Salesforce、ServiceNow专业的低代码提供商Mendix、OutSystems以及混合 RPA 和低代码应用程序供应商Appian。这些供应商具有强大产品能力、市场影响力以及用户体验。 2、挑战者在市场占有率、产品能力方面与领导者的差距并不是很大未来有能力成为该行业领导者。 3、特定领域者不仅可以提供低代码应用平台技术还混合了其他技术例如RPA、业务流程挖掘、BPM 等技术。他们是 LCAP 行业的中流砥柱拥有良好的发展空间。 4、远见者远见者具有良好的合作生态以及市场发展策略在产品创新方面也有很强的能力。但是在业务执行方面与领导者有着较大的差距。相信随着时间的推移他们会更上一层楼。
市场分类 目前我看到的市场上主要有两类 一种是基于表单驱动核心能力是表单、流程、报表在一定的场景下可以快速的做业务交付上手成本也比较低。比如宜搭、简道云、明道云、氚云等。 另一种是基于模型驱动核心是领域模型、业务沉淀、完整性有一定的技术壁垒上手成本相对比较高。比如Outsystems / Mendix / PowerApps / 奥哲云枢 / 金蝶云苍穹等。 市场布局 拿 PowerApps 来举例上面四个分别是 云 端 协同 低代码。已经是很大、很先进的布局了。从中我们能看到低代码平台只是其中的一部分。独木不成舟独木舟虽然简易也能用但毕竟能力有限。 探索过程 用两句话来概括下1. 始于表单终于表单2.从技术到产品。 从 2015 年开始我们一步一步探索做了很多很多无论是技术上还是产品上。比如模型驱动、小程序搭建等。这里面的每一块都可以单出拿出来讲很久。这里我举几个例子简单描述下。
钉钉审批-表单 钉钉审批这个搭建当时只有 8 个组件功能也很简单和现在相比也和易用。毕竟简单这个仅仅是我们的开始之后一发不可收拾。 中后台页面搭建 后来我们开始做中后台页面搭建但在开始推广时却受到了很大的阻力。 我们开始给前端用技术同学是来写代码的就排斥这种高不成低不就的搭建平台产品而且功能又不全大家意见很大。后来我们给服务端开发用当然服务端也是排斥的不只排斥搭建就像让一个写 Java 的人做前端的页面就是排斥。 但没办法前端资源就是不足再加上从上层开始推那一年效果突出。有些服务端的同学用的简直飞起他们做页面特别快没有联调成本接口都是自己定义的想怎么搞就这么高而且代码写的很规整。 再后来随着我们的功能逐渐的完善比如多分支、回滚等功能前端也开始渐渐接受了平台侧有很多页面都是用平台自己搭建的。 服务化 当时我们部门的业务大部分中后台系统服务端都能自交付。减少了很多前端资源。我们自己用舒服了于是开始想让其他团队也能使用。但每个业务场景都不一样默认的平台无法满足其他部门的诉求。所以我们开始做服务化。 服务化就是我可以让其他团队也快速拥有低代码搭建的能力并且可以做定制比如组件定制、设计器面板定制。这样思路就打开了不仅能支持其他团队的中后台场景凡是和搭建相关的场景都可以做。 比如上图的例子场景特别有趣每次我都会拿出这张图分享给大家绝对布局的画布构建好后服务端会自己做特殊解析最终显示在石墨屏上。类似这种例子有很多。包括后面要做的在线设计都是通过服务化来完成的。 代码互转/ WebIDE 随着我们的用户量越来越多复杂功能的实现和后续的可维护性受到了很多的挑战。 典型的例子是开始我的需求比较简单用搭建快速完成了但后面的需求评估下来发现搭建满足不了。于是我们开始做出码将搭建产物转成代码继续开发。 但是单纯做出码没什么挑战我们也考虑了不同角色的开发。当年的 WebIDE 也很火于是我们通过 WebIDE 做了一套搭建和代码互转的功能。我们创造了自己的 DSL其实也参考了 Salesforce有了自己的语言很多事情都好做了也可控。小程序也是这样的。 后面的路怎么走 灵魂三问1. 如何能把价值再做大2. 低代码 or 零代码3. 用户是谁 再问能否商业化呢要不要商业化呢如何商业化
看竞品分析。 Salesforce / Power Platform / 金蝶云苍穹他们的 PaaS 都是有明确支撑的业务领域CRM / ERP。PaaS 是基于自身的 SaaS 长出来的。我们要主打那块业务哪块业务能找到市场 如果单纯的做 PaaS感觉最后做出的可能还是工具。工具类的竞品像 Outsystems/ Mendix他们提供是软件工具、方法和架构可以快速建模、测试、部署、管理等是一套完整应用开发的闭环测试、部署、调试、稳定性等。所以单纯做工具最后被收购像 Mendix。还是支撑 SaaS 为目标我们要打的 SaaS 行业蛋糕还有吗另外还要考虑多租、二开等技术复杂度极高。 再看看国内简道云背后是帆软-数据出身氚云-流程出身。两个产品都偏零代码产品体验做的都很不错。猜测应该都是先有独立的能力后发展后低代码平台的。 结论呢当然没有。竞品分析只能帮助我们多了解具体的方向还需要自己去探索和挖掘。 疫情带来的变化 疫情让我看到了 疫情业务变化之快。企业创新业务变化之快。企业发展核心是提效降本。去年因为我留杭过年所以参与到了疫情项目用宜搭来做健康打卡从大年三十一连续在家干了两周7 * 24 小时待命。 健康打卡应该大部人都用过看着简单其实背后有很多复杂有针对员工的有针对 HR 的还有针对海外的。需求变化之快今天加个高风险城市明天加个海外地区需要各种定制。一个前端全链路完成快速试错、快速上线。如果没有宜搭真搞不定。后面我也去其他类似的竞品看过了我们这边的定制场景还真都无法完成。 这次项目让我更深刻的认识了宜搭产品的价值。 总结 2B领域下的低代码适合用冰山理论来解释。部分人认为的包括 5 年前的我也是这样认为的拖拽设计器 低代码。后来在深入做了两年后发现有物料、多端、出码、布局、逻辑、国际化、监控、模板、协议、服务化、帮助体系这么多功能要做。再往后做要从 2B 的视角去看就像之前微软的那边的局部云、协同、端。 后面还有很多的未知等着我们。 再回到现实总结五个点。 1、场景壁垒
我觉得我们需要寻找更多的「场景壁垒」比如疫情下快速交付的场景为什么疫情下大家会选择宜搭而不是选择其他开发模式因为快且场景不是特别复杂快需要找需要快的场景这种场景其他方式无法完成这就是壁垒。 2、完整性
用户需要在这个一个平台上能把所有研发相关的事情全部做完。完整性也包括了可维护性。可控的开发质量、维护性和升级成本二次需求开发。 3、生态
产品完整性有了后就可以打造开发生态通过更多的开发者生产更多的物料、服务。同时平台可以连接更多的物料、服务。 4、连接
这里的连接有两层含义一个是产品之前的连接一个是数据的连接。产品的连接可以产生 1 1 2 的效果。目前的趋势是在改变传统的 ERP/CRM 大而复杂的软件系统。越来越多小而灵活的应用产生而且随着企业的创新需求变化越来越快系统越来越多但不能做成烟囱数据的连接尤其重要。 5、灵活性和易用性
灵活性和易用性的平衡如果做不好平台也很容易做差。我看过一个竞品真的做到了代码完全交互化0 代码但是前端的逻辑用交互编排的方式其复杂度根本没办法二次维护。 讲了这么多并没有确切的回答之前自己提的问题因为没有完全正确的答案我们仍然需要不断的探索。低代码将成为B端服务领域的基础设施必将颠覆传统开发方式未来可期。
原文链接
本文为阿里云原创内容未经允许不得转载。
