原文：
状态
当使用本地（机器/实例绑定）状态时FaaS函数有很严格的限制。简单说，你应该假设对于任何函数调用，你创建的进程内或主机状态都不会对后续任何调用生效。这状态包括内存和要写入到本地磁盘的。换句话说从部署单元的角度看FaaS函数是无状态的。
这对应用架构有极大影响，尽管不是唯一的因素 - ‘12因子应用’概念有同样的限制 http://12factor.net/processes。
这个限制有什么可以代替的？正常来说表示要么FaaS函数是天生无状态 - 他们对输入提供纯函数变换 - 要么他们使用数据库， 跨应用缓存（如Redis），或网络文件存储（如S3）将跨请求的状态存储起来以备后续的处理请求时需要用来做输入。
执行周期
FaaS函数通常受限于每次调用可以允许运行的时间。目前AWS Lambda函数不允许运行超过5分钟，如果超过会被终止。
这意味着某些长执行周期的类如果不进行重构是不适合在FaaS函数中运行的，比如你可能需要创建很多不同的FaaS函数协调器，在传统环境中你可能只有一个有一个长周期的任务同时做协调和执行。
启动延迟
目前你的FaaS函数需要多长时间响应请求取决于很多因素，可能会在10ms到2分钟。这听起来很糟，但让我们具体点，用AWS Lambda作为例子。
如果你的函数不大（少于一千行代码）并用Javascript或Python实现，那么运行的开销应该不会超过10-100ms。更大的函数可能会要更长的时间。
如果你的函数使用JVM上的实现当JVM启动时你可能偶尔会看到较长的响应（大于10秒）。但是这只会发生在以下场景：
- 你的函数进程不经常处理时间，调用的时间间隔大于10分钟。
- 你的流量出现高峰，比如正常你每秒处理10个请求但突然在10秒内每秒100个请求出现。
这些情况可以用比较丑陋的技巧 - 每5分钟ping以下你的函数保证它的存活来解决。
这些问题是否值得关注？这取决于你应用的流量图形。我的前团队有一个用Java实现的Lambda用来处理亿级异步消息/天，他们不关心启动延迟。这说明如果你要写一个低延迟的交易引用你肯定不会想使用FaaS系统，无论你用什么语言实现。
无论你觉得你的应用是不是有这个问题，你应该用生产环境的负载来测试实际性能。如果你的case现在还不行，你可以在几个月后再测试一下，因为这是FaaS供应商的主要开发领域。