Serverless与容器——这是正确的吗?

如果您是一名开发人员或团队DevOps的一部分你有偏振或两个容器与serverless对话。在这篇文章中,我们回顾NetApp主持的一场辩论这个话题。主张容器是凯文·麦格拉思首席技术官,NetApp现货。福勒斯特Brazeal serverless的一侧,内容和社区主任云大师。在这篇文章中我们将介绍双方的关键参数。

——完美的包装容器构造

在容器之前,组织自己的方式打包和交付应用程序。每个团队都有自己的语言,政策,和管道生产方法的自定义应用程序和扩展。随着集装箱码头工人,每个人都能够使用一个构造打包和部署应用程序。在定义构造是伟大的我们如何打包应用程序。它允许我们把我们想要的任何代码,任何要求和图书馆,所有在一个容器里,然后允许其他人在他们选择的任何环境中运行这段代码。

同时我们可以减少代码依赖项,解耦代码从服务器层。因此你可以把这些微小物体(容器),很容易把它们从开发阶段生产而不用担心底层服务器依赖像一个操作系统。容器单独来宾操作系统从主机操作系统导致更好的解耦。这也使得他们更轻量级虚拟机需要自己的主机操作系统为每个实例。这是一个巨大的转变。我们终于有一个通用的方式交付应用程序。

容器与业务流程变得复杂

然而,事情并非所有美好与容器。我们需要一种方法来运行容器在生产和规模。这需要新的方法来处理container-to-container网络,有状态的存储和安全。新的挑战变得如何运行容器尽管这种复杂性。

解决方案是使用集装箱编配等工具便,码头工人群或Kubernetes。没过多久行业整合在一个协调器- Kubernetes。然而,Kubernetes操作不同于传统像VMware虚拟机管理平台。声明,强烈关注自动化,在很大程度上依赖于开源工具如Istio和普罗米修斯。这一切意味着Kubernetes有一个陡峭的学习曲线(读下去,看看如何改变)。

Serverless比较简单,但是牺牲控制

当Serverless走进混合似乎解决了运行的复杂性的容器中。与Serverless我们交出我们的代码的人,让他们为我们运行它。虽然这删除一些复杂性,我们失去控制底层的层。当我们试图控制依赖关系,冷启动时,自定义库,并限制资源消耗,它需要很多特定于供应商的自定义工具和手段将注意力从应用程序本身。从这个意义上讲,serverless变得越来越像容器一样就某一点后复杂。

这导致了一个混合的方法实现serverless容器。最大的外卖从serverless容器是“我们如何能使容器尽可能简单运行吗?然而,我们仍然不能妥协的控制。我们仍然需要获得最好的硬件、网络、存储、和更多的,这比serverless接近容器提供的东西。

Kubernetes带来两全其美——简单和控制

快进到今天,集装箱和集装箱编配变得容易得多。Kubernetes已成为事实上的容器在云中协调器,由于其活跃的社区,它变得更简单的管理。Kubernetes能够交付的易用性serverless承诺但不影响控制。

说,容器和serverless之间的组织选择,问题是:

1. 我们的平台是什么工具?
2. 我需要什么工具我DevOps团队和操作团队吗?
3. 我的操作团队可以处理服务失败?

当你开始运行数百万每秒事务数,性能优化、成本效率和应用程序级别以下的元素都很重要。serverless你仍然需要支持所有你即使你靠着别人部署到运行您的代码。你需要当一个服务下降的备份策略。虽然很容易开始,serverless无法继续操作简单,你需要成熟。这尤其适用于大型组织。厂商锁定等缺点,缺乏开放源码工具,和一个偏向现代应用程序在遗留的几率重的容器。

容器允许组织运行的遗产和现代应用程序的方式允许DevOps团队和工程师一起快速行动。这给了他们灵活地选择任何他们想去的云或系统。容器很容易使应用程序规模。

当然,它有助于从serverless获取知识并将它们应用于容器管理。然而,对于大型应用程序和大型组织,容器真的改变了应用程序部署到生产环境,以及他们使用云计算的方式。

如果你正在寻找一个混合容器和serverless,AWS Fargate允许您运行容器serverless环境。当然你失去控制底层基础设施和成本高。另一个选择(附近和亲爱的人在辨别NetApp)海洋的地方。它提供了免提,serverless-like体验,提供深度控制基础设施层,以及提供戏剧性的降低成本和性能保证。

serverless——自己的少,建造更多

首先要注意serverless是它并不像容器一样受欢迎。有口袋的行业serverless使用取得了巨大的成功。例如,亚马逊说他们使用Lambda运行大约一半的新发展。然而,serverless和法斯作为一个代码航运范式不是渐渐接管世界一些认为这可能。λ最近宣布,他们将支持容器的包装不仅抽象为λ和zip文件。这证明容器已经赢得了战役包装抽象。然而,这并不是故事的全部。

serverless心态比包装抽象,和现在是最大的范式转变发生。这种心态可以被描述为建造更多的少。有很多的例子,这种心态在DynamoDB等服务,Zapier,为什么Twilio, Auth0,和条纹。所有这些服务中断应用程序工作流程的小块组织自己管理,组织可以使用的东西,这样他们可以更加关注构建真正重要的是什么,比一个堆栈的管理和维护。

容器的心态,另一方面,是关于交付我们10年前相同的软件,只是用一个新的云最佳实践在其上的皮肤。对于很多遗留的用例很好,但最终,容器是重新包装过去,而serverless畅想未来。

有三个serverless反直觉的原因是奇妙的。让我们看看他们每个人。

1。Serverless违反热力学第二定律

传统的IT世界是这样,任何时候一行代码部署到生产开始腐烂。它需要不断投入工程和维护时间,代码和它运行的硬件要跟上竞争对手。serverless心态需要整个物理学的基本定律和把它在它的头上。Serverless使这些服务来获得更好的在随着时间的推移,不是更糟。这是因为总用例的serverless的成千上万的用户。的大部分基础设施抽象出来,云供应商完全控制和可以改进,所有客户受益。云服务供应商能够为各种工作负载优化性能。这就像一个伟大的蜂群思维代表你的工作。

一个很好的例子就是AWS DynamoDB。serverless数据库,DynamoDB用于运行下一个计费模型称为供应能力,你估计你想多少计算能力在你的数据库,你会每个月支付能力。然后AWS发布了一个新的支付方式DynamoDB称为“DynamoDB随需应变”你支付实际使用。这是昂贵的,如果你正在使用大量的数据,但是如果你不使用大量的数据在开发环境中或在登台环境中,DynamoDB按需每年可以节省数千美元。,只需要按需检查框——不需要工程创新能力,没有重构。的力量serverless使DynamoDB表比以前跑得更快和更少的成本。

2。Serverless是昂贵的(但这是好的)

Serverless是昂贵的,这是一件好事。原因在于,它只是钱。这是较低的值比额外的时间和脑力保持服务启动并运行。开发人员这种趋势要构建而不是购买。例如,使用开源麋鹿堆栈,而不是一个管理日志服务。但是,如果开发人员可以使用管理运行的日志服务领域专家知道日志的一切,他们可以专注于他们的核心业务。

机会有效贸易美元工程时间很少。Serverless使权衡这样过去比以往任何时候都更容易。你可以花钱的机会,腾出时间来建立长期提供更多的价值。这是另一个强大的理由赞成serverless容器。

3所示。Serverless锁你

Serverless涉及供应商锁定,或云锁定。这实际上是一件好事,和一个巨大的serverless卖点。

事实是每个人都锁在的东西。编程语言,还是建筑的选择,业务限制,或监管约束——组织陷入了选择,他们做了一些20年前他们是否喜欢与否。那么,问题是什么你想要锁上。

AWS云锁定的我是一个很好的例子,因为它在AWS云也证明了一切。这类似于活动目录是20年前认定企业认证。Active Directory总意义在这些大型企业环境,每个人都需要它,很容易找到人才来支持它,这是有据可查的。Serverless相似,尽管云锁定你能够深度利用云平台的本机内集成。有许多诱因,可以插入Lambda函数和其他管理服务。云提供商有兴趣让这对所有这些服务尽可能容易相互交谈,玩好然后让组织移动得更快,更快。

相反,与容器、组织不一定的优点避免厂商锁定虽然他们可能认为他们所做的。事实上,它往往表现为一种后门锁定,因为容器是复杂的,难以管理,我们最终将Kubernetes实例在云的手中通过托管服务提供商的和部和GKE。这些都是情况组织不想处理集装箱编配,相反,让云供应商运行容器。然而,这并不使便携式,独立于供应商的解决方案。如果你决定要搬到另一个云供应商,将会有一个高成本。它可能看起来像可移植性,但云锁在后端。

serverless心态是拥有更少,建造更多。

Serverless结构计算上运行您的代码你不管理,释放你追求真正的商业优势。它允许您编写一个函数,测试和部署,让云做最好。

结论

正如你可以告诉的,有完美的声音争论双方的辩论。这是千钧一发容器或serverless是否最适合您的组织。就容易得出一个评论CNCF谢丽尔挂的专家的辩论。她说:“从一开始就考虑第二天。因为它是很容易转移到这些技术的今天,但第二天的东西完全不同,这就是你需要做出决定。

确保捕捉整个辩论整个独家新闻,并观看一场热烈的讨论在小组成员之间。