推動 PaaS 使用超越 12 因素應用程式
重新檢視 PaaS 的通用性
平臺即服務(PaaS)在不斷變革的軟體開發領域中嶄露頭角。從 2006 年的 Force.com 開始,PaaS 已成為龐大的市值高達 1700 億美元的雲端產業中的一支領頭羊,其中包括 Heroku、AWS Elastic Beanstalk 和後來轉型為 Docker 的 DotCloud。然而企業在手動部署和工作負載生命週期管理方面仍然存在挑戰。那麼為什麼平臺即服務沒有被更廣泛地採用呢?
提供 PaaS 體驗跨越所有工作負載
PaaS 平臺可能更加多功能,這裡指的不僅僅是語言和框架的相容性。通常 PaaS 被定義為一站式部署任何應用程式的工具,然而這裡有一個陷阱。這裡所說的應用程式通常指的是 12 因素應用。然而許多工作負載並不那麼適合典型的 Web 應用程式;它們具有獨特的需求,例如批次處理作業、高效能計算(HPC)工作負載、GPU 密集任務、資料中心應用程式,甚至是量子計算工作負載。
需要改變的地方
首先接受 PaaS 範式的企業必須意識到沒有一個適用於所有工作負載的解決方案。前 Google 工程師 Kelsey Hightower 在最近的一次討論中強調了這一點。他用「工作負載 API」來指定一個提供無縫「這是我的應用程式,幫我執行它」體驗的工具。相較於需更精確並且容易導致混淆的平臺即服務(PaaS),他認為這一個術語更為準確。因此企業需要花更多努力,提供跨所有工作負載的無縫部署和管理體驗。
其次對於希望為所有工作負載提供無縫部署和管理體驗的企業來說必須考慮每個工作負載都應該擁有專屬的工作負載 API。例如,Amazon Lambda 可用於批次作業、Vercel 可用於前端、Vertex AI 可用於機器學習模型,Korifi 可用於 Web 應用程式等。因此企業需要審慎選擇工作負載 API。
結語
透過重新思考 PaaS 的通用性,開啟了企業更廣泛地應用 PaaS 的可能性,這無疑會促使技術領域的進步。儘管面臨挑戰,未來的 PaaS 發展值得期待。
延伸閱讀
- LanceDB 攜手 Midjourney 開發多模式 AI 資料庫
- 法國支付 app Lydia 推出行動銀行應用程式 Sumeria
- Triomics 籌集 1500 萬美元 A 輪融資,致力於自動化癌症臨床試驗配對
- Bluesky 即將新增直接訊息、影片支援及應用程式自訂動態訊息推送功能
- 抖音起訴美國政府 因應可能禁用該應用程式的新法律
- 資料科技公司 Daloopa 開發 AI 以自動化財務分析工作
- Kajabi 線上課程平臺現可建立個人品牌應用程式
- 一對 Airbnb 校友將智慧與自動化引入資料保護
- SafeBase 使用人工智慧自動化軟體安全審查
- RPA 供應商如何在 AI 代理人世界保持競爭力