选择Serverless还是Kubernetes?这种争辩并没有意义
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?这种争辩并没有意义
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Kubernetes-项目中pod调度使用法则
前言 kubernetes中部署的pod默认根据资源使用情况自动调度到某个节点。可在实际项目的使用场景中都会有更细粒度的调度需求,比如:某些pod调度到指定主机、某几个相关的服务的pod最好调度到一个节点上、Master节点不允许某些pod调度等。使用kubernetes中的节点调度、节点亲和性、pod亲和性、污点与容忍可以灵活的完成pod调度,从而满足项目中较为复杂的调度需求。下面用一些项目中的使用场景聊聊pod调度使用法则。 原创作者:钟亮 pod调度主要包含以下内容 nodeSelector nodeAffinity podAffinityz Taints 指定节点调度 kubectl get nodes #获取当前Kubernetes集群全部节点 NAME STATUS ROLES AGE VERSION dev-10 Ready <none> 45d v1.8.6 dev-7 Ready master 45d v1.8.6 dev-8 Ready <none> 45d v1.8.6 dev-9 Ready <none> 45d v1.8.6...
- 下一篇
Kubernetes上的负载均衡详解
如果您的应用程序是面向大量用户、会吸引大量流量,那么一个不变的目标一定是在高效满足用户需求的同时、不让用户感知到任何类似于“服务器繁忙!”的情况。这一诉求的典型解决方案是横向扩展部署,以便有多个应用程序容器可以为用户请求提供服务。但是,这种技术需要可靠的路由功能,需要可以有效地在多个服务器之间分配流量。本文分享的内容就是要解决负载均衡解决方案的问题。 Rancher 1.6是Docker和Kubernetes的容器编排平台,为负载均衡提供了功能丰富的支持。在Rancher 1.6中,用户可以通过使用开箱即用的HAProxy负载均衡器,来提供基于HTTP / HTTPS / TCP主机名/路径的路由。 而在本文中,我们将探讨如何在原生使用Kubernetes进行编排的Rancher 2.0平台上实现这些流行的负载均衡技术。 Rancher 2.0 负载均衡功能 通过Rancher 2.0,用户可以开箱即用地使用由NGINX Ingress Controller支持的原生Kubernetes Ingress功能进行7层负载均衡。因为Kubernetes Ingress仅支持HTTP和HTT...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Red5直播服务器,属于Java语言的直播服务器
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16