供應商控制、多租戶問題、供應商鎖定以及安全缺陷等，都有可能是由第三方API所導致的問題。在實施API時放棄系統控制可能會導致系統宕機、強迫性API升級、功能缺失、意外限制以及成本變更等后果。此外，多租戶問題也存在于其他云計算框架之中。

 

Salesforce(PaaS)就因其多租戶云結構而施加了部分監管限制，開發人員在使用Salesforce時必須要盡可能避免相關問題。具體而言，多租戶解決方案往往會在安全性、穩定性以及性能層面存在問題。

 

2. 操作工具缺失

 

開發人員依賴供應商為其提供調試與監控工具。一般來說，調試分布式系統的任務非常困難，通常需要訪問大量的相關指標才能確定產生問題的根本原因。

 

3. 架構的復雜性

 

開發人員通常需要花費大量時間來評估、實施和測試具體功能，才能最終決定這些功能應該如何進行細分。一次應用程序調用操作中所涉及的功能數量應該保持平衡。管理太多功能無疑將使問題變得更加復雜化，而忽略粒度將最終導致微服務架構變為“迷你整體”架構。

 

目前，Lambda已經對用戶能夠在所有lambda表達式上運行的并發執行總數作出了限制。其中的問題在于，這個限制是適用于整體AWS帳戶的。一些組織會使用相同的AWS帳戶進行生產及測試。這就意味著，如果組織中的某位工作人員著手進行一項新的負載測試，并嘗試執行1000個并發Lambda函數，那么生產應用程序將立即遭遇拒絕服務(DoS)狀況。

 

4. 實施的困難性

 

集成測試無服務器應用程序的難度非常高。與其他體系機構相比，無服務器FaaS(即每項功能)的集成單元要小得多，因此我們需要將大量單元加以集成，方能正常完成測試。此外，也存在一些與部署、版本控制和打包相關的問題。大家可能需要為整體邏輯應用程序中的每項功能單獨部署一項對應的FaaS組件。這也就意味著，您不能以原子性方式對一組功能進行統一部署，而由于不存在版本化應用程序的概念，所以原子回滾(atomic rollback)也無法實現。這樣的話，您可能需要關閉任何觸發相應功能的事件源、部署整體功能組，然后再重新啟動事件源。

 

無服務器架構是架構領域出現的一種激動人心的新變化，隨著開發人員積極采用 AWS Lambda 等計算服務，這種架構會更為迅速地發展起來。如今，一些無服務器應用程序支持成千上萬個用戶，并執行復雜的操作，包括處理繁重任務，比如視頻編輯和數據處理。在許多情況下，無服務器架構可獲得比傳統模式更好的效果，而且實施起來成本更低、速度更快。但是對于上文所述的有關這種架構的弊端也必須予以高度重視，并努力尋找解決方案應對上述弊端，以推動無服務器架構更加安全、穩定的發展。