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

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

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

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

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

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

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

根據(jù) Forrester 的報(bào)告，低代碼開發(fā)平臺(tái)市場(chǎng)將從2015年的17億美金增長(zhǎng)至2020年的155億美金，5年時(shí)間增長(zhǎng)接近十倍。

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

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

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

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

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

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

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

供應(yīng)商鎖定

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

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

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

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

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

定價(jià)改變的隱患

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

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

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

存在監(jiān)管隱患

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

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

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

隱藏的低效性

將控制權(quán)移交給功能齊全的API、庫(kù)和棧固然不錯(cuò)，但幕后的代碼通常效率要低得多，因?yàn)樗仨殲樵S多突發(fā)事件做好準(zhǔn)備。

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

低代碼工具供應(yīng)商必須防彈他們的產(chǎn)品，因?yàn)樗麄儾恢酪恍┥倒峡赡軙?huì)做什么。所有這些防彈技術(shù)可能都很棒，但就像裝甲坦克一樣，它的速度通常要慢得多。

功能有限

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

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

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

單向致命bug威脅

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

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

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

千篇一律的皮囊

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

其實(shí)，低代碼項(xiàng)目最終會(huì)產(chǎn)生相同的效果。這些項(xiàng)目可能最終看起來彼此都非常相似，因?yàn)殚_發(fā)人員使用的是相同的庫(kù)存部件。

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

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

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

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

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

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

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

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