这篇文章作者分别阐述了Kubernetes与Serverless的优缺点，实际上两者可能并不是竞争关系，在某些架构中，两者可以同时存在以满足不同的需求。但是最终的目的都是为了使应用程序部署更方便快捷，更易管理，更具成本效益以及对开发人员友好。
Kubernetes和Serverless都是令人兴奋的强大的平台，它们可以通过多种方式为企业在敏捷性，扩展性以及计算性能上获取巨大的提升。但是，不要忘记Kubernetes能提供一些Serverless所没有的功能，反之亦然。成功部署其中任何一个方案的关键点在于哪种技术更适用于当前的场景。
自首次亮相以来，Kubernetes已成为主流。但是，正如从主机迁移到客户端服务器上总会遇到各种问题，在采用完全基于容器架构的过程中也依然会遇到各种问题，尽管这种容器架构是由Kubernetes进行编排的。容器扩展并不是实时的，你需要等到容器上线，同时你也必须处理容器管理问题。据CNCF调查表明，存储，安全以及网络问题仍然是通过Kubernetes部署其架构的程序员最关心的问题。
一个Serverless应用，如果没有请求使用它的功能，那么它的成本可能降低到零，实际上如果没有请求，它们会停止运行，这可以显著的降低成本，并且有利于更迅速的伸缩。访问Serverless程序的请求越多，它的体量就会变得越大。
关于Serverless架构会取代容器化的应用程序的想法似乎是一个不合理的建议，并非一切功能都能被简化成一个短暂的功能（function）。一些程序需要在应用程序运行时持久化数据以及状态，Serverless的设计很难满足这种需求，但是大家对Serverless的兴趣却在快速增长。
例如，根据MarketsandMarkets Research的数据，FaaS（Function as a Service）市场预计将从2016年的1.88美元飙升至2021年的77.2亿美元。
然而，这不是一场零和博弈（即参与游戏的个体必须通过其他个体的损失来获益，所有个体不能同时获益或者损失），而Serverless的增长并不一定预示着Kubernetes和容器的死亡。实际上，它甚至可能帮助扩展Kubernetes的使用，至少可以通过主要的FaaS提供商来扩展其Serverless产品。
Serverless架构很可能通过仅仅支付使用的服务而不用支付运行容器或一组容器所需的开销来进一步降低成本，但是这件事需要进行权衡，不经常访问的Serverless代码虽然运行成本不高，但在运行时（如Java）或底层容器用于服务请求的情况下，可能会遇到延迟增加的问题。这些额外的延迟可能令人无法接受。
从一个开发者的角度来说，FaaS可以极大的促进效率的提升，使程序员的开发过程更加愉悦，程序员可以更快的将小块代码推到生产环境而不用顾虑配置和管理的开销，从而提高生产力。
Kubernetes——以及其他的容器化技术——已经拥有了它们应得的地位，Kubernetes市场的迅速普及和发展证明了它正满足市场需求。虽然我并没看出容器化的必要性，如果不必要，那么容器编排也没任何意义，这种解决方案也并总是适用。
同样Serverless的FaaS显然填补了市场的需求，并且整体上呈现出显着的增长。当然，增长并不一定意味着合适，但市场倾向于自我纠正以弥补这一点。
同样，Kubernetes vs.Serverless不是零和博弈。Serverless的增长并不表示Kubernetes的死亡。每个技术在现代应用程序的开发和部署中都发挥着重要作用。在过去的20年中，应用程序部署一直朝着更小，更易管理，更具成本效益和开发人员友好的架构迈进，并且毋庸置疑这种趋势会持续下去。虽然Serverless可能是将应用程序抽象到其最基本组件的逻辑结论，但并非所有应用程序都能以这种方式抽象出来。同理可得，出于对持久性和可伸缩性的需求，某些应用程序将会需要容器，需要容器的编排和管理。
Kubernetes和Serverless都是令人兴奋的强大的平台，它们可以通过多种方式为企业在敏捷性，扩展性以及计算性能上获取巨大的提升。但是，不要忘记Kubernetes能提供一些Serverless所没有的功能，反之亦然。成功部署其中任何一个方案的关键点在于哪种技术更适用于当前的场景。
Kubernetes的兴起
Kubernetes是为大规模的云计算设计的，一开始就是因为Google使用了超大规模的部署才开发了Kubernetes。之后Kubernetes被改造成可以小规模使用，并且适用于大多数大型云提供商，这归功于它过去几年迅猛的发展。根据Cloud Native Computing Foundation（CNCF）的用户调查，Kubernetes的增长远超过所有其他形式的编排软件。自首次亮相以来，Kubernetes已成为主流。但是，正如从主机迁移到客户端服务器上总会遇到各种问题，在采用完全基于容器架构的过程中也依然会遇到各种问题，尽管这种容器架构是由Kubernetes进行编排的。容器扩展并不是实时的，你需要等到容器上线，同时你也必须处理容器管理问题。据CNCF调查表明，存储，安全以及网络问题仍然是通过Kubernetes部署其架构的程序员最关心的问题。
那么选择Serverless呢？
Serverless架构，在很多方面只是对微服务架构的重新打包和重新构想，这种架构正在与Kubernetes形成竞争，因为它允许扩展应用程序和部署，无需担心复杂性和配置问题。这两个问题正是使用Kubernetes和容器的痛点。 但不要把两者当做一样的。Serverless也被称为功能即服务（FaaS），Serverless体系结构仍然需要运行服务器，但是它是事件驱动的架构，相比之下，容器化应用程序本质上仍然是传统的应用程序，只是分成许多较小的部分或服务。
使用容器化的应用程序，它永远不会完全关闭。即使没有人访问它，容器仍然需要存在并运行。你可以将它们缩小到单个实例，但它们仍在运行并需要花钱。
一个Serverless应用，如果没有请求使用它的功能，那么它的成本可能降低到零，实际上如果没有请求，它们会停止运行，这可以显著的降低成本，并且有利于更迅速的伸缩。访问Serverless程序的请求越多，它的体量就会变得越大。
关于Serverless架构会取代容器化的应用程序的想法似乎是一个不合理的建议，并非一切功能都能被简化成一个短暂的功能（function）。一些程序需要在应用程序运行时持久化数据以及状态，Serverless的设计很难满足这种需求，但是大家对Serverless的兴趣却在快速增长。
例如，根据MarketsandMarkets Research的数据，FaaS（Function as a Service）市场预计将从2016年的1.88美元飙升至2021年的77.2亿美元。
然而，这不是一场零和博弈（即参与游戏的个体必须通过其他个体的损失来获益，所有个体不能同时获益或者损失），而Serverless的增长并不一定预示着Kubernetes和容器的死亡。实际上，它甚至可能帮助扩展Kubernetes的使用，至少可以通过主要的FaaS提供商来扩展其Serverless产品。
Serverless架构很可能通过仅仅支付使用的服务而不用支付运行容器或一组容器所需的开销来进一步降低成本，但是这件事需要进行权衡，不经常访问的Serverless代码虽然运行成本不高，但在运行时（如Java）或底层容器用于服务请求的情况下，可能会遇到延迟增加的问题。这些额外的延迟可能令人无法接受。
从一个开发者的角度来说，FaaS可以极大的促进效率的提升，使程序员的开发过程更加愉悦，程序员可以更快的将小块代码推到生产环境而不用顾虑配置和管理的开销，从而提高生产力。
结论
应用程序开发和部署策略，都在不断发展。通常，从一个架构到另一个架构的迁移标志着第一个架构的终结，但情况并非总是如此。至少现在，还没有一个通用的解决方案可以解决低成本的，大规模的交付应用程序所遇到的所有问题。与任何部署模型一样，架构师需要在成本，性能和可管理性之间进行权衡。Kubernetes——以及其他的容器化技术——已经拥有了它们应得的地位，Kubernetes市场的迅速普及和发展证明了它正满足市场需求。虽然我并没看出容器化的必要性，如果不必要，那么容器编排也没任何意义，这种解决方案也并总是适用。
同样Serverless的FaaS显然填补了市场的需求，并且整体上呈现出显着的增长。当然，增长并不一定意味着合适，但市场倾向于自我纠正以弥补这一点。
同样，Kubernetes vs.Serverless不是零和博弈。Serverless的增长并不表示Kubernetes的死亡。每个技术在现代应用程序的开发和部署中都发挥着重要作用。在过去的20年中，应用程序部署一直朝着更小，更易管理，更具成本效益和开发人员友好的架构迈进，并且毋庸置疑这种趋势会持续下去。虽然Serverless可能是将应用程序抽象到其最基本组件的逻辑结论，但并非所有应用程序都能以这种方式抽象出来。同理可得，出于对持久性和可伸缩性的需求，某些应用程序将会需要容器，需要容器的编排和管理。
如果这两种技术没有直接相互竞争，它们很难不会有持续性的显著增长。
本文转自DockOne-选择Serverless还是Kubernetes？这种争辩并没有意义
