大家都知道我們的服務架構經歷了單體架構–集群架構–微服務架構的演進。我們的程序架構經歷了MVC–RPC–SOA–微服務架構的演進。
而在架構演進的過程中，我們越來越多地使用到各種開源產品。

在我的理解中，云原生是一種最佳理念的集合，前提是上云。
比如我單體架構使用了云產品redis，而這種中間件就是最適合我產品需求的，那我就可以說，我的單體架構融入且符合了云原生概念。

也有說法是，服務上云才就是原生，這個說法我是不太贊同的。
云服務很多都是比較好的中間件或是應用服務，我們使用了這些云服務能更優(yōu)化我的產品，這就是符合了云原生的概念，如服務治理。但是，如果我們的服務是很小的單實例服務，使用本地部署和維護都很方便，那上云的意義就并不大了，也不符合云原生最佳實踐的理念，上云只是為了減小我們的維護和運營成本。

再聊到低代碼，這個國內部分人正在研究的一個課題，但是在國外已經很流行了，而且這種低代碼也主要是為國外的習慣和行情而研發(fā)的。
它會先寫各種工具類，讓大家以后都使用好的工具類，而不需要去關注底層的代碼實現。
或者是它會先完成很多模塊的開發(fā)，讓其他服務直接調用這種模塊，也是不關心底層的實現邏輯，能大大提高開發(fā)進度。
但凡事有利有弊，當未來的開發(fā)者習慣了使用這種方式，而忽略了一些好的底層實現邏輯，那未來我們的技術就缺乏了創(chuàng)新的土壤。低代碼只能是解決我們的一時之需。
國外有這種需求我覺得偏向他們的開發(fā)人員數量在下降，而國內的開發(fā)者越來越多，我覺得還是要從底層學起，讓專家們多分享好的底層設計思路，多討論更符合多樣化環(huán)境下的架構設計，在節(jié)約成本的基礎上，還能讓技術得到提升，這樣國內的技術水平才能越來越好
所以個人觀點是，支持復雜環(huán)境的云原生化，不支持無腦的低代碼化。不知道你是怎么理解的，可以留下你的觀點，歡迎來噴。