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