无服务器架构是最近一个比较热的话题。我们也看到有很多的书籍、开源框架和大量的产品在不断涌现，在一些技术大会上也有专门的主题。6 月 17 日， Mike Robers 在 Martin Fowler 的博客网站上发布了一篇题为“ 无服务器架构 ”的文章，引起了业界的诸多关注。在该文章中，他认为无服务器是后端即服务 (BaaS) 和函数即服务 (FaaS) 的结合，并以 AWS Lambda 产品为例探讨了 FaaS 的特点、什么不是无服务器及需要考虑的其他相关问题。他指出：
就像很多软件发展趋势一样，业界并没有对“无服务器”有一个明确的说法，即使它真的表示以下两个不同而又重叠的领域也不会对此有所帮助：
无服务器先用来描述那些显著或完全依赖于第三方应用或服务（“在云端”）的应用程序。这些应用程序依赖于第三方来管理服务器端逻辑和状态，它们都是典型“富客户端”的应用程序（你可以想象为单一页面的 Web 应用程序或移动应用），并采用云平台提供的生态系统，包括可访问的数据库（如 Parse、Firebase）、认证服务（Auth0、AWS Cognito）等。这些类型的服务以前被描述为“（移动）后端即服务”。我在文中会用“BaaS”缩写来代替这样的服务。 无服务器还表示那些有服务器端逻辑的应用仍然需要由开发者来编写。不同于传统的架构，它运行在无状态计算的容器中，这些容器由事件触发的、是短暂的（也许仅仅只是一次调用）、并且完全由第三方管理。（感谢 ThoughtWorks 在他们最近的 技术雷达 的定义。）理解这个观点的另一种方式是“函数即服务（FaaS）”，其中 AWS Lambda 是目前最流行的 FaaS 实现之一。
Mike 主要分析了第二个领域，并用 FaaS 作为文中“无服务器”的代言词。他认为第二个领域相对较新，并且它和我们平常如何考虑技术架构的方式有显著的区别，也推动了无服务概念周边很多的炒作。他也提到了其实这些概念是相互关联的，并在不断合并。文中他给出了 UI 驱动的应用和消息驱动的应用两个例子解释了无服务架构的设计以及不同。
通过解读 AWS Lamda 产品描述，Mike 在文中分享了他对于 FaaS 的几个理解：
从根本上说，FaaS 是关于无需管理自己的服务器系统或者服务器应用，就能够运行后端代码的。 FaaS 不需要基于一个特定的框架或类库进行编码。 无服务器应用程序的运行部署与传统系统非常不同 - 我们将代码上传到 FaaS 服务提供商，它会帮我们做所有其他事情。 水平扩展是完全自动的、弹性的，并且由服务提供商进行管理。 FaaS 中的函数是由服务提供商定义的事件类型触发的。 大多数服务提供商还允许函数被 HTTP 请求响应触发，通常在某种 API 网关里。
他同时也探讨了 FaaS 在状态、执行时长、启动延时、API 网关、工具和开源等方面的表现。他提到了 FaaS 在本地状态的显著约束，并可以这样简单来理解：
对于任何的函数调用，你所创建的进程或者主机状态不会有一个对随后的调用可用，这包含了你写到内存和硬盘上的状态。换句话说，从部署单元角度来看，FaaS 的函数是无状态的。这对应用架构产生了巨大的影响。
这通常意味着 FaaS 要么是纯粹无状态的，即提供输入的纯函数转换；要么是利用数据库、跨应用缓存（如 Redis）或者网络文件存储（如 S3）的方式来存储跨请求的状态或处理请求需要的进一步输入。
而对于执行时间而言，
FaaS 函数的每次调用是有时间限制的。当前 AWS Lamda 函数不允许超过 5 分钟，超过就会被中断。这意味着长任务并不适合 FaaS，除非重新设计架构。
另外，FaaS 函数的响应时长取决于很多的因素，也许会从 10 毫秒到 2 分钟。Mike 认为如果你编写一个低延迟交易应用，那么不管你使用什么语言实现，可能都无法使用 FaaS 系统。
那么 Paas 是无服务器吗？在文中 Mike 引用了 Adrian Cockcroft 的回答
如果您的 PaaS 能够高效地在 20 分钟内启动运行半秒的实例，那么你可以称它为无服务器。
Mike 认为：
绝大多数 PaaS 应用并不是着眼于将整个应用的每个请求都来回切换，而 FaaS 平台做的正是这一点。FaaS 和 PaaS 之间的主要操作差异在于扩展。对于大多数的 PaaS 来说，你仍然需要考虑规模，例如在 Heroku 你想运行多少 Dynos。而如果是 FaaS 的应用，这完全是透明的。即使你将你的 PaaS 应用程序设置为自动扩展，你也不会对单个请求进行同样的配置（除非你有一个非常特殊的流量描述文件），所以当涉及到成本的时候，FaaS 应用会更高效。
同时他也指出这并不意味着没有运维。这里要考虑两个重要的事情：
首先，“运维”不仅仅意味着服务器管理。它也意味着监控、部署、安全、网络，也意味着一定的产品问题诊断和系统规模扩展。这些问题在无服务器应用中仍然存在，你依旧需要应对的策略。 其次，即使仍然发生系统管理的工作，你也仅仅是将它们外包给无服务器平台而已。
最后 Mike 对存储过程即服务的另一话题也进行了探讨，他认为:
这可能来自于一个事实，即 FaaS 函数的许多例子（包括一些我在本文中使用的）都是少量访问数据库的代码。如果这就是我们可以使用 FaaS 的所有场景，那么我认为这个名字是有帮助的。然而它实际上只是 FaaS 能力的一个子集。如果仅仅因为这个原因就形成这样观点的话，那这限制是不合理的。