We DO FaaS
sites • September 9, 2020
We DO FaaS
從上可以看出幾個重點：Serverless 是「事件驅動」（event-driven），由第三方服務（third-party services）、客戶端邏輯（client-side logic）與在雲端上的遠端程序呼叫（cloud-hosted remote procedure calls）所組成。這第三個組成的元素就是 FaaS。
FaaS 的幾個特性
就是個函式（independent, sever-side, logical functions）
名如其實，functions 就如同我們會在程式碼裡面寫的 functions，獨立、分離、自成一格。
無狀態（stateless）
每個請求都是獨立的。每次執行不會受到之前的執行內容/結果影響。任兩次對同一個 function 的呼叫可能會可能會在完全不同的容器（container）裡面執行。
來得很快，去得也快（ephemeral）
FaaS 隨叫隨開，並且做完了任務就馬上關掉，需要的啟動時間與關機時間都非常的短（尺度是毫秒）。
事件驅動（event-triggered）
雖然 functions 可以直接被取用，它們通常會從其他雲端服務被觸發，像是 HTTP 請求或是內部訊息通知。FaaS 比較常被使用的情境是雲端環境中各服務之間的橋樑。
擴展性高（scalable by default）
你可以一次啟動好幾個 container 來同時呼叫同一個 function。就算同意時間有很多的請求（incoming request）也不怕。
CloudFun Dairy
Cloud Computing Solution
從企業的角度來看 Serverless 最大的優勢就是降低成本，這篇文讓我們看到可口可樂因此省了多少錢。Serverless 可以真的做到「按件計酬」—當沒有使用的時候就沒有花費，這也是它跟 PaaS 最大的不同之處，因為 PaaS 不會因為一個事件而開啟整個應用程序又結束，但是 FaaS 可以做到。不過，如果你的應用程式結構複雜並且會長時間運行，那麼使用 Serverless 不會幫你省到什麼費用。 Serverless 最適合的情境是是不固定、落差大的需求量（spiky demands）。 Serverless 省錢方便的好處也有它的犧牲，由於許多工作都交給了第三方管理，所以企業對產品整體的控制權會減弱，也會有安全性、災後回復的風險。 從開發人員的角度來看 Serverless 可以將維運的負擔降到最低（比如說，不需要為不同的環境設定不同的機器），並且它與 Nanoservices, Microservices, SOA (Service-Oriented Architecture) 的概念是天作之合。同時，由於 FaaS 的高伸縮性，同時併發的請求們（concurrent requests）再也不是難題。 然而，由於 Serverless 還算是一個新的技術，再缺乏有經驗的人的引導之下，可能會導致個元件的碎片化（component fragmentation）、增加整以架構的複雜程度（complex ≠ complicated）還有增加測試的困難。 Serverless 也不是適合所有的架構。當你的應用程式依賴了很多第三方套件（3rd Party Dependencies），那麼表示當你打包這個應用程式時，它會變得很巨大，就不能發揮 FaaS 輕便簡潔的優勢了。
