六月，Kubernetes 慶祝十歲生日。該系統現已被全球數十萬家公司廣泛使用，以擴展其應用程式以滿足需求，甚至很難記住它存在之前的時間。但曾經有一段時間，還有其他的選擇，我甚至記得使用過其中的一些。
儘管已經相對成熟，許多大型開發團隊和公司仍然尚未開始遷移到Kubernetes，或正處於遷移過程中。但對於許多喜歡生活在邊緣的開發者來說，一項技術的10 年是一段很長的時間，也許對他們來說，Kubernetes 和整個「雲端原生」精神甚至感覺有點「厭倦」。
3 月在巴黎舉行的KubeCon EU，這也許是我參加過的歐洲最大、最好的KubeCon，我請歐洲雲原生思想領袖考慮雲原生的未來可能會怎樣，或者有什麼可以取代它。
更好地控制託管
除了Kubernetes，三大雲端主機（亞馬遜、Google和微軟）是雲端原生運算的催化劑。過去，他們最初的一大賣點是靈活的、基於使用情況的計費，並承諾為那些需求高峰的可擴展工作負載節省資金。但這並不一定對每個人都是如此，在KubeCon 上，轉向更傳統的主機是一個明顯的趨勢，三個大型歐洲主機（來自法國的OVHcloud 和Scaleway 以及來自英國的CIVO）擁有大量出現在展廳。
Civo的技術長Dinesh Majrekar提到，Broadcom最近收購VMWare可以為小型主機和對資料更敏感的企業客戶（例如歐洲的客戶）提供許多機會。正如Majrekar 所說：“我們能夠使用您自己的硬體在您自己的資料中心本地部署託管的企業級公有雲版本，並讓這些客戶能夠以VMware 方式使用虛擬機，這將非常有趣。”
最初，博通宣布了一項重大的定價變化，引起了許多現有客戶的擔憂。然而，在歐盟的多次投訴和調查之後，博通取消了其中一些變更。所以它為這些小型主機帶來多少業務現在還有待觀察。
一次寫，一次運行成為現實
程式設計師長期以來一直夢想著編寫一次程式碼並讓該程式碼在所有作業系統和平台上平等地運行。從Java 到Electron、Flutter 等，數十年來，開發人員一直在努力創造技術來實現這一理想。
WebAssembly（也稱為WASM）最初由Mozilla 於2017 年創建，已迅速成為Web 標準並受到所有主要Web 瀏覽器的支援。它允許C++ 和Rust 等編譯語言在瀏覽器中運行應用程式。又是Java Web 小程式了
在瀏覽器（客戶端）中運行編譯程式碼的能力非常有趣，但最近的發展使得WASM 相對於雲端原生更有趣。一些開源專案和公司正在使用WASM 來運行伺服器端，例如WasmEdge 和SpinKube，這為容器、在Kubernetes 上運行的隔離應用程式和依賴單元帶來了有趣的競爭。
WASM 提供了一種替代方案，無需擔心建立和維護安全且最佳化的容器來運行應用程式服務（它們會帶來無數的複雜性）。該服務作為編譯的二進位檔案運行，包括所有依賴項。由於WASM 的預設安全方法，它比容器更有效率且更不易受到攻擊，因為容器可能透過依賴項和錯誤配置而遭受數十（甚至數百）次漏洞。這並不意味著WASM 將取代Kubernetes。相反，它可能會取代Kubernetes 通常編排的容器。 Kubernetes 仍將管理擴充、部署等。
Civo 現在提供兩種在Kubernetes 服務上託管WASM 有效負載的選項：Fermyon Spin 和WASMedge。
Civo 的技術長Dinesh Majrekar 告訴我：“我們希望支援其他公司不支援的新技術，跟上它們的發展步伐，並允許客戶部署它們。”
芬蘭Aiven 的開發人員倡導者Sébastien Blanc 也認同WASM 是「下一個大事件」的觀點，並補充說他「押注於WebAssembly」。
開放基礎設施基金會的總經理 Thierry Carrez也同意這一觀點，該基金會負責監督堆疊中的專案並創建和管理資料中心基礎設施。
「我覺得容器作為計算單元將會發生變化，」卡雷茲說。 「至少會有多種選擇。 人們意識到虛擬機器在很多方面仍然做得更好。WebAssembly 在其他一些事情上做得更好，所以它會在容器上吃一點。 不過，我不確定我們是否會結束雲端原生趨勢。
Civo 的Dinesh 也提到，WASM 能夠遠端、本地或在裝置上運行相同的程式碼，為開發人員提供了有趣的可能性，可以將應用程式工作負載跨裝置去中心化到最需要的地方，遠離中心化伺服器。這正是邊緣運算對汽車、智慧型裝置和小型運算設備的承諾，這些設備正在世界各地慢慢普及。這些設備處理自己的小負載，但仍需要偶爾檢查其他地方託管的服務以進行更新以及發送和接收資料。
WASM 並不適合所有任務，允許有效負載與資料庫等外部服務進行通訊的方法仍在開發中。作為一項即將被廣泛採用的技術，它絕對值得研究和關注。
平台佔據中心舞台
在10 年的歷史中，Kubernetes 和雲端原生已經變得異常複雜。開發人員和實施人員將抽象層層疊加，試圖使基礎設施和服務的創建和維護更加易於管理和靈活。
這導致了「平台團隊」的整體趨勢，它幫助建立內部自助服務工具，其他團隊可以使用這些工具以受控方式創建和部署短期和長期基礎設施和服務。雖然這種有時被稱為「內部開發人員平台」的想法已經獲得了關注，尤其是在大公司內部，但並不是每個人都有資源將創建一個正常運作的平台團隊所需的所有部分整合在一起，因此很自然地，SaaS 公司應運而生，以填補這一空缺。那個差距。
「內部開發者平台」一詞是歐洲發明，由德國Humanitec 創造，與其密切相關的前身「服務目錄」也是由瑞典Spotify Backstage 團隊創造的。 Humanitec 的技術長Chris Stephenson 是建構Kubernetes 前身「Borg」的Google 團隊的一員。
隨著平台概念的發展，一些公司已轉向為內部團隊提供工具。德國的Giant Swarm 就是這樣的公司之一。他們是雲端原生的相對資深人士，我認識他們已經將近十年了。該公司目前正在開發他們所謂的產品“3.0”，旨在為開發團隊提供他們運作和創作工作所需的東西。
正如Giant Swarm 工程副總裁Joe Salisbury 告訴我的那樣：「我們希望幫助平台團隊專注於能力並專注於應用程式團隊，我們全力照顧基礎設施。他們不需要過多考慮Kubernetes 升級或圍繞監控或可觀察性的主要基礎設施。
通常，平台即服務提供者的幕後是基礎設施即程式碼工具，例如Terraform。 Terraform 由HashiCorp 創建和管理，自成立以來一直開源，去年它停止開源開發並更改許可證以停止任何商業化，引起了一系列爭議。這導致貢獻者社群迅速努力創建“OpenTofu”，並且有幾家公司已經在此基礎上創建了產品。
OpenTofu 的核心貢獻者兼Scalr 執行長Sebastian Stadil（提供OpenTofu 的可擴展SaaS 版本）解釋了該專案迄今為止的成功：
「自從OpenTofu 分叉創建以來的10 個月裡，已經形成了一個由Terraform 兼容的工具和項目組成的生態系統，包括Scalr、Terragrunt 和Infracost。”
隨著興趣的增長，越來越多的公司加入這個領域，我詢問Humanitec 的產品和成長副總裁Luca Galante，他們如何看待平台工程的當前狀態——Humanitec 在某種程度上幫助創建了這個術語。
「我們沒有發明平台工程，但我們確實給它起了一個名字，」加蘭特說。 「我們將繼續塑造這種敘事。我們透過思想領導文章、與從業者定期舉行的網路研討會以及我們的線上會議 PlatformCon 來實現這一目標，去年有22,000 名與會者，我們預計今年將有35,000名與會者。
對於雲端原生潛在的遙遠未來，Luca 提出了與人工智慧相結合的基礎設施持續抽象的想法。模型可以了解您對開發人員平台的特定需求，並根據簡單的提示或要求智慧地創建它們。許多年前，GitHub 提出了「ChatOps」的想法，但由於當時的聊天機器人能力不夠，這種做法失去了青睞。但現在，我們正與AppCD 等公司一起快速進入基礎設施即程式碼的生成式人工智慧新時代。
10年後
Kubernetes 和雲端原生，從人工智慧到智慧城市，從電子商務到重要基礎設施，為其他領域的創新提供動力。當用戶已經創新時，它還需要創新嗎？或者它（大部分）在後台默默工作是否足夠？我進入KubeCon 尋找未來巨大的變化，但實際上，情況永遠不會如此。
它支援的工作和有效負載將會改變，開發人員和工程師想要使用它的方式和地點也會改變。但隨著Kubernetes 及其相關技術現在在我們的工作流程中如此根深蒂固，我認為至少還需要10 年才能讓其當前用戶群的一半轉向最新的熱門新趨勢。
生日快樂，Kubernetes，還有更多的人。
資訊來源：由0x資訊編譯自THENEXTWEB。版權歸原作者所有，未經許可，不得轉載
