今天看到一篇不錯的 Choosing between Azure Container Service, Azure Service Fabric and Azure Functions 文章，他們摘錄的 Building Microservice Applications with Microsoft Azure 這場 56 分鐘討論的精華，這場討論分別由這三個產品的 PM 聚在一起，把這三個 Azure 服務之間的差異與選用的時機介紹得非常清楚，解決了我許多心中的疑問，以下是我在吸收消化之後的內容分享。
Azure Container Service (ACS)
ACS 讓 DevOps 的實現更加輕鬆，只要將必要的套件與作業系統環境設定封裝在一個容器中，就可以大幅簡化未來系統部署的難題，應用程式在主機與主機之間的移轉也將更加便利與省時，完全不需擔心有任何環境相依性的問題。在 ACS 可以讓你自由選擇不同的 Docker 管理工具 (Orchestrator)，ACS 內建 Docker Swarm、Mesos DC/OS、Google Kubernetes 三種平台可供選擇。
ACS 更加專注在「小型服務」的封裝，且還不到「微服務」的等級，你可以把特定一個服務所有的相依軟體與設定全部封裝到容器中，並透過 ACS 進行管理。你可以這樣想像，你把一個較大的網站，拆解成兩三個不同層級的服務，例如一個 Web 前端層、一個快取層、一個 API 層，其實說穿了還是一個網站，只是拆成三個容器來進行佈署而已，但佈署的時候透過容器技術可以更加彈性的配置，對開發人員與架構師來說相對彈性，也不用修改太多現有的程式或架構。
Azure Service Fabric
Service Fabric 提供了一種完成且成熟的開發模型，告訴你應該如何正確的建置微服務化的應用程式，你可以選擇 Reliable Services 或 Actor Model 開發模型來開發應用程式，此類的應用程式無論是「有狀態的」或「無狀態的」都可以，且應用程式可以更容易做到容錯處理(fault-tolerant)，延展性(Scalibility)也更容易完成。建置多個以微服務架購組成的應用程式，可以讓開發人員擁有更多的彈性配置基礎建設提供的資源，但相對的缺點就是較無法與傳統的應用程式進行整合，必須要大幅的調整程式碼與系統架構。
Service Fabric 有一個很容易判斷的使用時機點，如果應用程式有個服務需要長時間執行，而且執行過程中會有狀態需要保存起來，那麼用 Service Fabric 就對了。Service Fabric 使用 Gateway Pattern 所以多重服務可以自在的運作在 Gateway Hub 後面。舉例來說，一個 IoT 的系統，可能有百萬裝置同時運行，並且會把資料送到 Service Fabric 裡，那麼你的應用程式就可以用 Actor Model 來開發，每個 Actor 就可以代表一個 IoT 裝置，如此一來，上百萬個 Actor 就可以運行在 Service Fabric 之中，並且可以各自保存裝置的狀態在 Service Fabric 之中。相同的例子也可以套用在電子商務類型的應用系統中，例如每個顧客的購物車，就可以各用一個 Actor 來實現。不過 Service Fabric 應用程式最大的優點，應該是可以跑在 on-premise (企業內部) 或 Azure 或任何其他雲端平台。
Azure Functions
Azure Functions 來自 Azure App Service 的 WebJobs，很適合用在需要透過某種事件觸發，或透過排程自動執行的功能，他的開發方式非常簡單，執行環境也幾乎不用設定，你只要把程式寫好，部署到 Azure Functions 上執行，其他甚麼都不用管，也因此 Azure Functions 被歸類為無伺服器架構 (Serverless Architecture)。
如果你的應用程式可能會潛在的執行一段長時間的任務，且需要一個 HTTP 端點可以讓用戶端進行呼叫，程式本身的商業邏輯又不是特別的複雜的話，你是可以選擇 Azure Functions 來實現。你可以把 Azure Functions 視為一個可以延伸你現有應用程式的能力，它支援自訂路由的機制 (跟 Web API 類似)，也支援 Azure AD 與其他認證機制、SSL、自訂域名、RBAC (Role-based access control) 等等，同時也有非常好的 持續整合/持續交付 (CI/CD) 支援。所以如果你正在尋找一個簡易的應用程式開發模型，而且又不想設定或管理過於複雜的 IT 基礎建設，那麼 Azure Functions 是個不錯的選擇。
相關連結