Knative在7月份Google Next上发布时，在博客圈引发了一片哗然，然后Riff和Openwhisk采用了它实现自己的FaaS解决方案。从表面上看，它似乎是基于容器即服务（CaaS）解决方案的最佳实践，但对于功能即服务（FaaS）解决方案，可以认为Knative事实上是一个FaaS反模式。

在Knative的描述中，它指出它自己是“......构建，部署和管理现代无服务器工作负载”的方式，自Amazon Lambda推出以来，“无服务器”一词与FaaS相关联，说到这一点，重要的是要意识到创建一个无服务器进程或应用程序FaaS解决方案不是必须的，开发人员可以创建通常应用程序容器（例如使用NGINX），如果这些容器启动足够快并且可以在不受影响的情况下可暂停其操作，那么从技术上讲，基于Nginx的这些传统方式也是可以实现无需基于FaaS的无服务器架构。

在CaaS世界中，Knative可以被认为是在Kubernetes上执行自动缩放的正确方法，它解决了scale-to-zero情况，如果你想要正确自动缩放，则需要这样做，它还插入了诸如服务网格（Istio）之类的重要组件，以及执行日志记录和跟踪的能力。简而言之，对于CaaS，它似乎是一种最佳实践。

然而，谈到FaaS，恰恰相反，首先，重要的是要意识到FaaS解决方案有不同的风格。其中两个最重要的是：

1. FaaS解决方案是否有自己的调度器？

2. FaaS解决方案是否需要打包代码放入容器中？

这些问题的答案很重要，因为它从根本上改变了这些FaaS平台的功能，例如，具有自己的调度程序的FaaS解决方案可以：

1. 支持冷/暖/热 lambda池，从而获得更好的性能和日程安排

2. 支持组合函数的流水线优化

3. 在Kubernetes以外的环境中运行

看看Amazon Lambda，Google Cloud Functions和Azure Functions等公共云提供商，他们每个都使用自己单独的调度程序，而且是不依赖于像Kubernetes这样的外部调度器来进行调度的。

类似地，如何打包一个函数的问题很重要，因此不需要将代码打包到容器中有下面好处：

1. 可以快速迭代解决方案，而无需通过完整的CI / CD流程。（即，开发人员的工作效率不受影响）

2. 可以执行管道优化，例如在同一进程空间内以不同语言运行函数。

再次看看公共云提供商的FaaS解决方案，如AWS Lambda，他们部署的artifacts工件不是容器。

如果你看一下公开采用Knative的FaaS解决方案，那就比较弱了，者或缺乏这些能力，作为奖励，这些解决方案会获得比以前更好的扩展解决方案，同时还添加了Istio支持和日志记录集成。

然而，需要在下面两者之间权衡考虑：一个平台是偏重提高开发人员生产力？还是侧重提高应用程序的性能？

我们将再次强调......将代码打包到容器中应该被视为FaaS反模式！正确的方法是让容器以像那些公共FaaS解决方案一样，直接从工件artifact库中提取和执行代码。