在傳統企業服務領域，前幾年大火的微服務、中臺等概念為什麼慢慢涼了？為什麼開始談論起來 “erp已死，中臺已涼，低程式碼稱王”呢？
想要徹底搞清楚一個概念或者一門技術，首先是要排除那些商業化的包裝，先要回到歷史裡，回到它誕生的時間，一步一步看它發展脈絡，去探究它產生的背景和原因。
微服務起源
我能找到最早的地方就是ThoughtWorks首席諮詢師 James Lewis 提出的。就是下圖這哥們。
James Lewis是ThoughtWorks首席諮詢師，而且是該公司的技術顧問委員會成員。James對於採用相互協作的小型服務來構建應用系統的興趣，源自於他的整合大規模企業系統的工作背景。他已經使用微服務構建了許多系統，而且幾年以來已經成為正在成長的微服務社群的積極參與者。
2011年5月在威尼斯附近的一個軟體架構工作坊中，大家開始討論“微服務”這個術語，因為這個詞可以描述參會者們在架構領域進行探索時所見到的一種通用的架構風格。2012年5月，這群參會者決定將“微服務”作為描述這種架構風格的最貼切的名字。在2012年3月波蘭的克拉科夫市舉辦的“33rd Degree”技術大會上，本文作者之一James在其“Microservices - Java, the Unix Way”演講中以案例的形式談到了這些微服務的觀點（http://2012.33degree.org/talk/show/67），與此同時，Fred George也表達了同樣的觀點（http://www.slideshare.net/fredgeorge/micro-service-architecure）。Netflix公司的Adrian Cockcroft將這種方法描述為“細粒度的SOA”，並且作為先行者已經著手在Web領域進行了實踐——Joe Walnes, Dan North, Evan Botcher 和 Graham Tackley。
微服務的定義
“微服務架構”這個術語最近幾年橫空出世，來描述這樣一種特定的軟體設計方法，即以若干組可獨立部署的服務的方式進行軟體應用系統的設計。
簡單理解就是把原來一個應用程式，拆分成多個可以獨立部署的應用程式（服務也是一個獨立的應用程式）。
順理成章，微服務概念一出，進一步演變到把公用的部分組裝成通用的服務，這是軟體工程基本原理，封裝和抽象。
緊接著，一個國內炒得更火的概念就出來了，中臺。
中臺的來龍去脈
中臺的興起，是趨勢使然，但中臺相關概念被大家關注，是從阿里巴巴提出的中臺戰略開始。中臺這個概念是否是阿里巴巴創造的，業內還有爭議。對於阿里巴巴的中臺戰略，現在業界一般認為是從2015年馬雲開始走訪Supercell(一個芬蘭移動遊戲公司)開始的。
當時觸動馬雲和阿里高管團隊的事，誕生這麼多火遍全球遊戲的企業卻只有不到200名員工，而負責一款遊戲的每個團隊平均也只有5~7名團隊成員團隊有充分的自由，他們可以自行決定開發什麼樣的產品之後就會以最快的速度推出公測版，讓市場來來評斷來驗證產品的好壞，一旦產品不成功迅速放棄，此時不但不會有任何懲罰，反而團隊會舉杯，慶祝之後立即做出調整繼續，迅速尋找新的方向。
但要想讓這個機制運轉正常，必須有一個前提，就是產品的構建時間要足夠短，試錯的成本要足夠低，這樣才能夠保證團隊在大量的失措中，透過不斷從失敗中學習，持續迭代調整，儘快找到正確的方向，讓創新成功的進度條快速前進。
而背後支撐這個機制得以實現的就是super cell經過6年時間沉澱下來的遊戲開發過程中的一些公共的通用的遊戲素材和演算法，基於這些像樂高積木一樣的基礎設施，才可以同時支援幾個團隊，在幾周時間內像搭積木一樣快速開發出一款新遊戲。
中臺的定義
從源頭出發，中臺其實解決的本質問題依然是封裝和抽象，利用公共服務的方式提高應用的構建時間。依然沒有脫離軟體工程的基本思想。所以中臺更多的是概念，他沒有具體的實現。
devops 容器
緊接著，麻煩來了，應用程式被拆分了，原來部署一個就ok的系統，需要部署一百個了。怎麼辦？幸虧在這個時候，容器技術出現了，devops出現了。（容器技術和devops的起源跟本文無關就不詳細講了）
容器可以把這些微服務獨立打包成映象，再加上容器編排能力的加持，可以自動化部署了。
devops透過自動化的ci/cd功能，幫程式設計師解決了多個工程的的編譯釋出打包的工作。
到這裡，技術理論趨於完美了，透過微服務和中臺把應用系統拆分，在理論上解決了軟體工程的封裝、複用問題，封裝後造成的麻煩又可以用容器和devops來解決。大家都有更多的事幹了。O(∩_∩)O
架構師開始忙了，開發開始忙了，廠家可以打包賣解決方案產品了。大家一致的目標是把原來的老的應用程式推倒重來。再加上雲計算的推波助瀾，雲原生技術這種誰都可以定義的概念，好像不微服務化就不能上雲，就落伍了，市場徹底火爆了。
企業困境
企業麻煩了，這整套東西非常複雜，把原來簡單的應用拆分後，還要組合成跟以前一樣的系統，開發就更復雜了，拆了容易，怎麼組裝呢？都是一個個獨立的系統，互動複雜，事務問題、記憶體問題，想想都頭疼，再加上配套的平臺工具，難度指數級提高。一般的企業或者軟體團隊根本玩不轉。
而企業業務變化真的有那麼大嗎？企業的資料併發有那麼多大嗎？需要使用微服務這種可以快速橫向擴充套件的能力嗎？真正能實現服務任意提供快速變化的優勢嗎？
想解決這些問題不單單是使用微服務架構或者買箇中臺就能解決的，這裡面牽扯到服務怎麼劃分合理，業務怎麼抽象才更通用，這些都是實施的時候根據不同的業務場景決定的。
因此架構設計能力成為了瓶頸，大廠可以玩轉的東西，是因為他們有一群龐大的技術團隊。這些都是企業所缺少的。
因此這幾年，當年大火的微服務、中臺慢慢變得沉寂了。
零程式碼\低程式碼的曙光
企業需要解決的是業務問題，是把業務快速數字化的能力，用什麼架構其實不太關心，是SOA、微服務、單體 都無所謂。他們重點是要用，要好用。
上面所有的思路都是抽象、封裝的思路，都是為了把公用的東西抽離出來，避免反覆開發，提高複用率。只是微服務、中臺大多是從底層來解決這個問題。思路非常好，但複雜度太高。
零程式碼從應用層來解決，解決的思路一樣是抽象/封裝。只是抽象封裝的是應用層的東西。簡單理解就是把企業所使用的應用系統全部歸類、總結，抽象成一個個元件，然後在使用的時候再用視覺化的能力把這些元件拼裝成應用系統。
所以視覺化很重要，重要的原因是可以眼見為實，可以快速驗證，可以快速使用。這些都比底層的東西好理解，也更快見效。並且同樣的，符合高內聚、低耦合的軟體工程邏輯。
總結
軟體工程一直都是遵循基本的邏輯，高內聚、低耦合、複用，透過最大程度的複用，提高開發效率，從軟體開發的設計模式到SOA、微服務的架構都是同樣的思想，只是解決問題的角度不是一樣而已。
設計模式 從研發人員角度解決
架構設計 從架構角度解決
低程式碼 從應用層解決
低程式碼不是不考慮這些這些架構問題，在研發低程式碼平臺的時候，架構設計、軟體的設計模式等都是非常重要的環節，只有底層設計好了，應用層才能夠更加靈活。低程式碼平臺是把這些技術問題全部遮蔽到下面，專業人做專業事，就像你買車一樣，你關心車是用什麼架構設計的嗎？你只用關注你的使用場景就行了。
低程式碼就是這樣，是為了讓你迴歸本質，迴歸到業務層面，真正為客戶解決業務的實際問題。把架構設計留出專業人士吧。
