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

文章聯合撰稿人(排名不分前後)
叔同、谷樸、不瞋、育睿、許曉斌、至簡、典違、魯直、改之、小劍、湯志敏、白慕、循環、文卿,嘍哥、水鳥、神秀。前端

在籌備阿里雲首屆雲原生實踐峯會的過程當中,咱們展開了對雲原生技術的應用和研究領域的探索,邀請了 17 位雲原生技術專家從 Serverless、Service Mesh、Kubernetes、邊緣計算、容器實例與容器引擎、雲原生基礎架構、雲原生應用開發 7 個發展方向,回顧 2019 雲原生領域進展,描繪雲原生技術的新十年。git

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

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

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

雲原生實踐峯會即將開幕

大咖海報.jpeg

阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,作最懂雲原生開發者的技術圈。」

相關文章
相關標籤/搜索