相对于传统的服务器应用程序，基于FaaS的应用程序通常在模块功能上的设计相对单一，不同的功能往往分割到不同的云函数中处理，模块内聚程度相对较高。不同功能模块之间通过触发器来相互触发调用，功能模块之间的耦合度非常低。一个个高内聚低耦合的云函数非常有利于团队合作开发，也非常有利于后期的功能维护和缺陷定位。

每个云函数运行后通常都不能保留自己的运行状态和内存数据(静态变量有一些情况下会在同一个实例的不同调用周期间共享)，因此每个实例启动的时候面对的是一个一致的干净的初始状态，不需要考虑历史状态的处理和维护。

由于云函数运行的容器由云服务提供商维护，因此FaaS的开发者一般不需要面对服务器运维、扩缩容等繁杂的事务(即使在访问压力超过了默认上限的情况下，往往也只需要提交工单申请提升上限就可以实现扩容)，而且服务的安全性和稳定性相比自己维护服务器要高得多。

FaaS的一个劣势是冷启动带来的延迟问题。如果一个触发事件到来的时候，服务容器中没有可以立刻响应的实例，容器就需要启动新的代码实例来响应，根据服务商能力等不同，这个过程通常有毫秒级到秒级的延迟。各个云服务商都在通过优化淘汰策略和规则等手段独立降低冷启动率，而对于延迟非常敏感的业务，用户通常也可以用预热请求的方式来确保代码实例常驻在容器中，比如用定时器触发代码实例进行一个非常快的空响应。

FaaS的其他劣势包括语言版本落后(云服务商通常只提供最流行的几种开发语言的最稳定的几个运行环境)、依赖服务商提供的借口和周边产品能力带来的服务迁移困难等。

对于企业用户来说，FaaS相比传统的服务器架构有更浅的技术栈深度和更缓的学习曲线，这有利于团队提升效率，降低人力成本。而FaaS架构的一个劣势是难以进行传统的状态管理。因为FaaS架构的高度可扩展性意味着每个应用都随时会被创建出来新的实例或者销毁掉存在的实例，而实例不能长久地占有内存空间，因此要提供有状态的服务就必须要和独立的存储服务进行交互，这往往会增加服务延迟，导致占有了CPU和内存等资源却难以高效地利用。

因此Serverless应用一般不通过会话(Session)认证用户身份，而是采用Json Web Token(JWT)之类的无状态身份验证机制来代替Session身份验证。