编者按：作者 Justin 详细介绍无服务器云的两种产品形态及各自的利弊，并指出：为真正实现无服务器计算的理想，我们需要重新思考当前的计算和安全模型。虽然挑战很大，但回报更大。希望本文能帮您的团队用好「知晓云」作为无服务器云计算的优势。
每年软件工程行业都会出现数十种新工具和新趋势。现在我已经有一段时间了，我想我应该继续发表一些预测，类似一个像样的雷达：哪些趋势将对哪些趋势产生持久影响，哪些趋势会失败。可以肯定的是，我已经做出了一些令人尴尬的预测，例如：曾和我的一个朋友打赌说 Git 会输给 Mercurial，因为 Git 的用户体验太可怕了。我们都知道结果如何。
但总的来说，我认为我非常清楚哪些技术将成为赢家，哪些技术将成为输家。当谈到无服务器计算时，我不需要使用任何专业知识。
等等，你在说什么？
是的，你没看错。无需预言家就能看到无服务器计算是未来。没有人愿意管理服务器。管理服务器是想要执行代码的一个令人讨厌的副作用。我需要一个安全的环境来运行代码，并且由于我们的计算都基于「冯诺依曼架构」，我需要一些内存、一些磁盘空间和一个处理器。只要我有足够的东西，这些东西采取什么形式组合起来跑业务软件并不重要。我的业务代码需要这三者中的一部分，并且我需要一个环境来托管这些业务软件。就这么简单。
我希望实现这一点并不意味着我想管理服务器或它所运行的环境。理想情况下，我会去找云服务商并说：「这是我的应用程序，麻烦帮我运行它。」
在我们开始之前，让我们一起来了解一下无服务器到底是什么。你会看到一些无服务器的定义，说它根据需要提供计算资源。虽然这是一个纯粹的定义，但更常用的更广泛的定义是：它是以一种不需要您考虑管理服务器的方式提供计算资源的方式。
Heroku、Netlify、AWS ECS/EKS Fargate、Google Kubernetes Engine 和 Azure Kubernetes Service 等无服务器容器服务为您提供了一个环境，您可以在其中构建容器并将其推送到管理容器部署和执行的服务中。您不必担心运行托管您的控制服务器、节点服务器等资源如何组合为集群，您只需推送一个包含一些元数据的容器，其余的运维任务交给服务商平台处理。
AWS Lambda、Google Cloud Functions 或 Azure Functions 等无服务器函数是提供软件运行环境的服务，您可以在其中推送具有特定接口的代码块，然后再调用该代码。
许多人不认为无服务器容器是真正的无服务器，因为当您构建和推送容器时，您实际上是将整个服务器捆绑在一个漂亮的软件包中。虽然我倾向于同意它们不是「真正的」无服务器，但与运行完整的虚拟机相比，它们绝对具有巨大的优势，并且在某些情况下与无服务器功能相比具有明显的优势。
与传统服务器相比，无服务器容器有很多优势。这里有几个：
很少的服务器管理 —— 无需管理、修补或排除故障的服务器。您仍然在容器内有一个操作系统，但这可能是一个非常小的安装，并且需要你亲自管理的系统依赖对比（虚拟）服务器要小得多。
通常是无状态的 —— 在构建为容器设计的应用程序时，您通常会构建一个「12 要素应用程序」或遵循类似的模式。你的容器是牛，不是宠物。如果您的容器崩溃，则会自动启动一个新容器。
轻松的水平可扩展性 —— 虚拟机本身在可扩展性方面没有任何限制，但容器将您推向一个方向，允许无服务器容器服务根据需要轻松扩展您的软件。根据负载、时间和请求计数等因素，无服务器容器服务可以运行一个容器实例或 10,000 个容器实例，同时透明地处理存储分配、负载平衡、路由等。
安全性 —— 安装在容器中的操作系统通常是短暂的、非常小的，有时是只读的。因此，与典型的通用和长期服务器环境相比，它的可进行网络攻击的总面积要小得多。
源代码控制环境 —— 您的容器定义在可以放入源代码控制的文件中进行描述。虽然这在当今几乎任何情况下都是最佳实践，但与传统的服务器环境相比，它仍然是一个明显的优势，在传统服务器环境中，别人时不时还可以登录进入并更改服务器配置导致意外的配置不一致。
应用程序和环境捆绑 —— 您将应用程序与其运行的环境结合起来，并将其部署为一个单元。这样，如果您的软件的新版本使用更新的库、操作系统版本或新的语言版本，它都可以作为一个单元进行部署和回滚。
成本 —— 您可以轻松地向上和向下扩展工作负载。虽然运行无服务器容器可能会贵一些，但通过一些服务平台工具协助，您可以在灵活性上获得弥补。与传统的虚拟机选项相比，无服务器容器通常为您提供更大的灵活性，可以将资源分割成更小的单元。例如，一个 EC2 T3 nano 实例提供 2 个 vCPU，但您可以请求一个只有 0.25 个 vCPU 的容器。
无服务器函数云计算具有无服务器容器的所有优点，但将其提升到另一个层次。
几乎零管理 —— 在大多数情况下，您根本不需要考虑操作系统。您可以将代码向上推送，然后运行它。在操作系统级别没有什么需要修补，也没有什么需要维护 —— 只需推送并忘记它。
默认情况下是无状态的 —— 无服务器函数迫使你以无状态的方式编写代码，因为你不能依赖不同的调用之间留下的任何东西。这使得它们可以轻松扩展，因为您的函数可以在任何服务器上启动，而无需依赖于本地状态。
几乎完美的水平可扩展性 —— 某些东西会调用你的函数，然后它就会运行。如果它被调用一次，那么它运行一次。如果它被调用 100,000 次，那么它会运行 100,000 次。当然，有一些平台限制可能会发挥作用，但这些通常是防止您意外花费 10,000 美元的保障措施，而不是平台的限制。
成本 —— 无服务器函数计算仅在执行时才会计费和扣费。因此，如果您的功能很少执行或者非常突发，您可以节省大量云计算费用。
轻松迁移 —— 如果你有一个现有的应用程序，它可能需要运行一些计算任务，但你可以让它在容器内运行。
稳定的工作负载且更便宜 —— 如果你有一个一致的工作负载，那么无服务器容器可能会比无服务器函数的等效调用更便宜。
灵活性 —— 您的操作系统、二进制文件、语言、版本等没有任何限制。您可以控制整个容器。无服务器函数服务将限制您使用特定的运行时和版本。一些无服务器函数服务允许自定义运行时，但您仍将被锁定在操作系统中。
故障排除 —— 容器让您可以轻松进入并排除实时环境中发生的问题。它们还允许您在本地运行大部分环境，从而更容易调试正在发生的事情。
长时间运行的任务 —— 无服务器容器是始终运行的，最适合长时间运行计算任务。大多数无服务器函数都会对函数的执行时间有限制。例如，在撰写本文时，AWS Lambda 有 15 分钟的限制。
降低突发工作负载的成本 —— 无服务器函数是按调用付费的，这意味着您只需在代码实际执行时付费。这意味着对于不经常运行的工作负载，与典型的服务器或容器相比，它们可以便宜得多。
快速扩展 —— 无服务器函数服务可以创建一个新的函数实例，并在几秒钟内（有时只需几分之一秒）就可以为流量提供服务。这有一定的限制，您可以在下面的「扩展无服务器函数」部分中看到有关这些限制的更多讨论。
细粒度的可扩展性 —— 假设你有一个由几十个不同的无服务器函数组成的应用程序，其中一个函数的调用次数是其它函数的 1000 倍。该功能将独立于您的其它功能进行缩放，您甚至不必考虑它。
更重的部署 —— 无服务器容器通常需要一个大的构建步骤，然后您必须将数百兆字节的容器推送到您在云端的存储库。然后你必须在你的集群中部署你的容器，如果你有大型部署，这可能需要一段时间。这个周转时间比推动单个云函数并在几秒钟内启动并开始服务请求要长得多。
粗略的可扩展性 —— 当你部署一个无服务器函数时，你实际上只是部署了一个函数。该函数可以执行多项任务，但通常您正在部署一个单一用途的函数，该函数可以独立于所有其它函数进行扩展。当您部署无服务器容器时，您通常会部署整个应用程序或微服务。该应用程序或微服务中的所有功能都将部署到单个容器中，因此为了扩展它，您必须启动该容器的更多实例。这意味着整个软件模块都可以作为一个单元进行扩展。如果您的部分应用程序突然出现大量访问，那么您必须扩展整个模块以增加您可以服务的流量。
缺乏控制 —— 有人管理你的代码运行的服务器。您的代码在操作系统中运行，而不是您可以控制的操作系统。
专有的 —— 无服务器函数没有任何真正的行业标准。因此，您通常使用特定服务商的工具和接口来编写无服务器应用程序。使用 AWS step 函数之类的工具可以与服务商建立强大的联系，因为跨无服务器函数的编排现在根本不是标准的。这可以让您更深入地了解特定服务商的生态系统，并使其更难切换。
重写 —— 使用现有应用程序并使其在无服务器功能中运行通常是不可能的。您几乎总是必须从头开始编写应用程序才能利用无服务器功能。
可追溯性 —— 无服务器功能与微服务具有相同的挑战，但被带到了极端。在您的系统中跟踪单个请求可能涉及数十个无服务器函数。您需要确保使用 AWS X-ray、Google Cloud Trace 或 Azure 中的 Distributed Tracking 等工具。
调试/测试 —— 您可以使用无服务器、Google Function Framework 或 AWS SAM 等工具在本地计算机上相当轻松地运行云函数，但获得真实的调用和反馈可能是一个挑战，因为云函数通常以自动化和专有的方式与云生态系统集成。此外，AWS step 函数等服务在 lambda 之间引入了一个编排层，这会使调试实时环境中发生的情况变得更加困难。
部署 —— 无服务器函数的部署可能是一个挑战，但主要是因为它们提供了鼓励不良行为的工具（如 IDE）。使用无服务器框架可以使您的部署自动化和可管理，但您需要确保您努力维护好代码设置并保持其井井有条，否则版本控制和维护数十或数百个函数将成为真正的痛苦。
在这里扩展无服务器函数需要额外注意，因为人们通常认为 AWS Lambda 或 GCP Cloud Functions 等工具是可扩展性的灵丹妙药。他们假设您只需提升您的云函数并获得几乎即时的可扩展性。但这远非事实。这些无服务器函数服务使扩展变得非常容易，但平台存在一些限制，这些限制会影响函数的扩展速度和规模。
例如，AWS Lambda 的初始每个区域限制为 1000 个并发函数调用（这是该区域中的所有函数）。此限制是作为安全限制来防止意外资源使用的，并且可以通过联系 AWS 客服来提高。
基于此，您可能认为您只需调用 AWS 客服并请求将并发调用增加到 20,000 个，然后您可以将一堆请求推送到您的 Lambda 函数并让它快速扩展到该级别以满足您的需求服务。不幸的是，这种情况并非如此。
即使在获得 AWS 客服支持以将您的并发调用限制增加到 20,000 之后，AWS Lambda 仍会将您限制为每分钟 500 个额外的并发调用，这意味着如果您从零开始，将需要将近 40 分钟才能扩展到 20,000 个并发调用能力。同时，所有无法定向到运行中的函数的访问请求都将收到 429 错误。
如果您的流量需要更多的并发扩容服务，您可以购买亚马逊所谓的「预配置并发」。这将使一定数量的 Lambda 函数保持活跃并随时可用，但随后您将放弃无服务器函数的一些好处，因为您需要为保持它们始终运行而付费。但是，在某些情况下，这是值得权衡的。
还有人担心单个函数会耗尽特定区域可用的所有并发服务资源。您可以为特定函数配置「保留并发」，以确保它们的并发不会被其它函数完全消耗。但是，假设您的总并发数为 5000，并且您将函数的保留并发数设置为 1000，那么您将只剩下 4000 并发数用于该区域中的其余函数。
虽然其中许多设置对于提供安全和可用的软件运行环境是必要的，但它可以让刚接触无服务器函数的开发者们感到意外。
几乎所有的云平台都会抓住一切机会锁定你，Serverless 也不例外。 但是，与无服务器容器相比，无服务器函数更关注供应商锁定。 调用、部署、编排和分配函数的方式都取决于您使用的无服务器云供应商。
像 Knative 这样的项目在创建标准环境方面取得了进展，公司可以使用该环境来部署无服务器工作负载，但一般来说，您必须部署和管理平台本身才能获得好处。这可以消除以无服务器方式运行代码的许多好处。目标是避免运行基础设施，对吗？我应该提一下，您可以通过 Google Cloud Run 获得对 Knative 的原生支持，并且通过一些努力，您可以在 AWS Fargate 上运行 Knative。
听起来我们不喜欢无服务器函数计算，但事实并非如此。我们只是认为它们的用途比无服务器容器更有限。在某些用例中，无服务器函数是完美的解决方案。令人惊讶的是，这通常是您需要与底层云平台进行强大集成的时候。假设您要将图像上传到 S3，并让它自动触发以某种方式处理它的云功能；或者您有来自 Cloudwatch 等日志服务的日志数据，并且您想要一段代码来轻松分析日志流。这些都是无服务器功能真正展示其价值的场景。它们也适用于您拥有少量热端点的地方，您希望以不同于应用程序的其它部分的方式进行计算能力扩展。
如您所知，在大多数情况下，我们仍然推荐无服务器容器。但是你不会看到我们高兴得跳起来，因为无服务器容器并没有提供无服务器计算的终极理想。无服务器计算的终极理想是什么？我很高兴你问这个问题。
无服务器计算的终极理想是真正的「普适计算」。当我需要它们时，我的所有资源都可用，因为我需要它们。能够上传一大段代码（无论是单个函数还是整个应用程序）以及一些元数据，并让它以允许无限扩展的方式运行（有一些安全限制）。根本不必考虑它需要多少内存、存储或计算，它只是自动计算出来。无服务器函数实际上比无服务器容器更接近这一理想，但由于上述原因，它们仍然没有达到这个终极理想。
请不要将这篇文章解释为：我认为无服务器函数或容器服务尚未准备好，并适合现实世界中投产使用。对于大多数组织来说，运行服务器对他们来说应该与自己能发电一样重要（一些大型组织需要两者都用！）。使用无服务器云计算，您的代码仍在某处的服务器上运行，而不是您必须关心的服务器。这确实应该是大多数组织的长期目标，能够将一大块代码推送到服务平台并让它运行。无服务器计算还不能完全实现「 推送即忘」的代码更新梦想，但我们正在接近这个梦想。
无服务器计算已经到来，并且将继续存在。我们将继续看到无服务器服务越来越接近本文描述的理想状态。但是，尽管 Serverless 确实已经长大，但我们还有很长的路要走。为了真正实现无服务器计算的理想，我们需要重新思考当前的计算和安全模型。虽然挑战很大，但回报更大，所以我们可能会比我们想象的更快到达那里。
（作者：Justin Etheredge；封面图：Ivan Cujic）
加载中,请稍侯......