无服务器架构的弊端有：1、第三方API系统会导致提供商控制、多租户问题、提供商锁定及安全缺陷等问题；2、缺失操作工具，调试分布式系统的任务非常困难；3、开发人员需要花费大量时间来评估、实施和测试具体功能；4、实施的难度非常高，需要将大量单元加以集成，才能正常完成测试。
下面是详细介绍：
1、第三方API系统导致的问题
提供商控制、多租户问题、提供商锁定以及安全缺陷等，都有可能是由第三方API所导致的问题。在实施API时放弃系统控制可能会导致系统宕机、强迫性API升级、功能缺失、意外限制以及成本变更等后果。此外，多租户问题也存在于其他云计算框架之中。Salesforce（PaaS）就因其多租户云结构而施加了部分监管限制，开发人员在使用Salesforce时一定要要尽可能避免相关问题。具体而言，多租户解决方案往往会在安全性、稳定性以及性能层面存在问题。
2、操作工具缺失
开发人员依赖提供商为其提供调试与监控工具。一般来说，调试分布式系统的任务非常困难，通常需要访问大量的相关指标才能确定产生问题的根本原因。
3、 架构的复杂性
开发人员通常需要花费大量时间来评估、实施和测试具体功能，才能最终决定这些功能应该如何进行细分。一次应用程序调用操作中所涉及的功能数量应该保持平衡。管理太多功能无疑将使问题变得更加复杂化，而忽略粒度将最终导致微服务架构变为“迷你整体”架构。
目前，Lambda（亚马逊网络服务AWS提供的一种计算服务，其能够以一种大规模并行方式执行代码，以响应事件）已经对用户能够在所有lambda表达式上运行的并发执行总数作出了限制。其中的问题在于，这个限制是适用于整体AWS帐户的。一些组织会使用相同的AWS帐户进行生产及测试。这就意味着，如果组织中的某位工作人员着手进行一项新的负载测试，并尝试执行1000个并发Lambda函数，那么生产应用程序将立即遭遇拒绝服务（DoS）状况。
4、实施的困难性
集成测试无服务器应用程序的难度非常高。与其他体系机构相比，无服务器FaaS（即每项功能）的集成单元要小得多，因此我们需要将大量单元加以集成，方能正常完成测试。此外，也存在一些与部署、版本控制和打包相关的问题。大家可能需要为整体逻辑应用程序中的每项功能单独部署一项对应的FaaS组件。这也就意味着，您不能以原子性方式对一组功能进行统一部署，而由于不存在版本化应用程序的概念，所以原子回滚（atomic rollback）也无法实现。这样的话，您可能需要关闭任何触发相应功能的事件源、部署整体功能组，然后再重新启动事件源。
