阿里和騰訊的戰火，從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和解決方案商前不得不思考的問題。

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