令人尴尬的并行无服务器计算机的兴起

想象一下，一个应用程序通常需要1小时才能在单机…上运行。相反，如果您可以启动3600个lambdas，每个lambdas运行一秒来返回近乎即时的结果，会怎么样呢。

这是科幻小说吗？也许是开发人员的狂热梦想？或者可能是假新闻？

以上都不是。这是今天的现实。这句话摘自Keith Winstein在斯坦福大学举办的一次出色的研讨会，他在会上详细介绍了对计算未来的研究。

即使具有巨大实例，当计算被隔离到单个计算机时，也存在物理硬件限制。

考虑到这些约束，切分机器、旋转新实例并批量处理工作以进行并行处理是有意义的。分担负担&让多台机器参与进来。我喜欢它！

这一切都很好，但是使用这种方法有许多操作复杂性。要求数据科学家成为DevOps艺术的大师是一项艰巨的任务。

此外，将这些巨型实例保持在现成状态的成本是令人望而却步的。因此，当需要完成工作时，必须旋转新的盒子。与其他方法相比，这需要相当长的时间。

最后，由于底层架构和共享资源的“单机”性质，在此模型下仍然存在约束。

“摩尔没有免费的午餐”，因为当摩尔定律不再起作用时，处理能力似乎正在减速。来吧，量子计算！

注意：如果您对Kubernetes和针对大数据作业的横向扩展群集感到满意，以及下文所述的并行工作负载，祝您好运！下面在“无服务器计算”一节中描述的方法可以在受控服务器中使用，并带有典型的“自己管理”警告。

当利用“FAAS”时，这个视图在无服务器模型中看起来是什么样子。

像以前一样，工作被批量处理，数以千计的工人被派来处理这项任务。然而，这里的不同之处在于这些工人是如何旋转的，以及这种情况发生的速度。

“GG在启动时比Google Kubernetes引擎快45倍以上，比Spark-on-Lambda快13倍”(参见下面的GG框架)。

下面是FAAS提供者如何并行启动函数实例以响应请求的简化视图。

使用来自无服务器FAAS提供商的这种按需扩展，可以根据需要在任意数量的工作人员中启动作业。

这相当于调用数千个线程，与即时启动并行运行。

就像AWS S3是“无限文件存储服务”一样，AWS Lambda在这里被有效地用作“无限按需计算线程”。

注意：AWS帐户的软限制是1000次并发函数调用，以避免函数调用失控，但可以根据需要联系AWS取消这一限制。

任何可以以分布式方式分块和处理的进程都适用于这种大规模的并行运行时。

今天这方面最具挑战性的部分之一是，大多数软件被设计为在单台机器上运行，而并行化可能受限于本地可用的机器核心或线程的数量。

因为这种架构&“无服务器计算”非常新(咳嗽2014年)，所以大多数软件在设计上都没有利用这种方法。我认为，随着更多的人意识到这种方法，这种情况在未来会发生变化。

在我们继续之前，我强烈建议大家系好安全带，看看下面的视频。它深入介绍了几个用例&并演示了此方法的有效性。

GG框架是一个开源框架，帮助开发人员在云函数服务上使用数千个并行线程来执行应用程序，以实现接近交互的完成时间。

GG将较大的任务分解成一个中间表示形式，即一组与云无关的“块(Thunk)”。然后通过线路将其发送到给定的云服务。

其目标是向交互式用户提供结果-比在用户自己的计算机上或通过启动冷群集实现的速度快得多，而且比为偶尔执行任务维护热群集更便宜。

“PyWren公开了Python API，并将AWS Lambda函数用于线性代数和机器学习。无服务器MapReduce和Spark-on-Lambda演示了类似的方法。“。

GG在启动时比Google Kubernetes引擎快45倍以上，比Spark-on-Lambda快13倍。

每当我使用AWS Lambda时，它都会让我大吃一惊。当前执行2000个并行15分钟函数，使用快速文本进行超参数搜索。如果换成其他方式，🤯会花我几个小时的时间来做这件事。

我希望您能像我一样看到这一点；利用无服务器计算作为未来的超级计算机前景看好。

可以减少海量数据科学作业的运行时间，让科学家更快地模拟模型！搜索可以改进。可以大幅缩短软件编译和开发周期…。你说对了。

改进工具&；DX，使所有人(不仅仅是运维人员)都可以使用这些方法