簡介： 17位專家、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” 等頂級互聯網規?；瘓鼍爸袑崒嵲谠诘募夹g主角。

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

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

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

總結

以上是生活随笔為你收集整理的2020 云原生 7 大趋势预测的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。