点击查看目录
本文为翻译文章，点击查看原文。
让我们来看看 Serverless 与容器的采用率、工具支持以及围绕 Serverless 和容器化的其他争论。
在 Serverless 和容器中，我们有两种令人惊叹的技术，可以为工程师提供高效的，与机器无关的抽象。然而，两个阵营之间似乎存在着不可逾越的鸿沟。
如果你读过我在过去两年写的任何内容，你就会知道我坚定地站在 Serverless 阵营。但我也是容器的早期采用者。在 Docker 达到 1.0 里程碑后不久，2015 年初我的第一个容器化项目问世。
这篇文章不是为了再次引发阵营战争或宣布某个阵营的胜利。相反，我将尝试客观地看待 Serverless 和容器的状态，根据它们提供的利弊权衡，并对未来的情况给出诚实的看法。
鉴于 Serverless 和 FaaS 函数即服务（FAAS）通常已经可以互换使用，为了本文的目的，我将限制 Serverless 的定义为 FAAS 产品，例如 AWS Lambda。
容器状态
自从 Docker 早期可用以来已经走过了漫长的道路。随着我们在容器上运行的系统越来越复杂，我们的需求已经催生了丰富的工具生态系统。
AWS 还拥有自己的托管容器服务 ECS。这提供了与 AWS 生态系统其他部分更紧密的集成。
如服务网格也正在获得可见性和被采用。它们将常见的交叉问题（例如跟踪和断路器）移出应用层。通过解决基础架构层中的这些问题，它们为这些挑战提供了语言和运行时无关的解决方案。这使它们非常适合现代 IT 组织，即使用各种不同语言的构建微服务。
Serverless 现状
虽然围绕 Serverless 的炒作并没有和容器一样长。值得记住的是，在 Lamber 达到 1.0 之后仅一个月，AWS Lambda 就在 2014 年发布了。它随附了 CloudWatch 的基本日志记录和监视支持，即使我们现在依赖的许多事件源（例如 API Gateway）都是在之后引入的。
除了这些托管服务之外，还有一些解决方案可以让您在自己的 Kubernetes 集群上运行 Serverless。其中包括谷歌和合作公司最近宣布的 Knative。虽然这些解决方案试图满足许多开发人员的需求，但我感到他们放弃了 Serverless 的最佳功能——不必担心服务器！
采用趋势
根据一些调查和研究，Serverless 和容器的采用正在快速增长。以下是我认为的一些亮点。
- A Cloudability 发现，2017 年第四季度 AWS 用户的容器采用量增长了 246％，高于第三季度的 206％。同时，同一项研究发现，2017 年第四季度 AWS 用户 Serverless 采用量增长了 667％，高于第三季度的 321％。
- Serverless 公司最近发现，2018 年有 82％的接受调查的人员使用 Serverless，高于 2017 年的 45％。超过 53.2％的人表示他们使用 Serverless 技术对他们的工作至关重要。
- Serverless 公司的调查还报告说，在采用 Serverless 之前，24％的接受调查的人员对公共云的使用经验有限或为零。20.2％的为拥有 1000 多名员工的大型企业工作。
- Logz.io 的 DevOps Pulse 调查发现，在 2018 年，60.71％的接受调查的人员采用了容器编排，高于 2017 年的 42.11％。
有趣的是，DevOps Pulse 调查显示，Serverless 采用率比其他报告小得多。从 2018 年的 30.55％（2017 年）上升到 42.58％。这可能与其接受调查的人员的分布有关。其中 28.54％认为自己是开发者，而 44.26％认定为 DevOps、DevSecOps、SysAdmin 或 SRE。
这与我在容器和 Serverless 阵营之间的上述鸿沟的经验一致。那些认为自己是开发人员的人更倾向于 Serverless，而那些被认为是 DevOps 的人更有可能选择容器。
控制与责任
关于 Serverless 与容器的争论通常始于控制，或者在 Serverless 的情况下缺乏控制。这不是新的。事实上，我清楚地记得当 AWS 在 2009 年开始获得牵引力时围绕控制的相同辩论。现在 10 年后，尘埃落定于原始辩论，但我们未能吸取教训。
想要控制是人的本性，但你愿意为此付出多少钱？您知道您将承担的总体拥有成本（TCO）吗？
控制自己的基础设施的能力带来了很多责任。要承担这些责任，您需要拥有组织中的相关技能。这意味着工资（很容易成为大多数组织的最大开支），代理费以及从工程师和经理那里抽出时间进行招聘和入职。
考虑到所涉及的 TCO，具有该控制的目标必须是针对某些事物进行优化（例如，为业务关键工作流程实现可预测的性能），并且不为其自身控制。
构建基于容器的通用计算平台需要大量的工程专业知识和投资，该平台与 AWS Lambda 等 Serverless 产品一样高效，可扩展且具有弹性。大多数组织根本没有能力解决这个问题。尽管有大量的时间和金钱投入，但我知道一些大企业在他们的尝试中惨遭失败。
工具支持
使用 Serverless，您可以从 box-logging，指标和跟踪中获得基本的可观察性工具。尽管有这些警告，但一开始它们通常就足够了。
传统上迎合 IAAS 或容器市场的供应商也开始为 Serverless 应用程序提供支持。但是，他们需要调整自己的方法，因为 Serverless 无法再使用基于代理的方法。
还有越来越多的供应商专注于解决 Serverless 应用程序的可观察性和安全性问题。但是，大多数仍处于开发的早期阶段，尚未准备好进行严肃的生产使用。
与 Serverless 相比，容器空间具有更成熟和多样化的工具生态系统。事实上，我发现使用容器的挑战之一是处理绝大多数的选择！
有充足的修补机会，我也发现团队可能会忽略奖品（即为我们的客户建立更好的产品），并陷入过度工程的陷阱。
Serverless 的工具支持将会越来越好，但至少目前，仍然远远落后于容器。在容器领域工作的人面临的挑战是抵制修补和追求简单的冲动。
供应商锁定：风险与奖励
Serverless 的批评者通常使用供应商锁定作为他们的论据。与此同时，大多数 AWS 客户实际上都在要求更紧密的集成，以便他们可以从平台中获取更多价值。
可以肯定的是，供应商锁定是一种风险。但正如任何投资者都会告诉你的那样，如果你不承担风险，你就永远不会赚钱。诀窍是采取能够带来最佳回报的计算风险。
对于它所获得的所有关注，供应商锁定对于少数人来说是一种危险。相反，您更有可能找到过度设计的解决方案来阻止供应商锁定，而不是创建其他形式的锁定，无论是内部团队还是其他私有云供应商。
同样，这不是新的。几年前我们与 ORM 进行了同样的辩论。我们创建了所有这些抽象来防止供应商锁定，除了风险从未实现为我们大多数人的问题。所发生的一切都是我们花费了大量精力和时间，并推迟了我们的产品上市时间，因为这些产品从未成为问题。
更糟糕的是，ORM 引入了他们自己的问题和复杂性，并持续阻碍了发展。它成为开发团队的一项税收，并在可预见的未来减缓了功能交付。
对于那些必须进行数据库迁移的人来说，ORM 并没有让事情变得更好。除了其他一切之外，这只是你必须处理的另一个问题。
看到历史重演，这次，甚至更高的层次可能会影响整个组织，这是痛苦的！
公司发现 Serverless 团队的工作量越来越多，工程师也越来越多。所以，就像一个明智的投资者一样，我们应该问的问题是：“重要的生产力回报是否值得锁定风险，实现问题的可能性很小？”
未来是 Serverless 还是容器？
Serverless 为您提供了大量的生产力提升，但却以控制基础架构为代价。
对于我们的许多工作流程 - 网络 API，流处理，cron 作业等 - 实际上我们不需要这些所有的控制，我们应该祝福为我们处理管道的人。
但总会出现这样的情况：我们需要保持对基础架构的控制，以便优化性能，成本或更高的可用性。或者，我们的工作量可能不利于 Serverless 的当前限制，例如最长执行时间。
我认为 Serverless 和容器应该混合使用，而不是选择其中一个。实际上，许多公司都成功的采用了混合方法。
- 对 Serverless 满足其需求的工作负载使用 Serverless
- 例如，对于以下工作负载，请使用容器;
- 长期运行
- 需要可预测的性能
- 需要比 Serverless 更容易实现的弹性
- 不断地以大规模运行，并且按次付费定价模型变得过于昂贵
这也是 Netflix 前云架构师兼现任 AWS 云计算副总裁 Adrian Cockcroft 的建议。
我相信我们最终会看到这两种范式的趋同。容器技术最终将成为 Serverless - 想想 Fargate，加上每次调用定价模型和毫秒计费。同时，Serverless 平台将开放并允许您携带自己的容器。高级用户可以通过提供符合 API 的子组件进行日志记录等来保留对其基础架构的一些控制。
随着容器和 Serverless 之间的界限被打破，我们终于可以废除派系并停止谈论底层技术。我想谈的是如何构建客户想要使用的产品，以及如何更快地构建它们。
