正文
除了 FaaS 计算（如 AWS Lambda、Azure Functions 以及 Google Functions）之外，公共云提供商还提供了一系列其他服务用于组合并创建无服务器架构。从可伸缩的持久化存储和消息中间件，到 API 网关和内容分发网络，如今想要构建一个完整的系统完全不需要直接摆弄服务器。
每个云提供商的服务都可以通过其提供的软件开发工具包（SDK）进行全方位的配置，可以用其快速地发布产品来提供业务价值，前提是你要熟悉可用的服务及其配置选项。每个功能往往只负责处理简单的事件或请求，因此通常它们不需要大量代码，小而集中的业务逻辑就足够了。例如，一个功能可能只负责根据数据库表中的触发器，将变化信息推送到用户的电子邮件或相应的消息队列上，让其他子系统可以使用这个通知来更新外部系统。
然后，许多这样的功能用于实现业务逻辑及连接服务，从而提供了持久化、消息、集成、内容分发、机器学习等基本功能。这些服务解决了许多复杂的项目问题，并可以用其来创建复杂的解决方案而不会碰到太多困难，进而可以快速进行原型设计并开发。
使用了无服务器架构，就不可能在不考虑代码执行方式以及其他所需资源的情况下开始编写代码，至少这样做毫无意义。毕竟，为了了解代码如何与 API 网关、数据存储或消息中间件交互，首先必须部署代码，还要配置所有相关资源。虽然，可以使用模拟，而不通过真实的部署来执行代码，但这只提供了有限程度的验证，况且，这样不会运行该功能所需的整个基础架构堆栈。
无服务器架构需要配置好云资源这点可以说有利也有弊。那些习惯于使用自己机器，在本地开发模式下运行应用程序和系统的用户，很可能会因为较长的反馈周期而损失部分生产力。基础设施配置和代码部署确实需要更多的时间，但并不会像 IaaS 一样多，后者还要算上按需启动计算实例的时间。
从一开始就强制关注基础设施堆栈的主要好处是，能早在编写代码的时候，就考虑基础架构设置和配置机制。这与现在仍常见的传统方法不同，常常开发人员编写代码，并借助于持续集成工具进行打包，然后将其转交给运营团队进行部署，在这个过程中会假设不用考虑网络基础设施的问题。
DevOps 运动促进了开发和运营团队之间的合作，而在无服务器架构中，他们就根本不可能被分开。
在无服务器架构中，即使部署一个简单的功能，也需要对一些运营和财务方面的关键问题作出决定。两个最基本的配置选项就是可用内存和超时时间（即功能调用的预估时间）。这两个设置都会影响调用所需的花费，因为它是按照内存消耗和执行时间来收费的。此外，分配的内存通常与功能运行的计算实例相关联，更多的内存就意味着更多的处理能力。
