推動 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 發展值得期待。
延伸閱讀
- RPA 供應商如何在 AI 代理人世界保持競爭力
- 智慧 AI 新聞主播「Rio」在應用程式中募集資金
- 蘋果遲遲未刪除偽裝成 RockAuto 的明顯假冒應用程式
- 基於人工智慧時代，Anon 正在打造自動化認證層 - 技術新聞
- 美國政府指出 Chirp Systems 應用程式中的安全漏洞讓任何人遠端控制智慧家居門鎖
- Mood.camera：一款 iOS 應用程式，感知就像使用復古模擬相機
- Meta 將 Llama 3 智慧聊天機器人整合到其應用程式的搜尋欄位
- 全新社交應用 AirChat：會成為下一個 Clubhouse，還是扶搖直上？
- Indaband 推出全新應用程式，讓你和全球的人一起創作音樂
- 科德實驗室 (Kode Labs) 尋求成為商業建築自動化領域的 Salesforce
