阿里、腾讯SaaS加速器大战 低代码可否引爆燎原之火？

作者：张苏月 2019-06-26 11:38:18

云计算

SaaS 阿里和腾讯的战火，从C端烧到B端，又从B端烧到云端，甚至连名字和战略都异曲同工。

阿里和腾讯的战火，从C端烧到B端，又从B端烧到云端，甚至连名字和战略都异曲同工。

年初阿里云技术峰会上阿里发布了SaaS加速器战略，旨在让ISV和开发者只要简单拖拽，就可以快速搭建SaaS应用，阿里甚至提出了永不碰应用的承诺，而腾讯也在随后推出SaaS加速器计划，两家的目的都非常明确，就是打通企业到云端的最后一公里，SaaS加速器就是这把打开云业务深入到企业的钥匙。但是面对两家巨头，ISV和解决方案商又该如何抉择呢?

[[269021]]

SaaS加速器说白了就是一个低代码的开发平台，阿里和腾讯希望通过这样的策略让吸引更多的ISV将产品和应用搭建他们的云上，更直接一点就是完善云应用生态圈，让更多的企业选择自家的云。

但是这里有一个问题就是企业现在需求的是一体化的解决方案，而不是单点的应用，新应用与新应用之间，新应用与老应用之间的融合趋势已欲发明显。谁来解决呢?

指望ISV软件厂商吗?显然是行不通的，软件厂商只服务自有业务范围，超过这个度他不会去承接的，另外低代码还存在很多问题，先不论阿里和腾迅能否打通到企业的最后一公里，关键是关于低代码自身的问题也是这两家未来急需解决的关键。

提起低代码开发并不是新鲜词，最早可追溯到2000年左右，由知名研究与咨询机构 Forrester 创造了“低代码开发平台”术语。其发展经历了不同阶段：2000年至2015年可以算是低代码平台发展的第一阶段。这一阶段，低代码平台市场的发展非常迟缓，没有大幅度的升降，也没有表现亮眼的企业。

2015年至2018年这三年，低代码平台市场直接升温。2015年，AWS、Google、Microsoft 和 Oracle 等大型供应商开始进入市场，2018年西门子宣布以6亿欧元收购低代码应用开发领域的领导者Mendix、快速应用开发的低代码平台OutSystems获得了3.6亿美金的投资之后，低代码平台市场才真正开始火爆起来。

根据 Forrester 的报告，低代码开发平台市场将从2015年的17亿美金增长至2020年的155亿美金，5年时间增长接近十倍。

在 Forrester 绘制的该领域象限图中，Microsoft、OutSystems、Mendix、Kony和Salesforce占据了领导者地位，而ServiceNow、GeneXus、Progress Software、MatsSoft、WaveMaker、Thinkwise等后起之秀，也呈现出强劲的追赶之势。

可见，在国外市场，该技术的发展已经相对较成熟。当然，任何有市场价值的技术都会成为国内企业纷纷发力的方向，低代码开发技术也不例外。

尽管目前该技术领域在国内的发展远未达到红海状态，但这可能只是时间问题。而巨头们的进击是否也侧面透漏出了某些讯息。

关于低代码开发的好处，除了巨头们的宣传外，网络上各式各样到内容可能大家已经看或者听的太多了，在这里我们就不一一赘述了。

那么，关于其可能存在的隐患又有哪些呢?或许，对于想要采用该技术或者说通过加速器赋能的企业需要听一听下面这位国外CIO给出的建议：

这位名为 Peter Wayner 的CIO指出，当企业使用者更仔细地查看平台、结果和流程时，会发现用低代码来实现并不那么简单。尽管在所有的宣传中，大家一致指出该技术简化了企业开发流程，但其实随之而来的可能是后续更多的复杂性。

Peter Wayner 认为，隐藏在这些编程拐杖和读心术界面背后的几个黑暗秘密，或许会让低代码开发的诱人前景黯然失色。 

供应商锁定

与许多技术一样，使用低代码工具所做的工作量与企业所受到的控制其实是成正比的。

为什么这样说?通过将大部分工作交付给工具，企业对它们的依赖程度越高，它们对企业流程的控制能力也就越强。

这里我们给出一些可以最小化使用低代码工具带来的锁定问题的策略：企业可以编写可移植性更强的代码，隔离业务逻辑，然后使用连接代码将其封装，并将其与本地低代码API连接起来。

需要指出的是，这种方法尽管是可行的，但如果企业想把所有的东西都放到自己的服务器上，那么其最终还要自己写剩下的代码。

解除锁定却带来了新的编程工作，不知企业会作何选择呢?

定价改变的隐患

同许多销售策略一样，云平台通常会提供低价来吸引客户，然后在可能的时候提高价格。为什么他们敢于这样做?部分原因便是上面提到的锁定问题，一旦企业在该平台上构建了系统，他们就有了控制价格的筹码。

当然，除非你签了一份长期合同，否则无法确定明年或五年后的运行成本会是怎么变化的。所以，如果企业的低代码创建需要在这些云供应商的平台上完成，那么，企业在做合作谈判的时候就需要将其考虑在内了。

举一个可能的定价方面的例子——改变定价公式：从根据调用频率收费切换到根据带宽收费。

存在监管隐患

因为减少了代码编写的工作量，大多数使用低代码平台的企业很少注意幕后发生的事情。

也许这些幕后的代码是官方专有的;也许API调用背后隐藏着什么秘密……

当监管机构介入时，这一点尤其棘手。因为无从知晓这些“幕后之事”，企业就没办法告诉监管机构发生了什么，真的想要辩解却是“有口说不出”了。

隐藏的低效性

将控制权移交给功能齐全的API、库和栈固然不错，但幕后的代码通常效率要低得多，因为它必须为许多突发事件做好准备。

是不是某个傻瓜传递了一个空指针?函数的所有参数格式都正确吗?……

低代码工具供应商必须防弹他们的产品，因为他们不知道一些傻瓜可能会做什么。所有这些防弹技术可能都很棒，但就像装甲坦克一样，它的速度通常要慢得多。

功能有限

多数情况下，企业在进行低代码开发平台的演示时都非常棒。比如，销售工程师通过调用createDoggyDatingSite函数，仅用一行代码就创建了一个新的可爱的狗狗约会网站，而这个函数恰好构建在框架中。

其实，大多数低代码平台都比较通用，但是很可能很快就会耗尽内置函数的功能。有时候，客户可能无意间需要构建某个产品细节，但是任何低代码公司都不可能预测到所有的细节。

这就需要软件可以灵活地适应企业的需求，而企业所需的灵活性越大，就需要使用越多的代码来满足，但更多的代码就不是低代码了。

单向致命bug威胁

先举一个技术人员比较熟悉的例子，当Libssh出现bug时，服务器集群中的几乎所有Unix或Linux机器都将处于危险之中。

成功的低代码平台一般也设计了这一单向性，当软件运行正常的时候，这是一个很好的设计，但如同上面的Libssh bug一样，当网络中发现致命的缺陷时，所有与之关联的东西都将崩溃。

目前来说，还没有办法避免这个问题。

千篇一律的皮囊

有这么一个场景：一位聪明的汽车爱好者注意到，通过购买汽车零部件制造商的库存产品并将它们组装在一起，制造一辆汽车并不难。他花了大部分钱为该车打造了一个曲线优美的车身，但其他一切都很常见：大众汽车的门把手、保时捷911的座椅、福特的方向盘等等。

其实，低代码项目最终会产生相同的效果。这些项目可能最终看起来彼此都非常相似，因为开发人员使用的是相同的库存部件。

如果代码只是用于执行任务，比如维护仓库中的库存，那么外观并不重要。但是如果软件是企业品牌的一部分，那么企业就需要做好心里准备了：其低代码软件或许与竞争对手非常相似。

模仿者还是创新者?

很多东西，如果你很容易创建，那么别人肯定也很容易复制它。

低代码平台给与企业的便捷是其通过简单的拖拽，搭积木等方式构建符合自身应用的软件产品。所以很明显，该平台是倾向于避免排他性的。

这里的问题就是，如果该软件要支持另一家拥有竞争优势的企业，那也是OK的。因此，如果创建软件是你的业务模型，那么你就要准备好迎接一些竞争了。如何在同样的框架下脱颖而出是企业必须要考虑的问题。

不可否认，任何技术都有其利弊，低代码开发也不例外。无论AT的“低代码”SaaS加速器是出于“好心”还是“好益”，但跳上加速台的企业们不能只是“闭着眼旋转跳跃”，也要警惕脚下的这些“坑”。

如何尽可能减少上述低代码开发平台的隐患或许是AT打通企业最后一公里，吸引更多ISV和解决方案商前不得不思考的问题。

云端星星之火已经点燃，阿里、腾讯谁先燎原尚未可知。