相對于傳統(tǒng)的服務(wù)器應(yīng)用程序，基于FaaS的應(yīng)用程序通常在模塊功能上的設(shè)計相對單一，不同的功能往往分割到不同的云函數(shù)中處理，模塊內(nèi)聚程度相對較高。不同功能模塊之間通過觸發(fā)器來相互觸發(fā)調(diào)用，功能模塊之間的耦合度非常低。一個個高內(nèi)聚低耦合的云函數(shù)非常有利于團隊合作開發(fā)，也非常有利于后期的功能維護和缺陷定位。

每個云函數(shù)運行后通常都不能保留自己的運行狀態(tài)和內(nèi)存數(shù)據(jù)(靜態(tài)變量有一些情況下會在同一個實例的不同調(diào)用周期間共享)，因此每個實例啟動的時候面對的是一個一致的干凈的初始狀態(tài)，不需要考慮歷史狀態(tài)的處理和維護。

由于云函數(shù)運行的容器由云服務(wù)提供商維護，因此FaaS的開發(fā)者一般不需要面對服務(wù)器運維、擴縮容等繁雜的事務(wù)(即使在訪問壓力超過了默認(rèn)上限的情況下，往往也只需要提交工單申請?zhí)嵘舷蘧涂梢詫崿F(xiàn)擴容)，而且服務(wù)的安全性和穩(wěn)定性相比自己維護服務(wù)器要高得多。

FaaS的一個劣勢是冷啟動帶來的延遲問題。如果一個觸發(fā)事件到來的時候，服務(wù)容器中沒有可以立刻響應(yīng)的實例，容器就需要啟動新的代碼實例來響應(yīng)，根據(jù)服務(wù)商能力等不同，這個過程通常有毫秒級到秒級的延遲。各個云服務(wù)商都在通過優(yōu)化淘汰策略和規(guī)則等手段獨立降低冷啟動率，而對于延遲非常敏感的業(yè)務(wù)，用戶通常也可以用預(yù)熱請求的方式來確保代碼實例常駐在容器中，比如用定時器觸發(fā)代碼實例進行一個非?？斓目枕憫?yīng)。

FaaS的其他劣勢包括語言版本落后(云服務(wù)商通常只提供最流行的幾種開發(fā)語言的最穩(wěn)定的幾個運行環(huán)境)、依賴服務(wù)商提供的借口和周邊產(chǎn)品能力帶來的服務(wù)遷移困難等。

對于企業(yè)用戶來說，F(xiàn)aaS相比傳統(tǒng)的服務(wù)器架構(gòu)有更淺的技術(shù)棧深度和更緩的學(xué)習(xí)曲線，這有利于團隊提升效率，降低人力成本。而FaaS架構(gòu)的一個劣勢是難以進行傳統(tǒng)的狀態(tài)管理。因為FaaS架構(gòu)的高度可擴展性意味著每個應(yīng)用都隨時會被創(chuàng)建出來新的實例或者銷毀掉存在的實例，而實例不能長久地占有內(nèi)存空間，因此要提供有狀態(tài)的服務(wù)就必須要和獨立的存儲服務(wù)進行交互，這往往會增加服務(wù)延遲，導(dǎo)致占有了CPU和內(nèi)存等資源卻難以高效地利用。

因此Serverless應(yīng)用一般不通過會話(Session)認(rèn)證用戶身份，而是采用Json Web Token(JWT)之類的無狀態(tài)身份驗證機制來代替Session身份驗證。