Serverless and Microservices

探討Serverless和 Microservices有什麼不同或者異同，可以從三個面向來看: Infrastructure, Architecture, and Applications.

Infrastructure

Microservices並不關心這面向，但是Serverless本質上是FaaS。如同下圖，這對於DevOps和程式開發人員，有會很大的不同點，尤其是在思考 scale 和 state 的存放，會影響到程式開發的邏輯設計。

來源: Ali雲

Architecture

90% Serverless的架構設計，都是Event Driven Architecture (EDA)。Google cloud function的首頁，立刻說明 Lightweight Event-based Microservices。

Microservices的軟體架構實踐有很多種手法，Event Driven Architecture (EDA) 只是其中的一個手法。

但這邊需要特別強調一件事，EDA的架構設計的中心是以Event為主，第一個Priority是回應 Event 事件，the source of truth 是 the log of events。這和我們習慣的 Data Centric 的架構是不同的。

舉例來說，你對著 Amazon Echo 說，請幫我下訂單買娃娃屋。EDA的架構是先回應：是的，我收到你的需求了。你不希望等 Echo 把訂單下好 1 分鐘後才回應吧??

EDA的 source of truth 是 events log，因此要考慮到Events重複，失敗，重送，順序性等等的問題。在這架構下，Queue Services扮演了很重要的角色。

Applications

Microservices在軟體應用層扮演了很重要的角色，一個 Microservices 背後可能包含一個到多個的 serverless function calls。

以Amazon的Mobile網頁為例

source:nigx

這頁面包含了購物車的Item數目，使用者對這商品Review的星等，商品的主要訊息，推薦相關的商品，庫存資料，和運送資訊。如果以傳統的寫法，可能透過Middleware，去資料庫不同的Table把相關的訊息拿出來後，在全部回給mobile client。

如果透過Microservices的架構，可能會用到下面的服務:

• Shopping Cart Services: 提供購物車Item數量
• Order Services: 提供 order history
• Catalog Services: 提供商品主檔訊息
• Review Services: 商品星等
• Inventory Services: 商品庫存
• Shipping Services: 商品運送方法
• Recommendation Services: 推薦相關商品

這樣 Mobile client需要與很多的Microservices溝通，例如 servicesName.api.company.com，變得 mobile client與services之間沒有辦法 loose couple。如果各個的 services api還用了不同的protocols或者是認證，cache的機制不同，如下圖:

source:kong

因此在軟體應用層上，需要一個 "Mediator" 扮演這樣的角色，因此會看到 API Gateway：去統整這些 microservices的溝通，也讓 API 的管理能夠一致。

而且 API Gateway可以沿用舊的 uri:/ProductDetails=xxx 的介面，把後面相關的 microservices 給封裝起來。

目前AWS APIGateway提供了AWS Lambda functions的功能，所以後面的Microservices不在侷限於 EC2 了，可以透過 FaaS 的方式去提供。