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

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

由于云函數運行的容器由云服務提供商維護，因此FaaS的開發者一般不需要面對服務器運維、擴縮容等繁雜的事務(即使在訪問壓力超過了默認上限的情況下，往往也只需要提交工單申請提升上限就可以實現擴容)，而且服務的安全性和穩定性相比自己維護服務器要高得多。

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

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

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

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