先來簡單介紹一下這兩者的差別：Azure Functions vs. Service Fabric

• Service Fabric 使用時機：如果應用程式有個服務需要長時間執行，而且執行過程中會有狀態需要保存起來，那麼就選用 Service Fabric。比如說一個 IoT 系統，可能有百萬裝置同時運行，每個 IoT 裝置都是一個 Actor，如此一來，上百萬個 Actor 同時運行，就可以保存各自的狀態在 Service Fabric 之中。
• Azure Functions 使用時機：適合用在需要透過某種事件觸發，或排程自動執行的功能，可以事先寫好 .NET、Javascript、Java 等程式以待執行。所以 Azure Functions 又被歸類為無伺服器架構 (Serverless Architecture)。另一種用法，我們也可把 Azure Functions 視為現有應用程式能力的延伸 (Enabler)。

Service Fabric

Service Fabric 是針對建立雲端原生服務量身打造，適合從小規模單一服務開始，到擴充為成千上萬個服務的規模使用。現今的網際網路級別服務是使用微服務建立，常見微服務範例包括：通訊協定閘道器 (Protocol Gateways)、使用者設定檔 (User Profiles)、購物車 (Shopping Carts)、庫存處理 (Inventory Processing)、佇列 (Queues)、快取 (Caches)。

在架構設計上，我們希望每個執行個體都能獨立管理與升級。這個概念的實現是依靠 Service Fabric 可以部署容器或任何可執行檔作為執行個體，並以執行個體為單位進行管理。常件的執行個體可以部署 .NET、ASP.NET Core、node.js、Windows 容器、Linux 容器、Java 虛擬機器、指令碼、Angular 等。

微服務的架構設計，也成就了軟體循環經濟；寫一次微服務，可以無數次、重複利用地部署到 Service Fabric 上使用。基於 Service Fabric「調整叢集中的節點數目，應用程式也隨之調整」、「監視和診斷應用程式的健全狀況，並設定用來執行自動修復的原則」、「Service Fabric 會從失敗中復原，並會根據可用資源將負載分佈最佳化」等特性，我發覺這套系統背後的演算法，也很適合來建模物質流，因為每一個軟體物件都對應到一個現實物件，每一個軟體物件、微服務都有其功能，就好像每一個現實物件也提供某種功能一樣。那麼把它超細分、再部署、高密度，不就是循環經濟、生生不息、我們所追求的最終態勢嗎？