2018年关于无服务器含义的几个观点 - Subbu的博客

我们需要几乎瞬时的资源弹性，而不必预先分配资源或支付超出需要的资源。我们还希望将所有运行最佳实践融入运行时，以免我们担心代码运行得几乎是低级自动化，低操作性和低健壮性，这是近十年来云计算最基本的两项追求，无服务器是实现这些机遇的最接近的。

然而，当我回顾2018年时，我发现在消息，价值和方向等方面：有许多框架可供使用，出版了大量书籍，并在全球范围内就此主题召开了多次会议，这些其实无关紧要，更重要的是，企业是否会持续采用，我们慢慢会意识到好处。

阻碍我们的可能是我们的心智模型和无服务器的观点。正如最近的一篇论文“ 无服务器计算：前进一步，后退两步 ”所指出的那样，“无服务器计算的概念足够模糊，允许乐观主义者对它可能意味着什么进行任何可能的广泛解释。”我不得不表示同意。

在这篇文章中，我想总结三个当代关于无服务器的观点，以及这些观点的含义。我的目标是表明我们的观点决定了结果，除非我们改进观点，否则我们可能找不到更好的未来。

1.像其他人一样管理服务器
在此视角中，无服务器功能将运营职责转移到提供者，因此，作为无服务器功能的使用者，您不必考虑管理服务器。因此，服务器配置，操作系统升级，维护，容量管理等所有相关职责从消费者转移到能力提供者。据认为，这种观点可以让您免于思考“运营”并让您专注于您的代码。
在极端情况下，您可以扩展此视图以将其他人运行的任何服务归类为无服务器。在这里，我使用维基百科对服务的定义为“可以远程访问并独立操作和更新的独立功能单元”。Kelsey Hightower的推文下面的幻灯片举例说明了无服务器作为运营结构的这一观点。在撰写本文时，我不知道这张幻灯片的原作者。
如果无服务器是一个可操作的构造，这是否意味着我的本地堆栈也可以是无服务器的，只要其他人而不是我做所有的操作即可？ -  @kelseyhightower
根据这种观点，任何云服务都有资格成为“无服务器”。您可以根据获得灵活性，弹性和成本效率的难易程度，通过其“无服务器程度”对每项服务进行评级。服务越容易获得这些品质，能力就越“无服务”。这就是你在上面的幻灯片中从左到右看到的内容。
在描述“后端即服务”（BaaS）时，CNCF的无服务器工作组也属于这种观点。
后端即服务（BaaS），它是第三方基于API的服务，可替代应用程序中的核心功能子集。因为这些API是作为一种自动扩展和透明操作的服务提供的，所以开发人员认为这是无服务器的。

BaaS是描述多租户中间件服务的行话。
这种观点的一个关键限制是它让你专注于将后端重活外包给提供者，却忽略了无服务器的关键属性，这就是无服务器还包括一个编程和运行时环境，让你编写和运行你的码。

例如，比较亚马逊的S3和Lambda。两者都是多租户，弹性，自动配置，按使用付费的服务，虽然前一个为您提供存储对象的API，而另一个为您提供一个自以为是的编程框架和运行时编写和运行您的代码。

此视图还支持像AWS这样的云提供商运行许多托管服务，就像您在上面的幻灯片中看到的那样，但不支持当今存在的可移植开源无服务器框架。大多数开源和第三方无服务器解决方案都要求您自行配置一些资源并对其进行管理。例如，在Kubernetes上运行OpenFaaS或Kubeless等框架并不是[url=https://kubeless.io/]无视[/url]服务器，因为您仍需要配置，管理，升级和保护Kubernetes集群。

2.无服务器作为函数和事件的视角
从这个角度来看，无服务器是一种编程模型，为声明性配置触发事件的小代码函数单元组成。微服务的概念匹配其逻辑极限。在此视图中，函数和事件是面向开发人员的编写应用程序的抽象。
此视角完全侧重于面向开发人员的抽象，根据这种观点，任何使用函数和事件作为抽象的框架都是无服务器的。时候操作运行时所需的资源无关紧要。
我听说其他基于Kubernetes的函数框架的支持者表达了类似的观点。由于这种视角不关注谁运行服务器，它为几个开源项目提供了最广泛的保护，以提供创新和有趣的功能和基于事件的编程框架。
虽然开发人员的经验非常重要，但这种观点忽视了诸如弹性，成本效率和降低运营开销等属性。您可能还想知道这个视角是否只是AWS Lambda的逆向工程，无需成本和运营效率即可重新创建开发人员体验。

3.无服务器作为服务功能（FaaS）的视角
这种视角是最常用的无服务器视图，描述了2014年AWS Lambda最初提供的内容，现在又有一些其他云提供商。它结合了函数和基于事件的无状态编程模型，以及作为服务提供的运行时。此外，您还可以访问用于中间件功能的丰富云服务。

虽然这种观点很好地服务于某些无状态的应用程序模式，但它也使我们无法超越函数和事件。我们无法以松散耦合的无状态短暂事件触发函数的形式表达世界上今天和明天的编程问题。

没有其他工作能够比最近发布的加州大学伯克利分校论文“ 无服务器计算：前进一步，后退两步 ”更好地描述这种鸽子的后果。以下是该文的一些示例亮点。

• 对于模型训练问题：“Lambda的有限资源和数据传输架构意味着在Lambda上运行此算法比在EC2上运行慢21倍，并且价格高出7.3倍。”
• 对于通过批处理问题提供的低延迟预测：“这个”服务器“版本（分别用EC2和ZeroMQ替换Lambda和SQS）的每批延迟为2.8ms - 比优化的Lambda实现快127倍。”括号是我加上的。
• 对于分布式计算问题：“在（无法实现的）最佳情况下 - 当每个领导者在加入系统后立即当选时 - 系统将仅在领导者选举协议中花费1.9％的总时间。即使您认为这是可以忍受的，请注意使用DynamoDB作为细粒度的通信介质是非常昂贵的：支持1,000个节点的集群成本至少每小时450美元。“

接下来是什么？
这些观点在哪里引导我们？离我们今天不远的地方。
虽然我无法写出具体数字，很可能不到当今全球计算容量的1％的几分之一用于运行无服务器工作负载。因此无服务器的机会几乎是无限的，很明显，今天对无服务器的看法不会让我们为大多数编程问题提供近乎瞬时的弹性，成本和运营效率。假设我们拥有解决所有当前和未来编程问题所需的所有无服务器原语是愚蠢的。
然而，我对未来充满希望。我也期待着我们承认事件触发函数作为面向抽象的主要开发人员只是几种可能性之一，我们需要新类型的框架作为服务来解决其他类型的问题。
明天的无服务器产品很可能是“作为服务的框架”，“函数即服务”只是解决某类无状态编程问题的一种可能性。