所有文章
目录

    使用低代码平台 - 危险的赌注

    低代码应用平台(LCAP - low code application platforms)在多样、复杂的现代软件开发情势下应运而生。依据Gartner(高德纳,全球最具权威的IT研究与顾问咨询公司)的数据,Mendix 是这方面的翘楚,所以允许本文将它做为参照。但其实类似的结论也适用于 Outsystems、Appian、 Kony、 Betty Blocks 以及其他平台。

    text

    在向高管推销时,LCAP 们会号称业务人员(即非专业开发人员)就能构建企业级的解决方案。那么,后来专业开发人员都失业了吗?事实是 - 几年以后 Mendix 承认:专业开发人员比以往更需要。见下图。

    text

    好尴尬呀!我猜测 Mendix 意识到任何比基本的 CRUD 复杂的事情都需要一个软件工程师,就好像除了打气之外的汽车维修工作都是需要专业人员一样。

    不幸的是,当下的低代码平台并不是给专业开发人员设计的。并且长时期的依赖低代码平台对业务来说是危险的赌注。下面我来解释其中的原因。

    做原型开发很赞

    事实上 Mendix 对开发简单的自动化商业流程、或者交付可运行的原型系统来说,是业余开发人员不错的选择。在一个可视化的设计器中定义数据模型,使用内置的组件、模板来设计脚手架交互UI,甚至可以使用 microflows(microflow 类似于 Java 中的方法,有入参,出参,可在里面做循环,判断等等)描述业务逻辑:

    text

    完成之后,可以把应用一键部署到 Mendix 云上,然后运行。看上去简单而有魔力,这足够让企业高管签支票。

    但是,当你的应用过了原型阶段,用户交互和业务逻辑会不可避免的越来越复杂。这个时候,为了避免结果一团糟,你将需要一个专业工程师来推进项目。

    所以下一步,我们从专业工程角度来看。

    (慢)代码

    用低代码平台的时候,任何逻辑 - 包括计算和用户交互 - 都需要用一个 microflow 来描述,如上节中的图示。这里就有一些问题。

    首先,会慢。想象一下,拖动、配置,然后将十几个模板连接起来,相比于在好用的 IDE 里敲十几行代码。 规模上去以后,你的 microflows 不可避免的多到难以管理。

    其次,可读性。模板看上去很妙,但是后面的 Sub_RegistrationValidation 呢?不跟进去根本无法阅读。

    权宜之下,Mendix 提供了 Java 操作。你可以在一个 microflow 中调用 Java 方法(但是由于云部署的限制,对这些 Java 方法也有严格的限制)。你可以在 Eclipse 中写好 Java 代码,尽管更多人选择更优秀的IDE - IntelliJ。透明度是一个风险 - Java 代码的入口都在 microflows 中,所以调试、跟踪都变的复杂了。逻辑流程分散在两处。

    最后不得不提的一点是版本控制。好消息是确实有这方面的版本控制软件,坏消息是它是 Subversion 的一个受限制的子集。跟 git 再见吧。

    不可控

    任何熟悉 Java 生态的人都不会低估开源的能量。当有一个异常抛出时,你能看到发生异常的代码,也能通过调试来看发生了什么,你能 Google,也能提一个pull request。最坏的情况,你可以 fork 整个项目。这些都是可控的。

    用 Mendix 的话就什么都别想了。它是一个商业权属物,调用栈里是个黑盒子。你可选的只有付费的售后支持,或者祈祷上天能在社区获得回答,每月大概200个问题,与 stackoverflow 上带 Spring 标签的问答数目比比?

    销售商锁定

    Mendix 可能是被经常问到这个话题,他们发布了一篇文章来解释如何解除锁定。如果仔细阅读,它提到了:

    你可以拿到你的数据、DDL,UI 资源和代码(microflows 可以神奇地转为 Java 代码)。

    那么你拿到的代码可以脱离 Mendix 的运行库和 API 独立编译或者运行吗?事实上,这需要重写整个系统。你被锁在一个商业权属物平台上,你甚至不拥有你构建的系统。

    扩展性受限

    Mendix 的目标客户是大型企业,所以“扩展性”在他们的市场材料中被多次提及。2017年他们引入了“stateless runtime” - 无状态运行时,所有会话信息即存在客户端,又持久化到数据库。理论上,横向扩展将没有上限。听起来很酷,但有一个问题 - 数据库。

    数据库通常是企业级应用的瓶颈所在。在集群的无状态 Mendix 服务后面是用什么在存储数据呢?没有惊喜 - 就是关系型数据库。 Mendix 使用的是 PostgreSQL。Mendix 没有缓存,而且它生成的 DDL 是有问题的,比如,我见过对一个 1:N 的关系生成了一张 N:M 的临时表。

    如果控制权在自己手里这样也可以接受。Oracle 及其他数据库已经证明了 RDBMS 是可以扩展的,你可以优化 DB 结构,缓存数据或者使用 Citus 这样的方案来做扩展。但问题是使用 Medix 的话控制权不在你手里。

    唯一可行的是使用只读复制(如 Amazon RDS),但这个对写数据没有帮助。

    总结,存在基础上的扩展限制,并且缺少微调性能的选项。

    降低 (提高)技术要求

    降低技术要求对主管来说听起来很美妙,昂贵的、难找的专业人员不再需要了。实际上,这是一个坏招。当你真的需要一个专业开发人员时,就会苦恼如何找到一个好的开发人员,因为对于专业的工程师来说,使用低代码平台意味着职业生涯的结束。

    价格很美丽

    最后但并非不重要。一个单应用授权最低 $1875每月,限于50个内部用户,并且最少购买三年。可以部署到 premises 的企业授权最低 $7825,几乎$100K(10万$)每年。所以一个有几千内部用户的大型企业每年大概需要几百万美元。

    并且要注意的是依据以上讨论,我们只是针对相对比较简单的应用。这对我来说很疯狂了。这个定价下,你还不能自己发布你自己构建的应用。

    那为什么LCAP还如此流行?

    在我看来,答案令人沮丧。在大型机构中管理工程师团队 - 无论是内部还是外部 - 目前来说都过于复杂。预先进行预算规划,相关人员(架构师或者直线经理)各自有各自的议程,缺乏责任感等等。 所以推进、实现自己的想法很难。更有趣的是,管理人员下意识的应对策略还是雇用更多的开发人员,当然还有更多的经理。毋庸置疑,这会使情况变得更糟。我知道有几家拥有超过10,000(!!!)个开发人员的银行,我还知道里面至少有一半的人在从事无用的工作。 令人绝望的是,企业高管因此寻求那种神奇的、解决所有问题的解决方案,例如LCAP - 低代码应用平台。

    如何摆脱这一团糟是另一篇文章的主题。 但这是一个管理问题,而不是技术问题。 跳过所有细节,如果你能让3-10位具有相当资质的人员全力开发,并能与相关人员和决策者直接沟通,你将获得比想象中的更快、更便宜、出色的结果。

    有其他选择吗?

    如今,开发人员工具和框架有很多选择。 例如,Spring Framework 是最流行的企业软件开源框架,可以与 React 或 Angular 等 Web 框架很好地结合在一起。 在过去几年中,Spring InitializrJHipster 之类的工具使上述操作变得更加容易。

    如果你需要更快的结果和更容易采用的方法,那么CUBA Platform之类的RAD工具非常值得考虑。 它建立在 Spring Framework 之上,并通过可视化开发工具和无缝集成扩展插件市场进行补充。 对于开发人员而言,这可能是 LCAP 的最接近的替代方案,同时仍然提供灵活性和便捷的开发过程。

    总结

    低代码平台用来开发原型很赞。 它们将业务相关人员和 IT 连接,使结果可视化,促进双方更快地达成一致。 由于参与人员很少,所以成本也很低。但也只能到此为止!

    否则,继续使用下去,开发速度将减慢,你将越来越多地陷入又贵又限制诸多的商业权属平台中。

    只要 AI 还没有替代我们工作,企业软件就应该由专业开发人员来构建。 因此,设定一个可到达的目标,组建一支精干的小型团队,聘请有能力的领导,让他们自己选择工具,并且不要忘记将他们纳入业务领域。 很快地,你将看到你的想法逐渐成形!

    了解如何在 12 分钟内完成一个简单可运行的应用程序