阿里和騰訊的戰(zhàn)火，從C端燒到B端，又從B端燒到云端，甚至連名字和戰(zhàn)略都異曲同工。

年初阿里云技術(shù)峰會上阿里發(fā)布了SaaS加速器戰(zhàn)略，旨在讓ISV和開發(fā)者只要簡單拖拽，就可以快速搭建SaaS應(yīng)用，阿里甚至提出了永不碰應(yīng)用的承諾，而騰訊也在隨后推出SaaS加速器計劃，兩家的目的都非常明確，就是打通企業(yè)到云端的最后一公里，SaaS加速器就是這把打開云業(yè)務(wù)深入到企業(yè)的鑰匙。但是面對兩家巨頭，ISV和解決方案商又該如何抉擇呢?

SaaS加速器說白了就是一個低代碼的開發(fā)平臺，阿里和騰訊希望通過這樣的策略讓吸引更多的ISV將產(chǎn)品和應(yīng)用搭建他們的云上，更直接一點就是完善云應(yīng)用生態(tài)圈，讓更多的企業(yè)選擇自家的云。

但是這里有一個問題就是企業(yè)現(xiàn)在需求的是一體化的解決方案，而不是單點的應(yīng)用，新應(yīng)用與新應(yīng)用之間，新應(yīng)用與老應(yīng)用之間的融合趨勢已欲發(fā)明顯。誰來解決呢?

指望ISV軟件廠商嗎?顯然是行不通的，軟件廠商只服務(wù)自有業(yè)務(wù)范圍，超過這個度他不會去承接的，另外低代碼還存在很多問題，先不論阿里和騰迅能否打通到企業(yè)的最后一公里，關(guān)鍵是關(guān)于低代碼自身的問題也是這兩家未來急需解決的關(guān)鍵。

提起低代碼開發(fā)并不是新鮮詞，最早可追溯到2000年左右，由知名研究與咨詢機構(gòu) Forrester 創(chuàng)造了“低代碼開發(fā)平臺”術(shù)語。其發(fā)展經(jīng)歷了不同階段：2000年至2015年可以算是低代碼平臺發(fā)展的第一階段。這一階段，低代碼平臺市場的發(fā)展非常遲緩，沒有大幅度的升降，也沒有表現(xiàn)亮眼的企業(yè)。

2015年至2018年這三年，低代碼平臺市場直接升溫。2015年，AWS、Google、Microsoft 和 Oracle 等大型供應(yīng)商開始進入市場，2018年西門子宣布以6億歐元收購低代碼應(yīng)用開發(fā)領(lǐng)域的領(lǐng)導(dǎo)者Mendix、快速應(yīng)用開發(fā)的低代碼平臺OutSystems獲得了3.6億美金的投資之后，低代碼平臺市場才真正開始火爆起來。

根據(jù) Forrester 的報告，低代碼開發(fā)平臺市場將從2015年的17億美金增長至2020年的155億美金，5年時間增長接近十倍。

在 Forrester 繪制的該領(lǐng)域象限圖中，Microsoft、OutSystems、Mendix、Kony和Salesforce占據(jù)了領(lǐng)導(dǎo)者地位，而ServiceNow、GeneXus、Progress Software、MatsSoft、WaveMaker、Thinkwise等后起之秀，也呈現(xiàn)出強勁的追趕之勢。

可見，在國外市場，該技術(shù)的發(fā)展已經(jīng)相對較成熟。當(dāng)然，任何有市場價值的技術(shù)都會成為國內(nèi)企業(yè)紛紛發(fā)力的方向，低代碼開發(fā)技術(shù)也不例外。

盡管目前該技術(shù)領(lǐng)域在國內(nèi)的發(fā)展遠未達到紅海狀態(tài)，但這可能只是時間問題。而巨頭們的進擊是否也側(cè)面透漏出了某些訊息。

關(guān)于低代碼開發(fā)的好處，除了巨頭們的宣傳外，網(wǎng)絡(luò)上各式各樣到內(nèi)容可能大家已經(jīng)看或者聽的太多了，在這里我們就不一一贅述了。

那么，關(guān)于其可能存在的隱患又有哪些呢?或許，對于想要采用該技術(shù)或者說通過加速器賦能的企業(yè)需要聽一聽下面這位國外CIO給出的建議：

這位名為 Peter Wayner 的CIO指出，當(dāng)企業(yè)使用者更仔細地查看平臺、結(jié)果和流程時，會發(fā)現(xiàn)用低代碼來實現(xiàn)并不那么簡單。盡管在所有的宣傳中，大家一致指出該技術(shù)簡化了企業(yè)開發(fā)流程，但其實隨之而來的可能是后續(xù)更多的復(fù)雜性。

Peter Wayner 認為，隱藏在這些編程拐杖和讀心術(shù)界面背后的幾個黑暗秘密，或許會讓低代碼開發(fā)的誘人前景黯然失色。

供應(yīng)商鎖定

與許多技術(shù)一樣，使用低代碼工具所做的工作量與企業(yè)所受到的控制其實是成正比的。

為什么這樣說?通過將大部分工作交付給工具，企業(yè)對它們的依賴程度越高，它們對企業(yè)流程的控制能力也就越強。

這里我們給出一些可以最小化使用低代碼工具帶來的鎖定問題的策略：企業(yè)可以編寫可移植性更強的代碼，隔離業(yè)務(wù)邏輯，然后使用連接代碼將其封裝，并將其與本地低代碼API連接起來。

需要指出的是，這種方法盡管是可行的，但如果企業(yè)想把所有的東西都放到自己的服務(wù)器上，那么其最終還要自己寫剩下的代碼。

解除鎖定卻帶來了新的編程工作，不知企業(yè)會作何選擇呢?

定價改變的隱患

同許多銷售策略一樣，云平臺通常會提供低價來吸引客戶，然后在可能的時候提高價格。為什么他們敢于這樣做?部分原因便是上面提到的鎖定問題，一旦企業(yè)在該平臺上構(gòu)建了系統(tǒng)，他們就有了控制價格的籌碼。

當(dāng)然，除非你簽了一份長期合同，否則無法確定明年或五年后的運行成本會是怎么變化的。所以，如果企業(yè)的低代碼創(chuàng)建需要在這些云供應(yīng)商的平臺上完成，那么，企業(yè)在做合作談判的時候就需要將其考慮在內(nèi)了。

舉一個可能的定價方面的例子——改變定價公式：從根據(jù)調(diào)用頻率收費切換到根據(jù)帶寬收費。

存在監(jiān)管隱患

因為減少了代碼編寫的工作量，大多數(shù)使用低代碼平臺的企業(yè)很少注意幕后發(fā)生的事情。

也許這些幕后的代碼是官方專有的;也許API調(diào)用背后隱藏著什么秘密......

當(dāng)監(jiān)管機構(gòu)介入時，這一點尤其棘手。因為無從知曉這些“幕后之事”，企業(yè)就沒辦法告訴監(jiān)管機構(gòu)發(fā)生了什么，真的想要辯解卻是“有口說不出”了。

隱藏的低效性

將控制權(quán)移交給功能齊全的API、庫和棧固然不錯，但幕后的代碼通常效率要低得多，因為它必須為許多突發(fā)事件做好準備。

是不是某個傻瓜傳遞了一個空指針?函數(shù)的所有參數(shù)格式都正確嗎?......

低代碼工具供應(yīng)商必須防彈他們的產(chǎn)品，因為他們不知道一些傻瓜可能會做什么。所有這些防彈技術(shù)可能都很棒，但就像裝甲坦克一樣，它的速度通常要慢得多。

功能有限

多數(shù)情況下，企業(yè)在進行低代碼開發(fā)平臺的演示時都非常棒。比如，銷售工程師通過調(diào)用createDoggyDatingSite函數(shù)，僅用一行代碼就創(chuàng)建了一個新的可愛的狗狗約會網(wǎng)站，而這個函數(shù)恰好構(gòu)建在框架中。

其實，大多數(shù)低代碼平臺都比較通用，但是很可能很快就會耗盡內(nèi)置函數(shù)的功能。有時候，客戶可能無意間需要構(gòu)建某個產(chǎn)品細節(jié)，但是任何低代碼公司都不可能預(yù)測到所有的細節(jié)。

這就需要軟件可以靈活地適應(yīng)企業(yè)的需求，而企業(yè)所需的靈活性越大，就需要使用越多的代碼來滿足，但更多的代碼就不是低代碼了。

單向致命bug威脅

先舉一個技術(shù)人員比較熟悉的例子，當(dāng)Libssh出現(xiàn)bug時，服務(wù)器集群中的幾乎所有Unix或Linux機器都將處于危險之中。

成功的低代碼平臺一般也設(shè)計了這一單向性，當(dāng)軟件運行正常的時候，這是一個很好的設(shè)計，但如同上面的Libssh bug一樣，當(dāng)網(wǎng)絡(luò)中發(fā)現(xiàn)致命的缺陷時，所有與之關(guān)聯(lián)的東西都將崩潰。

目前來說，還沒有辦法避免這個問題。

千篇一律的皮囊

有這么一個場景：一位聰明的汽車愛好者注意到，通過購買汽車零部件制造商的庫存產(chǎn)品并將它們組裝在一起，制造一輛汽車并不難。他花了大部分錢為該車打造了一個曲線優(yōu)美的車身，但其他一切都很常見：大眾汽車的門把手、保時捷911的座椅、福特的方向盤等等。

其實，低代碼項目最終會產(chǎn)生相同的效果。這些項目可能最終看起來彼此都非常相似，因為開發(fā)人員使用的是相同的庫存部件。

如果代碼只是用于執(zhí)行任務(wù)，比如維護倉庫中的庫存，那么外觀并不重要。但是如果軟件是企業(yè)品牌的一部分，那么企業(yè)就需要做好心里準備了：其低代碼軟件或許與競爭對手非常相似。

模仿者還是創(chuàng)新者?

很多東西，如果你很容易創(chuàng)建，那么別人肯定也很容易復(fù)制它。

低代碼平臺給與企業(yè)的便捷是其通過簡單的拖拽，搭積木等方式構(gòu)建符合自身應(yīng)用的軟件產(chǎn)品。所以很明顯，該平臺是傾向于避免排他性的。

這里的問題就是，如果該軟件要支持另一家擁有競爭優(yōu)勢的企業(yè)，那也是OK的。因此，如果創(chuàng)建軟件是你的業(yè)務(wù)模型，那么你就要準備好迎接一些競爭了。如何在同樣的框架下脫穎而出是企業(yè)必須要考慮的問題。

不可否認，任何技術(shù)都有其利弊，低代碼開發(fā)也不例外。無論AT的“低代碼”SaaS加速器是出于“好心”還是“好益”，但跳上加速臺的企業(yè)們不能只是“閉著眼旋轉(zhuǎn)跳躍”，也要警惕腳下的這些“坑”。

如何盡可能減少上述低代碼開發(fā)平臺的隱患或許是AT打通企業(yè)最后一公里，吸引更多ISV和解決方案商前不得不思考的問題。

云端星星之火已經(jīng)點燃，阿里、騰訊誰先燎原尚未可知。