京寵展信息指南
671
2025-04-01
本文目錄一覽:
簡介:?什么是低代碼?我們?yōu)槭裁葱枰痛a?低代碼會讓程序員失業(yè)嗎?本文總結了低代碼領域的基本概念、核心價值與行業(yè)現(xiàn)狀,帶你全面了解低代碼。
什么是低代碼
“Low-Code”是什么?如果你是第一次聽說,沒準也會跟我當年從老板口中聽到這個詞后的內心戲一樣:啥?“Low-Code”?“Code”是指代碼我知道,但這個“Low”字是啥意思?不會是老板發(fā)現(xiàn)我最近趕工寫的代碼很丑很“Low”吧... 想多了,老板怎么可能親自review代碼呢。那難道是指,“Low-level programming”里的“Low”?老板終于發(fā)現(xiàn)讓我等編程奇才整天堆Java業(yè)務代碼太浪費,要派我去閉關寫一個高性能C語言網(wǎng)絡庫... 顯然也不是,老板哪能有這技術情懷呢。那到底是什么意思?作為一名搜商比情商還高的程序員,能問Google的絕不會問老板。于是我一頓操作后,不假思索地點開了第一條搜索結果:Low-code development platform。
Wikipedia定義
從Wiki的這段定義中,我們可以提煉出幾個關鍵信息:
? 低代碼開發(fā)平臺(LCDP)本身也是一種軟件,它為開發(fā)者提供了一個創(chuàng)建應用軟件的開發(fā)環(huán)境。看到“開發(fā)環(huán)境”幾個字是不是很親切?對于程序員而言,低代碼開發(fā)平臺的性質與IDEA、VS等代碼IDE(集成開發(fā)環(huán)境)幾乎一樣,都是服務于開發(fā)者的生產(chǎn)力工具。
? 與傳統(tǒng)代碼IDE不同的是,低代碼開發(fā)平臺提供的是更高維和易用的可視化IDE。大多數(shù)情況下,開發(fā)者并不需要使用傳統(tǒng)的手寫代碼方式進行編程,而是可以通過圖形化拖拽、參數(shù)配置等更高效的方式完成開發(fā)工作。
Forrester定義
順著Wiki的描述還能發(fā)現(xiàn),原來“Low-Code”一詞早在2014年就由Forrester提出了,它對低代碼開發(fā)平臺的始祖級定義是這樣的:
請點擊輸入圖片描述
相比Wiki的版本,這個定義更偏向于闡明低代碼所帶來的核心價值:
? 低代碼開發(fā)平臺能夠實現(xiàn)業(yè)務應用的快速交付。也就是說,不只是像傳統(tǒng)開發(fā)平臺一樣“能”開發(fā)應用而已,低代碼開發(fā)平臺的重點是開發(fā)應用更“快”。更重要的是,這個快的程度是顛覆性的:根據(jù)Forrester在2016年的調研,大部分公司反饋低代碼平臺幫助他們把開發(fā)效率提升了5-10倍。而且我們有理由相信,隨著低代碼技術、產(chǎn)品和行業(yè)的不斷成熟,這個提升倍數(shù)還能繼續(xù)上漲。
? 低代碼開發(fā)平臺能夠降低業(yè)務應用的開發(fā)成本。一方面,低代碼開發(fā)在軟件全生命周期流程上的投入都要更低(代碼編寫更少、環(huán)境設置和部署成本也更簡單);另一方面,低代碼開發(fā)還顯著降低了開發(fā)人員的使用門檻,非專業(yè)開發(fā)者經(jīng)過簡單的IT基礎培訓就能快速上崗,既能充分調動和利用企業(yè)現(xiàn)有的各方面人力資源,也能大幅降低對昂貴專業(yè)開發(fā)者資源的依賴。
低代碼核心能力
基于上述的定義和分析,不難總結出如下這3條低代碼開發(fā)平臺的核心能力:
請點擊輸入圖片描述
??全棧可視化編程:可視化包含兩層含義,一個是編輯時支持的點選、拖拽和配置操作,另一個是編輯完成后所及即所得(WYSIWYG)的預覽效果。傳統(tǒng)代碼IDE也支持部分可視化能力(如早年Visual Studio的MFC/WPF),但低代碼更強調的是全棧、端到端的可視化編程,覆蓋一個完整應用開發(fā)所涉及的各個技術層面(界面/數(shù)據(jù)/邏輯)。
??全生命周期管理:作為一站式的應用開發(fā)平臺,低代碼支持應用的完整生命周期管理,即從設計階段開始(有些平臺還支持更前置的項目與需求管理),歷經(jīng)開發(fā)、構建、測試和部署,一直到上線后的各種運維(e.g. 監(jiān)控報警、應用上下線)和運營(e.g. 數(shù)據(jù)報表、用戶反饋)。
??低代碼擴展能力:使用低代碼開發(fā)時,大部分情況下仍離不開代碼,因此平臺必須能支持在必要時通過少量的代碼對應用各層次進行靈活擴展,比如添加自定義組件、修改主題CSS樣式、定制邏輯流動作等。一些可能的需求場景包括:UI樣式定制、遺留代碼復用、專用的加密算法、非標系統(tǒng)集成。
不只是少寫代碼
回到最初那個直擊心靈的小白問題:Low-Code中的“Low”,到底是啥意思?答案已經(jīng)顯而易見:既不是指抽象程度很低(相反,低代碼開發(fā)方式的抽象程度要比傳統(tǒng)編程語言高一個level),也不是指代碼很low(也相反,低代碼所生成的代碼一般都經(jīng)過精心維護和反復測試,整體質量強于大部分手寫代碼),而是單純的“少寫代碼” —— 只在少數(shù)需要的情況下才手寫代碼,其他大部分時候都能用可視化等非代碼方式解決。
再往深一點兒看,低代碼不只是少寫代碼而已:代碼寫得少,bug也就越少(正所謂“少做少錯”),因此開發(fā)環(huán)節(jié)的兩大支柱性工作“趕需求”和“修bug”就都少了;要測的代碼少了,那么測試用例也可以少寫不少;除了開發(fā)階段以外,平臺還覆蓋了后續(xù)的應用構建、部署和管理,因此運維操作也更少了(Low-Code → Low-Ops)。
然而,少并不是最終目的:如果單純只是想達到少的效果,砍需求減人力、降低質量要求也是一樣的。低代碼背后的哲學,是少即是多(Less is More),或者更準確說是多快好省(Do More with Less) —— 能力更多、上線更快、質量更好,成本還更省,深刻踐行了阿里“既要,又要,還要”的價值觀精髓。
請點擊輸入圖片描述
平臺的職責與挑戰(zhàn)
上面說的是低代碼給開發(fā)者提供的能力與吸引力,那么作為服務的提供方與應用的承載者,低代碼開發(fā)平臺自身應該承擔怎樣的職責,其中又會遇到多大的挑戰(zhàn)?是否就一定要如阿里云所主張的那樣,“把復雜留給自己,把簡單留給別人”?雖然這句話聽起來很深明大義,但不知道大家有沒有想過,為什么我們一定要抱著復雜不放,平白無故給自己找事?就不能直接干掉復雜,也給咱阿里云自己的員工留點簡單嗎?是工作太容易就體現(xiàn)不出來KPI價值了,還是家里的飯菜不如公司的夜宵香?
冥思苦想許久后,我從熱力學第一定律中找到了答案:開發(fā)一個應用的總復雜度是恒定的,只能轉移而不可能憑空消失。要想讓開發(fā)者做的更少,安心享受簡單的快樂,那么平臺方就得做的更多,默默承擔盡可能多的復雜度。就像一個滿身腱子肉的雜技男演員,四平八穩(wěn)地托舉著在高處旋轉與跳躍的女搭檔;上面的人顯得越輕盈越毫不費力,下面的人就得越穩(wěn)重越用盡全力。當然,不是說上面的女演員就很輕松沒壓力,只是他們各自的分工不同,所承擔的復雜度也不一樣。
根據(jù)《人月神話》作者Fred Brooks的劃分,軟件開發(fā)的復雜度可以劃分為本質復雜度(Essential complexity )和偶然復雜度(Accidental complexity)。前者是解決問題時固有的最小復雜度,跟你用什么樣的工具、經(jīng)驗是否豐富、架構好不好等都無關,而后者就是除此之外在實際開發(fā)過程中引入的復雜度。通常來說,本質復雜度與業(yè)務要解決的特定問題域強相關,因此這里我把它稱為更好理解的“業(yè)務復雜度”;這部分復雜度不是任何開發(fā)方法或工具能解決的,包括低代碼。而偶然復雜度一般與開發(fā)階段的技術細節(jié)強相關,因此我也相應把它稱為“技術復雜度”;而這一部分復雜度,恰好就是低代碼所擅長且適合解決的。
為開發(fā)者盡可能屏蔽底層技術細節(jié)、減少不必要的技術復雜度,并支撐其更好地應對業(yè)務復雜度(滿足靈活通用的業(yè)務場景需求),這是身為一個低代碼開發(fā)平臺所應該盡到的核心職責。
請點擊輸入圖片描述
在盡到上述職責的同時,低代碼開發(fā)平臺作為一個面向開發(fā)者的產(chǎn)品,還需要致力于為開發(fā)者提供簡單直觀的極致開發(fā)體驗。這背后除了巨大的工作量,還得能在“強大”和“易用”這兩個很難兩全其美的矛盾點之間,努力找到一個符合自己產(chǎn)品定位與目標客戶需求的平衡點 —— 這也許是設計一個通用低代碼開發(fā)平臺所面臨的最大挑戰(zhàn)。
三、低代碼相關概念對比
純代碼(Pro-Code / Custom-Code)
“純代碼”可能算是我杜撰的一個詞,更常見的說法是-碼(Pro-Code)或定制代碼(Custom-Code);但意思都一樣,就是指傳統(tǒng)的以代碼為中心(Code-Centric)的開發(fā)模式。之所以我選擇用“純代碼”,是因為如果用“-碼”會顯得似乎低代碼就不專業(yè)了一樣,而用“定制代碼”又容易讓人誤解成低代碼無法支持定制的自定義代碼。
當然,更準確的稱謂我認為是“高代碼”(與低代碼恰好對應,只是名字太難聽,被我嫌棄了...),因為即便是使用傳統(tǒng)的代碼IDE,有些開發(fā)工作也支持(甚至更適合)以非代碼方式完成,比如:iOS端開發(fā)時使用的SwiftUI界面設計器、服務端開發(fā)數(shù)據(jù)庫應用時使用的PowerDesigner建模工具。不過這部分可視化工作在傳統(tǒng)開發(fā)模式下只是起輔助作用,最后通常也是生成開發(fā)者可直接修改的代碼;開發(fā)者仍然是以代碼為中心來開展主要工作。
低代碼與純代碼之間的關系,其實跟視頻和文章之間很像:
低代碼就像是現(xiàn)代的“視頻”,大部分內容都由直觀易理解、表達能力強的圖片組成,因此更容易被大眾所接受。但與此同時,視頻也不是死板得只能有圖片,完全可以添加少量文字(如字幕、標注)來彌補圖片表達不夠精確的問題。BTW,關于“圖”和“文字”之間的辯證關系,可以進一步參考《架構制圖:工具與方法論》[1]這篇文章中的相關描述。
純代碼則更像是傳統(tǒng)的“文章”,雖然很久以來都一直是信息傳播的唯一媒介,但自從視頻技術誕生以及相應軟硬件基礎設施的普及以來,便逐漸開始被搶走了風頭。如今,視頻已成為大部分人獲取信息的主要渠道(從電視電影到B站抖音),而經(jīng)常讀書讀文章的人卻越來越少。但不可否認的是,文章依然有它存在的意義和受眾(不然我也不會費這勁敲這么多字了),即使“市場份額”一直在被擠壓,但永遠會有它立足的空間。
請點擊輸入圖片描述
如果按上面這種類比關系推導,低代碼未來也會遵循與視頻類似的發(fā)展軌跡,超越純代碼成為主流開發(fā)模式。Gartner的預測也表達了相同的觀點:到2024年,所有應用程序開發(fā)活動當中的65%將通過低代碼的方式完成,同時75%的大型企業(yè)將使用至少四種低代碼開發(fā)工具進行應用開發(fā)。
但同樣地,就像是視頻永遠無法取代文章一樣,低代碼也永遠無法徹底取代純代碼開發(fā)方式。未來低代碼和純代碼方式將以互補的形態(tài)長期共存,各自在其所適合的業(yè)務場景中發(fā)光發(fā)熱。在后面的“低代碼業(yè)務場景”章節(jié),會詳細列出哪些場景在現(xiàn)階段更適合用低代碼模式開發(fā)。
零代碼(Zero-Code / No-Code)
從分類的完備性角度來看,有“純代碼”自然也應該有完全相反的“零代碼”(也稱為“無代碼”)。零代碼就是完全不需要寫代碼的應用開發(fā)平臺,但這并不代表零代碼就比低代碼更高級和先進,它只是做了一個更極端的選擇而已:徹底擁抱簡單的圖形可視化,完全消滅復雜的文本代碼。選擇背后的原因是,零代碼開發(fā)平臺期望能盡可能降低應用開發(fā)門檻,讓人人都能成為開發(fā)者(注意:開發(fā) ≠ 寫代碼),包括完全不懂代碼的業(yè)務分析師、用戶運營,甚至是產(chǎn)品經(jīng)理(不懂裝懂可不算懂)。
即便是專業(yè)開發(fā)者,在技術分工越來越精細的趨勢下(前端/后端/算法/SRE/數(shù)據(jù)分析..),也很難招到一個能獨立開發(fā)和維護整套復雜應用的全棧工程師。但零代碼可以改變這一切:無論是Java和JavaScript傻傻分不清楚的技術小白,還是精通深度學習但沒時間學習Web開發(fā)的算法大牛,都可以通過零代碼實現(xiàn)自己的技術夢或全棧夢。“改變世界的idea已有,就差一個程序員了”,這句玩笑話或許真的可以成真;哦不,甚至都用不著程序員,有idea的人自己就能上。
請點擊輸入圖片描述
當然,所有選擇都要付出代價,零代碼也不例外。完全拋棄代碼的代價,就是平臺能力與靈活性受限:
? 一方面,可視化編輯器的表達能力遠不及圖靈完備的通用編程語言,不引入代碼根本沒法實現(xiàn)靈活的定制與擴展(當然,理論上也可以做成Scrach/Blockly那樣的圖形編程語言,但那樣不過是換一種形式在手寫代碼而已)。
? 另一方面,由于目標受眾是非專業(yè)開發(fā)人員,平臺能支持的操作會更趨于“傻瓜化”(e.g. 頁面只支持大塊業(yè)務組件的簡單堆疊,不支持細粒度原子組件和靈活的CSS布局定義),同時也只會透出相對“親民化”的模型和概念(e.g. 使用“表格”表示數(shù)據(jù),而不是用“數(shù)據(jù)庫”),無法支撐強大專業(yè)的底層開發(fā)原語和編程理念。
請點擊輸入圖片描述
雖然零代碼與狹義上的低代碼有著上述明顯差異,但從廣義上來說,零代碼可以當作低代碼的一個子集。Gartner在其相關調研報告中,就是將“No Code”劃在了范圍更廣的低代碼應用平臺“LCAP”(Low-Code Application Platform)中。而當前市面上很多通用的低代碼開發(fā)平臺,也都兼具一定程度的零代碼能力;比如低代碼領域領頭羊Mendix,既提供了簡單易用的零代碼Web IDE - Mendix Studio,也包括一個功能更強大的低代碼桌面IDE - Mendix Studio Pro。
HpaPaaS(高生產(chǎn)力應用PaaS)
上文提到,“Low-Code”一詞是拜Forrester所賜。作為同樣是國際知名調研機構(a.k.a 造詞小能手)的Gartner,顯然不會輕易在這場可能決定低代碼領域江湖地位的新概念作詞大賽中認輸,于是也于2017年發(fā)明了“HpaPaaS”(High-productivity application Platform as a Service)這個聽上去更高大上的縮寫詞。
按照Gartner的定義,HpaPaaS是一種支持聲明式、模型驅動設計和一鍵部署的平臺,提供了云上的快速應用開發(fā)(RAD)、部署和運行特性;這顯然與低代碼的定義如出一轍。但事實證明,名字起得太專業(yè)并不見得是好事,“HpaPaas”最終還是敗給了起源更早、更接地氣也更順口的“Low-Code”:從2019年開始,Gartner在其相關調研報告中也開始全面采用“Low-Code”一詞(如LCAP),親手為“HpaPaaS”打上了 @deprecated 印記。
請點擊輸入圖片描述
圖源:What’s the difference between SaaS / IaaS / PaaS / aPaaS / HpaPaaS?
值得補充的是,“HpaPaaS“這個詞也并非橫空出世,而是傳承自更早之前Gartner提出的“aPaaS”,它倆之間的關系是:HpaPaaS只是aPaaS的一個子類;除了HpaPaaS這種通過低代碼實現(xiàn)的高生產(chǎn)力應用開發(fā)平臺以外,aPaaS還包括面向純代碼的傳統(tǒng)應用開發(fā)平臺(High-control aPaaS,即可控度更高的純代碼開發(fā)方式)。
不值得但就想八卦一下的是,“aPaaS”這個詞也非憑空捏造,而是與云計算的興起淵源頗深。相信各位云道中人都已猜到,aPaaS與IaaS/PaaS/SaaS這些云計算遠古概念是一脈相承的:aPaaS介于PaaS和SaaS之間,相比PaaS提供的服務更偏應用,但又不像SaaS一樣提供現(xiàn)成的軟件服務(更詳細的說明可參考配圖來源文章)。
四、為什么需要低代碼
低代碼是什么可能并沒那么重要,畢竟在這個信息爆炸的世界,永遠不缺少新奇而又短命的事物。大部分所謂的新技術都只是曇花一現(xiàn):出現(xiàn)了,被看到了;大部分人“哦”了一聲,已閱但表示不感興趣;小部分人驚嘆于它的奇思妙想,激動地點了個贊后,回過頭來該用什么還是什么。真正決定新技術是否能轉化為新生產(chǎn)力的,永遠不是技術本身有多么優(yōu)秀和華麗,而是它是否真的被需要,即:為什么需要低代碼?如果用不同的主語填充上面這個問句(冷知識:這叫做“延遲主語初始化”),可以更全面地看待這個問題:
為什么「市場」需要低代碼?
在這個大爺大媽都滿嘴“互聯(lián)網(wǎng)+”和“數(shù)字化轉型”的時代,企業(yè)越來越需要通過應用(App)來改善企業(yè)內部的信息流轉、強化與客戶之間的觸點連接。然而,誕生還不太久的IT信息時代,也正面臨著與我國社會主義初級階段類似的供需關系矛盾:落后的軟件開發(fā)生產(chǎn)力跟不上人民日益增長的業(yè)務需求。
請點擊輸入圖片描述
Gartner預測,到2021年應用開發(fā)需求的市場增長將至少超過企業(yè)IT交付能力的5倍。面對如此巨大的IT缺口,如果沒有一種革命性的“新生產(chǎn)力”體系,很難想象僅憑現(xiàn)有傳統(tǒng)技術體系的發(fā)展延續(xù)就能徹底解決問題。而低代碼技術正是帶著這樣的使命而降臨,期望通過以下幾個方面徹底革新應用開發(fā)生產(chǎn)力,拯救差一點就要邁入水深火熱的IT世界:
提效降本 質量保障
雖然軟件行業(yè)一直在高速發(fā)展,新的語言、框架和工具層出不窮,但作為從業(yè)者我們不得不承認:軟件開發(fā)仍處于手工作坊階段,效率低、人力成本高、質量不可控。項目延期交付已成為行業(yè)常態(tài),而瓶頸幾乎總是開發(fā)人員(對機器能解決的問題都不是問題);優(yōu)秀的開發(fā)人才永遠是稀缺資源,還賊貴;軟件質量缺陷始終無法收斂,線上故障頻發(fā)資損不斷。
相比而言,傳統(tǒng)制造業(yè)經(jīng)過幾百年工業(yè)革命的發(fā)展,大部分早已擺脫了對“人”的強依賴:從原料輸入到制品輸出,中間是各種精密儀器和自動化流水線的穩(wěn)定支撐,真正實現(xiàn)生產(chǎn)的標準化和規(guī)模化。雖然信息化號稱是人類的第三次工業(yè)革命,但以軟件行業(yè)目前的狀況,遠遠還沒到達成熟的“工業(yè)化”階段。
所以,親愛的程序員朋友,當你與前端聯(lián)調了一上午接口,又與產(chǎn)品撕逼了一下午需求,再與自己的bug抗爭了一整晚,好不容易遁入夢鄉(xiāng)又被一連串報警短信吵醒時,是否有抬頭對著星空憧憬過:“I have a dream... that one day,軟件開發(fā)也能像工業(yè)制品一樣,批量流水化生產(chǎn),穩(wěn)定高效沒煩惱。” 事到如今,不管你有沒有意識到,這個憧憬正在慢慢變成現(xiàn)實。
請點擊輸入圖片描述
是的,低代碼正在將應用軟件開發(fā)過程工業(yè)化:每個低代碼開發(fā)平臺都是一個技術密集型的應用工廠,所有項目相關人員都在同一條產(chǎn)線內緊密協(xié)作。開發(fā)主力不再是熟知for循環(huán)一百種寫法的技術Geek,而是一群心懷想法業(yè)務sense十足的應用Maker。借助應用工廠中各種成熟的基礎設施、現(xiàn)成的標準零件、自動化的裝配流水線,開發(fā)者只需要專注于最核心的業(yè)務價值即可。即便是碰到非標需求,也可以隨時自己動手,用最靈活的手工定制(代碼)方式來解決各種邊角問題。
擴大應用開發(fā)勞動力
通過讓大部分開發(fā)工作可以僅通過簡單的拖拽與配置完成,低代碼(包括零代碼)顯著降低了使用者門檻,讓企業(yè)能夠充分利用前面所提到的平民開發(fā)者資源。部分純零代碼需求場景下,低代碼還能讓業(yè)務人員實現(xiàn)自助式(self-service)應用交付,既解決了傳統(tǒng)IT交付模式下的任務堆積(backlog)問題,避免稀缺的專業(yè)開發(fā)資源被大量簡單、重復性的應用開發(fā)需求所侵占,也能讓業(yè)務人員真正按自己的想法去實現(xiàn)應用,擺脫交由他人開發(fā)時不可避免的桎梏。
請點擊輸入圖片描述
至此,應用開發(fā)能力不再是少數(shù)專業(yè)開發(fā)者的專利和特權,且今后所需要的技能門檻與擁有成本也會越來越低,真正實現(xiàn)所謂的“技術民主化”(democratization of technology)。
加強開發(fā)過程的溝通協(xié)作
多方調查結果顯示,軟件項目失敗的最主要原因之一就是缺乏溝通(poor communication)。傳統(tǒng)開發(fā)模式下,業(yè)務、產(chǎn)品、設計、開發(fā)、測試與運維人員各司其職,且各有一套領域內的工具和語言,長久以來很容易形成一個個“豎井”(silos),讓跨職能的溝通變得困難而低效。這也是為什么當前熱門的敏捷開發(fā)和DevOps都在強調溝通(前者是協(xié)同Biz與Dev,而后者是協(xié)同Dev和Ops),而經(jīng)典的DDD領域驅動設計也主張通過“統(tǒng)一語言”來減少業(yè)務與技術人員之間的溝通不一致。
請點擊輸入圖片描述
有了低代碼后,這一狀況將得到根本改善:上述各角色都可以在同一個低代碼開發(fā)平臺上緊密協(xié)作(甚至可以是同一個人),這種全新的協(xié)作模式不僅打破了職能豎井,還能通過統(tǒng)一的可視化語言和單一的應用表示(頁面/數(shù)據(jù)/邏輯),輕松對齊項目各方對應用形態(tài)和項目進度的理解,實現(xiàn)更終極的敏捷開發(fā)模式,以及在傳統(tǒng)DevOps基礎之上更進一步的BizDevOps[2]。
統(tǒng)一開發(fā)平臺下的聚合效應
低代碼嘗試將所有與應用開發(fā)相關活動都收斂到同一個平臺(one platform)上后,將會產(chǎn)生更多方面的聚合效應與規(guī)模收益:
??人員聚合:除了上一點所提到的各職能角色緊密協(xié)作以外,人員聚合到統(tǒng)一的低代碼開發(fā)平臺進行作業(yè)后,還能促進整個項目流程的標準化、規(guī)范化和統(tǒng)一化。
??應用聚合:一方面,新應用的架構設計、資產(chǎn)復用、相互調用變得更容易;另一方面,各應用的數(shù)據(jù)都天然互通,同時平臺外數(shù)據(jù)也能通過集成能力進行打通,徹底消除企業(yè)的數(shù)據(jù)孤島問題。
??生態(tài)聚合:當?shù)痛a開發(fā)平臺聚合了足夠多的開發(fā)者和應用后,將形成一個巨大的、連接一切、有無限想象力的生態(tài)體系,徹底放飛低代碼的價值。
低代碼開發(fā)平臺(Low-Code Development Platform,LCDP)是低代碼開發(fā)所需的環(huán)境。大多數(shù)低代碼平臺都是以云上提供的aPaaS(Application Platform as a Service,應用程序平臺即服務)的形式,不僅用于開發(fā),還用于應用程序的運行,實現(xiàn)了軟件開發(fā)到應用的一貫性支持。
所謂低代碼開發(fā),是指盡量無需編寫源代碼,通過使用“圖形用戶界面/GUI”這一可視化操作,在極短的時間內實現(xiàn)系統(tǒng)開發(fā)的手法。目前也有通過在Web瀏覽器上搜索所需組件,整合粘貼來制作應用程序的工具。
采用低代碼開發(fā),無需SQL記述就可以制作數(shù)據(jù)庫,簡化開發(fā)工序。在保證一定擴展性的同時,可以有效縮短開發(fā)工時。
為什么選擇低代碼開發(fā)平臺?低代碼開發(fā)平臺最初被關注的是用于移動應用的開發(fā)。與基礎系統(tǒng)開發(fā)相比,手機app開發(fā)對速度的要求更高,而且還必須支持多設備。在傳統(tǒng)意義上,要在短時間內推出這樣的移動應用程序是非常困難的,于是,低代碼開發(fā)平臺進入了開發(fā)人員的視野。
在現(xiàn)今社會,低代碼開發(fā)平臺受到關注的最大理由是數(shù)字化轉型(DX)。所謂數(shù)字化轉型,是指通過人工智能和物聯(lián)網(wǎng)等信息技術,將一切事物通過數(shù)字數(shù)據(jù)連接起來,從而從根本上改變企業(yè)業(yè)務模式。
目前許多企業(yè)都在致力于數(shù)字化轉型,以求在高速發(fā)展的時代中生存下來。企業(yè)的IT部門為了推進數(shù)字化轉型,必須更密集的進行軟件開發(fā)。但是,軟件開發(fā)技術人員的數(shù)量是遠遠不夠的,僅靠IT部門根本無法滿足軟件開發(fā)的需求。
低代碼開發(fā)平臺,可以被一般的業(yè)務人員、一線工作人員、管理人員等非專業(yè)的開發(fā)人員使用,無論是否有開發(fā)基礎或經(jīng)驗,都可以經(jīng)過簡單的培訓進行軟件開發(fā)。
低代碼開發(fā)的優(yōu)勢縮短開發(fā)時間
低代碼開發(fā)最大的優(yōu)勢是可以縮短開發(fā)時間,也就節(jié)約了開發(fā)成本。低代碼開發(fā)平臺提供了大量的通用組件,可以實現(xiàn)一些基礎功能。必要時可以添加自己編寫的代碼,來滿足用戶的功能需求,提供質量穩(wěn)定的應用程序。
無需擔心安全性
低代碼開發(fā)平臺的供應商會提供相應的安全對策,用戶無需擔心程序的安全性以及開發(fā)過程中的安全風險。為了實現(xiàn)特殊功能,需要自己編寫代碼時,用戶只需關注自己的編寫部分的安全性即可。
降低開發(fā)門檻
在低代碼開發(fā)中,無需編寫復雜的源代碼,就可以在專用的平臺上編寫程序。即使沒有受過編程專業(yè)教育的人,也可以在平臺上輕松地進行開發(fā)工作。在傳統(tǒng)印象中,程序開發(fā)都是由專業(yè)的工程師來完成,使用低代碼開發(fā)平臺,程序開發(fā)的門檻大大降低了。
低代碼開發(fā)平臺的主要功能通用性組件
低代碼開發(fā)平臺提供了大量通用的組件,這些可供使用的組件種類多樣。
此外,用戶也可以利用第三方開發(fā)的組件。這樣的可再利用形式的組件,支撐著在低代碼開發(fā)平臺的視覺建模。
視覺建模
低代碼開發(fā)平臺以模型驅動型開發(fā)為基礎,任何人都可以通過可視化建模,輕松實現(xiàn)程序開發(fā)。
通過拖放可以將所需的流程和組件整合,無需編程即可創(chuàng)建程序。同時,有編程技能的工程師也可以根據(jù)需要進行編碼,從而定制組件。
支持各種架構
要開發(fā)與企業(yè)架構相對應的基礎系統(tǒng),就必須具備與各種系統(tǒng)協(xié)作的功能。在這一點上,低代碼開發(fā)平臺支持大多數(shù)的主流操作系統(tǒng)和數(shù)據(jù)庫。
另外,通過豐富種類的API,可以和外部系統(tǒng)自由合作。因此,低代碼開發(fā)平臺具有可擴展性和開放架構,可支持大企業(yè)的基礎系統(tǒng)開發(fā)。
基于代碼的擴展
完全不使用代碼的無代碼工具,特點是使用預設好的功能來制作簡單的應用程序。對于低代碼開發(fā)平臺,用戶也可以通過編碼自由擴展組件的功能。
低代碼開發(fā)平臺可以根據(jù)客戶各自的需求,進行各種各樣的定制,即使是復雜的大規(guī)模系統(tǒng)開發(fā)也能應對。
軟件全生命周期整體支持
目前提供的低代碼開發(fā)平臺大部分采用的是云服務aPaaS的形式。
因此,低代碼開發(fā)平臺并非單純的應用開發(fā)工具,從與數(shù)據(jù)庫的自動連接、測試、正式啟動、進一步運行管理、變更管理等開發(fā)工序到實際運用工序,搭載了支持整個軟件生命周期的功能。
與無代碼開發(fā)平臺的區(qū)別與低代碼開發(fā)平臺對應的是無代碼開發(fā)平臺(No-Code Development Platform, NCDP)。無代碼顧名思義,就是不以編寫代碼為前提的開發(fā)方法。
低編碼和無編碼在某種程度上非常相似。前述的可視化建模、可再利用的通用性組件、生命周期管理等低代碼開發(fā)平臺的特征也適用于無代碼開發(fā)平臺。
無代碼開發(fā)平臺同樣適用于專業(yè)的開發(fā)者和無基礎開發(fā)者,提供了能夠在更短的時間內輕松發(fā)布應用的環(huán)境。無需通過編碼進行編程,通過PaaS平臺提供,可以在不構建操作環(huán)境的情況下立即運行。
乍一看,無代碼開發(fā)平臺只是從低代碼開發(fā)平臺中去掉了編寫代碼的要素。但實際上它們是非常不同的。
首先,無代碼開發(fā)平臺不能通過編寫代碼來擴展或定制功能。因此,無代碼開發(fā)平臺目標是通過預先準備好的組件和API,實現(xiàn)功能范圍內的相對簡單的程序開發(fā)。不需要專業(yè)開發(fā)人員進行系統(tǒng)設計和數(shù)據(jù)庫設計,經(jīng)過簡單的功能設計后立刻就可以使用。
典型的例子是使用Excel等電子表格的普通業(yè)務人員,將Excel和紙質工作系統(tǒng)化,自己創(chuàng)建應用程序,以簡化日常工作。這些應用程序由其使用者來完成運營,隨著業(yè)務的變化可以靈活的調整應用程序的功能。
無代碼開發(fā)平臺不能通過編寫代碼擴展功能,所以不適合功能較多的程序開發(fā)。此外,由于API的系統(tǒng)協(xié)作自由度較低,也不適合核心系統(tǒng)的開發(fā)。
低代碼:朝著更好的未來行進得益于一些廠商的努力,低代碼行業(yè)正在構建起健康的生態(tài)。我們在討論低代碼的未來時,需要清楚一點的是,低代碼并非萬能,它有清晰的能力邊界,而非一些聲音所說的會“搶走程序員的飯碗”。低代碼是企業(yè)數(shù)字化建設當中“最后一公里”,在保障企業(yè)數(shù)字化進程的價值賦能下,中國市場會有低代碼的一方天地。
國內的簡搭(jabdp)開發(fā)平臺是一個低代碼開發(fā)平臺,復雜的業(yè)務功能,只需要會基本的sql語句和javascript語法,就能進行快速開發(fā),滿足其個性化的業(yè)務需求,設計出各種復雜的企業(yè)web應用。主要特點如下:
可靈活定制:簡搭(jabdp)低代碼平臺提供了強大的定制能力,包括頁面定制、數(shù)據(jù)表管理、業(yè)務流程定制等,便于實現(xiàn)各類企業(yè)應用。
權限管理:簡搭(jabdp)低代碼平臺提供組織結構管理和精細的權限管理多人,便于企業(yè)根據(jù)實際情況靈活地進行權限設置和調整,促進內部協(xié)作。
易于部署和維護:簡搭(jabdp)低代碼平臺提供一鍵部署功能,無需配置復雜的網(wǎng)絡服務器;根據(jù)企業(yè)的需求變化進行系統(tǒng)維護也更容易。
支持二次開發(fā)和系統(tǒng)集成:簡搭(jabdp)低代碼平臺是一個開放的快速開發(fā)平臺,有經(jīng)驗的程序員依然可以基于jabdp定制開發(fā)出許多高級的功能,而不受jabdp本身的限制;同時,簡搭(jabdp)低代碼平臺開發(fā)出的應用也可以很方便地與企業(yè)的現(xiàn)有信息系統(tǒng)集成,或者與微信、釘釘?shù)鹊谌綉眉伞?/p>
簡搭(jabdp)低代碼平臺適合用于大部分的企業(yè)級web應用的開發(fā),尤其適合企業(yè)信息管理系統(tǒng)(MIS)、企業(yè)資源計劃系統(tǒng)(ERP)、客戶關系管理系統(tǒng)(CRM),業(yè)務支撐系?統(tǒng)(BSS)等。并且就一些經(jīng)典的項目案例提取整合出各種類型的項目模板,共享給開發(fā)者參考,開發(fā)者可以在原有的項目基礎上進行修改定制,以打造其個性化的企業(yè)信息化平臺。
關于低代碼開發(fā)平臺,一個常見的誤區(qū)是認為“低代碼開發(fā)平臺只適用于平民開發(fā)者(Citizen?Developer)”。平民開發(fā)者是指那些非傳統(tǒng)的、沒有受過專業(yè)編程教育的開發(fā)者,他們主要用低代碼平臺來創(chuàng)造和定制應用。
當然,通過使用低代碼開發(fā)平臺,可以降低對多數(shù)項目人員的技術要求。在多個項目并行時,只需要一個有經(jīng)驗的程序員進行數(shù)據(jù)表、業(yè)務邏輯等的設計即可,其他項目人員無需編程能力,這樣在人月數(shù)和人員要求兩個方向都能有效控制項目的投入。
借助低代碼開發(fā)平臺,可以更高效地理解中小企業(yè)的信息化項目需求,控制項目開發(fā)的成本,同時適應中小企業(yè)信息化需求變化快和缺乏專業(yè)技術人員進行項目維護的特點,是開發(fā)中小企業(yè)信息化項目的最佳選擇。
什么是零代碼應用開發(fā)平臺?
盡管市場上也把建站、網(wǎng)店開發(fā)、小程序開發(fā)等免代碼服務也稱為零代碼開發(fā),但因為這些平臺面向apaas特征的是特定的目的,服務一個專有的范式,所以一般不將他們劃入零代碼平臺的范疇之內。真正的零代碼開發(fā)平臺面向的是廣泛和多樣的需求,在設計aPaaS產(chǎn)品的時候,并不確定一個特定的用戶會用它來搭建什么應用。
當然,雖說面向的需求是廣泛的,也不代表aPaaS是萬能的。零代碼開發(fā)幾乎都是面向企業(yè)應用世界,而很難擴展到消費者應用領域,比如游戲、社交、工具軟件等必然長期屬于原生開發(fā)的世界。
所以,零代碼應用開發(fā)平臺需要一個比較準確的定義。它是指圍繞企業(yè)數(shù)據(jù)和業(yè)務管理需求,通過可視化方式設計數(shù)據(jù)結構,用戶交互形式、設置訪問權限和定義工作流程的平臺。apaas特征你會發(fā)現(xiàn),即使是原生開發(fā)企業(yè)軟件,大體也是按照以上這幾個步驟來進行的。
我用一個相對完整的列表,將零代碼開發(fā)平臺的能力元素和特性描述如下:
1)可視化構筑業(yè)務對象數(shù)據(jù)表(Entity),并支持建立關聯(lián)。甚至需要支持跨應用的數(shù)據(jù)表關聯(lián)。(這是aPaaS未來可能勝出其他方案的關鍵優(yōu)勢)。
2)為不同的數(shù)據(jù)場景配置不同類型的視圖(View),能夠定義數(shù)據(jù)行和列的過濾,能夠設置列表、看板、日歷等不同界面形式。
明道云構筑的銷售應用數(shù)據(jù)視圖
3)能夠定義不同用戶角色(Role),并賦予角色不同的數(shù)據(jù)訪問和改寫權限(Permission Set)。權限定義越精細越好。
明道云構筑用戶角色和權限組合的界面
4)能夠建立針對數(shù)據(jù)的匯總表和統(tǒng)計圖表(Report)
5)能夠建立自定義的輸入表單(Form),分發(fā)給不同角色使用。
6)能夠建立自定義的打印報表(Form Report),用于輸出各類形式表格,通過Email,短信發(fā)送或者打印。
7)能夠管理企業(yè)用戶、部門、組織結構,并將其用于應用邏輯關系,比如應用的分發(fā),角色的賦予和工作流中的流向信息。
8)能夠可視化配置工作流(Workflow),支持特定條件下的數(shù)據(jù)新增,改寫,刪除等操作,并能夠融入數(shù)據(jù)填寫,審批等人工流程節(jié)點。工作流的運行能夠監(jiān)控和保存日志。
明道云構筑審批工作流的界面
9)應用能夠封裝后分發(fā)(Distribution)給不同的用戶。
10)面向企業(yè)內部個人用戶的工作臺,儀表臺等特性,實現(xiàn)個性化使用。
不同的aPaaS產(chǎn)品會有不同的特色和側重點。所以以上特性并不一定存在于每一個aPaaS產(chǎn)品中。但是,特性越完整的,就越接近一個典型意義上的零代碼企業(yè)應用開發(fā)平臺。在以上實現(xiàn)中,有純粹的零代碼模式,也有個別需要用低代碼方式來降低產(chǎn)品復雜度,但同時也會讓非技術人員難以上手。
所以,aPaaS是SaaS應用和開發(fā)工具的混合,說它是SaaS,是因為開發(fā)者和終端用戶使用的是同一個產(chǎn)品,只是通過權限和分發(fā)關系讓界面千人千面。說它是開發(fā)工具,是因為它用模型模擬的應用搭建思路和原生數(shù)據(jù)庫應用開發(fā)是類似的。
軟件的應用特點和二次開發(fā)能力共存也不是一個新鮮事物。用Excel軟件構筑一個個人所得稅計算器,讓用戶可以輸入自己的工資,即可得到應繳稅額,對于使用者來說是應用,對編制這個Excel文件的人來說是開發(fā)工具,但他們用的都是Excel。
為什么企業(yè)軟件領域可以實現(xiàn)零代碼開發(fā)?
為什么游戲和社交軟件做不到零代碼開發(fā),而企業(yè)軟件市場卻出現(xiàn)apaas特征了零代碼工具?是因為企業(yè)軟件的開發(fā)比較簡單嗎?
當然不是。能夠模式化完成一個工作的原因在于這項工作具備可重復性,就像我們會用3D打印制作一兩件零件,但如果要生產(chǎn)成千上萬個同樣的零件,我們寧可花費成本先去制作模具。企業(yè)軟件可以模式化開發(fā)的原因就在于大多數(shù)企業(yè)管理軟件都由非常類似的需求和實現(xiàn)方式來構成,如果不積極利用這些相似性和模型化方法就需要不斷重復發(fā)明類似的輪子。
當然也并非所有的企業(yè)應用都有相似性。在特定行業(yè)和職能中總有一些需要專門化設計和開發(fā)的應用。但在企業(yè)的運營全流程中,圍繞客戶,供應商,銷售訂單,產(chǎn)品,供應商,采購訂單,制造流程,服務流程等商業(yè)對象,企業(yè)軟件要解決的問題具有很強的相似性。這些相似性,或者使用范式可以被概括為以下環(huán)節(jié):
1)圍繞上述商業(yè)對象(Business Objects)的數(shù)據(jù)搜集和存儲,并對數(shù)據(jù)的有效性進行驗證。例如:建立一個采購訂單,向特定供應商采購三項商品。
2)數(shù)據(jù)的查詢和呈現(xiàn)。例如:運營部門查詢處A倉庫在今天應該到貨的采購訂單。財務部門查詢貨物已經(jīng)收訖,并且應該在本周付款的采購訂單。
3)數(shù)據(jù)的計算。例如:當采購訂單的貨物到達特定倉庫后,更新相關商品的庫存信息。
4)流程的控制。例如:當起草采購訂單并準備發(fā)出時,根據(jù)采購的類別和金額發(fā)起不同的審核流程,在審核通過或者拒絕后執(zhí)行不同的流程內容。
5)信息通知。例如:在采購訂單批準后,自動生成采購單并發(fā)送給供應商,并通知倉庫準備收貨。
6)數(shù)據(jù)的統(tǒng)計和分析。例如:匯總過去一年的采購訂單中按照BOM清單的產(chǎn)品金額分布,或者按照供應商的分布。
企業(yè)軟件的設計和開發(fā)人員對以上這些使用范式都非常熟悉,它們經(jīng)常出現(xiàn)在各種企業(yè)軟件的開發(fā)需求中。實際上,除了以上抽象出的范式,企業(yè)軟件的其他獨特功能點并不太多了,甚至很多屬于所有企業(yè)級軟件共有的模塊,比如管理用戶和用戶組,權限角色等。正是因為這個原因,企業(yè)軟件的開發(fā)存在高度模型化的可能,從而在大部分場景下,擺脫對原生代碼開發(fā)的依賴。
在云時代之前,除了Access以外,蘋果公司也有FileMaker,Intuit公司也曾經(jīng)開發(fā)過Quickbase(這個名字來源于Intuit公司財務軟件產(chǎn)品Quicken),Quickbase后來被剝離,一直到今天都在提供服務。即使在原生開發(fā)領域內,企業(yè)軟件市場也出現(xiàn)了各種現(xiàn)成的開發(fā)框架,它們和今天的零代碼平臺一樣,都是為了通過模型化來提高交付效率和質量的辦法。
為每個企業(yè)的軟件需求,都從第一行代碼開始寫起,單獨依靠某種高級語言和集成開發(fā)環(huán)境建立開發(fā)項目,這種做法已經(jīng)越來越?jīng)]有必要。正如Gartner的預測,大部分的企業(yè)應用將來都會依賴零代碼平臺,以至于不遠的將來,零代碼平臺并不會刻意保留這個前綴,因為這將成為天經(jīng)地義的事情,這就像今天為了滿足一個通用需求,大多數(shù)企業(yè)不會去定制開發(fā),甚至零代碼平臺都不會用,而是直接使用一個標準的SaaS產(chǎn)品。
為什么aPaaS具有難以替代的優(yōu)勢?
用戶開始選擇aPaaS產(chǎn)品,不僅僅是因為他們可以這樣做,更重要的是因為不得不這樣做。因為aPaaS與定制開發(fā),以及標準SaaS產(chǎn)品相比有幾個難以替代的優(yōu)勢。
1)滿足企業(yè)的多樣化需求
企業(yè)軟件需求的多樣化是定制開發(fā)模式的起源。雖然標準SaaS產(chǎn)品能夠滿足企業(yè)應用需求中的共性部分,但是因為行業(yè)、規(guī)模和產(chǎn)品內在特性的差異,每個企業(yè)的管理方式和流程都有自己的特點,而且它還會根據(jù)企業(yè)的規(guī)模階段不斷演變。這種差異在不同職能中程度不一,一般來說,圍繞產(chǎn)品設計、制造和服務履行的核心業(yè)務流差異度更高,而人事,財務等價值創(chuàng)造的支持環(huán)節(jié)差異度比較小。
在這種背景下,用戶始終在尋求一種既能保持足夠的靈活性,又能夠控制開發(fā)的成本和復雜度的方法。aPaaS基本就是直接針對這個問題而誕生的。
2)從定制開發(fā)中需求溝通的痛苦中解脫
企業(yè)軟件實現(xiàn)過程中的第一痛點還不是貴,而是需求溝通的復雜。有業(yè)務需求的人不是開發(fā)軟件的人,能夠開發(fā)軟件的人對業(yè)務痛點并沒有切身的體會和經(jīng)驗。于是行業(yè)非常依賴專業(yè)的企業(yè)軟件需求分析和實現(xiàn)方法設計能力,但這個能力是非常稀缺的資源。這也難怪企業(yè)軟件開發(fā)需求的提出主體總是五花八門的,他們之間也需要進行復雜的溝通和信息匯總。
更要命的是,很多時候需求在實施之前都無法100%確定,企業(yè)自己無法提出一個完整的解決方案。這時候,要么需要求助于咨詢機構這樣的外腦,要么就只能走一步看一步。這兩個方案聽起來都不令人舒適。前者絕非普通中小企業(yè)所能夠承受,后者可能會影響系統(tǒng)的開發(fā)和實施質量。
aPaaS的出現(xiàn)倒是讓走一步看一步的方案變得更加現(xiàn)實。企業(yè)可以通過零代碼平臺漸進地開始實施。如果整個系統(tǒng)過于復雜,可以先從一個具體的環(huán)節(jié)開始,局部數(shù)字化(比如先把訂單管起來)。反正用aPaaS搭建的速度足夠快,用戶甚至可以利用零代碼工具來生成企業(yè)應用原型,在實際使用中進行驗證,確認了終端用戶可以掌握,原先識別的問題可以被有效解決之后,再繼續(xù)推進更完整的實施。
可以這么說,零代碼工具可以讓開發(fā)者和使用者之間的距離充分縮短。在極端情況下,使用者甚至可以自己就是搭建開發(fā)者自己。他們可能在一兩個小時的搭建后就能夠確認這個方案是不是能夠有效地解決問題。
3)在企業(yè)內部打通數(shù)據(jù)中臺的需求
在企業(yè)IT中,還有一個致命痛點存在,那就是不同業(yè)務系統(tǒng)之間的數(shù)據(jù)相互隔離,不能綜合使用,使得企業(yè)難以進行跨職能的數(shù)據(jù)相關性和因果分析,也難以實現(xiàn)跨職能的數(shù)據(jù)自動化。比如要分析一個價格調整措施對財務報表的影響,這個工作在任何一個孤立的信息系統(tǒng)中是無法完成的,而如果要做到,就至少需要從采購,銷售,營銷和財務系統(tǒng)中獲得數(shù)據(jù)。同樣的道理,企業(yè)也很難在遇到財務目標無法達成的情況下,自動做出最優(yōu)的價格決策。這些都是影響企業(yè)運營水平至關重要的問題。近年來,Gartner提出的Paced Layer架構,以及阿里給電商企業(yè)提供的中臺方案就是針對這種需求的反饋。
大企業(yè)當然可以投入專門的資金來打造數(shù)據(jù)中臺性質的系統(tǒng),但小企業(yè)支付不起,并不代表他們不想獲得這樣的能力。aPaaS平臺提供了這個可能性。
首先,因為aPaaS平臺管理數(shù)據(jù)的模型一致,所以它一般能夠提供一個標準化程度非常高的編程接口,從外部系統(tǒng)匯合數(shù)據(jù)變得相對容易很多,這就像路由器一樣,不管apaas特征你有多少聯(lián)網(wǎng)設備,它們都可以用統(tǒng)一的協(xié)議連接在一起。有了集中的數(shù)據(jù),各種應用需求都變得容易兌現(xiàn)。哪怕個別系統(tǒng)依然需要通過抽取數(shù)據(jù)服務后另行原生開發(fā),也比不斷重復做數(shù)據(jù)整合工作要高效很多倍。
甚至,如果用aPaaS平臺直接管理業(yè)務數(shù)據(jù)對象,這個數(shù)據(jù)整合工作都可以免除。用戶可以直接在各個職能相關的數(shù)據(jù)對象中建立關聯(lián),建立匯總查詢,批量抽取數(shù)據(jù)到BI平臺,建立不同數(shù)據(jù)之間的自動化。
有關企業(yè)數(shù)字中臺的介紹,建議可以讀一下這篇采訪文章。
4)突出的成本和效率優(yōu)勢
零代碼開發(fā)平臺和原生代碼開發(fā)相比到底能夠提高多少效率目前還沒有精確的計量,但這個效率差至少是10倍以上。傳統(tǒng)開發(fā)模式需要10天的,aPaaS一天之內就能夠搞定。
更重要的效率差別不僅僅是時間,還包括零代碼平臺可以免除專業(yè)技術人員的參與。雖然它要求搭建者熟悉業(yè)務,完成基本的邏輯梳理,但畢竟這和動輒需要和好幾位技術人員一起開會溝通需求要高效得多。即便在復雜的應用系統(tǒng)上,也至多只需要2-3人分工就能夠完成整個項目的實現(xiàn)。因為簡化協(xié)作的原因帶來的成本節(jié)省甚至都不值十倍了。因為所有人都知道找到靠譜的定制軟件開發(fā)團隊幾乎就是一件撞大運的事情。
同時,定制開發(fā)通常很難提供高品質的軟件。軟件運行的可靠性,缺陷消除的程度都很難和標準化產(chǎn)品相比,畢竟定制軟件只有一個用戶。而一個aPaaS平臺不僅要同時服務很多終端用戶,還要服務五花八門的應用搭建者,它能夠做到一次對,次次對;一次缺陷消除,所有用戶收益的效果。
5)開箱即用和自己動手的兩全
和成型的SaaS應用相比,aPaaS看似有一個缺點,就是依然需要“搭建”。這有點像整體家具系統(tǒng),擺在樣品間很好看,但是實際買回家還需要施工人員來拼裝才能達到預期的效果。
實際上,這個問題并不是無解,甚至很好解。aPaaS一開始自然不可能獲得各個行業(yè)的最佳實踐,讓每個企業(yè)都能夠看到“樣板間”效果。但是,隨著時間的推移,用戶企業(yè)和集成商的參與,樣板間會越來越多,甚至比SaaS產(chǎn)品提供的用例方案更加強大,因為后者提供的是一個固定家具的擺設效果,而前者能夠根據(jù)不同的房型,提供不同的家具組合方案。
而且,在足夠明確的細分市場下(比如金屬加工制造流程管理這樣的顆粒度),可以在aPaaS平臺上開發(fā)出完全開箱即用的應用,直接分發(fā)給不同企業(yè)使用。有了這個能力,aPaaS不僅能夠服務好終端用戶,還能夠催生集成商工作模式的變革,他們不僅可以通過出售IT服務掙錢,還能夠在服務中加入解決方案的價值,消除定制開發(fā)成本,大幅提高項目服務毛利。
有了開箱即用的能力后,就能夠大大加速企業(yè)采納的意愿。而且,才采納以后,“自己動手”的能力依然存在。就像先進的整體家居系統(tǒng)不僅可以組合,而且可以重新組合。企業(yè)軟件的適用模式永遠和企業(yè)階段有關,比如小型制造業(yè)并不見得需要質量管理單元,但當年產(chǎn)值突破一億元左右后,不僅面臨ISO認證的剛性需求,也內在地需要引入全面質量管理。這樣的企業(yè)可以在軟件實施后依照實際需要繼續(xù)調整、改進和增加軟件模塊。這個過程同樣是低成本和高效率的。
6)平臺特征提供的計算能力保證
在數(shù)據(jù)庫應用中,有一個潛在的計算性能問題,尤其是在大規(guī)模數(shù)據(jù)表中進行復雜查詢和聯(lián)動計算時。如今,很多行業(yè)的企業(yè)數(shù)據(jù)規(guī)模都從數(shù)千數(shù)萬條記錄增長到百萬,千萬,甚至電商廠商輕而易舉可以達到億級數(shù)據(jù)。在制造和物流行業(yè),物聯(lián)網(wǎng)技術也必然帶動更多的聯(lián)網(wǎng)對象,產(chǎn)生的數(shù)據(jù)不僅規(guī)模巨大,而且計算形式也需要有針對性地加強。
對于定制實施系統(tǒng)來說,要分別通過分布式數(shù)據(jù)庫,流式計算等先進技術來克服性能問題是一件極其昂貴的事情。aPaaS平臺雖然為用戶提供的是一個應用級的產(chǎn)品,但因為它范式統(tǒng)一,就有機會將這些基礎計算隱藏起來,讓用戶不必關心這些后臺事務就能夠獲得高性能的計算服務。通過aPaaS平臺管理的數(shù)據(jù)表無論規(guī)模有多大,讀寫有多么頻繁,實時查詢的要求有多高,總有一個計算框架可以勝任。這種平臺的擴展性讓客戶可以真正放心,aPaaS帶來的不僅僅是開發(fā)效率的提升,還包括一個伸縮自如的基礎設施服務。即便企業(yè)將來的業(yè)務規(guī)模成長百倍,也不會需要徹底重建IT系統(tǒng)。實際上,年收入數(shù)百億美元的業(yè)務,背后驅動的IT平臺極有可能就是Salesforce的http://force.com平臺搭建的應用,而不需要是獨立建立的應用系統(tǒng)。
正是因為以上這些優(yōu)勢,aPaaS在沒有得到行業(yè)命名之前就已經(jīng)開始逐步滲透到企業(yè)IT服務領域。在最近幾年正在悄悄替代大量的定制實施軟件項目,也讓原先依靠標準SaaS產(chǎn)品的企業(yè)找到了新的選擇。
aPaaS目前適合什么樣的企業(yè)?
aPaaS雖然擁有巨大的優(yōu)勢,但也不代表它能夠滿足所有行業(yè)和企業(yè)的所有IT需求。下面列出了一些常見的排除項。aPaaS方案對這些性質的需求吸引力不強。
1)行業(yè)有明顯的專有特征
有些行業(yè)本身的專有化程度很高,而且企業(yè)之間的差異性不大,這時候垂直的行業(yè)應用可能更加合理。
圍繞這個特征最典型的例子就是餐飲業(yè)和酒店業(yè)。所有餐飲業(yè)的運營邏輯都是類似的,除了單店和連鎖可能使用不同復雜度的方案以外,應用模塊都大同小異。而且,這個行業(yè)解決問題的方法和范式是有明顯的行業(yè)特征的,比如餐廳的排隊等座系統(tǒng),點單結賬系統(tǒng)等。用零代碼工具來構建如此專有的場景反而更加麻煩,而且無法有效提供有行業(yè)特色的視圖。
2)行業(yè)有獨立的代碼審計要求
金融等行業(yè)的核心業(yè)務系統(tǒng)因為法規(guī)等要求不能使用零代碼平臺,因為它無法滿足代碼審計的要求。aPaaS平臺不一定能夠提供源代碼給用戶企業(yè),而且即使提供,也無法佐證應用系統(tǒng)處理數(shù)據(jù)的準確性。這些行業(yè)因為監(jiān)管要求高,本身資金也寬裕,所以不會應用aPaaS方案在核心業(yè)務環(huán)節(jié)。
3)面向顧客的前臺系統(tǒng)
這個當然就是指的電商網(wǎng)店平臺了。雖然電商零售的基本數(shù)據(jù)管理和aPaaS的能力并無太大的距離,但是面向消費者的前臺系統(tǒng)一般要求更高的靈活性和營銷設施的配套,用零代碼平臺創(chuàng)建不如直接使用專門的電商系統(tǒng),比如有贊、微盟等開店方案。它們提供的不僅僅是店面功能,還包括圍繞顧客的營銷服務和支付平臺,這些是aPaaS所不擅長的領域。
除此之外的大部分企業(yè)IT需求,零代碼平臺都有足夠的優(yōu)勢來勝任。而且,隨著軟件和服務的界限越來越模糊,很難說未來的aPaaS不能擴展它的領地。企業(yè)軟件的本質就是生產(chǎn)力工具,aPaaS的核心精神就是圍繞企業(yè)的數(shù)字化運營提供高生產(chǎn)力選項。
在用戶滲透的過程中,當前階段的零代碼平臺更多滿足的還不是普通企業(yè)的需求,而是那些有一定的自建IT能力的企業(yè)。他們一般擁有若干名信息化專員,能夠理解自己企業(yè)的核心業(yè)務流程和問題,能夠和業(yè)務部門展開有效的溝通。除了終端企業(yè)用戶外,行業(yè)咨詢群體和ISV群體也開始更多關注零代碼工具,因為行業(yè)咨詢者永遠都希望擁有屬于自己的落地工具集,而他們很難投入做出自己高質量的原生軟件產(chǎn)品;而ISV群體則常年面臨項目實施成本高,客戶需求差異度大的痛點,希望通過某種平臺來降低開發(fā)服務成本,沉淀自己的方案能力,從而讓項目實施具備更多的可復制特點。行業(yè)咨詢、管理咨詢和ISV群體對零代碼平臺的掌握最終會讓這個門類的解決方案走入更多的主流企業(yè)用戶。
讀完這段,如果你對零代碼平臺有興趣,明道云提供直接的使用體驗,你可以自助注冊試用。
低代碼開發(fā)平臺最近好像挺熱啊,聽說微軟、Google都入局了,國內資本如今也在熱捧。百度指數(shù)了解了一下,關聯(lián)度最高的那幾個國內產(chǎn)品,不少是存在了好多年,更有甚者xx表差不多是上一個世紀的老產(chǎn)品了,也來蹭一下熱度。
那么,低代碼到底是什么玩意?是新鮮事物么?為啥上個世紀的老產(chǎn)品也湊一份熱鬧?我們一起去看看。
低代碼平臺,洋文稱Low Code Development Platform,注意了,這個Low可不是你想的那個Low,不是低級的意思,而是少量、簡易的DSL代碼甚至是無代碼的意思。
為什么能夠是更少量甚至是無代碼呢?開發(fā)者們想想自己是怎么減少重復代碼的就會明白了。 我拿自定義表單的場景作為例子,從演化的路徑上來看,是這樣的:
一開始,在一個應用里實現(xiàn)了一個自定義表單的功能,做新應用的時候,也需要這個功能,我們會把原來的代碼復制一份,然后簡單改一些樣式或變量,搞定。
然后,越來越多的應用需要自定義表單的功能了,我們把那砣代碼抽象成一個函數(shù)庫,每次需要的時候只需要引用函數(shù)庫,給不同的參數(shù)就好了,省了代碼復制不說,一下子就提升了代碼的可維護性,這時,代碼就開始變少了。
再后來,我們嫌引用函數(shù)庫還麻煩了,我們把這個功能做成了一個獨立應用或微服務,提供一系列常見的表單模板,使用的時候,在這個應用里面選一個模板,稍配置一下,然后復制一個鏈接到目標應用上粘貼一下就能用了。這個時候,自定義表單變成了一個Saas服務,目標應用中要實現(xiàn)自定義表單的功能已經(jīng)不需要編寫代碼了。至此,這個自定義表單服務就是一個低代碼應用了。
所以,低代碼的本質就是應用場景的極致抽象并且模板化的過程。實際上,我們以前看到的低代碼產(chǎn)品多了去了,只是那個時候還沒有低代碼這個概念罷了。下面我給你說說:
上面舉的自定義表單例子,你可能有意無意間接觸過了,例如金數(shù)據(jù),就是對表單收集這個場景進行了極致的抽象,形成一套固定的表單設計套路,并且讓表單的開發(fā)可以通過可視化配置來完成。順帶說一句,金數(shù)據(jù)的創(chuàng)始人現(xiàn)在就在二次創(chuàng)業(yè),做的正是低代碼開發(fā)平臺。所以,你懂的了。
早年的DreamWave、FrontPage,現(xiàn)在的RapidWeaver等可視化網(wǎng)頁制作軟件、大量的在線可視化網(wǎng)站拖拉拽建站應用,就是網(wǎng)頁制作場景的低代碼平發(fā)平臺。
BAAS,Backend As A Service,后端服務平臺,直接讓開發(fā)者省掉了后端的開發(fā)工作,也是一種典型的低代碼開發(fā)平臺,例如微信小程序的云開發(fā)平臺、知曉云、Lean Cloud等。
眾多的移動應用、小程序可視化制作平臺,提供大量的場景模板,簡單調整一下參數(shù)就可以得到一個自己的應用。
以上這些應用場景的本質都是低代碼或零代碼,但為什么低代碼平臺的概念在這幾年才興起?我猜想,是應用的場景覆蓋得更廣、涉及開發(fā)的環(huán)節(jié)更完整導致了平臺化的出現(xiàn)。
應用的場景覆蓋得更廣了,之前的低代碼應用,只能夠滿足相對窄的應用場景,如建站、表單、BAAS,但到了后面,抽象層次往下降一層,允許定義數(shù)據(jù)結構、定義界面和流程,能夠解決更多通用的場景了,就自然而然有了平臺的感覺。
涉及開發(fā)的環(huán)節(jié)更完整了,以前的建站,純粹是前端頁面的拼湊,而BAAS,也只是解決后端的問題,而到了后來的小程序可視化制作時,就把前后端的開發(fā)都囊括進去了,幾乎就不需要代碼開發(fā)了,又自然而然有開發(fā)平臺的即視感了。
再看看微軟和Google的低代碼平臺,都是解決相對通用場景、涵蓋前后端開發(fā)環(huán)節(jié)的形態(tài),就更加印證了我的猜想。
不對呀,上面說到了通用場景,但同時也說了低代碼的本質是場景的抽象并且模板化,通用和模板化不矛盾嗎?這里就要說低代碼平臺的限制了,所謂的通用場景也只能是相對通用,可模板化的,于是就有了模板化的通用場景,即這個通用場景是受限的,不是完全的通用。所以,現(xiàn)在大多數(shù)的低代碼平臺都是面向企業(yè),做企業(yè)應用的。因為企業(yè)應用,是一個可以模板化的垂直通用場景,例如釘釘宜搭、簡道云、織信Informat等等,都是服務企業(yè)用戶。
最后,低代碼并非零代碼,盡管市面上有不少零代碼的應用平臺打著低代碼的旗號吸引關注。代低碼平臺的底層邏輯還是一個開發(fā)平臺,需要對個性化的需求開放實現(xiàn)途徑,如何開放?開放接口?二次開發(fā)?還是開放DSL?不一而足。如果一個平臺沒有支持個性化需求的開發(fā)能力,那它不算是一個及格的低代碼開發(fā)平臺,充其量只是低代碼應用罷了。
好了,現(xiàn)在你已經(jīng)知道什么是低代碼了,往后,我會帶大家一起實現(xiàn)一些低代碼開發(fā)的場景,并對低代碼的商業(yè)化進行深度的思考,例如誰會為低代碼平臺買單、低代碼平臺到底是專業(yè)平臺還是小白應用等等。? 合理并且有效地運用低代碼,不僅可以讓我們工作高效地運行,還能最大程度保證團隊目標的達成。我推薦織信,它內置了100+的應用模板,覆蓋OA、ERP、CRM、績效、人事、企業(yè)服務、個人及組織等多個應用場景。
低代碼是指低代碼開發(fā)平臺,低代碼開發(fā)平臺(LCDP)是無需編碼(0代碼)或通過少量代碼就可以快速生成應用程序的開發(fā)平臺。通過可視化進行應用程序開發(fā)的方法(參考可視編程語言),使具有不同經(jīng)驗水平的開發(fā)人員可以通過圖形化的用戶界面,使用拖拽組件和模型驅動的邏輯來創(chuàng)建網(wǎng)頁和移動應用程序。
低代碼開發(fā)平臺(LCDP)的正式名稱直到2014年6月才正式確定,整個低代碼開發(fā)領域卻可以追溯到更早前第四代編程語言和快速應用開發(fā)工具。
優(yōu)勢
1、上手快
由于低代碼或0代碼的特征,無疑會大大降低編程語言的學習難度,尤其是0代碼(無代碼)開發(fā)平臺,甚至完全不懂程序語言的業(yè)務人員都可以快速進行學習和應用開發(fā)。
2、開發(fā)快
由于使用大量的組件和封裝的接口進行開發(fā),以及集成云計算的IaaS和PaaS層能力,使得開發(fā)效率大幅提升;普遍的觀點,低代碼能夠提升30%以上的開發(fā)效率,而0代碼(無代碼)則能夠數(shù)倍提升開發(fā)效率;并大幅降低開發(fā)成本。
“云服務”是指在云計算的技術架構支撐下apaas特征,對外提供的按需分配、可計量的IT服務,可用于替代用戶本地自建的IT服務,按服務層次可分為IaaS、PaaS、SaaS。PaaS介于IaaS和SaaS之間,隨著云計算的深入發(fā)展,逐漸成為云計算技術和應用創(chuàng)新最活躍的領域。PaaS行業(yè)產(chǎn)業(yè)鏈包括上游基礎硬件和基礎軟件供應商,中游主要的的PaaS服務商以及下游的產(chǎn)品運營服務商。
行業(yè)主要上市公司:阿里巴巴(09988)、騰訊控股(00700)、用友網(wǎng)絡(600588)、金蝶國際(00268)、東軟集團(600718)、華勝天成(600410)、優(yōu)刻得(688158)等
本文核心數(shù)據(jù):云計算市場規(guī)模、PaaS市場規(guī)模
行業(yè)概況
1、定義
云計算是分布式計算的一種,指的是通過網(wǎng)絡“云”將巨大的數(shù)據(jù)計算處理程序分解成無數(shù)個小程序,然后,通過多部服務器組成的系統(tǒng)進行處理和分析這些小程序得到結果并返回給用戶。“云”實質上就是一個網(wǎng)絡,狹義上講,云計算就是一種提供資源的網(wǎng)絡,使用者可以隨時獲取“云”上的資源,按需求量使用,并且可以看成是無限擴展的,只需按使用量付費。從廣義上說,云計算是與信息技術、軟件、互聯(lián)網(wǎng)相關的一種服務,這種計算資源共享池叫做“云”,云計算把許多計算資源集合起來,通過軟件實現(xiàn)自動化管理,快速提供資源。
公有云、私有云和混合云是從部署方式的角度對云計算進行的分類。公有云,指基礎設施由某一組織所擁有,面向公眾或某一行業(yè)提供云計算服務的部署模式;私有云,是將云基礎設施與軟硬件資源部署在內網(wǎng)之中,供機構或企業(yè)內各部門使用的云計算部署模式。混合云指,同時部署公有云和私有云的云計算部署模式。
而“云服務”是指在云計算的技術架構支撐下,對外提供的按需分配、可計量的IT服務,可用于替代用戶本地自建的IT服務,按服務層次可分為IaaS、PaaS、SaaS。
關于IaaS、PaaS、SaaS這三者的區(qū)別,行業(yè)內的軟件架構師們曾用披薩作為比喻進行解釋。
假設一個餐飲業(yè)者,計劃經(jīng)營披薩店。店長可以選擇從頭到尾生產(chǎn)披薩,但是所需設備、資源和流程較多,因此店長決定外包一部分工作,購買apaas特征他人的服務,現(xiàn)有三種可選方案:
1)方案一(IaaS):apaas特征他人提供廚房、爐子、煤氣,店長使用這些基礎設施,自行烤制披薩。
2)方案二(PaaS):除了基礎設施,他人還提供披薩餅皮,店長只需自己配料,讓他人烤制。即店長只參與了設計披薩的味道(海鮮披薩或者雞肉披薩),他人提供平臺服務,讓店長的的設計實現(xiàn)。
3)方案三(SaaS):他人提供披薩成品。店長只需參與銷售環(huán)節(jié),可以進行一定的包裝設計。
上述三種方案即與IaaS、PaaS、SaaS形成了對應。IaaS是云服務的最底層,主要提供一些基礎資源,產(chǎn)品主要有Amazon
EC2、Linode、Joynet、IBM Blue Cloud以及Cisco UCS等。
PaaS提供軟件部署平臺(runtime),抽象掉了硬件和操作系統(tǒng)細節(jié),可以無縫地擴展(scaling)。開發(fā)者只需要關注自己的業(yè)務邏輯,不需要關注底層。產(chǎn)品主要有Google
App Engine、Heroku以及Windows Azure latform等。
SaaS是軟件的開發(fā)、管理、部署都交給第三方,不需要關心技術問題,可以即拿即用。普通用戶接觸到的互聯(lián)網(wǎng)服務,幾乎都是SaaS。產(chǎn)品有Salesforce
sales cloud、GoogleAppsyiji IBM Lotus Live等。
而PaaS介于IaaS和SaaS之間,隨著云計算的深入發(fā)展,逐漸成為云計算技術和應用創(chuàng)新最活躍的領域。從應用場景來看,PaaS分為APaaS(Application
PaaS,應用開發(fā)平臺即服務)、IPaaS(Integration
PaaS,集成平臺即服務)、IoTPaaS(物聯(lián)網(wǎng)平臺即服務)、AIPaaS(人工智能平臺即服務)、BDPaaS(大數(shù)據(jù)平臺即服務)、DBPaaS(DataBase
PaaS數(shù)據(jù)庫平臺即服務)、SOPaaS(Security and Operation
PaaS,安全及運維平臺即服務)等。而從服務范圍來看,PaaS又可以分為公有PaaS和私有PaaS。
2、產(chǎn)業(yè)鏈剖析:介于IaaS和SaaS之間
PaaS行業(yè)產(chǎn)業(yè)鏈包括上游基礎硬件和基礎軟件供應商,中游主要的PaaS
服務商以及下游的產(chǎn)品運營服務商。上游的laaS服務商為中游的PaaS服務商提供基礎設施資源和服務,包括云主機、云儲存、云網(wǎng)絡、CDN、虛擬化硬件等。中游PaaS服務商為下游的SaaS服務商提供數(shù)據(jù)庫、應用開發(fā)、應用部署、應用運行、基礎框架、中間件等服務。下游的SaaS服務商提供的SaaS服務包括CRM、ERP、HRM、OA(財務管理)、內容服務、通信協(xié)作等。
行業(yè)發(fā)展歷程:行業(yè)進入融合期
在PaaS行業(yè)早期,云計算廠商最先關注SaaS和laas,對PaaS的開發(fā)相對滯后。2011-2012年間,AWS Beanstalk、RedHat
Openshift、VMWare Cloud Foundry等PaaS平臺陸續(xù)推出市場。轉折出現(xiàn)在2013年,dotCloud的Solomon
Hykes第一次演示了Docker技術,提供了一種在Linux容器中運行應用的新方式。隨著云計算概念的熱潮,阿里巴巴、華為等科技巨頭在公有云PaaS領域層層加碼,一批初創(chuàng)型PaaS服務公司涌現(xiàn)在市場中,PaaS加速應用推廣。發(fā)展至今,SaaS、laaS廠商的業(yè)務向PaaS市場滲透,云計算產(chǎn)業(yè)融合趨勢越來越顯著。
行業(yè)政策背景:政策環(huán)境利好
近年來,國務院、工信部等部門發(fā)布一系列云計算相關法規(guī)標準,一方面將用于指導云計算系統(tǒng)的設計、開發(fā)和部署,另一方面更是規(guī)范和引導云計算基礎設施建設、提升云計算服務能力水平(尤其是云計算安全方面)、以及規(guī)范市場秩序等。數(shù)字化轉型和產(chǎn)業(yè)升級是大勢所趨,云計算作為數(shù)字經(jīng)濟的基石,有望依托政策拐點,率先迎來行業(yè)景氣度的新一輪提升。
行業(yè)發(fā)展現(xiàn)狀
1、公有云有望成為主要動力
隨著經(jīng)濟回暖,全球云計算市場所受影響逐步減弱,至2021年已基本恢復到疫情前增長水平。根據(jù)Gartner統(tǒng)計,2021年以laaS、PaaS、SaaS為代表的全球公有云市場規(guī)模達到3307億美元,增速32.5%。
根據(jù)中國信通院數(shù)據(jù),2021年中國云計算總體處于快速發(fā)展階段,市場規(guī)模達3229億元,較2020年增長54.4%。其中,公有云市場規(guī)模增長70.8%至2181億元,有望成為未來幾年中國云計算市場增長的主要動力。
2、PaaS保持細分市場最高增速
根據(jù)中國信通院數(shù)據(jù),2017-2021年,中國公有云PaaS雖然在三種類型的公有云服務市場中占據(jù)著最小的市場份額,但是近年來一直保持著各細分市場中最高的增長速度,2021年其市場規(guī)模增長至196億元,增速為90.7%,占整體市場的份額由2017年的4.47%上升至2021年的15.04%。
注:上圖環(huán)形圖由內到外依次為2017-2021年數(shù)據(jù)。
3、技術賦能型PaaS占市場份額最大
根據(jù)海比研究院報告,PaaS具體可分為技術賦能型、應用開發(fā)型、集成服務型及底座支撐型四種類型。其中,技術賦能型核心價值在于將技術賦能于前端的應用和業(yè)務,降低技術的使用門檻;應用開發(fā)型核心價值在于提升應用開發(fā)效率;集成服務型核心價值在于解決數(shù)據(jù)孤島問題并深度挖掘數(shù)據(jù)價值;底座支撐型核心價值在于提供以云原生技術為主的底層技術支持。總體來看,PaaS處于成長期,發(fā)展?jié)摿薮蟆F渲校?020年,技術賦能型市場規(guī)模達108億元,占市場份額最大,為38.5%。
4、下游制造業(yè)市場占比最大
根據(jù)海比研究院數(shù)據(jù),制造行業(yè)PaaS市場規(guī)模最大,約占12.1%的市場份額,主要由于制造業(yè)企業(yè)眾多,且常采用均價較高的定制化PaaS。
行業(yè)競爭格局
1、區(qū)域競爭:北廣杭深領跑全國
為客觀反映各地云計算市場的發(fā)展狀況,并衡量地方政府對云計算發(fā)展的引導作用,中國社科院戰(zhàn)略研究所聯(lián)合阿里云通過主成分分析法(Principal
Components Analysis,PCA),針對中國大陸的城市及省級行政區(qū)構建了一套云計算發(fā)展評價指標體系。
從云計算發(fā)展水平綜合得分情況來看,中國大陸的337個地級及以上城市可分為5個梯隊,包括深圳、杭州、北京和廣州4個云計算一線城市、成都等14個云計算二線城市、石家莊等80個云計算三線城市、德州等101個云計算四線城市和長治等138個云計算五線城市。
中國大陸的31個省級行政區(qū),同樣可根據(jù)云計算評價指標體系綜合得分分為5個梯隊。其中,第一梯隊包括廣東、浙江、北京和江蘇,4省市對后續(xù)梯隊省級行政區(qū)的優(yōu)勢顯著;第二梯隊包括山東、福建、四川、湖南、河北、上海、湖北;第三梯隊為河南、遼寧、安徽、陜西;第四梯隊包括貴州、江西、內蒙古、廣西、山西、重慶、云南、天津、甘肅和黑龍江;第五梯隊包括吉林、青海、海南、新疆、寧夏、西藏。
2、企業(yè)競爭:阿里云、亞馬遜云科技、華為云為行業(yè)領導者
根據(jù)賽迪發(fā)布的《2021-2022?年中國PaaS市場研究年度報告》,從市場地位與發(fā)展能力兩個維度對中國PaaS市場廠商競爭力進行評估,阿里云、亞馬遜云科技、華為云處于市場領先地位。
行業(yè)發(fā)展前景及趨勢預測
1、新型數(shù)據(jù)中心構建版圖
數(shù)據(jù)中心的構建和完善對云計算的發(fā)展極為重要。新型數(shù)據(jù)中心是以支撐經(jīng)濟社會數(shù)字轉型、智能升級、融合創(chuàng)新為導向,以5G、工業(yè)互聯(lián)網(wǎng)、云計算、人工智能等應用需求為牽引,匯聚多元數(shù)據(jù)資源、運用綠色低碳技術、具備安全可靠能力、提供高效算力服務、賦能千行百業(yè)應用的新型基礎設施,具有高技術、高算力、高能效、高安全特征。隨著新一代信息技術快速發(fā)展,數(shù)據(jù)資源存儲、計算和應用需求大幅提升,傳統(tǒng)數(shù)據(jù)中心正加速與網(wǎng)絡、云計算融合發(fā)展,加快向新型數(shù)據(jù)中心演進。《新型數(shù)據(jù)中心發(fā)展三年行動計劃(2021-2023年)》的發(fā)布有利于給apaas特征我國云計算產(chǎn)業(yè)提供規(guī)劃指導,有利于apaas特征我國云計算產(chǎn)業(yè)極其配套措施的完善和協(xié)同發(fā)展。
根據(jù)《新型數(shù)據(jù)中心發(fā)展三年行動計劃(2021-2023年)》,我國將用3年時間,基本形成布局合理、技術先進、綠色低碳、算力規(guī)模與數(shù)字經(jīng)濟增長相適應的新型數(shù)據(jù)中心發(fā)展格局。總體布局持續(xù)優(yōu)化,全國一體化算力網(wǎng)絡國家樞紐節(jié)點、省內數(shù)據(jù)中心、邊緣數(shù)據(jù)中心梯次布局。技術能力明顯提升,產(chǎn)業(yè)鏈不斷完善,國際競爭力穩(wěn)步增強。算力算效水平顯著提升,網(wǎng)絡質量明顯優(yōu)化,數(shù)網(wǎng)、數(shù)云、云邊協(xié)同發(fā)展。能效水平穩(wěn)步提升,電能利用效率(PUE)逐步降低,可再生能源利用率逐步提高。
2、PaaS發(fā)展趨勢
未來,隨著我國云計算技術和應用的不斷深入發(fā)展,我國PaaS行業(yè)將呈現(xiàn)以下發(fā)展趨勢:
更多本行業(yè)研究分析詳見前瞻產(chǎn)業(yè)研究院《中國云計算產(chǎn)業(yè)發(fā)展前景預測與投資戰(zhàn)略規(guī)劃分析報告》。
關于apaas特征和ap的特性的介紹到此就結束了,不知道你從中找到你需要的信息了嗎 ?如果你還想了解更多這方面的信息,記得收藏關注本站。 apaas特征的介紹就聊到這里吧,感謝你花時間閱讀本站內容,更多關于ap的特性、apaas特征的信息別忘了在本站進行查找喔。版權聲明:本文內容由網(wǎng)絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內刪除侵權內容。
版權聲明:本文內容由網(wǎng)絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內容,請聯(lián)系我們jiasou666@gmail.com 處理,核實后本網(wǎng)站將在24小時內刪除侵權內容。