過去的幾年,是云原生技術和理念得到廣泛接受的幾年。在這個快速發(fā)展的領域,預測未來顯得尤其困難,但是我們又有著一些堅定的信念,相信以開放創(chuàng)新為支撐的云原生領域會持續(xù)重塑軟件生命周期,帶來不斷的價值。
2019,在眾多熱門技術趨勢中,云原生的關注度居高不下,很多開發(fā)者都對由此而興起的一眾技術十分追捧,眾多企業(yè)開始探索云原生架構轉型落地。在中國,開發(fā)者們經(jīng)歷了從關注“云原生概念”到關注“云原生落地實踐”的轉變。
在籌備阿里云首屆云原生實踐峰會的過程中,我們展開了對云原生技術的應用和研究領域的探索,邀請了 17 位云原生技術專家從 Serverless、Service Mesh、Kubernetes、邊緣計算、容器實例與容器引擎、云原生基礎架構、云原生應用開發(fā) 7 個發(fā)展方向,回顧 2019 云原生領域進展,描繪云原生技術的新十年。
2020 云原生標志性事件預測
展望 2020,在云原生技術的應用和研究領域,我們預見會有這些標志性事件。
第一,云原生技術關注重心在上移,Serverless 和應用管理重點。
過去的幾年我們看到,云原生技術重心圍繞容器和容器編排。Docker 和 K8s 的成功幾乎成了云原生的代名詞。很多人說,Kubernetes is becoming boring,這是對于技術的趨勢來說。
云原生關注重心即將上移:
應用的定義和配置、發(fā)布和線上的自動化運維,成為開發(fā)和運維人員關心的核心內容。阿里巴巴和微軟聯(lián)合推出的 Open Application Model (OAM) 就是這個方向的一個重要項目。
作為云原生技術的延伸,無服務器計算(Serverless)將進一步釋放云計算的能力,將安全、可靠、可伸縮等需求由基礎設施實現(xiàn),使用戶僅需關注業(yè)務邏輯而無需關注具體部署和運行,極大地提高應用開發(fā)效率,同時這個方式促進了社會分工協(xié)作,云廠商可以進一步通過規(guī)?;⒓s化實現(xiàn)計算成本大幅優(yōu)化。相信在 2020 會有更多的創(chuàng)新和落地實踐在這個領域涌現(xiàn)。
第二,云原生技術成為云服務商的創(chuàng)新和競爭力的主陣地。
隨著以容器為基礎的云原生技術被用戶廣泛接受,可以肯定的預期,容器會很快成為云和用戶的基本界面。因此對于云的服務提供商來說,基于容器、微服務、無服務器、服務網(wǎng)格等新型云原生技術的領域,必將是云廠商未來創(chuàng)新和競爭力的主陣地。
虛擬化未來 3 年還會是云上資源增量的主體,但是硬件虛擬化加速的裸金屬和安全沙箱容器的組合,正在加速企業(yè)的上云和容器化過程。云廠商未來技術競爭力的關鍵,在云傳統(tǒng)的優(yōu)勢包括規(guī)模、穩(wěn)定性、成本發(fā)揮到極致的前提下,必將通過云原生技術和產品的持續(xù)創(chuàng)新來服務客戶來獲得客戶的認可。云原生產品領域將成為云廠商競爭白熱化的必爭之地。
第三,云原生從數(shù)據(jù)中心走向云邊端一體化,將無處不在。
云原生技術起源于數(shù)據(jù)中心內的應用和服務,并在過去幾年逐漸擴展到邊緣場景甚至端上的計算。相信未來隨著 5G/IoT 的快速發(fā)展,云邊端一體化的云原生技術將深入更多的企業(yè)和更豐富場景,將無處不在。
第四,云原生將經(jīng)歷企業(yè)落地之痛,云原生上云將成為趨勢。
云的技術發(fā)展會領先于企業(yè)落地的速度。盡管云原生技術已經(jīng)被廣泛接受,其在企業(yè)技術棧的落地仍然需要時間,也面臨不少挑戰(zhàn)。如容器化過程中改變傳統(tǒng)虛擬機模式下的運維習慣,企業(yè)傳統(tǒng)應用分布式微服務化的改造涉及 re-architecturing 等因素。
云原生被企業(yè)接受之后,落地的過程需要解決這些挑戰(zhàn)。運維管理含有豐富組件并快速演進的云原生的基礎設施也對企業(yè) IT 人員的技術技能提出了更高的要求。然而我們相信,云原生技術帶來的資源成本降低,研發(fā)運維效率提升等巨大價值,會驅動企業(yè)迎接這些挑戰(zhàn)。
在這個過程中,使用云原生上云,基于容器和服務網(wǎng)格等標準界面和混合云方案,將極大的降低遷云復雜度,使企業(yè)可以更快遷移到云上標準服務。通過云原生上云最大化使用云的能力,高效的社會分工,使企業(yè)聚焦于自身業(yè)務發(fā)展,相信將成為企業(yè)的共識。
2020 云原生 7 大技術領域趨勢
1、Serverless
2019,行業(yè)中的各大 Serverless 計算平臺的能力有了長足進步,變得更加通用。例如通過預留資源完全消除冷啟動對延時的影響,使得延時敏感的在線應用也能夠使用 Serverless 方式構建。Serverless 生態(tài)不斷發(fā)展。在應用構建,安全,監(jiān)控報警等方面涌現(xiàn)了很多開源項目和創(chuàng)業(yè)公司,工具鏈越來越成熟。
用戶對 Serverless 的接受度不斷增加。除了互聯(lián)網(wǎng)等迅速擁抱新技術的行業(yè),傳統(tǒng)企業(yè)用戶也開始采用 Serverless 技術。站在新的一個十年, Serverless 領域將發(fā)生如下演進:
Serverless 將進一步從偏離線業(yè)務進入在線業(yè)務。
真正的按請求次數(shù)計費和從零到一的響應時間是一個天然的矛盾,以 FaaS 為代表的 Serverless 技術一開始都是從對響應時間不敏感的,事件驅動的偏離線業(yè)務入手。但是今天我們已經(jīng)看到,包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在內的產品特性,都在讓用戶稍微付出一點額外的成本以換取更低的響應時間。這對于在線業(yè)務來說,無疑是更適合的。
Serverless 不僅是應用或者函數(shù)的能力,也會加速推動基礎設施和服務 Serverless 化。
業(yè)務代碼托管給 Serverless 平臺之后,即能享受到自動彈性,按請求計費能能力。但是如果基礎設施和相關服務不具備實時的擴縮容能力,那么對于業(yè)務整體來說,就不是彈性的。我們已經(jīng)看到 AWS 圍繞 Lambda 對 VPC 網(wǎng)絡、數(shù)據(jù)庫連接池等資源做了大量實時彈性優(yōu)化,相信其他的廠商也會跟進,進而行業(yè)整體會加速基礎設施和各類云服務的 Serverless 化。
以 Knative 為代表的開源解決方案將得到越來越多的關注。
盡管各個云廠商都在大力推廣自己的 Serverless 產品,但是開發(fā)者普遍還是會擔心被廠商綁定,因此具備一定規(guī)模的組織會基于開源方案,如 Knative,搭建自己的 Serverless 平臺。而一旦某個開源方案成為主流,云廠商就會主動去兼容開源標準并增大社區(qū)投入。
Serverless 開發(fā)者工具和框架會進一步繁榮。
IDE,問題診斷,持續(xù)集成/發(fā)布等配套的工具和服務的用戶體驗會更加完整。我們將看到更多的成功案例和最佳實踐。在前端開發(fā)等領域將會出現(xiàn)為 Serverless 而生的應用框架,將工程效率發(fā)揮到極致。
Java 持續(xù)進擊,將成為 Serverless 平臺主流語言之一。
Serverless 平臺要求應用的鏡像足夠小以能夠快速分發(fā),同時要求應用的啟動時間極短。雖然在這些方面,Java 和 NodeJS 和 Python 等語言有差距,但是 Java 社區(qū)在不斷努力。我們看到 Java 通過 Java 9 Modules 以及 GraalVM Native Image 等技術在不斷努力“減肥”,主流框架 Spring 也開始擁抱 GraalVM,而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 領域給人煥然一新的感覺。
解決 FaaS 狀態(tài)傳遞的中間層(加速層)研究或產品有望得到突破。
Serverless 在 Function 場景下未來最大的挑戰(zhàn)是 function 之間串聯(lián)需要狀態(tài)(state)傳遞、function 處理需要頻繁和外部存儲交互等帶來的時延放大。傳統(tǒng)的架構這些都是在一個程序進程內部處理完畢。解決上述挑戰(zhàn)需要可計算中間層(加速層),可計算中間層(加速層)是未來學術研究和產品攻堅發(fā)展方向之一。
基于 WebAssembly(簡稱 WASM) 的 FaaS 方案有望出現(xiàn)。
Docker 的創(chuàng)始人之一 Solomon Hykes 曾說,“如果2008年有 WASM 和 WASI,我們當時就沒有必要創(chuàng)造 Docker 了”,這句話在一定程度上說明了 WASM 的重要性。雖然當下 WASM 更多作為一種運行在瀏覽器端的技術被人了解,但是它具備非常優(yōu)秀的安全隔離能力,極快的啟動速度,以及對于超過20種語言的支持,那么為什么不能讓它運行在服務端呢?這些技術特性都非常契合 FaaS 的要求。
2、Service Mesh
在 2019 年,Service Mesh 的整體解決方案逐漸顯現(xiàn)了寡頭壟斷的局面。一個解決方案能否得到行業(yè)的普遍認可,關鍵在于其背后的技術團隊對分布式應用治理復雜度是否有深刻洞見,以及能否打造一個被所有云廠商都采納的事實標準。事實標準對于使用 Service Mesh 的客戶來說,意味著分布式應用能根據(jù)自己的需要在多云和混合云上方便部署。
站在新的一個十年, 2020 年 Service Mesh 領域將有如下變化:
2019 Service Mesh 熱度持續(xù)上升,落地的問題將在 2020 得到解決。
2019 年,Service Mesh 在部分公司如螞蟻金服迎來大規(guī)模的落地,整個業(yè)界的熱度在持續(xù)上升,大大加大了國內公司對于 Service Mesh 的信心,目前幾乎每家稍微大一點的互聯(lián)網(wǎng)公司都已經(jīng)開始實踐 Service Mesh,包括美團、頭條、百度等公司。
當然,在 2019 年業(yè)界落地遇到的各種問題,包括 Sidecar 大規(guī)模運維的問題等等,以 OpenKruise/kruise 的為代表的 SidecarSet 雖然已經(jīng)在做一些努力,但是目前仍然存在升級 Pod 過程過于復雜的問題,這些問題有望在 2020 年得到解決。
Istio 將更加成熟,更加適合大規(guī)模集群的落地。
2020 年 Istio 作為控制平面的一種技術實現(xiàn)仍將在 Service Mesh 領域扮演核心角色。Istio 獲得業(yè)界廣泛關注的原因,在于背靠 Google 公司的內部工程實踐,以及對工程實踐的再思考和重新提煉。Istio 在過去一年的重要工作是完善功能和改善穩(wěn)定性確保小規(guī)模生產可用,在 2020 年隨著阿里巴巴采用這一技術實現(xiàn)大規(guī)模落地將為 Istio 的規(guī)?;\用提供真實的場景,這將使得 Istio 在接下來的一年在支持集群規(guī)模的能力上大幅提高。
此外,隨著探索,Istio 的可運維性和架構的合理性在 2020 年也將迎來積極的變化,其部署和運維的復雜性高等問題將得到解決。Istio 所采納的 Envoy 開源項目,在新的一年依然保持 Service Mesh 數(shù)據(jù)平面的事實標準這一領導地位,Istio 和 Envoy 兩大開源社區(qū)因為緊密協(xié)作而更好地推動 Service Mesh 向前演進。
Serivce Mesh on EdgeService 熱度持續(xù) Service Mesh & IoT。
2019 年 Serivce Mesh on Edge 的熱度在逐漸提升,Edge 本質上要提供更快的響應提升體驗。對于 Service Mesh 來說,被從“舒適”的云端下放到 Edge,要解決性能,低資源消耗,安全,高可用等問題,具體 Kernel Bypaasing,Sidecar as Node+WASM,SmartNic 軟硬件結合, IoT Identity 結合,secret 保護,低輸出成本,非可靠網(wǎng)絡環(huán)境等,當下看還非常有挑戰(zhàn),這些問題將在 2020 年得到部分解決。
More Than Service Mesh。
Service Mesh 作為解耦應用與基礎設施的關鍵技術,在 2020 年將有更多的產品通過與 Service Mesh 結合去完成 BaaS 化,這除了減少沒有必要的重復建設,還使得云產品因為將那些與應用無關的內容剝離出來下沉為基礎設施的一部分而加速自身的演進速度,以及給云產品的使用者帶去更棒的軟件開發(fā)和維護體驗而加速業(yè)務的探索效率和降低探索成本。
我們看到 Envoy 也提供了 MySQL、Redis、MongoDB、DynamoDB 的協(xié)議支持,能夠支持請求解析、請求級統(tǒng)計、失敗統(tǒng)計等通用的可觀測性特性。后續(xù) Mesh 將繼續(xù)發(fā)展,成為整個網(wǎng)絡層面的一個基礎設施,用以管控所有應用層面的出/入口流量。
展望 2020 年,Service Mesh 將會成為解決異構系統(tǒng)通信、混合云架構等方向上的必備組件,在混合云、新老架構的場景下,Service Mesh 和原有基礎設施的結合能力將成為 Service Mesh 落地的關鍵,比如對于 VM 場景的支持,對于傳統(tǒng)服務注冊中心的支持等等,相信會有更多的公司通過實踐而對 Service Mesh 的價值更有體感,通過創(chuàng)造更多的成功客戶故事而加速 Service Mesh 的普及。也許,2020 年將成為 Service Mesh 的普及年。
3、Kubernetes
2019 年,在社區(qū)頭部參與者的持續(xù)推進下,“規(guī)模”與“性能”終于成為了 Kubernetes 項目的重要關鍵詞,這不僅真正意義上打通了 Kubernetes 在企業(yè)生產環(huán)境中大規(guī)模落地的最后一公里,也讓 Kubernetes 第一次成為了 “雙11” 等頂級互聯(lián)網(wǎng)規(guī)?;瘓鼍爸袑崒嵲谠诘募夹g主角。
站在新的一個十年, 2020 年 Kubernetes 領域將有如下變化:
Kubernetes 將成為用戶和云計算新的交互界面。
隨著云原生計算的普及,越來越多的應用負載都部署在 Kubernetes 之上,包括數(shù)據(jù)庫、大數(shù)據(jù)、AI智能和創(chuàng)新應用,Kubernetes 已成為云原生計算的基石。得益于 Kubernetes 的大規(guī)模應用管理能力、多云混合云的支持能力,在 2020 年,Kubernetes 會成為用戶和云計算新的交互界面。從架構的角度,Kubernetes 成為了 IaaS 層的控制平面,并進一步推動底層 IaaS(計算、存儲、網(wǎng)絡)的能力優(yōu)化,來滿足容器帶來的一二個數(shù)量級的高密度和高動態(tài)性要求。
Kubernetes 掌控能力成為企業(yè)運維團隊的核心技能,并和 AIOPS 相互促進發(fā)展。
Kubernetes 的大規(guī)模使用是否會帶來企業(yè)運維人員的失業(yè)?實際上,隨著越來越多的企業(yè) IT 架構,從 on Kubernetes 到 in Kubernetes,大量的 CRD、自定義 Controller 和服務網(wǎng)格的引入,給 Kubernetes 的穩(wěn)定性和性能優(yōu)化帶來大量的挑戰(zhàn)。Kubernetes 的掌握深度逐漸成為企業(yè)運維團隊技術能力的重要評估標尺,而企業(yè)運維人員的技能也會從自動化向數(shù)據(jù)化和智能化發(fā)展。
預測在 2020 年,圍繞著 Kubernetes 的 AIOps 會逐漸涌出,來進一步完善 Kubernetes 的成本優(yōu)化、故障檢測和集群優(yōu)化。
而 Kubernetes 等云原生技術也會讓 AIOps 不再霧里看花:
1)得益于 Kubernetes 的良好設計,包括聲明式API、不可變架構、優(yōu)雅的擴展機制,可以促進應用發(fā)布和運維的操作歸一化(Normalization);2)結合 GItOps、Tekton、SecOps 等自動化流程的落地,應用的生命周期更加標準化(Standardization);3)隨著 OpenTelemetry、CloudEvents 等項目的推進,應用可觀測性領域在日志、監(jiān)控、Tracing、事件等領域進一步標準化和融合,使得多指標、根因分析的數(shù)據(jù)集更加豐富,從而提高 AIOPS 的 AI 層面的準確率和覆蓋率。
新內核、新硬件助力容器優(yōu)化 OS 的演進。
容器技術經(jīng)過了多年的發(fā)展,從早期的 Docker、rkt、CRI-O 等,到 containerd、Kata Container、gVisor,已經(jīng)成為 Kubernetes 運行的重要基石。然而無論是 runc 場景的進一步隔離,還是安全容器場景的進一步性能優(yōu)化,還需要持續(xù)的打磨和增強。
隨著新內核技術包括 CGroup V2、namespace、virtiofs 等的逐步成熟,可以進一步增強容器運行時的能力。另一方面,一些新硬件包括 NPU、MoC、NUMA 等的引入,也給容器和 K8s 調度帶來了更多的優(yōu)化空間和場景。得益于這些能力的加成,為容器場景量身定制的容器優(yōu)化 OS 成為可能,并會快速發(fā)展。
容器網(wǎng)絡和 Mesh 網(wǎng)絡將進一步融合。
Service Mesh 經(jīng)過多年的市場培育,2020 年將會成為 Service Mesh 技術的普及年。而 Service Mesh 的性能優(yōu)化也會成為重頭戲,一些下沉方案也在選擇基于 CNI(容器網(wǎng)絡接口)和內核技術進一步優(yōu)化網(wǎng)絡轉發(fā)性能。
而容器網(wǎng)絡自身也在逐漸演進,從面向 ip 到面向 Identity,從單容器網(wǎng)絡平面到多網(wǎng)絡平面,并進一步優(yōu)化網(wǎng)絡轉發(fā)性能和零可信安全。在 2020 年,我們相信容器網(wǎng)絡和 Mesh 網(wǎng)絡將進一步融合,在 Network ServiceMesh、NFV等場景進一步集成。
4、邊緣計算
隨著 5G 和萬物互聯(lián)時代的到來,聯(lián)網(wǎng)智能終端設備數(shù)量將急劇增加,傳統(tǒng)云計算中心集中存儲、計算的模式已經(jīng)無法滿足終端設備對于時效、容量、算力的需求,將云計算的能力下沉到邊緣側、設備側,并通過中心進行統(tǒng)一交付、運維、管控,將是云計算的重要發(fā)展趨勢。
IDC 預計,到 2020 年全球將有超過 500 億的終端與設備聯(lián)網(wǎng),超過 40% 的數(shù)據(jù)要在網(wǎng)絡邊緣側進行分析、處理與存儲,這對邊緣計算提供了充分的場景和想象空間。
站在新的一個十年,2020 年邊緣計算領域將有如下變化:
以 Kubernetes 為基礎的云原生技術,經(jīng)過近幾年的高速發(fā)展,適用范圍、落地場景、技術成熟度等均有了長足發(fā)展,其核心價值之一是通過統(tǒng)一的標準實現(xiàn)在任何基礎設施上提供和云上一致的功能和體驗。將云原生技術和邊緣計算相結合,可以快速實現(xiàn)『云-邊-端』一體化的應用分發(fā),解決在海量邊、端設備上統(tǒng)一完成大規(guī)模應用交付、運維、管控的訴求;
在安全方面,云原生技術可以提供容器等更加安全的工作負載運行環(huán)境,以及流量控制、網(wǎng)絡策略等能力,能夠有效提升邊緣服務和邊緣數(shù)據(jù)的安全性;
在邊緣網(wǎng)絡環(huán)境下,基于云原生技術的邊緣容器能力,能保證弱網(wǎng)、斷網(wǎng)的自治性,提供有效的自恢復能力,同時對復雜的網(wǎng)絡接入環(huán)境有良好的兼容性;
依托云原生領域強大的社區(qū)和廠商支持,云原生技術對異構資源的適用性逐步提升,在物聯(lián)網(wǎng)領域,云原生技術已經(jīng)能夠很好的支持多種 CPU 架構和通信協(xié)議,并實現(xiàn)較低的資源占用。
目前已經(jīng)有不少廠商在進行云原生邊緣計算的嘗試,并有了部分成功案例,相信在 2020 年隨著 5G 的快速鋪開,云原生邊緣計算的發(fā)展將大大提速。
5、容器實例與容器引擎
在 2019 年的最后一個月 AWS 終于發(fā)布了 Fargate for EKS 產品,這也宣告了云上 Kubernetes 使用 Serverless 容器實例作為底層運行時資源的產品形態(tài)得到了業(yè)界更廣泛的認可。通過容器實例作為底層運行實體可以讓用戶專注于構建自身的業(yè)務和服務,無需再配置和管理服務器,擺脫基礎設施運維的復雜性。同時通過真正的按需付費和實時擴容來降低用戶的使用成本。 無論是亞馬遜的 Fargate,微軟的 ACI 還是阿里云的 ECI,各產品當前在對接 Kubernetes 的具體架構上仍然有分歧,以 Fargate 為代表采用的是透傳 Node 信息的方式來提供對 Kubernetes 功能的完整支持;以 ACI/ECI 為代表則采用 virtual kubelet 方式對接 Kubernetes 對容器實例進行管理。
但無論采用何種對接方式,容器實例產品的核心依然需要構建在彈性、成本和 Kubernetes 兼容性上。通過彈性實現(xiàn)用戶服務的按需實時擴容,用戶無需選擇實例和集群容量,不需要為額外的服務器預置而付費;通過實時擴容實現(xiàn)真正的按使用資源付費,降低用戶的使用成本;Kubernetes 已經(jīng)成為容器編排領域的事實標準,對 Kubernetes 功能的兼容性決定著容器實例的適用范圍。
站在新的一個十年,相信在 2020 年容器實例產品會在這三個方面繼續(xù)改進和完善,持續(xù)提升彈性能力,降低用戶的使用成本,并不斷完善與 Kubernetes 的集成。同時也會有更多的云原生應用遷移到 Kubernetes+ 容器實例上,享受云原生的技術紅利。
從上述各廠商的同類產品中我們也可以看到此類產品在設計上的共同之處:
一個實例對應一個 Pod
對接 Kubernetes
安全容器作為底層容器引擎
這其中使用安全容器作為底層容器引擎是各家都很重視的底層基礎能力。在 2019 年安全容器技術的隔離性越來越被看重,作為一個隔離層,不僅提升云原生平臺的安全性,也對可運維性、服務質量和用戶數(shù)據(jù)保護有顯著效果。不過,回歸初心,用戶選擇云原生的本質是容器帶來的敏捷性,他們可以快速地調度并啟動容器,并且可以靈活地使用資源,這方面安全技術尚不能達到傳統(tǒng)容器的水平。 不論是 Kata Containers 還是 gVisor,開源安全容器引擎在 2019 年都取得了很多進展,Kata Containers 明確提出了“做面向云原生的虛擬化”作為 2020 年的目標:
在沙箱間共享資源,同時保持沙箱邊界仍然清晰。
即時、動態(tài)地按需為沙箱提供資源,而不是像分區(qū)那樣進行固定的資源分配。
主機的用戶態(tài)工具、VMM、乃至應用的內核聯(lián)合起來,彼此協(xié)同為沙箱中的應用提供服務。
在 2020 年,Kata 代表的虛擬化容器會與傳統(tǒng)虛擬化漸行漸遠而更加“應用中心”,gVisor 為代表的進程級虛擬化也期待更多為應用的優(yōu)化。我們相信在 2020 年的時候,我們還不會有一個統(tǒng)一的安全容器技術,但展望 21 世紀 20 年代的頭幾年,我們期待軟硬件的共同發(fā)展會讓主流的容器引擎都具有更好的隔離性。
6、基礎架構演進
基于 Kubernetes 的 Serverless Infras 架構演進一直是各大云廠商和社區(qū)關注的焦點。2019 年 12 月 AWS 在拉斯維加斯召開了一年一度 re:Invent 大會上宣布了 EKS on AWS Fargate 產品正式 GA,這個消息在云市場和社區(qū)里掀起了不小的波瀾。
EKS on Fargate 提供了標準的 Serverless Infra.的用戶體驗,即用戶購買了 EKS 的服務后,不再需要購買額外的 Infra 云資源(如VM,Nitro),就可以使用原生 K8s API 部署自己的應用,并且支持按量計費。
Serverless Infra.架構使得用戶無需關注計算、網(wǎng)絡、存儲等底層基礎設施細節(jié),真正讓用戶回歸到面向POD應用資源部署形態(tài)上去;同時管控面與數(shù)據(jù)面的強隔離能力將會是 Serverless Infra.架構的關鍵,除了對用戶屏蔽底層基礎設施細節(jié)外,Serverless Infra. 需要提供給用戶一個安全可信的租戶隔離環(huán)境
2019 年隨著經(jīng)濟體全面上云,底層調度系統(tǒng)全面升級到云原生 Kubernetes + 輕量級容器架構演進,并且大規(guī)模部署在神龍裸金屬實例上;同時基于 kata-container 的安全容器運行時技術趨于成熟,已經(jīng)具備大規(guī)模鋪開的條件。
站在新的一個十年,預計2020 年,將是經(jīng)濟體全面邁向基礎設施 Serverless Infra. 的一年,Serverless Infra.架構將會基于神龍+安全容器架構,通過構建軟/硬多租戶能力,彈性能力和高度的容器自愈能力,為用戶提供極致的安全、穩(wěn)定、隔離性的用戶體驗。同時底層資源池共享也能有效提升整體資源利用率,并池后資源互通將會有效降低整體機器成本
7、應用開發(fā)
展望 2020,我們認為云原生+智能化將成為下一代研發(fā)平臺最重要的兩個特性,它將進一步降低開發(fā)者采納復雜技術的門檻以及通過工具釋放生產力。當所有復雜度都卸載到云上以后,我們將回到 10 年前開發(fā)單機程序時的高效。
站在新的一個十年, 2020 應用開發(fā)領域將發(fā)生如下演進:
從 Web-IDE 演進為 Cloud-Native IDE
2019 年是 VS Code 生態(tài)繼續(xù)高歌猛進的一年,得益于其模塊化的設計,VS Code 中的幾個核心組件Monaco編輯器,插件體系,Language Server Protocol(LSP)等成為了Web-IDE的標準選型。社區(qū)也出現(xiàn)了code-server這樣基于 VS Code 一行命令拉起 Web-IDE 的方案。
除了 VS Code 之外,Theia 也繼續(xù)演進,尤其是基于 Theia 的gitpod.io 讓人眼前一亮,通過把 gitpod 按鈕集成在諸如 GitHub README 頁面上,一鍵實現(xiàn)了從代碼到預覽的順滑體驗。
另一方面,大廠已有的 Web-IDE 方案也需要回過頭來擁抱社區(qū),徹底如 Facebook 完全從自研的Nuclide 轉而投向 VS Code,而無論是 Amazon的Cloud9 還是 Google 尚未對外的 Cider,如果要在商業(yè)化上更進一步,支持 VS Code 的插件體系想必也是理所當然。
從 Local-IDE 到 Web-IDE 讓我想起了當年從 PC 到移動端。雖說時至今日,不少專業(yè)工具 PC 端的體驗仍然是移動端難以企及的,但移動端的主導地位早已不容置疑。
Web-IDE 具備開箱即用,環(huán)境一致可控以及和其它Web服務無縫集成的先天優(yōu)勢。接下來要做的除了繼續(xù)補齊和 Local-IDE 在端功能的差距外,還可以結合分布式編譯構建,集中式代碼倉庫,海量代碼索引分析,云端協(xié)同等,提供真正的 Cloud-Native IDE。
工具 -> 平臺 -> 標準
GitHub 今年推出了 GitHub Actions,通過它可以在工作流中靈活地集成各種第三方服務。GitLab 也在更早的時候就推出了可定制化的 CI 流水線配置。無論是 GitHub 還是 GitLab,它們都從早期單純的代碼托管工具成長為了一站式 DevOps 平臺。
最早以 IntelliJ 工具起家的 JetBrains 不再滿足于僅僅打磨 IDE,今年也推出了 Space,力圖打造一站式研發(fā)團隊平臺。以項管工具 Jira 起家的 Atlassian,一直是自研收購兩架馬車并駕齊驅,今年通過收購又在自己研發(fā)平臺的版圖上增加了針對管理者視角的 Jira Align。
后起之秀如 sourcegraph 干脆直接在網(wǎng)站上號稱自己是 The new standard developer platform。不管是基于 Dev 工具的右移,抑或是基于 Ops 工具的左移,當年的工具們都或多或少地長成所謂的一站式 DevOps/DevSecOps 平臺。
那接下來,在這些平臺之上是否能提煉出通用的標準?比如 CI 領域,是否能有一套 CI 流水線定義可以一統(tǒng)CircleCI,GitLab,GitHub Actions 諸如此類?是否也有一套 workflow 標準可以讓用戶在 AWS Step Functions, Argo, Tekton 之間無縫遷移?
在更高的抽象層面,諸如 Open Appliction Model(OAM) 這樣的標準是不是能真正架起從業(yè)務架構到基礎架構的橋梁。雖然如今的研發(fā)平臺已然是諸侯割據(jù)的局面,但在云原生,標準先行的理念下,我還是會期待有離業(yè)務層更接近的云原生標準去串聯(lián)起整個研發(fā)平臺。
開發(fā)者工具從本地工作到云端協(xié)作
當前的開發(fā)者工具絕大多數(shù)采用的是 lift and shift 的方式從本地平移上云,產品設計針對的還是單人人機交互,移到云端的研發(fā)工具還沒有很好地利用云端多人實時交互的能力。無論是多人協(xié)作(云已經(jīng)讓我們離彼此更近),還是人機協(xié)作(云已經(jīng)讓機器變得更強),我期待著出現(xiàn)進一步挖掘云端協(xié)作能力的創(chuàng)新點。
更多云原生研發(fā)平臺涌現(xiàn)
以 Kubernetes、Serverless、Service Mesh、Cloud IDE 為代表的多項云原生技術在過去一年讓人印象深刻。我們意外的觀察到,以中小互聯(lián)網(wǎng)公司為代表的技術群體開始快速擁抱這個技術體系,并且通過云原生落地,快速的獲得了以往互聯(lián)網(wǎng)大廠才有的精英軟件交付能力,比如復雜的流量治理能力,灰度發(fā)布能力,A/B Test 能力,多環(huán)境管理能力,基礎設施一鍵拉起,快速擴縮能力等等。
但在企業(yè)采納新技術的同時,也面臨著諸多挑戰(zhàn),比如開源軟件復雜的搭建過程,黑屏化的交互設計,缺乏研發(fā)管理方法,缺乏企業(yè)權限管理能力等。因此一大批軟件供應商開始基于云原生技術體系開發(fā)相關的管理平臺,比如 QingCloud,Rancher,阿里云容器服務。作為云上研發(fā)協(xié)同平臺領導者的云效也在積極將 CICD 工具、測試環(huán)境管理方法、應用運維理念、DevOps 協(xié)同方法論等與云原生技術融合貫通,為企業(yè)提供開箱即用的新技術解決方案。
數(shù)據(jù)和智能的工具時代到來
云原生是一套開放標準的技術體系,核心貢獻者就是當今世界的互聯(lián)網(wǎng)云廠商巨頭企業(yè)。隨著技術的發(fā)展和影響力的增強,逐步將企業(yè)的私有技術壁壘打破,并且開始采納云上現(xiàn)成的云原生產品來改造自身的技術體系。技術的收斂帶來了統(tǒng)一數(shù)據(jù)規(guī)范的可能,而數(shù)據(jù)是所有智能化的基石。
我們觀察到最近一年 AWS、微軟、Facebook、ebay 等廠商都在積極布局智能化工具,從傳統(tǒng)的“代碼”智能工具逐步擴展到“服務”智能工具。比如最近 AWS 發(fā)布的CodeGuru,它是一個用于代碼審查自動化和性能優(yōu)化推薦的機器學習服務。它能找出最影響程序性能的代碼行,并讓提供修復或改進代碼的具體建議。這就是代碼大數(shù)據(jù)和運行時服務大數(shù)據(jù)結合的智能工具。
2020 如何兌現(xiàn)新技術給業(yè)務帶去的價值
對于云原生從業(yè)者來說,2020 年最大的挑戰(zhàn)可能是兌現(xiàn)新技術給業(yè)務帶去的價值。雖說過去一年對云原生的價值有不同層次、不同視角的解讀,但更多還是從技術層面,鮮有各行各業(yè)的客戶成功案例闡述新技術所帶來的直接業(yè)務價值。
從市場的角度:仍存在大量的傳統(tǒng)行業(yè)的企業(yè)處于物理機或虛擬機時代,受資產狀況的影響他們很難一下子將核心業(yè)務搬遷到云原生之上而體會到新技術的巨大價值;另一方面,對于早已進入容器時代的那些企業(yè),他們在軟件資產上過去多年持續(xù)地投入了大量的資源做建設,從功能層面早已建立起了與云原生等同的軟件資產,不會很快從自建轉變?yōu)樵圃?。這是市場面對新技術普及之前的正常姿態(tài),行業(yè)客戶從兩端正在被改變,今天大家正逐步對云原生這一概念達成有具象的共識。
站在新的一個十年起點,云原生從業(yè)者應當堅定自己對于新技術價值的理解和洞察,沉下心去將云原生的基礎能力建設好。同時,需要特別重視以合適的方式和時機去兌現(xiàn)業(yè)務價值,通過更多的成功客戶故事去加速市場對新技術的接受,讓自己的成果更快、更好地被市場認可,創(chuàng)造行業(yè)趨勢,為云計算的發(fā)展做出自己的貢獻。
第三十四屆CIO班招生
國際CIO認證培訓
首席數(shù)據(jù)官(CDO)認證培訓
責編:baiyl
免責聲明:本網(wǎng)站(http://www.www.gypb.net/)內容主要來自原創(chuàng)、合作媒體供稿和第三方投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
本網(wǎng)站刊載的所有內容(包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等)版權歸原作者所有。任何單位或個人認為本網(wǎng)站中的內容可能涉嫌侵犯其知識產權或存在不實內容時,請及時通知本站,予以刪除。