這個周末我去參加了2021年華南CIO大會，發(fā)現(xiàn)基本上每年大會都有一個熱點，比如今年的熱點就是低代碼開發(fā)平臺。
我們可以回顧下最近幾年的熱點變化。
- 17-18年：微服務(wù)
- 18-19年：中臺
- 19-20年：RPA，數(shù)字化營銷
- 20-21年：低代碼，云原生
就我自己的文章輸出來看，基本上也和這個大趨勢符合。比如我17年左右會更多地寫微服務(wù)架構(gòu)設(shè)計和實施方面的文章，18，19年輸出了不少關(guān)于中臺建設(shè)的文章。而最近幾年關(guān)注重心則是云原生整體解決方案和低代碼開發(fā)平臺。
在IT行業(yè)，各種新興技術(shù)層出不窮，互聯(lián)網(wǎng)大廠的各種造詞能力也相當(dāng)強大，也讓每年基本都有新熱點和新技術(shù)產(chǎn)生。
類似19年可能剛興起低代碼開發(fā)，而到了今年可以看到做低代碼平臺的各種廠商，不論是做SaaS服務(wù)的，還是傳統(tǒng)toB實施的，還是圍繞騰訊，釘釘生態(tài)的。估計至少有上100家企業(yè)在做低代碼方面的產(chǎn)品。導(dǎo)致低代碼整個行業(yè)也處于群雄逐鹿和混亂的局面。
在上半年，ThoughtsWork的徐昊寫了一篇文章，談到低代碼平臺是行業(yè)毒瘤，首先這個看法我個人不認同，任何新事物都有其存在的價值和道理，也不可能去解決你所有的問題。而是應(yīng)該在合適的時候采用最合適的方法。
低代碼平臺本身是好東西，但是很多廠商將低代碼平臺吹噓來無所不能，再復(fù)雜的系統(tǒng)和規(guī)則都能夠零代碼，拖拖拽拽就實現(xiàn)，這就是完全不講武德了。所以低代碼平臺不是行業(yè)毒瘤，反而是廠商競爭中的信口開河和瞎吹噓才是行業(yè)毒瘤。
回顧下中臺的概念也是同樣的道理。
中臺本身是一個很好的概念和思想，強調(diào)將企業(yè)共性業(yè)務(wù)能力下沉，然后形成可復(fù)用的業(yè)務(wù)能力中心提供給上層應(yīng)用，讓上層應(yīng)用能夠靈活敏捷的去開發(fā)。
這個思路本身沒有任何問題。
但是很多做中臺的廠商，特別是很多互聯(lián)網(wǎng)出來創(chuàng)業(yè)的廠商，一味地去夸大中臺的作用，給企業(yè)畫大餅，搞個中臺就無所不能，企業(yè)原來已有的IT系統(tǒng)也要全部改一遍，去建大而全的中臺能力而不是考慮如何保留企業(yè)遺留IT資產(chǎn)。這些也導(dǎo)致了大量的中臺項目最終建設(shè)失敗，或者根本沒有起到預(yù)想的效果。
這并不是中臺的思路不好，而是廠商夸大宣傳最終又沒有實現(xiàn)最終的效果和目標(biāo)，導(dǎo)致了用戶持續(xù)大量反噬，這不能怪用戶只能怪廠商。
再回來談微服務(wù)也是同樣的道理。
倒退個3到5年，估計很多企業(yè)也被微服務(wù)搞死過。
原因也很簡單，本身一個單體應(yīng)用運行得好好的，最終被拆分為20多個微服務(wù)，導(dǎo)致多個微服務(wù)間集成復(fù)雜，分布式事務(wù)失控，后續(xù)的問題排查困難，運維監(jiān)控困難等一系列的問題。
這本身不是微服務(wù)思想不對，而是應(yīng)用不對。
其一就是企業(yè)在沒有達到一定的IT治理管控能力的時候盲目上微服務(wù)，其二就是前期的架構(gòu)建模階段對微服務(wù)拆分不合理導(dǎo)致拆分太細，或者拆分后的微服務(wù)間緊耦合。
微服務(wù)思想本身不應(yīng)該去背這個鍋。
在去年我參加華南CIO大會的時候，RPA機器人火的一塌糊涂，聽說今年有些RPA廠商或團隊已經(jīng)解散。
那么RPA機器自動化這個究竟好不好？
同樣的道理，任何一個新鮮事物的存在都有其道理。RPA機器人和自動化技術(shù)整合解決了傳統(tǒng)業(yè)務(wù)系統(tǒng)底層集成困難的問題，將重復(fù)的工作自動化掉。
這個思路沒有任何問題。一定有其應(yīng)用場景和應(yīng)用價值。但是要意識到的是RPA更多是一個折中方案，而不是目標(biāo)方案。
為何這樣說？
如果一個甲方企業(yè)本身有能力去做底層業(yè)務(wù)系統(tǒng)間的數(shù)據(jù)集成和接口集成，但是你自己偷懶不做，而是通過上層RPA的思路去解決問題。那么就是一種明顯的治標(biāo)不治本的方法。
一根大樹，本身底層的多個樹根應(yīng)該集成和盤錯在一起形成合力，支撐上層的枝繁葉茂。但是現(xiàn)在底層這個樹根間集成不做了，前面在樹枝和樹葉上拉繩子，捆線條。雖然這樣可以臨時解決問題，但是最終這個樹后面越難再發(fā)展和成長，哪天突然倒下也不是不可能。
所以當(dāng)我重新思考這些火熱概念后，給出一些關(guān)鍵的思考總結(jié)如下。
微服務(wù)
重申原則，就是你在沒有明確需求的情況下不要隨意去拆分微服務(wù)。即使你用微服務(wù)開發(fā)框架，也可以不做大的拆分。大部分企業(yè)來說，實際業(yè)務(wù)并發(fā)量都還沒有到必須要微服務(wù)化才能夠解決問題。
其次，應(yīng)用擴展優(yōu)先考慮傳統(tǒng)單體模式下的擴展方法，類似集群擴展，數(shù)據(jù)庫讀寫分離等。也可以采用按子組織水平擴展。
中臺
如果你的企業(yè)本身已經(jīng)有一定的信息化建設(shè)基礎(chǔ)，那么構(gòu)建中臺的最佳做法是對已有遺留IT系統(tǒng)中可復(fù)用的業(yè)務(wù)能力進行梳理，基于SOA的思路來構(gòu)建一個業(yè)務(wù)服務(wù)共享中心。而不是全新去構(gòu)建一個中臺。
對于數(shù)據(jù)中臺來講，如果沒有做細粒度的微服務(wù)拆分，數(shù)據(jù)反哺業(yè)務(wù)的問題也不需要數(shù)據(jù)中臺來解決，直接在業(yè)務(wù)中臺或傳統(tǒng)遺留業(yè)務(wù)系統(tǒng)里解決即可。因此傳統(tǒng)企業(yè)構(gòu)建數(shù)據(jù)中臺，不是追求數(shù)據(jù)服務(wù)開放并反哺業(yè)務(wù)，而是數(shù)據(jù)整合后的分析和利用，思路仍然可能是傳統(tǒng)的BI系統(tǒng)構(gòu)建思路。
RPA機器人和自動化
對于RPA是一個折中方案而非目標(biāo)方案。當(dāng)企業(yè)面臨諸多遺留系統(tǒng)底層接口集成困難的場景的時候，可以采用RPA方式來解決重復(fù)工作的自動化協(xié)同問題。但是在有條件的情況下，仍然還是以底層數(shù)據(jù)和接口集成為主而非上層的界面協(xié)同集成。
RPA不要越做越大，這個后期維護將是一個大問題。一個是核心邏輯本身不清楚，一個是底層業(yè)務(wù)系統(tǒng)本身也處于變更的不穩(wěn)定狀態(tài)。
低代碼開發(fā)平臺
在低代碼平臺本身的行業(yè)標(biāo)準(zhǔn)規(guī)范，成熟度沒有達到前。企業(yè)不要將核心的業(yè)務(wù)系統(tǒng)放到低代碼開發(fā)平臺上。
低代碼平臺企業(yè)可以做一些嘗試，可以將類似OA，項目管理，運維管理等偏工單和流程類的業(yè)務(wù)系統(tǒng)構(gòu)建在低代碼開發(fā)平臺上，積累相關(guān)的實踐和應(yīng)用經(jīng)驗。
最后就是低代碼開發(fā)平臺在選擇的時候要考慮不要被平臺廠商綁架的情況，任何低代碼開發(fā)平臺開發(fā)完成的應(yīng)用一個基本要求就是能夠脫離低代碼平臺運行，并具備足夠的高可用和擴展性要求。
版權(quán)聲明：本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務(wù)，不擁有所有權(quán)，不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容， 請發(fā)送郵件至 舉報，一經(jīng)查實，本站將立刻刪除。