當前，新一輪科技革命和產業變革正在重塑全球技術發展格局，傳統開發模式開始變得難以滿足企業產品業務快速迭代和升級需求，數字化轉型已然成為大勢所趨，加之伴隨著容器、Kubernetes 及微服務等技術熱度的持續攀升，可以說云原生正以不可撼動之勢，劍指云計算的下一個十年。在此趨勢下，我們不禁展望未來：云原生市場將如何發展？各大云原生平臺能否實現互通？云原生時代下，開發者會遇到怎樣的問題，又該如何抓住機遇？

（圖中從左到右依次為：于邦旭、陳皓、張鑫、司徒放）

為此，在 2021 長沙·中國 1024 程序員節上，我們特設了「云原生時代的開發者」圓桌對話環節，在 CSDN 副總裁于邦旭的主持下，MegaEase 創始人陳皓、火山引擎副總經理張鑫和阿里云應用 Paas 與 Serverless 產品線負責人司徒放三位專家共同探析云原生的未來圖景，揭示云原生時代對開發者帶來的價值與挑戰。

以下為對話全文：

從“小作坊”步入“工業時代”

于邦旭：云原生時代為軟件開發帶來了哪些新的機遇和挑戰？對程序員來說又面臨著哪些變化與不變？

陳皓：對程序員來說變化在于“分布式”。以前開發代碼可能都是在一臺機器上完成，但現在不行了——除了一臺電腦，開發者還需要很多配套設施，這大概也會是云原生的一個變化。

挑戰則是人們需要去了解更多知識，包括組件都比以前復雜得多，由此導致開發環境、編程環境也變得更為復雜。

于邦旭：誠然如此，早期我們寫代碼通常都是寫完直接上傳，由運維去部署。當時程序員寫代碼關注的可能是操作系統和單機，但現在我們更多關注的是云。換句話說，以前我們可能是面向操作系統編程，而今天是面向云原生編程：我們用的很多 API 可能已經不是操作系統所帶來的，而是云操作系統帶給我們的。

張鑫：我打個比方：我認為沒有云原生之前，我們的生產方式很像小作坊或者夫妻店，而有了云原生之后就開始步入類似工業時代的大規模、自動化生產，但這種轉變有好也有壞。小作坊時代效率比較低，但感覺更為可控；大規模自動化階段在效率上有所提升，可有些時候程序員可能會感覺比較黑核，因為代碼提交后系統會自動適配，心里容易感到有些不安。

正如陳皓老師剛剛所說，云原生時代對程序員來說的確會改變他們的編程方式和習慣。以前我們編程的時候，需要在業務邏輯里面寫控制邏輯、還有服務發現等，都需要寫在代碼里。但到如今新的模式后就真的完全解耦了，其實這是一件好事，但對程序員來說必須要完成這種思維和習慣的轉變。

于邦旭：我對此深有同感。2012 年左右，那時我需要寫一個能實時上報心跳的程序，但當時 ETCD 和 Consul 還不夠成熟，開源領域也不像如今這么火，所以我沒能獲知 ZooKeeper 的存在。當時的我，一般就是寫個代碼然后一直上報，上報之后再去寫大量的程序，然后從數據庫里讀出來、判斷它的狀態、再做后續的判斷。結合陳皓老師和張鑫老師的看法，其實未來我們只需要引入一個云原生的 SDK 進行初始化，甚至可能連初始化都不需要，這一切問題就迎刃而解了。但這同時也會給開發人員帶來一種疑惑：為什么我寫完程序放到云原生平臺后，監控系統那邊的人很容易就能知道我服務的狀態？為什么明明我沒做這個工作，我的應用卻掌握了這個技能？

司徒放：因為我是做云產品這一塊，所以我會看到很多傳統客戶的整個軟件開發過程已經被云原生沖擊得七零八落了。不論是從 CI/CD、運維、監控還是到觀測，整個開發領域在云原生時代下產生了非常巨大的變化和沖擊，也就要求開發者要重新學習，學會推倒重來。同時，變革之下也是機遇，而我相信，云原生帶來的將是未來 10 年都難得一遇的絕好機會。

此外，對許多業務企業來說，一方面云原生確實會給他們帶來沖擊，但另一方面他們也能從中受益：曾經需要自研的部分，如今幾乎可以在開源領域中“唾手可得”。

于邦旭：從我的角度來說，云原生更大的機會是在于幫助一個企業省錢，這個省錢不僅僅是說省資源，更是降低線上損失。曾經，一個公司如果想做在線網站，必須招聘一個優秀的 IDC 運維人員，為此公司還需要幫他對接采購、對接買服務器，包括上架網站和之后的運維工作。但在云計算誕生以后，這個問題完全得到解決：你不需要有專業的 IDC 建設和運維人員，你只需要把應用部署到云原生平臺上，所有工作就都可能由專業的云計算公司來完成。在這一基礎上，企業就可能將優秀的研發人員專門投入到業務層面而非基礎建設，這也就是云原生時代下該抓住的機遇。

“化敵為友”可能并不是夢？

于邦旭：目前阿里云、華為云、騰訊云還有火山引擎都推出了自己的云原生解決方案，未來這幾家云原生是否有可能互通？

陳皓：總體上看來，我覺得不太可能。這些公司都是商業公司，并不中立，他們希望的是用戶能夠留在自己的平臺上。不過從 AWS 發布 EKS Anywhere 可以看出公有云已經感到云原生的壓力了——它賣控制臺，但代碼卻可以運行在私有云里，也就是說 AWS 在這一點上開始中立，在把目前的公有云廠商往下壓，讓用戶得以自建系統。這樣一來對用戶來說，一方面降低了成本，另一方面也擁有了自主可控的能力，不會被云廠商給鎖住。不過即便有這種轉變的態勢，我依舊不覺得他們最終能夠互通。

張鑫：從目前的趨勢來說，互通是一個方向，但問題是誰來做這件事情，是云廠商、獨立第三方還是用戶？我最近看了很多報告：有些美國報告指出現在平均一家美國企業在用 5.2 朵云，但這個云里也包含了他們自己的 IDC；中國信通院最近也有一個調研報告，其中約 58% 的受訪企業表示未來一定要基于混合云。

從商業本質來說，我認為應該是要滿足“互通”這個市場需求的——因為以客戶的角度出發，肯定是希望互聯互通、有彈性，而不是被綁定，所以剩下的就是由誰來完成這件事。從 AWS 發布 EKS Anywhere、阿里發布 ACK Anywhere，可以看出公有云廠商現在都有不同的策略，作為“后來者”的火山引擎來說，我們也希望能做得更開放。

司徒放：云廠商自然是希望開發者、企業和用戶都可以長在自己的云上，盡可能滿足所有人。但我個人認為，用戶的多元化訴求是必然的，這也必定是未來的一個趨勢。

云廠商通常會把 IaaS 這層作為構建產品差異化競爭力的重點，所以會想方設法在計算能力、網絡、存儲等方面盡力提升，但本質上這其實已經被 K8s 標準化了。而對于 PaaS 這層來說，用戶的多元需求不會改變，這在云原生的趨勢下體現得更明顯，所以云廠商會進一步擁抱開源。我們也知道用戶喜歡開源開放，國內開源的環境也越來越好，因此我們也不斷通過貢獻社區、推出一些開放的、與社區兼容的產品等，去推動標準的建立，希望能做得更加中立和開放，也便于用戶遷移過來或離開——個人認為，我們應該貼緊用戶的需求，靠云產品自身硬核實力而不是綁定來留住用戶。

中立的前提：開源開放

于邦旭：未來有沒有可能出現這樣一種情況：有一家公司專門做云原生平臺，但它不做 IaaS，可開發者卻更愿意使用這家公司的云原生標準或把應用托管到這家云原生平臺，最后由這家云原生平臺將其調度到其他家的 IaaS 上？

陳皓：我認為會出現這種公司，但前提是它必須保證開源開放，采用的必須是通用技術，甚至還要把源代碼給到用戶，方便他們對其貢獻。舉個例子，如果阿里云是這樣的公司，那它就要做到允許用戶一鍵遷到騰訊云，這樣才能讓人信服它是開放的。但對于一個商業公司來說，這其實很難。

對于用戶來說，他們的訴求其實也各不相同。有些用戶喜歡體驗非常好的封閉產品，例如蘋果手機，也有些用戶更喜歡自主可控、支持自行修改的開源產品，例如安卓手機。回首過去 20 年皆是如此：要么你的確做得好，我愿意付錢，要么雖然你可能做的不如他好，但你性價比高并且開放。所以這兩種形態一定是會并存的，不存在誰打過誰，即便未來有這么一家公司可能會把 PaaS 這些東西都做得更中立、更標準，但依然會有用戶選擇像阿里云和 AWS 這樣的專有云。

張鑫：這個問題我們公司內部討論的也非常多。作為后發者，我們當時在想，火山引擎要采取一個怎樣的定位，是做一個獨立的純 PaaS，還是一起做 IaaS？后來我個人感覺同時做 IaaS 和一個非常中立的 PaaS 可能不矛盾。

雖然這件事直觀看來用戶肯定不相信，會覺得“你做 IaaS 肯定是希望把我綁在這”、“你又做 IaaS 又做 PaaS，怎么可能是中立的”。但從開放和中立的真正含義上來說，我覺得我們可以做到：

第一，讓用戶今天上得去明天下得來，并且成本很低，令他們覺得安心。

第二，要足夠標準化，不要讓用戶有“我用了你的產品就用不了其他家產品”的擔憂。

第三，要有足夠靈活的可擴展性，甚至開放源碼。

只要 PaaS 層滿足這三個特性，不論有沒有做 IaaS，用戶都能感覺到你是相對開放和中立的。不過這只是一個理想狀態，能不能實現還要看未來。

司徒放：現在可以看到已經有越來越多的云原生產品和平臺出現，很多云廠商包括我們也都在做這方面的東西。剛剛陳皓老師提到能否從阿里云一鍵切換到騰訊云，雖然現階段不管是阿里云還是其他云，大家還不會做這件事，未來要看這件事將來會如何演化，因為最終的出發點都是客戶的訴求。

在阿里云做 PaaS 的人也希望客戶能一直使用下去，所以阿里云 PaaS 是一定會往開放、標準化和開發者友好的方向去做的，只是說現在PaaS的多云形態還沒到那個時候，我們 PaaS 跟 IaaS 的產品集成還有很大提升空間。

自主可控 vs. 方便穩定

于邦旭：現在很多云廠商都提供了標準的服務，但開發者可能更愿意使用一個標準的云平臺把它變成服務化，所以未來云廠商的服務是否會演變成這種形態：開發者只使用云廠商的 IaaS 和 PaaS 能力，而真正的服務形態可能來自更為低價的開源版本？

陳皓：我覺得這種需求是一定會有的，主要出于對以下三個因素的考慮：

第一，成本，這無需多說。

第二，定制化需求。以阿里云 Kafka 為例，它的標準是一致的，或者最多有幾個版本讓用戶選擇，但對用戶來說，有時可能要根據業務場景有所調整，定制化能力就顯得較為重要，而這對云廠商的運維來說又比較困難。

第三，問題響應速度。如果使用的是開源版本，一旦發現問題開發人員就可以立即解決；但如果使用的是云廠商封閉化的標準服務，開發人員則需要給云廠商開工單、解釋問題等，比較影響解決問題的效率。

不過這也存在一個隱患，即如果公司開發人員擁有這些修改權限，也會對應用穩定性產生一定威脅，因此還是需要在功能和穩定性之間進行權衡。

張鑫：這需要根據不同的用戶群體而定。有些企業不想把自身的研發或運維團隊擴建得太大，標準化的云上產品基本也可以滿足業務需求，他們就會選擇商業化服務。也有一些企業更喜歡自主可控，就會出現于老師說的這種情況，這主要有三個原因：

第一，服務響應慢，商業產品完全黑核，自己改不了，有問題只能發工單；

第二，很難結合自己的場景做深度定制和優化；

第三，隨著開源和云原生的出現，自建的成本和門檻都降低了一些。

但這種模式下，用戶往往會需要另外一種服務：有一些互聯網公司希望云就用標準的 IaaS，中間 PaaS 層就基于開源自己搭，但同時他們也希望有一個最佳實踐的技術團隊來進行指導和解決難題。

司徒放：這個現象在云上是十分常見的，我們也有很多客戶是直接拿開源自建。

有些企業相對來說技術實力沒那么強，其實用開源也可以，但真正出了問題之后他們還是往云廠商和云服務遷移，然后這個時候比的就是成本。這種場景下，云產品其實一直在降價，或者說它會提供一些基礎版來匹配這一類用戶。

還有一種擁有很強技術實力的大型公司，他們也有足夠的運維實力，所以如果他們傾向用標準的 IaaS，然后在 PaaS 層自建，這種客戶目前很可能是不會用到阿里云的PaaS，所以有時候為這類企業提供一些最佳實踐的幫助和咨詢更為合適。

在開源的層面上，我認為在開源社區可以一起做相關交流，但未來還是要看人才的流動情況，比如能搞得起 kafka 這種深度問題的人才會有多少？這種人才誰養得起？在這種考慮下，只有云廠商和大公司才能招到這種人才，一般小公司很難招到這種專業人才，所以我認為未來的趨勢應該還是以采用標準云服務為主。

程序員能力提升指南

于邦旭：各位對于工程師和程序員的培養理念是什么？在幫助自家公司程序員的能力提升上有何舉措？

陳皓：首先我招的不算精英，精英我也招不起，我招的是潛力不錯但被其他公司低估的人或者年齡較大其他公司不愿意用的人。

關于程序員能力提升方面，我主要有四個方法：

第一，寫作。所有東西都必須寫下來，寫作是一種深度思考，是一種結構化的表達方式和溝通方式，我認為只要能把東西寫好或者寫得有條理性的人，基本上學習能力都會很強。因為寫作需要做歸納總結，而歸納總結是學習能力中最高級的方式。

第二，所有技術方案都要拿出引用：到底是誰做的？有誰這么用了？最佳實踐是怎樣的？以此驅使他必須去翻很多論文、開源實踐等，這叫“磨刀不誤砍柴工”，因為我最討厭的就是憑經驗做事。

第三，分享。分享也是一種很好的學習方式，我們公司有硬性的分享要求，現在也在對外，因為對外你就會知道你要準備哪些知識。

第四，給予更多挑戰性工作。這就像下棋一樣，你得找個高手才能越下越好。

總體來說，我們公司培養人才就是以上這四個方法，基本在我們公司干一年提升的能力等于在別的公司干五年。

張鑫：我認為在人才培養方面有兩點需要注意：

第一，多參與開源。因為參與開源面對的是整個開放社區和生態，這不僅會迫使我們更好地去提升自己的代碼質量和架構能力，我們還可以從中找到設計很好的代碼或者經驗比較強的人當“師傅”。

第二，做 To B。當企業內部發展平穩后，可以通過 To B 創造更多富有挑戰性的場景，以此推動程序員不斷提升自我能力。

司徒放：阿里在人才培養上不僅關注技術，對商業、對客戶、對產品使用等方面也有一個較為齊全的系統提升。

例如，阿里有“83 行代碼”活動——工程師覺得自己代碼寫得好，就可以把優秀代碼放到一個內網頁面供大家評審；阿里有個不斷更新的開發規約——里面有很多“避坑指南”供開發人員參考；阿里內部有一個 ATA——技術人員會把一些架構方案和設計在內網拋出來，文章質量很高，員工可從中學習；阿里也很推崇開源開放——技術團隊會鼓勵大家去做開源投入相關的事情，并且在開源社區中能學習到很多。

最后作為程序員來說，我有一個感覺挺幸福的點，那就是讓自己的技術有變現的能力。相較于之前只能做一些 PPT 展示技術成果，現在通過 To B、云服務市場，你的產品有人用錢為你“投票”，這種挑戰和成就感是完全不一樣的。

本文來自微信公眾號 “CSDN”（ID：CSDNnews），作者：鄭麗媛，36氪經授權發布。