在函数即服务环境中使用面向 actor/agent 的编程有意义吗？
Does it make sense to use actor/agent oriented programming in Function as a Service environment?
我想知道，是否可以在函数即服务环境（OpenWhisk、AWS Lambda）中应用 agent/actor 库（Akka、Orbit、Quasar、JADE、Reactors.io）？
有道理吗？
如果是，什么是最小的示例帽子提供附加值（当我们仅使用 FaaS 或仅使用 actor/agent 库时缺少）？
如果不是，那么我们是否能够构建决策图，这可以帮助我们决定，对于我们的问题，我们应该使用 actor/agent 库还是 FaaS（或其他东西）？
这是一个更多基于意见的问题，但我认为，在目前的情况下，将参与者放入 FaaS 是没有意义的——相反的工作实际上非常好：OpenWhisk 实际上是在 Akka 之上实现的。
有几个原因：
- FaaS 目前的形式本质上是无状态的，这极大地简化了请求路由之类的事情。 Actor 本质上是有状态的。
- 根据我的经验，FaaS 功能通常是脱节的 - 当然您需要一些外部资源，但这是心智模型：通用资源和功能。在演员模型中，我们倾向于考虑表示为演员的特定实体的类别，即用户 Max，而不是 table 个用户。我在这里不涵盖仅将 actor 用作并发单元的范围。
- FaaS 应用程序的生命周期非常短 - 这是它们背后的基石之一。由于更复杂的 actor 的创建、放置和状态恢复可能需要一段时间，而且您通常需要很多 actor 来执行单个任务，因此您可能最终会发现恢复系统状态比实际执行任务，需要该状态。
话虽如此，这两种方法有可能在未来最终融合，但需要随之而来的是思维和基础架构模型的变化（即 actors 生活在运行时，FaaS 必须意识到这一点). IMO 在现有 FaaS 提供商之上设置现有的参与者框架在这一点上是不可行的。
我想知道，是否可以在函数即服务环境（OpenWhisk、AWS Lambda）中应用 agent/actor 库（Akka、Orbit、Quasar、JADE、Reactors.io）？
有道理吗？
如果是，什么是最小的示例帽子提供附加值（当我们仅使用 FaaS 或仅使用 actor/agent 库时缺少）？
如果不是，那么我们是否能够构建决策图，这可以帮助我们决定，对于我们的问题，我们应该使用 actor/agent 库还是 FaaS（或其他东西）？
这是一个更多基于意见的问题，但我认为，在目前的情况下，将参与者放入 FaaS 是没有意义的——相反的工作实际上非常好：OpenWhisk 实际上是在 Akka 之上实现的。
有几个原因：
- FaaS 目前的形式本质上是无状态的，这极大地简化了请求路由之类的事情。 Actor 本质上是有状态的。
- 根据我的经验，FaaS 功能通常是脱节的 - 当然您需要一些外部资源，但这是心智模型：通用资源和功能。在演员模型中，我们倾向于考虑表示为演员的特定实体的类别，即用户 Max，而不是 table 个用户。我在这里不涵盖仅将 actor 用作并发单元的范围。
- FaaS 应用程序的生命周期非常短 - 这是它们背后的基石之一。由于更复杂的 actor 的创建、放置和状态恢复可能需要一段时间，而且您通常需要很多 actor 来执行单个任务，因此您可能最终会发现恢复系统状态比实际执行任务，需要该状态。
话虽如此，这两种方法有可能在未来最终融合，但需要随之而来的是思维和基础架构模型的变化（即 actors 生活在运行时，FaaS 必须意识到这一点). IMO 在现有 FaaS 提供商之上设置现有的参与者框架在这一点上是不可行的。