敏捷開發與無伺服器：Functions、Logic Apps 與 App Service 的分工

我看過太多次同一個場景：一支排程程式，用 Functions 寫得很痛苦，因為它其實只是在串五個 SaaS 的 API。也看過反過來的，用流程設計工具硬拼出一套資料轉換，維護的人看到那張圖就想離職。

選錯不是因為不懂技術，是因為沒有先把問題問清楚。這篇要把 Functions、Logic Apps 與 App Service 三者的分工講明白，順便交代 2026 年這三邊各自的變化。

這三個服務最常見的誤用，不是選錯服務，而是根本沒先把「我要解決的是什麼形狀的問題」問出來。

先問問題，再挑服務

把三者放在一起比功能，很容易越比越亂，因為它們的功能確實有重疊。比較有效的做法是倒過來，先問你手上這件事長什麼樣子。

官方文件裡有一句話很適合當口訣：Azure Functions 是程式碼為先，Azure Logic Apps 是編排為先。這句話能解掉大概八成的選型爭論。

Azure Functions：事件驅動的運算單位

Functions 的核心概念只有兩個：觸發程序決定什麼時候跑，繫結決定資料從哪來、往哪去。你寫的那段程式碼被夾在中間，不必自己寫連線與輪詢。

{
  "bindings": [
    { "type": "queueTrigger", "direction": "in",  "name": "msg" },
    { "type": "blob",         "direction": "out", "name": "result" }
  ]
}

上面只是結構示意，重點在形狀：一個進來的觸發、若干個進出的繫結。真正會影響你系統行為的，其實是託管方案。

託管方案決定了一切

同一份程式碼，放在不同的託管方案上，伸縮方式、冷啟動、逾時上限與網路能力都不一樣。官方文件在 2026 年 8 月的版本裡列出這幾個選項。

Flex Consumption 值得單獨提一句：它的伸縮決策是以函式為單位計算的，同一個應用裡不同觸發類型會落在各自的執行個體上，而不是整包一起長大。

Logic Apps：把流程從程式碼裡搬出來

Logic Apps 的價值不在「不用寫程式」，而在「流程本身變成一份可以被讀、被審查、被版控的定義」。一年後接手的人看得懂那張圖，這件事的價值很難被高估。

它的另一個現實優勢是連接器。官方文件寫的是超過一千四百個現成連接器，涵蓋 Azure 服務、Office 365、資料庫、SAP 與 IBM MQ 這類企業系統，以及 FTP 與 SFTP 檔案分享。

• 內建連接器：直接跑在 Logic Apps 執行階段上，吞吐量與效能較好，也用來控制流程結構與處理資料。
• 受管連接器：由微軟託管、跑在 Azure 上的服務包裝層，多數使用前要先建立連線並驗證身分。
• 企業整合能力：整合帳戶可存放交易夥伴、合約、結構描述與對應，支援 AS2、EDIFACT、X12、RosettaNet 等 B2B 協定。
• 寫程式的空間還在：Standard 的工作流程裡可以直接跑 JavaScript、.NET 程式碼、C# 指令碼與 PowerShell 指令碼。

2026 年的 Logic Apps 多了一個身分

這兩年 Logic Apps 明顯往代理程式的方向長。除了原本的自動化流程，它現在也被拿來當作 AI 代理程式的編排層與工具層。

• Agent loop：讓工作流程的動作變成代理程式可以呼叫的工具，先在 Standard 正式推出，之後也擴到 Consumption。
• 對話式代理程式：以通道的形式讓代理程式透過入口網站或自訂聊天用戶端與人互動。
• Logic Apps MCP 伺服器：把既有的工作流程直接開成 MCP 相容的工具，讓代理程式可以探索與呼叫，於 2026 年 Build 宣布正式推出。
• Logic Apps Automation：把工作流程、代理程式、知識服務與模型存取打包成受管的 SaaS 體驗，於 2026 年 Build 以公開預覽推出。

App Service：現代化的 Web 託管

App Service 的定位單純：託管以 HTTP 為基礎的 Web 應用，基礎設施維護、安全修補、伸縮與診斷工具都內建。它不是拿來跑事件處理的，是拿來讓一個服務長期在線的。

架構上要記住一個邊界：應用被歸在 App Service 方案這個邏輯運算邊界裡，同一個方案內的所有應用共用配置到的運算、記憶體與儲存空間。

2026 年這一側的關鍵字是現代化與代理程式化。Premium v4 方案建立在較新一代的虛擬機硬體上，Isolated v4 於 2026 年 Build 在 App Service 環境 v3 上宣布正式推出。

• Easy AI：讓既有的 Web 應用不必重新架構就能變成代理程式可用的端點，2026 年 Build 時標示為預覽。
• 內建 MCP 支援：把 App Service 上的應用直接開成 MCP 端點，同場宣布，標示為預覽。
• App Service Managed Instance：Build 2026 時仍為預覽，之後官方另有正式推出的公告，導入前請確認最新狀態。
• 部署與工具改善：更明確的部署錯誤訊息、更快的 Python 部署管線、FastAPI 自動偵測等，宣布為正式推出。

三者何時該用誰

最後補一句實務經驗：這三者在同一個方案裡共存是常態，不是設計失誤。常見的組合是 Logic Apps 負責編排與對外整合，中間需要算東西的那幾步呼叫 Functions，對使用者的介面留在 App Service。

真正該避免的不是混用，而是拿錯工具解錯問題：用程式碼硬拼流程，或用流程圖硬拼演算法。