传统的互联网APP主要采用C/S架构，服务器端需长期维持业务进程来处理客户端请求，并调用代码逻辑完成请求响应流程。而在Serverless架构中，应用业务逻辑将基于FAAS架构形成独立为多个相互独立功能组件，并以API服务的形式向外提供服务；同时，不同功能组件间的逻辑组织代码将存储在Amazon Lambda，Azure Function，Google Cloud Functions等产品上，业务代码仅在调用时才激活运行，当响应结束占用资源便会释放。
Serverless与传统云服务的对比
广义上讲，云计算的发展实际上就是一个serverless化的过程。近年来涌现的平台即服务（Platform-as-a-Service, PaaS），容器即服务（Container-as-a-Service，CaaS）等，都在一定程度上实现了serverless。每一种服务，都在不同的粒度上对计算进行抽象，而Serverless计算，则将计算的抽象粒度提升到了函数层次，属于函数即服务（Function-as- a-Servcie，FaaS）。相对于PaaS/CaaS，FaaS支持更小的计量和伸缩的粒度，因此在成本和伸缩平滑性上具有独特的优势。
下表从不同维度对比了IaaS，CaaS，PaaS和FaaS。
开发效率
- 低：用户需要处理机器相关的问题，包括容错，扩容缩容等问题。
- 中：用户只需要实现业务逻辑。
- 高：用户只需实现业务逻辑，并通过事件驱动的方式有效组合各项服务。例如上传图片到对象存储服务后，自动触发对应的函数处理。
可伸缩性
- 低：以机器为粒度，在数分钟内完成扩容/缩容。
- 中：以容器为粒度，在数秒内完成扩容/缩容。
- 高：以事件/请求为粒度，扩容/缩容对用户是透明的，随用户访问量自动伸缩。
可运维性
- 低：用户需要管理操作系统及以上层。
- 中：用户需要管理容器即以上层。
- 高：用户需要管理应用及以上层。
成本
- 高：按照资源规格，小时时间粒度计费。
- 低：按照资源规格，毫秒时间粒度计费。
Serverless的优点
低运营成本
在业务突发性极高的场景下，系统为了应对业务高峰，必须构建能够应对峰值需求的系统，这个系统在大部分时间是空闲的，这就导致了严重的资源浪费和成本上升。在微服务架构中，服务需要一直运行，实际上在高负载情况下每个服务都不止一个实例，这样才能完成高可用性；在Serverless架构下，服务将根据用户的调用次数进行计费，按照云计算pay-as-you-go原则，如果没有东西运行，你就不必付款，节省了使用成本。同时，用户能够通过共享网络、硬盘、CPU等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。
简化设备运维
在原有的IT体系中，开发团队即需要维护应用程序，同时还要维护硬件基础设施；Serverless架构中，开发人员面对的将是第三方开发或自定义的API 和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。用户不再需要管理服务器。部署升级简化为上传代码，回滚至指定版本变得快速易用。
提升可维护性
Serverless架构中，应用程序将调用多种第三方功能服务，组成最终的应用逻辑。目前，例如登陆鉴权服务，云数据库服务等第三方服务在安全性、可用性、性能方面都进行了大量优化，开发团队直接集成第三方的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。
开发效率高
这一点在现在互联网创业公司得到很好的体现，创业公司往往开始由于人员与资金等问题，不可能每个产品线都同时进行，这时候就可以考虑第三方的Baas平台，比如使用阿里云提供的RDS，极光推送的消息推送，Bmob支付以及地理位置等等，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。
用户不必考虑服务器相关的容错，负载均衡，自动伸缩等方面的问题，开发难度降低。函数计算要求用户将系统解耦为一组功能单一的函数，相互配合完成。因此一些公共的组件，例如身份验证，能够抽象出来，借助专门的服务完成，无需自己实现。函数计算内建日志，性能指标监控等功能，用户不再需要自己配置维护相关系统。
高效平滑伸缩
函数执行能力实时横向平滑伸缩，对用户完全透明。很适合访问模式有明显波峰波谷的应用。
Serverless的缺点
不适合所有场景
Serverless服务在公共云中运行，因此非常关键的任务应用程序不一定可以充分依赖它。比如执行大量交易的银行系统或患者生命支持系统需要比公共云系统能够提供的更高水平的性能和可靠性。有可能组织可以使用专用硬件或运行私有或混合云与自己的计算服务，才可能满足可服务性和可靠性要求。
没有统一的行业标准
平台会提供Serverless架构给大玩家，比如AWS Lambda，运行它需要使用AWS指定的服务，比如API网关，DynamoDB，S3等等，一旦你在这些服务上开发一个复杂系统，你会粘牢AWS，以后只好任由他们涨价定价或者下架等操作，个性化需求很难满足，不能进行随意的迁移或者迁移的成本比较大，同时不可避免带来一些损失。Baas行业内一个比较典型的事件，2016年1月19日Facebook关闭曾经花巨额资金收购的Parse，造成用户不得不迁移在这个平台中产生一年多的数据，无疑需要花费比较大的人力和时间成本。
较大的供应商依赖
Serverless架构中会对云服务商本身产生极大的依赖，即供应商锁定。如果开发人员决定使用第三方API和服务（包括AWS），那么架构可能会强烈耦合到正在使用的平台。 需要彻底考虑供应商锁定的含义以及使用第三方服务的风险，包括公司可行性，数据主权和隐私，成本，支持，文档和可用功能集。
松耦合架构并不能降低复杂度
目前的情况也只适合简单的应用开发，缺乏大型成功案例的推动。对于Serverless缺乏统一的认知以及相应的标准，无法适应所有的云平台。从集中设计方法到更分散的Serverless方法不会自动降低底层系统的复杂性。由于需要进行远程而不是进程内调用，以及需要处理网络中的故障和延迟，解决方案的分布式特性可能会带来自身的挑战。