2020 雲原生 7 大趨勢預測

（作者排名不分先後）

作者：叔同、谷樸、不瞋、育睿、許曉斌、至簡、典違、魯直、改之、小劍、湯志敏、白慕、循環、文卿，喽哥、水鳥、神秀

過去的幾年，是雲原生技術和理念得到廣泛接受的幾年。在這個快速發展的領域，預測未來顯得尤其困難，但是我們又有着一些堅定的信念，相信以開放創新為支撐的雲原生領域會持續重塑軟體生命周期，帶來不斷的價值。

2019，在衆多熱門技術趨勢中，雲原生的關注度居高不下，很多開發者都對由此而興起的一衆技術十分追捧，衆多企業開始探索雲原生架構轉型落地。在中國，開發者們經曆了從關注“雲原生概念”到關注“雲原生落地實踐”的轉變。

在籌備阿裡雲首屆雲原生實踐峰會的過程中，我們展開了對雲原生技術的應用和研究領域的探索，邀請了 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 不再霧裡看花：

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

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

3）随着 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 容器執行個體作為底層運作時資源的産品形态得到了業界更廣泛的認可。通過容器執行個體作為底層運作實體可以讓使用者專注于建構自身的業務和服務，無需再配置和管理伺服器，擺脫基礎設施運維的複雜性。同時通過真正的按需付費和實時擴容來降低使用者的使用成本。

無論是亞馬遜的 Fargate，微軟的 ACI 還是阿裡雲的 ECI，各産品目前在對接 Kubernetes 的具體架構上仍然有分歧，以 Fargate 為代表采用的是透傳 Node 資訊的方式來提供對 Kubernetes 功能的完整支援；以 ACI/ECI 為代表則采用 virtual kubelet 方式對接 Kubernetes 對容器執行個體進行管理。

但無論采用何種對接方式，容器執行個體産品的核心依然需要建構在彈性、成本和 Kubernetes 相容性上。通過彈性實作使用者服務的按需實時擴容，使用者無需選擇執行個體和叢集容量，不需要為額外的伺服器預置而付費；通過實時擴容實作真正的按使用資源付費，降低使用者的使用成本；Kubernetes 已經成為容器編排領域的事實标準，對 Kubernetes 功能的相容性決定着容器執行個體的适用範圍。

站在新的一個十年，相信在 2020 年容器執行個體産品會在這三個方面繼續改進和完善，持續提升彈性能力，降低使用者的使用成本，并不斷完善與 Kubernetes 的內建。同時也會有更多的雲原生應用遷移到 Kubernetes+ 容器執行個體上，享受雲原生的技術紅利。

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

一個執行個體對應一個 Pod

對接 Kubernetes

安全容器作為底層容器引擎

這其中使用安全容器作為底層容器引擎是各家都很重視的底層基礎能力。在 2019 年安全容器技術的隔離性越來越被看重，作為一個隔離層，不僅提升雲原生平台的安全性，也對可運維性、服務品質和使用者資料保護有顯著效果。不過，回歸初心，使用者選擇雲原生的本質是容器帶來的靈活性，他們可以快速地排程并啟動容器，并且可以靈活地使用資源，這方面安全技術尚不能達到傳統容器的水準。

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

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

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