文章聯合撰稿人（排名不分先後）
叔同、谷樸、不瞋、育睿、許曉斌、至簡、典違、魯直、改之、小劍、湯志敏、白慕、迴圈、文卿，嘍哥、水鳥、神秀。

在籌備[阿里雲首屆雲原生實踐峰會](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247488825&idx=1&sn=7581ce1673bb99037fd6c9f7048f220b&chksm=fae51ef6cd9297e02b0405322da3388ae5da7c0dbc51aff5eea7daeb8ecf96533b54946afd63&scene=21#wechat_redirect)的過程中，我們展開了對雲原生技術的應用和研究領域的探索，邀請了 17 位雲原生技術專家從 Serverless、Service Mesh、Kubernetes、邊緣計算、容器例項與容器引擎、雲原生基礎架構、雲原生應用開發 7 個發展方向，回顧 2019 雲原生領域進展，描繪雲原生技術的新十年。

# 2020 雲原生標誌性事件預測

展望 2020，在雲原生技術的應用和研究領域，我們預見會有這些標誌性事件。

## 第一，雲原生技術關注重心在上移，Serverless和應用管理重點。
過去的幾年我們看到，雲原生技術重心圍繞容器和容器編排。Docker 和 K8s 的成功幾乎成了雲原生的代名詞。很多人說，Kubernetes is becoming boring，這是對於技術的趨勢來說。

雲原生關注重心即將上移：

- 應用的定義和配置、釋出和線上的自動化運維，成為開發和運維人員關心的核心內容。阿里巴巴和微軟聯合推出的 Open Application Model (OAM) 就是這個方向的一個重要專案；

- 作為雲原生技術的延伸，無伺服器計算（Serverless）將進一步釋放雲端計算的能力，將安全、可靠、可伸縮等需求由基礎設施實現，使使用者僅需關注業務邏輯而無需關注具體部署和執行，極大地提高應用開發效率，同時這個方式促進了社會分工協作，雲廠商可以進一步透過規模化、集約化實現計算成本大幅最佳化。相信在 2020 會有更多的創新和落地實踐在這個領域湧現。

## 第二，雲原生技術成為雲服務商的創新和競爭力的主陣地。
隨著以容器為基礎的雲原生技術被使用者廣泛接受，可以肯定的預期，容器會很快成為雲和使用者的基本介面。因此對於雲的服務提供商來說，基於容器、微服務、無伺服器、服務網格等新型雲原生技術的領域，必將是雲廠商未來創新和競爭力的主陣地。

虛擬化未來 3 年還會是雲上資源增量的主體，但是硬體虛擬化加速的裸金屬和安全沙箱容器的組合，正在加速企業的上雲和容器化過程。雲廠商未來技術競爭力的關鍵，在雲傳統的優勢包括規模、穩定性、成本發揮到極致的前提下，必將透過雲原生技術和產品的持續創新來服務客戶來獲得客戶的認可。雲原生產品領域將成為雲廠商競爭白熱化的必爭之地。

## 第三，雲原生從資料中心走向雲邊端一體化，將無處不在。
雲原生技術起源於資料中心內的應用和服務，並在過去幾年逐漸擴充套件到邊緣場景甚至端上的計算。相信未來隨著 5G/IoT 的快速發展，雲邊端一體化的雲原生技術將深入更多的企業和更豐富場景，將無處不在。

## 第四，雲原生將經歷企業落地之痛，雲原生上雲將成為趨勢。
雲的技術發展會領先於企業落地的速度。儘管雲原生技術已經被廣泛接受，其在企業技術棧的落地仍然需要時間，也面臨不少挑戰。如容器化過程中改變傳統虛擬機器模式下的運維習慣，企業傳統應用分散式微服務化的改造涉及 re-architecturing 等因素。

雲原生被企業接受之後，落地的過程需要解決這些挑戰。運維管理含有豐富元件並快速演進的雲原生的基礎設施也對企業 IT 人員的技術技能提出了更高的要求。然而我們相信，雲原生技術帶來的資源成本降低，研發運維效率提升等巨大價值，會驅動企業迎接這些挑戰。

在這個過程中，使用雲原生上雲，基於容器和服務網格等標準介面和混合雲方案，將極大的降低遷雲複雜度，使企業可以更快遷移到雲上標準服務。透過雲原生上雲最大化使用雲的能力，高效的社會分工，使企業聚焦於自身業務發展，相信將成為企業的共識。

# 2020 雲原生 7 大技術領域趨勢

## 1. Serverless

2019，行業中的各大 Serverless 計算平臺的能力有了長足進步，變得更加通用。例如透過預留資源完全消除冷啟動對延時的影響，使得延時敏感的線上應用也能夠使用 Serverless 方式構建。Serverless 生態不斷髮展。在應用構建，安全，監控報警等方面湧現了很多開源專案和創業公司，工具鏈越來越成熟。

使用者對 Serverless 的接受度不斷增加。除了網際網路等迅速擁抱新技術的行業，傳統企業使用者也開始採用 Serverless 技術。站在新的一個十年， Serverless 領域將發生如下演進：

- **Serverless 將進一步從偏離線業務進入線上業務。**

真正的按請求次數計費和從零到一的響應時間是一個天然的矛盾，以 FaaS 為代表的 Serverless 技術一開始都是從對響應時間不敏感的，事件驅動的偏離線業務入手。但是今天我們已經看到，包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在內的產品特性，都在讓使用者稍微付出一點額外的成本以換取更低的響應時間。這對於線上業務來說，無疑是更適合的。

- **Serverless 不僅是應用或者函式的能力，也會加速推動基礎設施和服務 Serverless 化。**

業務程式碼託管給 Serverless 平臺之後，即能享受到自動彈性，按請求計費能能力。但是如果基礎設施和相關服務不具備實時的擴縮容能力，那麼對於業務整體來說，就不是彈性的。我們已經看到 AWS 圍繞 Lambda 對 VPC 網路、資料庫連線池等資源做了大量實時彈性最佳化，相信其他的廠商也會跟進，進而行業整體會加速基礎設施和各類雲服務的 Serverless 化。

- **以 Knative 為代表的開源解決方案將得到越來越多的關注。**

儘管各個雲廠商都在大力推廣自己的 Serverless 產品，但是開發者普遍還是會擔心被廠商繫結，因此具備一定規模的組織會基於開源方案，如 Knative，搭建自己的 Serverless 平臺。而一旦某個開源方案成為主流，雲廠商就會主動去相容開源標準並增大社群投入。

- **Serverless 開發者工具和框架會進一步繁榮。**

IDE，問題診斷，持續整合/釋出等配套的工具和服務的使用者體驗會更加完整。我們將看到更多的成功案例和最佳實踐。在前端開發等領域將會出現為 Serverless 而生的應用框架，將工程效率發揮到極致。

- **Java 持續進擊，將成為 Serverless 平臺主流語言之一。**

Serverless 平臺要求應用的映象足夠小以能夠快速分發，同時要求應用的啟動時間極短。雖然在這些方面，Java 和 NodeJS 和 Python 等語言有差距，但是 Java 社群在不斷努力。我們看到 Java 透過 Java 9 Modules 以及 GraalVM Native Image 等技術在不斷努力“減肥”，主流框架 Spring 也開始擁抱 GraalVM，而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 領域給人煥然一新的感覺。

- **解決 FaaS 狀態傳遞的中間層（加速層）研究或產品有望得到突破**。

Serverless 在 Function 場景下未來最大的挑戰是 function 之間串聯需要狀態（state）傳遞、function 處理需要頻繁和外部儲存互動等帶來的時延放大。傳統的架構這些都是在一個程式程式內部處理完畢。解決上述挑戰需要可計算中間層（加速層），可計算中間層（加速層）是未來學術研究和產品攻堅發展方向之一。

- **基於 WebAssembly(簡稱 WASM) 的 FaaS 方案有望出現。**

Docker 的創始人之一 Solomon Hykes 曾說，“如果2008年有 WASM 和 WASI，我們當時就沒有必要創造 Docker 了”，這句話在一定程度上說明了 WASM 的重要性。雖然當下 WASM 更多作為一種執行在瀏覽器端的技術被人瞭解，但是它具備非常優秀的安全隔離能力，極快的啟動速度，以及對於超過20種語言的支援，那麼為什麼不能讓它執行在服務端呢？這些技術特性都非常契合 FaaS 的要求。

## 2. Service Mesh

在 2019 年，Service Mesh 的整體解決方案逐漸顯現了寡頭壟斷的局面。一個解決方案能否得到行業的普遍認可，關鍵在於其背後的技術團隊對分散式應用治理複雜度是否有深刻洞見，以及能否打造一個被所有云廠商都採納的事實標準。事實標準對於使用 Service Mesh 的客戶來說，意味著分散式應用能根據自己的需要在多雲和混合雲上方便部署。

站在新的一個十年， 2020 年 Service Mesh 領域將有如下變化：

- **2019 Service Mesh 熱度持續上升，落地的問題將在 2020 得到解決。**

2019 年，Service Mesh 在部分公司如螞蟻金服迎來大規模的落地，整個業界的熱度在持續上升，大大加大了國內公司對於 Service Mesh 的信心，目前幾乎每家稍微大一點的網際網路公司都已經開始實踐 Service Mesh，包括美團、頭條、百度等公司。

當然，在 2019 年業界落地遇到的各種問題，包括 Sidecar 大規模運維的問題等等，以 OpenKruise/kruise 的為代表的 SidecarSet 雖然已經在做一些努力，但是目前仍然存在升級 Pod 過程過於複雜的問題，這些問題有望在 2020 年得到解決。

- **Istio 將更加成熟，更加適合大規模叢集的落地。**

2020 年 Istio 作為控制平面的一種技術實現仍將在 Service Mesh 領域扮演核心角色。Istio 獲得業界廣泛關注的原因，在於背靠 Google 公司的內部工程實踐，以及對工程實踐的再思考和重新提煉。Istio 在過去一年的重要工作是完善功能和改善穩定性確保小規模生產可用，在 2020 年隨著阿里巴巴採用這一技術實現大規模落地將為 Istio 的規模化運用提供真實的場景，這將使得 Istio 在接下來的一年在支援叢集規模的能力上大幅提高。

此外，隨著探索，Istio 的可運維性和架構的合理性在 2020 年也將迎來積極的變化，其部署和運維的複雜性高等問題將得到解決。Istio 所採納的 Envoy 開源專案，在新的一年依然保持 Service Mesh 資料平面的事實標準這一領導地位，Istio 和 Envoy 兩大開源社群因為緊密協作而更好地推動 Service Mesh 向前演進。

- **Serivce Mesh on EdgeService 熱度持續 Service Mesh & IoT。**

2019 年 Serivce Mesh on Edge 的熱度在逐漸提升，Edge 本質上要提供更快的響應提升體驗。對於 Service Mesh 來說，被從“舒適”的雲端下放到 Edge，要解決效能，低資源消耗，安全，高可用等問題，具體 Kernel Bypaasing，Sidecar as Node+WASM，SmartNic 軟硬體結合, IoT Identity 結合，secret 保護，低輸出成本，非可靠網路環境等，當下看還非常有挑戰，這些問題將在 2020 年得到部分解決。

- **More Than Service Mesh。**

Service Mesh 作為解耦應用與基礎設施的關鍵技術，在 2020 年將有更多的產品透過與 Service Mesh 結合去完成 BaaS 化，這除了減少沒有必要的重複建設，還使得雲產品因為將那些與應用無關的內容剝離出來下沉為基礎設施的一部分而加速自身的演進速度，以及給雲產品的使用者帶去更棒的軟體開發和維護體驗而加速業務的探索效率和降低探索成本。

我們看到 Envoy 也提供了 MySQL、Redis、MongoDB、DynamoDB 的協議支援，能夠支援請求解析、請求級統計、失敗統計等通用的可觀測性特性。後續 Mesh 將繼續發展，成為整個網路層面的一個基礎設施，用以管控所有應用層面的出/入口流量。

展望 2020 年，Service Mesh 將會成為解決異構系統通訊、混合雲架構等方向上的必備元件，在混合雲、新老架構的場景下，Service Mesh 和原有基礎設施的結合能力將成為 Service Mesh 落地的關鍵，比如對於 VM 場景的支援，對於傳統服務註冊中心的支援等等，相信會有更多的公司透過實踐而對 Service Mesh 的價值更有體感，透過創造更多的成功客戶故事而加速 Service Mesh 的普及。也許，2020 年將成為 Service Mesh 的普及年。

## 3. Kubernetes

2019 年，在社群頭部參與者的持續推進下，“規模”與“效能”終於成為了 Kubernetes 專案的重要關鍵詞，這不僅真正意義上打通了 Kubernetes 在企業生產環境中大規模落地的最後一公里，也讓 Kubernetes 第一次成為了 “雙11” 等頂級網際網路規模化場景中實實在在的技術主角。

站在新的一個十年， 2020 年 Kubernetes 領域將有如下變化：

- **Kubernetes 將成為使用者和雲端計算新的互動介面。**

隨著雲原生計算的普及，越來越多的應用負載都部署在 Kubernetes 之上，包括資料庫、大資料、AI智慧和創新應用，Kubernetes 已成為雲原生計算的基石。得益於 Kubernetes 的大規模應用管理能力、多雲混合雲的支援能力，在 2020 年，Kubernetes 會成為使用者和雲端計算新的互動介面。從架構的角度，Kubernetes 成為了 IaaS 層的控制平面，並進一步推動底層 IaaS（計算、儲存、網路）的能力最佳化，來滿足容器帶來的一二個數量級的高密度和高動態性要求。

- **Kubernetes 掌控能力成為企業運維團隊的核心技能，並和 AIOPS 相互促進發展。**

Kubernetes 的大規模使用是否會帶來企業運維人員的失業？實際上，隨著越來越多的企業 IT 架構，從 on Kubernetes 到 in Kubernetes，大量的 CRD、自定義 Controller 和服務網格的引入，給 Kubernetes 的穩定性和效能最佳化帶來大量的挑戰。Kubernetes 的掌握深度逐漸成為企業運維團隊技術能力的重要評估標尺，而企業運維人員的技能也會從自動化向資料化和智慧化發展。

預測在 2020 年，圍繞著 Kubernetes 的 AIOps 會逐漸湧出，來進一步完善 Kubernetes 的成本最佳化、故障檢測和叢集最佳化。

而 Kubernetes 等雲原生技術也會讓 AIOps 不再霧裡看花：

- 得益於 Kubernetes 的良好設計，包括宣告式API、不可變架構、優雅的擴充套件機制，可以促進應用釋出和運維的操作歸一化（Normalization）；

- 結合 GItOps、Tekton、SecOps 等自動化流程的落地，應用的生命週期更加標準化（Standardization）；

- 隨著 OpenTelemetry、CloudEvents 等專案的推進，應用可觀測性領域在日誌、監控、Tracing、事件等領域進一步標準化和融合，使得多指標、根因分析的資料集更加豐富，從而提高 AIOPS 的 AI 層面的準確率和覆蓋率。

- **新核心、新硬體助力容器最佳化 OS 的演進。**

容器技術經過了多年的發展，從早期的 Docker、rkt、CRI-O 等，到 containerd、Kata Container、gVisor，已經成為 Kubernetes 執行的重要基石。然而無論是 runc 場景的進一步隔離，還是安全容器場景的進一步效能最佳化，還需要持續的打磨和增強。

隨著新核心技術包括 CGroup V2、namespace、virtiofs 等的逐步成熟，可以進一步增強容器執行時的能力。另一方面，一些新硬體包括 NPU、MoC、NUMA 等的引入，也給容器和 K8s 排程帶來了更多的最佳化空間和場景。得益於這些能力的加成，為容器場景量身定製的容器最佳化 OS 成為可能，並會快速發展。

- **容器網路和 Mesh 網路將進一步融合。**

Service Mesh 經過多年的市場培育，2020 年將會成為 Service Mesh 技術的普及年。而 Service Mesh 的效能最佳化也會成為重頭戲，一些下沉方案也在選擇基於 CNI（容器網路介面）和核心技術進一步最佳化網路轉發效能。

而容器網路自身也在逐漸演進，從面向 ip 到面向 Identity，從單容器網路平面到多網路平面，並進一步最佳化網路轉發效能和零可信安全。在 2020 年，我們相信容器網路和 Mesh 網路將進一步融合，在 Network ServiceMesh、NFV等場景進一步整合。

## 4. 邊緣計算

隨著 5G 和萬物互聯時代的到來，聯網智慧終端裝置數量將急劇增加，傳統雲端計算中心集中儲存、計算的模式已經無法滿足終端裝置對於時效、容量、算力的需求，將雲端計算的能力下沉到邊緣側、裝置側，並透過中心進行統一交付、運維、管控，將是雲端計算的重要發展趨勢。

IDC 預計，到 2020 年全球將有超過 500 億的終端與裝置聯網，超過 40% 的資料要在網路邊緣側進行分析、處理與儲存，這對邊緣計算提供了充分的場景和想象空間。

站在新的一個十年，2020 年邊緣計算領域將有如下變化：

- 以 Kubernetes 為基礎的雲原生技術，經過近幾年的高速發展，適用範圍、落地場景、技術成熟度等均有了長足發展，其核心價值之一是透過統一的標準實現在任何基礎設施上提供和雲上一致的功能和體驗。將雲原生技術和邊緣計算相結合，可以快速實現『雲-邊-端』一體化的應用分發，解決在海量邊、端裝置上統一完成大規模應用交付、運維、管控的訴求；

- 在安全方面，雲原生技術可以提供容器等更加安全的工作負載執行環境，以及流量控制、網路策略等能力，能夠有效提升邊緣服務和邊緣資料的安全性；

- 在邊緣網路環境下，基於雲原生技術的邊緣容器能力，能保證弱網、斷網的自治性，提供有效的自恢復能力，同時對複雜的網路接入環境有良好的相容性；

- 依託雲原生領域強大的社群和廠商支援，雲原生技術對異構資源的適用性逐步提升，在物聯網領域，雲原生技術已經能夠很好的支援多種 CPU 架構和通訊協議，並實現較低的資源佔用。

目前已經有不少廠商在進行雲原生邊緣計算的嘗試，並有了部分成功案例，相信在 2020 年隨著 5G 的快速鋪開，雲原生邊緣計算的發展將大大提速。

## 5. 容器例項與容器引擎

在 2019 年的最後一個月 AWS 終於釋出了 Fargate for EKS 產品，這也宣告了雲上 Kubernetes 使用 Serverless 容器例項作為底層執行時資源的產品形態得到了業界更廣泛的認可。透過容器例項作為底層執行實體可以讓使用者專注於構建自身的業務和服務，無需再配置和管理伺服器，擺脫基礎設施運維的複雜性。同時透過真正的按需付費和實時擴容來降低使用者的使用成本。

放眼看亞馬遜AWS的 Fargate，微軟Azure的 ACI ，以及阿里雲的 ECI，各產品當前在對接 Kubernetes 時的具體架構上仍然有分歧，以 Fargate 為代表採用的是透傳 Node 資訊的方式來提供對 Kubernetes 功能的完整支援；而以 ACI/ECI 為代表則採用 virtual kubelet 方式對接 Kubernetes 對容器例項進行管理。

但無論採用何種對接方式，容器例項產品的核心依然需要構建在彈性、成本和 Kubernetes 相容性上。透過彈性實現使用者服務的按需實時擴容，使用者無需選擇例項和叢集容量，不需要為額外的伺服器預置而付費；透過實時擴容實現真正的按使用資源付費，降低使用者的使用成本；Kubernetes 已經成為容器編排領域的事實標準，對 Kubernetes 功能的相容性決定著容器例項的適用範圍。

站在新的一個十年的起點，相信在 2020 年容器例項產品會在這三個方面繼續改進和完善，持續提升彈效能力，降低使用者的使用成本，並不斷完善與 Kubernetes 的整合。同時也會有更多的雲原生應用遷移到 Kubernetes+ 容器例項上，享受雲原生的技術紅利。

從上述各廠商的同類產品中我們也可以看到此類產品在設計上的共同之處：

- 一個例項對應一個 Pod
- 對接 Kubernetes
- 安全容器作為底層容器引擎

這其中使用安全容器作為底層容器引擎是各家都很重視的底層基礎能力。在 2019 年安全容器技術的隔離性越來越被看重，作為一個隔離層，不僅提升雲原生平臺的安全性，也對可運維性、服務質量和使用者資料保護有顯著效果。不過，迴歸初心，使用者選擇雲原生的本質是容器帶來的敏捷性，他們可以快速地排程並啟動容器，並且可以靈活地使用資源，這方面安全容器技術尚不能達到傳統容器的水平。<br> <br>不論是 Kata Containers 還是 gVisor，開源安全容器引擎在 2019 年都取得了很多進展，Kata Containers 明確提出了“做面向雲原生的虛擬化”作為 2020 年的目標：

- 在沙箱間共享資源，同時保持沙箱邊界仍然清晰；
- 即時、動態地按需為沙箱提供資源，而不是像分割槽那樣進行固定的資源分配；
- 主機的使用者態工具、VMM、乃至應用的核心聯合起來，彼此協同為沙箱中的應用提供服務。

在 2020 年，Kata 代表的虛擬化容器會與傳統虛擬化漸行漸遠而更加“應用中心”，gVisor 為代表的程式級虛擬化也期待更多為應用的最佳化。我們相信在 2020 年的時候，我們還不會有一個統一的安全容器技術，但展望 21 世紀 20 年代的頭幾年，我們期待軟硬體的共同發展會讓主流的容器引擎都具有更好的隔離性。

## 6. 基礎架構演進

基於 Kubernetes 的 Serverless Infras 架構演進一直是各大雲廠商和社群關注的焦點。2019 年 12 月 AWS 在拉斯維加斯召開了一年一度 re:Invent 大會上宣佈了 EKS on AWS Fargate 產品正式 GA，這個訊息在雲市場和社群裡掀起了不小的波瀾。

EKS on Fargate 提供了標準的 Serverless Infra.的使用者體驗，即使用者購買了 EKS 的服務後，不再需要購買額外的 Infra 雲資源（如VM，Nitro），就可以使用原生 K8s API 部署自己的應用，並且支援按量計費。

Serverless Infra.架構使得使用者無需關注計算、網路、儲存等底層基礎設施細節，真正讓使用者迴歸到面向POD應用資源部署形態上去；同時管控面與資料面的強隔離能力將會是 Serverless Infra.架構的關鍵，除了對使用者遮蔽底層基礎設施細節外，Serverless Infra. 需要提供給使用者一個安全可信的租戶隔離環境

2019 年隨著經濟體全面上雲，底層排程系統全面升級到雲原生 Kubernetes + 輕量級容器架構演進，並且大規模部署在神龍裸金屬例項上；同時基於 kata-container 的安全容器執行時技術趨於成熟，已經具備大規模鋪開的條件。

站在新的一個十年，預計2020 年，將是經濟體全面邁向基礎設施 Serverless Infra. 的一年，Serverless Infra.架構將會基於神龍+安全容器架構，透過構建軟/硬多租戶能力，彈效能力和高度的容器自愈能力，為使用者提供極致的安全、穩定、隔離性的使用者體驗。同時底層資源池共享也能有效提升整體資源利用率，並池後資源互通將會有效降低整體機器成本

## 7. 應用開發

展望 2020，我們認為雲原生+智慧化將成為下一代研發平臺最重要的兩個特性，它將進一步降低開發者採納複雜技術的門檻以及透過工具釋放生產力。當所有複雜度都解除安裝到雲上以後，我們將回到 10 年前開發單機程式時的高效。

站在新的一個十年， 2020 應用開發領域將發生如下演進：

- **從 Web-IDE 演進為 Cloud-Native IDE。**

2019 年是 VS Code 生態繼續高歌猛進的一年，得益於其模組化的設計，VS Code 中的幾個核心元件Monaco編輯器，外掛體系，Language Server Protocol(LSP)等成為了Web-IDE的標準選型。社群也出現了code-server這樣基於 VS Code 一行命令拉起 Web-IDE 的方案。

除了 VS Code 之外，Theia 也繼續演進，尤其是基於 Theia 的gitpod.io 讓人眼前一亮，透過把 gitpod 按鈕整合在諸如 GitHub README 頁面上，一鍵實現了從程式碼到預覽的順滑體驗。

另一方面，大廠已有的 Web-IDE 方案也需要回過頭來擁抱社群，徹底如 Facebook 完全從自研的Nuclide 轉而投向 VS Code，而無論是  Amazon的Cloud9 還是 Google 尚未對外的 Cider，如果要在商業化上更進一步，支援 VS Code 的外掛體系想必也是理所當然。

從 Local-IDE 到 Web-IDE 讓我想起了當年從 PC 到移動端。雖說時至今日，不少專業工具 PC 端的體驗仍然是移動端難以企及的，但移動端的主導地位早已不容置疑。

Web-IDE 具備開箱即用，環境一致可控以及和其它Web服務無縫整合的先天優勢。接下來要做的除了繼續補齊和 Local-IDE 在端功能的差距外，還可以結合分散式編譯構建，集中式程式碼倉庫，海量程式碼索引分析，雲端協同等，提供真正的 Cloud-Native IDE。

- **工具 -> 平臺 -> 標準。**

GitHub 今年推出了 GitHub Actions，透過它可以在工作流中靈活地整合各種第三方服務。GitLab 也在更早的時候就推出了可定製化的 CI 流水線配置。無論是 GitHub 還是 GitLab，它們都從早期單純的程式碼託管工具成長為了一站式 DevOps 平臺。

最早以 IntelliJ 工具起家的 JetBrains 不再滿足於僅僅打磨 IDE，今年也推出了 Space，力圖打造一站式研發團隊平臺。以項管工具 Jira 起家的 Atlassian，一直是自研收購兩架馬車並駕齊驅，今年透過收購又在自己研發平臺的版圖上增加了針對管理者視角的 Jira Align。

後起之秀如 sourcegraph 乾脆直接在網站上號稱自己是 The new standard developer platform。不管是基於 Dev 工具的右移，抑或是基於 Ops 工具的左移，當年的工具們都或多或少地長成所謂的一站式 DevOps/DevSecOps 平臺。

那接下來，在這些平臺之上是否能提煉出通用的標準？比如 CI 領域，是否能有一套 CI 流水線定義可以一統CircleCI，GitLab，GitHub Actions 諸如此類？是否也有一套 workflow 標準可以讓使用者在 AWS Step Functions, Argo, Tekton 之間無縫遷移？

在更高的抽象層面，諸如 Open Appliction Model(OAM) 這樣的標準是不是能真正架起從業務架構到基礎架構的橋樑。雖然如今的研發平臺已然是諸侯割據的局面，但在雲原生，標準先行的理念下，我還是會期待有離業務層更接近的雲原生標準去串聯起整個研發平臺。

- **開法者工具從本地工作到雲端協作。**

當前的開發者工具絕大多數採用的是 lift and shift 的方式從本地平移上雲，產品設計針對的還是單人人機互動，移到雲端的研發工具還沒有很好地利用雲端多人實時互動的能力。無論是多人協作（雲已經讓我們離彼此更近），還是人機協作（雲已經讓機器變得更強），我期待著出現進一步挖掘雲端協作能力的創新點。

- **更多雲原生研發平臺湧現。**

以 Kubernetes、Serverless、Service Mesh、Cloud IDE 為代表的多項雲原生技術在過去一年讓人印象深刻。我們意外的觀察到，以中小網際網路公司為代表的技術群體開始快速擁抱這個技術體系，並且透過雲原生落地，快速的獲得了以往網際網路大廠才有的精英軟體交付能力，比如複雜的流量治理能力，灰度釋出能力，A/B Test 能力，多環境管理能力，基礎設施一鍵拉起，快速擴縮能力等等。

但在企業採納新技術的同時，也面臨著諸多挑戰，比如開源軟體複雜的搭建過程，黑屏化的互動設計，缺乏研發管理方法，缺乏企業許可權管理能力等。因此一大批軟體供應商開始基於雲原生技術體系開發相關的管理平臺，比如 QingCloud，Rancher，阿里雲容器服務。作為雲上研發協同平臺領導者的雲效也在積極將 CICD 工具、測試環境管理方法、應用運維理念、DevOps 協同方法論等與雲原生技術融合貫通，為企業提供開箱即用的新技術解決方案。

- **資料和智慧的工具時代到來。**

雲原生是一套開放標準的技術體系，核心貢獻者就是當今世界的網際網路雲廠商巨頭企業。隨著技術的發展和影響力的增強，逐步將企業的私有技術壁壘打破，並且開始採納雲上現成的雲原生產品來改造自身的技術體系。技術的收斂帶來了統一資料規範的可能，而資料是所有智慧化的基石。

我們觀察到最近一年 AWS、微軟、Facebook、ebay 等廠商都在積極佈局智慧化工具，從傳統的“程式碼”智慧工具逐步擴充套件到“服務”智慧工具。比如最近 AWS 釋出的CodeGuru，它是一個用於程式碼審查自動化和效能最佳化推薦的機器學習服務。它能找出最影響程式效能的程式碼行，並讓提供修復或改進程式碼的具體建議。這就是程式碼大資料和執行時服務大資料結合的智慧工具。

# 2020 如何兌現新技術給業務帶去的價值

對於雲原生從業者來說，2020 年最大的挑戰可能是兌現新技術給業務帶去的價值。雖說過去一年對雲原生的價值有不同層次、不同視角的解讀，但更多還是從技術層面，鮮有各行各業的客戶成功案例闡述新技術所帶來的直接業務價值。

從市場的角度：仍存在大量的傳統行業的企業處於物理機或虛擬機器時代，受資產狀況的影響他們很難一下子將核心業務搬遷到雲原生之上而體會到新技術的巨大價值；另一方面，對於早已進入容器時代的那些企業，他們在軟體資產上過去多年持續地投入了大量的資源做建設，從功能層面早已建立起了與雲原生等同的軟體資產，不會很快從自建轉變為雲原生。這是市場面對新技術普及之前的正常姿態，行業客戶從兩端正在被改變，今天大家正逐步對雲原生這一概念達成有具象的共識。

站在新的一個十年起點，雲原生從業者應當堅定自己對於新技術價值的理解和洞察，沉下心去將雲原生的基礎能力建設好。同時，需要特別重視以合適的方式和時機去兌現業務價值，透過更多的成功客戶故事去加速市場對新技術的接受，讓自己的成果更快、更好地被市場認可，創造行業趨勢，為雲端計算的發展做出自己的貢獻。

# 雲原生實踐峰會即將開幕

![大咖海報.jpeg](https://ucc.alicdn.com/pic/developer-ecology/a4e2716522e447379ea78deb057fe866.jpeg)

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247488832&idx=1&sn=aa09e51d0c67bafc50a0811c52755602&chksm=fae51e8fcd929799be5b9161c8304cb5d8bfea1c221cac36707ce08304078f7293b6d39d4f4f&token=1607043143&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

2020 雲原生技術 7 大領域趨勢全預測

相關文章