您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 其他 > 正文

一家低代码厂商停服后……

发表于:2022-06-21 作者:千山 来源:51CTO技术栈

日前,低代码厂商黑帕云宣布正式停止服务。

图片

来源:互联网

  在新一轮低代码热潮中,黑帕云成为欣欣向荣的光景里第一家宣告退出的厂商。

  这家成立于2019年的企业在去年7月宣布A轮融资,但之后不久就传出了其要被字节跳动旗下飞书收购的消息。如今黑帕云的停服直接揭示了低代码领域创业团队求存不易的一面。即使资本青睐,外界看好,站在了风口,也拿到了融资,市场的考验依旧残酷。

  这两年的低代码赛道熙熙攘攘,但对大多数入局的玩家来说,技术如何演进,商业模式如何突围,依旧在求索之路上。

需求渴切

  低代码本身并不算新概念,因此在低代码赛道升温之余常有人质疑其“老瓶装新酒”,有炒作之嫌。

       2000年 VPL(Visual Programming Language),即可视化编程语言,就已出现;2014年,国际知名市场调研企业  Forrester 正式提出“低代码/零代码”的概念,将其定义为无需编码或通过少量代码就可以快速生成应用程序的开发平台;2018年,Gartner 提出  aPaaS 和 iPaaS 的概念;2019年开始,中国的低代码市场进入小步快跑的增长期……

  由此可见,关于可视化开发的尝试早已开始,但它们都没有对应用程序的创建方式产生重大影响。为何在沉寂了一段时间后,低代码又来到了聚光灯下呢?其中的关键在于,随着数字化浪潮的到来,出现了庞大的应用缺口。

  近些年来,伴随云计算、人工智能、物联网、5G等技术的发展,越来越多的企业需要加速数字化转型。加之疫情倒逼企业寻找高效转型的方法,使用低代码提升应用开发效率,通过更敏捷的交付来推动业务创新速度,成为了企业降本增效的选择之一。

  回顾一下2018年,彼时,低代码赛道初露峥嵘:OutSystems成为估值逾10亿美元的独角兽,一时风头无两。随后,西门子又宣布以6亿欧元的价格收购低代码应用开发平台Mendix。几乎在同一时期,AWS、Google、Microsoft、Oracle等巨头也纷纷布局低代码领域……

  低代码再度“火”起来后,中国市场的表现同样值得瞩目。Gartner有调研数据显示,未来5年至少需要开发5亿个新应用,才能满足中国企业数字化转型的需求。面向这一市场,低代码无疑大有可为。据悉,在2018-2020年间,中国无/低代码领域总体投融资事件共16起,在总融资规模上,国内无/低代码平台商共获融资近15亿人民币,融资企业总估值近70亿元。

  在这一趋势下,大厂的入局为低代码领域的新玩法注入了更多想象。去年1月,伴随钉钉6.0版本的发布,钉钉宣布全面开放底层能力和1300个API接口,同步提出了“低代码革命”。发布会上,阿里云智能总裁张建锋表示,基于云钉一体的“低代码开发”,将成为新一代的软件开发方式,并称希望未来3年在钉钉上能长出1000万个钉应用。资料显示,截至2021年12月底,钉钉上的低代码应用数已超过240万。

前景未明

  尽管用户需求迫切,市场空间广阔,资本青睐有加,但需要正视的是,中国低代码企业大多处于起步阶段,行业格局尚未明朗,不久的未来可能面临整体洗牌。在此期间,低代码相关技术和商业模式的不成熟会成为掣肘多数创业企业的关键因素。

在技术上,低代码工具的优点一目了然。首先,低代码平台通过拖拽组件等形式,可以更好地应对敏态业务的开发需求,比之全代码开发,能有效降低成本,缩短交付周期;再者,低代码工具为业务人员参与应用开发提供了一种可行之法,有助于推动全民开发成为业务和

IT 协作的重要组成部分。

  不过,低代码工具的短板也同样明显。

  第一,通用性和个性化之间的矛盾难以调和。要降低开发门槛,就要尽可能让有限的封装覆盖更多的场景。但事实上,应用场景千差万别,如果想做个性化改动可能会面临增加试错成本的风险。

  第二,安全性。因为低代码厂商提供的封装代码模块是无法被开发者检查测试的。当低代码无法保证安全控制时,企业可能不得不采购第三方安全管理工具,反而增加运维成本。

  在商业模式上,低代码领域还有待探索。无论是走产品路线还是提供定制化服务,低代码厂商的前景都面临重重挑战。

  首先,现有可替代工具过多,且不少免费。如何让用户愿意了解并使用低代码是首要问题,尤其是对于中小客户,商业逻辑能否跑通并达成规模化效应还是个未知数。

  其次,应用不够丰富,生态难以构建。低代码目前来说仍属于小众的企服产品,如果没有大应用生态做支撑,就其本身来说很难存活。钉钉的平台型低代码模式之所以卓有成效,并不是因为差异化,也不是细分赛道做得更出色,而是钉钉作为一款协作办公平台,本身协同密度足够大,可以高效地基于其庞大的底座构建应用生态。

  其三,大厂入局后的连锁效应。2020年前后,一众大厂开始入局低代码,阿里推出“钉钉搭”,腾讯也推出了“微搭”,为这一赛道也带来了变数。彼时,黑帕云在2021年底选择被收购时,就有业内人士猜测,这可能是其创始人在权衡利弊后的选择,在商业化方面小团队依靠自身发展,不如借助大厂的资源和生态优势进一步孵化。

  尚未成熟的技术和商业模式让低代码市场前景未明,但也让其呈现了一种野蛮生长的活力。等赛道趋于饱和,市场大浪淘沙之后,低代码本身如何进化,将成为行业共同的命题。

来自开发者的声音

  随着越来越多的企业入局,低代码频频成为舆论关注的焦点,“全民开发”“非开发人员也能搭建应用”逐渐植入大众印象。但事实真的如此吗?并不尽然。51CTO技术社群中各行业开发者们就此表达了自己的观点。

争议1:低代码到底面向的是谁?

  【coeus】感觉低代码不是给开发用的。可视化编程、低代码、零代码要实现的不就是“不需要开发插手人人可用”吗?所以一个大众化的产品就要简单、无脑、定制化低。开发用的类似低代码的东西,大家都归纳到组件、工具、模块中了,都不认为是低代码产品。

  【边城浪子】低代码主要是两种服务模式:面向业务人员和面向专业人员(开发人员),阿里、腾讯已经开源的低代码平台就是面向开发者。

  【张业贵】低代码不是面向开发者,而是面向有一定软件使用经验的业务人员,所以对于开发者没有效率。如果非要说低代码是给开发者用的,而且是匹配的业务场景,那肯定是高效的,毕竟大部分业务逻辑都封装了,大部分工作都自动化了,这有点像脚手架的感觉。但是强耦合或者强数据相关的业务下,基本还是废的,不如搞代码工具或者代码模板。

争议2:低代码适宜哪些应用场景?

  【老黄】低代码应该是解决复杂场景的,如果是简单的那种,没什么必要。

  【Kevin】个人认为,低代码解决的是(标准化)通用场景,和复杂度成弱关联性。

  【十七念】低代码感觉比较适合标准化流程的,比如问卷、事项申报这种,还有对界面交互没啥太大期待的。

  【紫竹】低代码意味着定制化,这两者成正比关系,定制化越高,代码越固化,可以改动的内容越少,参数化就越高,也就是所谓的低代码;而普适性和定制化成反比关系,代码想适应更多的场景,就要解决更多的问题,就要枚举更多的特例,增加开发量,实际上就不满足定制化。这个矛盾无法解决。

  【飞狐】分行业,分需求,低代码也是因地制宜。我认为,基于产品化的话局限性比较大,如果这个产品化的低代码适用行业广,可做成产品,稍微修改就可以,基于流程的话效率是提高了,但前期投入成本比较高,是否需要就看扩展性了。

争议3:对开发者来说,低代码真的有用吗?

  【looffy】:说实话,懂的人不愿用(搞不定复杂业务),不懂的人玩不转(还是需要有点编程逻辑思路的)。

  【Signx】实现原型倒是很快,对于不复杂的业务还是有用的,比如某些小厂实现信息化,原来采用手工的方式转换成电子化的。

  【Timo】(低代码)还在发展,远远没有成熟。成熟的一个标志就是普适性的低代码平台以及做垂直领域的低代码平台各司其职。作为开发人员,低代码平台可以作为日常管理的工具,对提升开发效率有用。但具体有什么用就见仁见智了,比如刚毕业的小孩儿让用低代码提升效率……还不如去看源码更实在一点。

尾声    

  固然低代码的局限还很多,但相较传统软件开发成本高、周期长的特点,低代码在特定场景下的确有不容忽视的优势。产品未来如何发展才能持续满足市场需求?叠加功能,还是维持简洁的设计?开放更多接口,引导更多开发者参与?抑或进一步细分场景进行差异化设计?无论选择哪个方向,都需要小心试错,及时调整。“全民开发”的未来是否会到来,何时到来还不得而知,但对于低代码厂商而言,倾听用户声音,扎实做好产品,乘风而起之日总会到来。

 相关文章