文章聯合撰稿人（排名不分先後）
叔同、谷樸、不瞋、育睿、許曉斌、至簡、典違、魯直、改之、小劍、湯志敏、白慕、循環、文卿，嘍哥、水鳥、神秀。
在籌備阿里雲首屆雲原生實踐峯會的過程中，我們展開了對雲原生技術的應用和研究領域的探索，邀請了 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 年安全容器技術的隔離性越來越被看重，作爲一個隔離層，不僅提升雲原生平臺的安全性，也對可運維性、服務質量和用戶數據保護有顯著效果。不過，迴歸初心，用戶選擇雲原生的本質是容器帶來的敏捷性，他們可以快速地調度並啓動容器，並且可以靈活地使用資源，這方面安全容器技術尚不能達到傳統容器的水平。
不論是 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 年最大的挑戰可能是兌現新技術給業務帶去的價值。雖說過去一年對雲原生的價值有不同層次、不同視角的解讀，但更多還是從技術層面，鮮有各行各業的客戶成功案例闡述新技術所帶來的直接業務價值。
從市場的角度：仍存在大量的傳統行業的企業處於物理機或虛擬機時代，受資產狀況的影響他們很難一下子將核心業務搬遷到雲原生之上而體會到新技術的巨大價值；另一方面，對於早已進入容器時代的那些企業，他們在軟件資產上過去多年持續地投入了大量的資源做建設，從功能層面早已建立起了與雲原生等同的軟件資產，不會很快從自建轉變爲雲原生。這是市場面對新技術普及之前的正常姿態，行業客戶從兩端正在被改變，今天大家正逐步對雲原生這一概念達成有具象的共識。
站在新的一個十年起點，雲原生從業者應當堅定自己對於新技術價值的理解和洞察，沉下心去將雲原生的基礎能力建設好。同時，需要特別重視以合適的方式和時機去兌現業務價值，通過更多的成功客戶故事去加速市場對新技術的接受，讓自己的成果更快、更好地被市場認可，創造行業趨勢，爲雲計算的發展做出自己的貢獻。
雲原生實踐峯會即將開幕
“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”