如果你徘徊在十字路口，需要外部帮助决策，本文列举了一些场景，可能有助于你做出选择。
我经常被问到的一个问题是：构建云原生应用，我该使用Serverless还是Kubernetes？我认为两个选项各有利弊，选择哪个取决于你的需求。
下周Ansgar Schmidt和我就这个话题会有个对话。我们仍在修改我们的幻灯片，不过关于总结何时使用Kubernetes以及何时使用Serverless的那部分，我们已经完成了。
请注意我们是将Serverless和Kubernetes做比较，而非容器。因为利用开源Serverless平台OpenWhisk你也可以直接用Docker容器来构建函数。同样的，我们也不会拿一个很简单的Serverless函数和Kubernetes上一个很复杂的微服务应用来比较，但是双方有相似复杂度。
使用Serverless，当：
一个本地网站就是一个很好的Serverless场景，它在夜间只有一点甚至没有流量。由于Serverless平台只针对你的代码运行时才使用到的资源计费，这就能明显的降低成本。应用越长时间不做事，Serverless平台成本低的概率就越大。
然而这不是说Serverless就意味着低成本，比如你的应用需要7X24小时都保持运行。它还有一些隐藏成本，比如API管理的一些额外消费，或者测试函数调用时的成本。
你首次开发且希望生产率更高
如果你既无Serverless，也无Kubernetes的开发经验，那么开发一个Hello World应用，让其运行在Serverless平台上是更容易的。当使用Kubernetes时，通常你必须花费一段时间去创建集群，配置Kubernetes以获取公网IP，然后才能部署你的第一个应用。而使用Serverless平台，你可以简单地使用云服务商提供的web工具，就能在几分钟之内启动应用。
然而，Serverless也不总是比Kubernetes容易。构建并管理一个有一系列函数的Serverless应用，比一个简单的只有一个容器的Kubernetes应用，可要难多了。事实上，对于更复杂的应用，Kubernetes可能更容易使用，因为Kubernetes平台更成熟（参考下文）。
你需要自带的自动伸缩能力
Serverless的其中一个强大的功能就是其自带的函数自动伸缩能力，开����,����发人员无需做任何事情就能拥有该功能。Kubernetes当然也可以对Pod甚至节点使用自动伸缩功能，但是它需要一些配置，另外这个过程有点慢，因为它只在应用特定规则的时候才触发。
然而，Kubernetes相比某些Serverless平台，可能会提供更好的伸缩特性，因为它更成熟，并且提供了不同可用区（zones）之间的HA（high availability）能力，而这并非所有Serverless平台都提供。
使用Kubernetes，当：
我不知道是否有Serverless平台支持A/B测试，这是我认为构建云原生应用必须具备的一个关键能力。除此之外，Kubernetes对应用的监控能力也更成熟。例如，使用Istio，你可以看到微服务的执行时间，哪个服务调用了哪个服务，以及是否存在瓶颈。Serverless平台还没有真正意义上的这项功能，且只在最近才开始启动添加这类特性，来定义函数间的流向，比如亚马逊的Step Functions，以及OpenWhisk的 Composer。
然而，如果你的应用相当简单，例如只有一个函数来提供一个API，那么Serverless则是更好的选择，因为部署将更容易，且对单函数的监控能力，各个Serverless平台都已提供。
你需要最小的响应时延
使用Serverless平台，函数的首次调用会花费一定时间，因为代码需要初始化。例如，在OpenWhisk上，你可以使用Docker容器运行Java应用，它会花费一定时间来启动。如果你需要快速且可靠的响应时间，你应该使用Kubernetes。
像OpenWhisk这种Serverless平台，最近通过一系列缓存的使用，已明显提升了响应时延。在最初的冷启动之后，你不应该再看到这些很长的响应时间，目前的响应时间对你的应用来说已足够了。
你想要不带资源限制的高计算性能
Serverless平台典型地需要一些资源限制，例如函数不能使用超过512M的内存，运行时间不能超过5分钟。如果这些限制对你的应用来说太严格，那么你也需要使用Kubernetes。
然而，某些时候可能可以将应用拆成更小的函数。某些场景下甚至就希望这么做，例如将一个已有的单体应用迁移到云上。
最后的思考
原文链接：https://dzone.com/articles/when-to-use-serverless-when-to-use-kubernetes