前言

[Azure 筆記] 前言

---

原文

Compare Azure Functions hosting options

---

Hosting Options

Azure 為 Function Apps 提供了幾種 hosting options (或稱作 hosting plans)
不同的 Hosting options 在下列方面都有不同
你可以依需求選擇合適的 Hosting options

• Function app 的 scale 方式
• 每個 function app instance 可用的資源
• 支援的進階功能，例如 Azure Virtual Network connectivity
• 是否支援 Linux containers
• 成本

下面是 Azure 有提供的 hosting options

Hosting option	Service	Availability	Container support
Consumption plan	Azure Functions	Generally available (GA)	None
Flex Consumption plan	Azure Functions	Preview	None
Premium plan	Azure Functions	GA	Linux
Dedicated plan	Azure Functions	GA	Linux
Container Apps	Azure Container Apps	GA	Linux

不同的 hosting options 各有優點
我們就一起來看看它們的特點吧

　

Consumption plan

這是預設的 hosting options
只有當你的 function 在運行時才會計費 (pay-as-you-go)
同時也支援 automatic scale
Instance 的數量會隨着 incoming events 的數量而改變

　

Flex Consumption plan

這和 consumption plan 類似
但提供了更多的選項讓用戶可以更靈活的控制 automatic scale

同樣的
這個 plan 是 pas-as-you-go 和支援 automatic scale 的

同時
這個 plan 支援 virtual networking
也支援戶用設置 per instance concurrency
也就是單個 instance 同時處理多少個 event 的數量
Azure 會跟據這個數值以及 incoming events 的數量來改變 instance 的數量 (automatic scaling)

此外，用戶也可以設置 pre-provisioned(always ready) instance 的數量來減少 cold start

　

Premium plan

這個 plan 支援 prewarmed worker
因而可以在 idle 後沒有延遲的執行應用程式

也可以使用更強大的 instance
以及連接到 virtual network

在下列情況時可以考慮使用 premium plan

• 你的 app 會被持續的，或是近乎持續的執行
• 想要更細緻的控制 instance 並想在單一使用 event-driven scaling 的 plan 中 deploy 複數的 function app
• 有大量的低資源消耗的運算，有高的執行次數但是 GB seconds 較低
  • GB seconds 是 cloud computing 的一種計價方式
    計算的方法是以佔用的 RAM 的量乘以時長
    如果應用程式佔用了 2 GB 的 RAM 運行了 10 秒
    那麼資源的使用量就是 20 GB seconds
• Consumption plan 所能提供的 CPU 及 memory 未能滿足你的需求
• 您的程式代碼執行時間超過 consumption plan 所允許的運行時間上限
• 你需要 virtual network connectivity
• 你需要使用 custom Linux image

　

Dedicated plan

按照常規的 App Service 計劃費率來計費
如果你需要長時間執行你的程序
而又不能使用 Durable Functions
那這個 plan 就是你的最佳選擇

如果符合以下使用場景的話
請考慮使用這個 plan

• 你需要準確的預計收費
• 你需要手動對 instance 進行 scaling (指的應該是 scale in / out)
• 你需要在同一個 plan 運行複數的 web apps 或 function apps
• 需要更大的 compute size 選項 (指的應該是更多的 CPU 和 RAM)
• 需要 App Service Environment (ASE) 提供的 full compute isolation 和 secure network access
• 需要 ASE 提供的高記憶體用量(high memory usage)和高擴展性(high scale)

　

Container Apps

你可以在 Azure Container Apps 中創建及部署環境完全受控的 containerized function apps

你可以把你的 function 和其他的 microservices, APIs, websites, workflows 一起執行為一個 container-hosted programs

在下列的情況請考慮使用 Container Apps

• 你想要把 custom libraries 和你的 function code 打包在一起
• 你需要將 code execution 從本地（on-premises）或舊版應用程序（legacy apps）遷移到 cloud native 並在 container 中運行的 microservice
• 你想要避免管理 Kubernetes clusters 的複雜性
• 你需要高端的處理能力(high-end processing power)

---

Function app timeout duration

在 host.json 這個 project file 中
有一個名為 functionTimeout 的屬性設置了 function app 的 timeout duration
若你的 function 未能在這個指定的時間內 return / response
那就會觸發 timeout

下列是不同的 plan 的 timeout duration 的預設值和上限值 (單位為分鐘)

Plan	預設值	上限值1
Consumption plan	5	10
Flex Consumption plan	30	Unlimited3
Premium plan	302	Unlimited3
Dedicated plan	302	Unlimited3
Container Apps	305	Unlimited3

這是上面表格的上標數字的相應註解

1. 不論你設置了什麼數值，230 秒就是 HTTP triggered function 能花費的時間上限
2. version 1.0 的 Function 預設值是 Unlimited
3. 保證能運行 60 分鐘，此時間段外可能會因下列因素而被中斷
   • OS and runtime patching
   • vulnerability patching
   • scale in behaviors
4. Flex Consumption plan 不會強制執行這個時間限制，但其運行仍有可能因下列因素而被中斷 (注：目前沒有找到其他官方文件印證這句)
   • scale-in
   • deployments
   • apply updates
5. 當 replica 的數量下限為 0，預設的 timeout 就會因應 trigger 的種類而不同 (就目前能找到的資料來看，應該是只適用於 Container Apps)

---

Reference

https://learn.microsoft.com/en-us/azure/container-apps/scale-app?pivots=azure-cli