從no-code到low-code：企業級hpaPaaS的未來

作者 | 康為

來源 |

阿裡技術公衆号

引子

宜搭負責人骁勇給我舉過一個例子，我們小時候逢年過節穿的衣服，都是去裁縫店選一下材料、量一下尺寸，等個半個來月，讨回來就可以穿了，衣服合身又喜歡。鏡頭切回今天，我們隻需要在天貓、淘寶上看看圖檔、選擇合适的尺寸就可以下單了，第二天就可以穿上，偶爾一絲不合身，偶爾大街上撞衫，但我們并不在意，因為我們享受到了更多的便利與高效。受益于這個産業制定了很多的标準化模型，比如身材模型：S、L、XL、XXL，我不再需要每次都去量身高尺寸，現在标準化生産出來的衣服可以滿足超過 90% 的需求，除明星或特殊場景之外也不會費心思去量身定制。

服裝、飲食、汽車乃至各行各業發展至今都已經形成非常成熟、高效的産業鍊，軟體研發行業同樣如此，業務需求在增長且變化快，越是技術密集型的工種越容易帶來人力不足的瓶頸。這就越需要更多的标準和模型的制定，标準越趨于統一，就越高效，有時候 “放棄創造力才是最大的創造力”，本質是追求普惠，可以預見，未來絕大多數場景将使用标準化模闆通過無定制或低定制來完成業務需求。

期望的軟體研發姿勢

接下來就簡單談一談基于 no-code > low-code > pro-code 漸進式思路的研發體系。

一 前置概念

在開篇之前先介紹幾個概念：

雲計算主要分為三大類服務：軟體即服務 (SaaS)、平台即服務 (PaaS) 和基礎架構即服務 (IaaS)。

• 軟體即服務 (SaaS) 是一種通過網際網路傳遞應用的模式。客戶能夠通過 Web 浏覽器通路 SaaS 應用，這意味着，客戶無需購買、安裝、維護和更新硬體或軟體。SaaS 提供商負責確定一切順利進行，而且客戶通常能夠使用最新版本的應用。
• 平台即服務 (PaaS) 能夠提供雲平台和各種工具，幫助開發人員建構和部署雲應用。使用者可以通過 Web 浏覽器通路 PaaS，是以企業無需購買和維護基礎硬體和軟體。借助 PaaS，開發人員還能采用租用的方式挑選所需的功能。
• 采用基礎架構即服務 (IaaS)，企業可以通過按使用付費的方式，“租用”伺服器、網絡、存儲器和作業系統等計算資源。IaaS 提供商負責托管基礎架構和處理系統維護及備份等任務，這樣，客戶就無需購買硬體或雇傭内部專家對其進行管理。

在 PaaS 層有專門用來支援應用在雲上開發、部署、運作的平台，稱之為 aPaaS (Application platform as a service)，在 aPaaS 基礎上，提供 no-code & low-code 方式開發應用的平台稱之為 hpaPaaS (High-productivity aPaaS)，提供快速應用研發能力，比如業務編排、邏輯編排、模型驅動、頁面編排等。

以上概念加入了一些我的個人了解，不同平台可能有不同解釋，我們接下來對比一下業内幾款明星平台，看能給到我們什麼參考？

二 業内精品

• Microsoft PowerApps：微軟全家桶服務內建的非常好，比如 Excel，全站寫代碼的地方都統一為 Excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分強大，定位 hpaPaaS (low-code)；
• Google AppMaker：谷歌産，谷歌全家桶服務內建的非常好，谷歌工程師文化在 SCRIPTS 展現得比較極緻，無論是後端、前端都使用開發生态的 JS 文法，代碼提示十分友好，定位 hpaPaaS (low-code);
• Salesforce SaaS：平台領頭羊，集 IaaS、PaaS、SaaS 與一體的雲平台，目前市值 1255 億美元;
• Sap：集 IaaS、PaaS、SaaS 與一體的雲平台，相比 salesforce，使用的技術要新一些，體驗上要好一些，目前市值 1577 億美元；
• OutSystems：提供桌面 IDE，最近提供的 OutSystems AI 能夠輔助模型設計，定位 hpaPaaS (low-code)，作為後起之秀，表現不俗，已獲得多輪融資，在 2018 年估值 10+ 億美元，俨然成為下一個獨角獸。

應用研發能力對比如下：

幾點産品體驗感受：

• Google 和 Microsoft 老牌玩家玩 hpaPaaS 這一套相當得心應手，體驗相當講究，把自家的服務包括三方常用服務整合的非常好。
• OutSystems 類似微軟，提供多種流式編排，很多時候不需要寫代碼，同時也整合了非常多資料服務，比如 Swagger 的 OpenAPI。
• Salesforce 和 SAP 類似，從單一的應用程式，到一套應用程式，到一個快速應用開發平台，企業協作工具，再到一個應用程式容器和資料庫提供，提供了一套完整的生态鍊，以 SaaS、PaaS、IaaS 的分層方式對外輸出。

幾點參考：

• 高效整合才能降低成本，這是所有玩家的心智，不容質疑。
• 視角要放大，要能夠覆寫 90% 場景，必須要建構一套完整的生态鍊，從 no-code 到 low-code 再到 pro-code 都要有對應的解決方案，且要做到互相之間能夠打通，這是 Salesforce 和 SAP 給到的經驗，目前 AppMaker 和 PowerApps 主要針對表單、表格垂直領域，還不能夠玩大，單一領域視角解決的問題有限。
• 可視化的流式編排針對特定場景提效明顯，應對稍微複雜一點的場景，一點也不好玩，比如 AppMaker 就粗暴一點，直接使用 SCRIPTS，書寫表達式更舒服，不知道使用 OutSystems 的使用者是什麼感受。

三 走過的可視化建站

很長一段時間，國内興起了很多可視化建站産品，「可視化建站」是「低代碼建站」的前身，目标也是不用寫一行代碼，拖拖拽拽就可以把一個站點搭建起來，但更多的是從表現層（前端）單一領域去解決問題，隻能完成靜态頁面的效果，對于真正的業務很難走完閉環。

總結一下突出的問題：

• 純前端思維，比如資料服務接入方式，缺少像 AppMaker/PowerApps 支援 DataConnectors 的統一資料接入層，和各個系統沒有形成有效整合。
• 能解決的場景也有限，高度複雜的企業級 CRM 系統，不是通篇一律的，業務邏輯高度複雜，面臨定制化考驗，稍微複雜一點的，需要做的工作可能會更多，甚至有時候搞不定，沒有享受到可視化搭建帶來的福報。
• 很多專業開發在搭建平台施展不開才華，缺少專業級工具支援，比如 VSCode、Git。
• 不同角色之間不能有效的形成配合，比如後端資料接口，不能在可視化搭建工具中反射出來。
• 搭建頁面大多以 Schema 形式存儲，代碼也不好 diff，在運作時動态渲染也會帶來性能問題。
• ......

看到衆多業内優秀的設計，給我們帶來了很多奇思妙想，典型的 hpaPaaS 這種架構一定程度上能将我們标準化場景完全解決掉，但标準化場景偏消費性質，消費我們生産的物料沉澱、場景沉澱等，這樣的純 hpaPaaS 平台應對企業級場景肯定會透支，我們在為能活 102 年的超大型企業設計商業作業系統時，不能一律求快、求簡單，還需要考慮靈活性、擴充性、複雜性，在這套系統上要能源源不斷的生産标準化的物料、場景，持續将複雜性問題抽象沉澱，形成一個有效的生态循環系統，我們需要的是一種加強版的 hpaPaaS 平台 —— 企業級 hpaPaaS 平台。

四 企業級的 hpaPaaS

以我們「企業智能事業部」為例做一下簡單的業務分型：

中背景業務大多是和表單、表格相關的，這對 hpaPaaS 平台來說是好事，但真正代表企業級場景特别是财務、法務等系統，涉及到的表單可以用魔鬼來形容，比如表單嵌套表格，表格再嵌套表格（存在必然有合理之處），無法使用一套規則來描述，強大如 AppMaker 或 PowerApps，對這類問題基本無解，主要是沒有提供 backup 機制，企業級應用最初始狀态大多是定制型應用，如何進化為标準化的配置型應用，進一步成為解決方案或商業能力，這是「企業級 hpaPaaS 平台」需要重點解決的。

将較年輕的産品 AppMaker 和 PowerApps 定義為商業級解決方案，将較成熟的 SAP 和 Salesforce 定義為企業級解決方案，商業級能解決大多數通用問題，而企業級是要能解決更多複雜性問題，面對複雜性企業級問題時，我認為最起碼要做到兩點：

• 将不同場景所需要的能力進行分解、分層，最後通過能力的整合來應對，提升靈活變通能力；
• 同時有通用方案和兜底方案，多種方案之間應該遵循統一标準，是打通融合的。

如果非要用一句話概括企業級 hpaPaaS 能力，我認為是從 no-code 到 pro-code 的漸進式能力，如下圖：

實作這樣的「企業級的 hpaPaaS」有以下幾個重難點：

重難點一：從 no-code 到 pro-code

以一個簡單的業務系統為例來說一下這個過程。

疊代一（no-code 開發）

最初比較簡單，符合标準化的 CRUD：

1. 進行業務模組化，配置業務規則；
2. 根據建立好的模型選擇标準化 CRUD 模闆，直接産出；
3. 預覽、釋出。

疊代二（low-code 開發）

但是有些地方需要稍作定制，比如時間戳的格式化、頁面上需要額外展示使用者詳細資訊：

1. 将标準化生成的産物，以可視化編輯打開；
2. 修改關聯字段時間的格式化方式、新增使用者資訊塊；
3. 儲存、預覽、釋出。

疊代三（pro-code 開發）

随着業務複雜度變高，很多業務邏輯需要寫更多代碼，也希望代碼被版本控制、進行 diff 等：

1. 将标準化生成的産物在 WebIDE 中打開；
2. 編輯視圖，比如關聯的動作，定位到對應動作代碼，修改邏輯；
3. 使用 WebIDE 提供的 git 功能，進行代碼對比及代碼送出；
4. 儲存、編譯、預覽、釋出。

no-code 和 low-code 試錯成本低，在創業時期我更希望使用這兩種方式，随着我的業務的成長，價值逐漸被認可，對該産品的要求也變高，這時候我也願意投入更多，這時候可以采用 pro-code 方式對我的項目進行精裝修，這種漸進式傳遞能力将越來越多的被推崇。

在這過程中，有一個關鍵點，no-code 到 low-code 再到 pro-code 始終遵循的是一個标準，在我需要時可以被任意方式打開。

雖然我們期望未來業務研發隻有 10% 的工作需要 pro-code 來完成，但 pro-code 的相關技術體系也是不可或缺的，它就是一個全功能開放的底層架構，no-code 和 low-code 在這之上做的更垂直化，是以并不是說 10% 就不需要了，尤其在做企業級研發，pro-code 的存在更是一顆定心丸。

對于 pro-code 核心關鍵點有：

• WebIDE：pro-code 環節設計上是可以使用桌面 IDE 的方式，但未來必定屬于雲開發時代，桌面 IDE 天然的和 PaaS 平台有割裂感，過去我們擔心 WebIDE 技術不成熟，今天 vscode 引領了新一代的編輯器變革，帶來諸如 coder、theia 等功能和性能都很完備的 WebIDE 技術儲備，技術上沒什麼好擔心的；
• Git 打通：企業級産品，沒有那麼随意，一般需要強管控，其中版本控制尤為重要，不管是 pro-code 還是 no-code，最終形态都是一種代碼形式的标準産物，都應該托管在 Git 倉庫上，在必要的時候可以進行回溯和對比；
• 可視化編輯打通：可視化編輯是 low-code 和 no-code 的代表功能，通過 Recore （統一 DSL）的技術将可視化和 pro-code 打通，是 pro-code、low-code、no-code 三者之間形成互通的必要條件。

重難點二：服務的內建

在上面提到的産品中，都有這樣的一個設計，無論是自家的服務還是别人家的服務通過一個內建平台，将他們有機的整合在一起，在任何需要的環節，都能被高效的使用。

圖檔源自：

https://developers.google.com/

我們也提出 OneService 概念，期望将與資料相關的接口或服務通過 OneService 內建起來，打通生産中的各個環節，如下圖：

重難點三：生命力

我們設計的系統，比較關心兩個問題：

1. 能創造多少價值？
2. 能活多久？

我認為一個具有頑強生命力的系統，應當在時間次元上持續創造價值，有以下幾個關鍵點：

• 适合的土壤，大風向以及政策鼓勵，有強烈市場需求；
• 持續标準化，标準化不是一個固定結果，而是一個動态過程，需要有一個進化機制，保證标準化的生态具有自潔能力，适應行業發展；
• 行業滲透，打通行業鍊路上下遊，将标準、理念融入到行業各節點，能夠反哺自己的生态，并有助于形成規模；
• 共同成長，帶動行業成長，行業的成長就是自己的成長。

五 未來可期

SaaS 化的平台，以 SAP 和 Salesforce 為代表在歐美國家活的很滋潤，在中國剛起步，從過去一年的變化可以看到，國家越來越多的政策在鼓勵中小型創新企業，意味着未來 toB 市場前景廣闊，阿裡整體風向現在也是 toB，釘釘和阿裡雲已經在這條路上越走越穩，讓我們看到，在 toB 這件事情上時機已經成熟，而我們現在要做的就是把本土化的 SaaS 平台做好、做強。

相關參考與連結 https://www.sap.cn/products/business-technology-platform.html