Paper Reading: From Cloud Computing to Sky Computing

From Cloud Computing to Sky Computing

21 年 UCB 提出了 Sky Computing 的概念，后续也有一篇 35 页的 The Sky Above The Clouds

相比起传统的云服务，sky computing 更像一个大一统的中间层，比如可以调用不同的云服务。但看他们实验室的项目已经基本都在做 LLM 相关，没有太多 sky computing 的后续了。

作者 Ion 也是 Databricks 的 cofounder，也是 spark 的原作者

Abstract

我们考虑云计算的未来，并探讨如何引导其发展成为一个更为连贯的服务，我们称之为天空计算。

主要的障碍更多是经济层面的而非技术层面的，我们提出互惠对等作为关键的推动步骤。

Introduction

In 1961, John McCarthy

“computation may someday be organized as a public utility, just as the telephone system is a public utility. We can envisage computer service companies whose subscribers are connected to them […]. Each subscriber needs to pay only for the capacity that he actually uses, but he has access to all programming languages characteristic of a very large system.”

也就是一次付费可以用多种云的服务

他简短的描述准确地描绘了我们如今称之为云计算的情景，用户可以访问大量的计算和存储资源，并且只需为使用的资源付费。相反，他对经济学的预测则大相径庭；如今，在美国，电话服务已不再是公共事业，而是通过一系列竞争的供应商提供。然而，尽管电话服务不是公共事业，但它基本上是一种商品，提供了统一的用户体验：即，无论你使用哪个供应商，你都可以联系到任何人，并且切换供应商相对容易；你甚至可以在切换时保留你的号码。

回到麦卡锡的预测，我们在这里关注的不是没有单一的公共计算事业，而是云计算并不是一种无差别的商品。与电话服务不同，云计算市场已经远离了商品化，云服务提供商通过专有服务来努力使自己与众不同。在本文中，我们建议采取一些步骤来克服这种差异化，并帮助创建一个更加商品化的云计算版本，我们称之为天空计算。在此之前，我们简要总结了云计算的历史，为本文的其余部分提供背景。

Historical Context

The NSF high performance computing (HPC) initiative in the 1980s provided an early glimpse of the utility computing vision, though limited to the HPC community

个人计算机产业由那些想要拥有自己的机器进行捣鼓的爱好者发起，并由摩尔定律推动，使得个人计算机能够迅速满足不断增长的用户需求。

互联网的出现迅速使得包括电子邮件、公告板系统和游戏在内的多种流行服务在全球范围内可访问。 许多公司，如雅虎、谷歌、eBay 和亚马逊，都遵循了这条道路，但创建大规模服务特定基础设施的责任成为了进入互联网服务市场的障碍，因为这些步骤需要巨额投资，大多数公司无法负担。

这一情况在 2006 年发生了变化，当时亚马逊推出了 S3 和 EC2，通过 democratizing access to compute/storage and promoting the “pay-as-you-go” business model.

这，再加上摩尔定律的终结（这使得在本地集群中构建和扩展服务变得相当昂贵），导致了对可能成为 utility computing 的重新推动。

然而，商业趋势将我们推向了不同的方向。在亚马逊在云计算领域占据主导地位的早期，他们为云计算设定了事实上的标准。然而，在过去十年中，这个市场上出现了多个竞争对手。根据最近的一份报告[6]，AWS 现在仅拥有 32%的市场份额，其次是微软占 19%，谷歌占 7%，阿里巴巴占 6%，其他云（如 IBM 和甲骨文）瓜分了剩余的 37%市场份额（由于四舍五入误差，这总计为 101%）。

这种竞争导致了价格的下降和产品与服务的不断增加。例如，仅 AWS 就提供了超过 175 种产品和服务[8]。然而，许多这些服务是专有的，这些专有服务是云提供商区分自己的主要方式之一。例如，每个云都有自己管理集群的 API，自己的对象存储版本，自己的数据仓库版本，自己的无服务器产品，等等。在一个云上开发的应用程序通常在不同的云上无法运行，除非进行大量修改，就像为微软 Windows 编写的应用程序需要大量修改才能在 Mac OS 上运行一样。因此，云计算市场的竞争使我们远离了公用计算的愿景。

当然，有许多呼吁标准化云计算[28, 39]，但这些对推动云计算差异化的影响甚微。当前云提供商的商业模式围绕着吸引并留住客户，这与提供纯粹的商品化服务相悖。那么，我们要解决的问题是，我们如何朝着公用计算的目标取得进展？

我们的提议被称为天空计算，意在表明我们试图超越单个云的局限。然而，我们并不是第一个使用“天空计算”这一术语的人。自 2009 年以来，几篇论文提出了以这个名字命名的设计[30, 34, 35]。然而，这些论文关注于特定的技术解决方案，例如在跨云基础设施即服务平台（如 Nimbus）上运行中间件，并针对特定的工作负载，如高性能计算（HPC）。本文对天空计算持更广泛的视角，将其作为未来应用程序的通用软件平台，并考虑技术趋势和市场力量如何在天空计算的出现中发挥关键作用。

Lessons from the Internet

尽管云计算和互联网在许多方面存在差异，但我们认为互联网提供了一组有用的历史教训。在 20 世纪 60 年代初，几个团体正在开发分组交换技术。这些早期的网络工作良好，但彼此不兼容。社区面临一个选择：是应该标准化单一的网络技术，还是能找到一种方式来容纳多样性？1972 年，罗伯特·卡恩提出了开放架构网络[32]，主张一个通用的互操作性层，允许任何两个网络互联。这成为了互联网协议（IP）。

个人觉得 Internet 和 Cloud 还是不太一样

Cloud 从本质来说就不太适合标准化，成本来说，谁便宜就用谁。

因此，有三个关键的设计决策使得互联网能够为由异构技术（从以太网到 ATM 到无线）和竞争公司组成的大型基础设施提供统一的接口。首先是掩盖技术异构性的“兼容性”层。第二是域间路由，它将互联网粘合在一起，使其对终端用户来说像一个网络。第三是一组经济协议，形成了我们称之为“对等”层，允许竞争网络在创建统一网络中合作。

互联网要解决的三个问题：

compatibility

interdomain routing

economic agreements

这对云计算有什么启示？为了实现公用计算的愿景，应用程序应该能够在任何云提供商上运行（即一次编写，随处运行）。此外，用户不应该需要管理单个云上的部署，或者在从一个云迁移到另一个云时面临重大障碍。简而言之，对于开发者来说，构建一个多云应用程序应该像构建一个运行在单一云上的应用程序一样容易。我们称之为天空计算。我们使用这个术语是因为公用计算意味着基础设施是一个公共事业，而天空计算指的是在由多个和异构的竞争商业云提供商组成的基础设施上构建公用计算的幻象。

我们认为，互联网必须解决的三个设计问题正是从我们当前的云集合中创建天空计算所需的组成部分。我们需要一个兼容性层来掩盖低级技术差异，一个跨云层来将作业路由到正确的云，以及一个对等层，允许云之间就如何交换服务达成协议。在接下来的三个部分中，我们将更详细地描述这些层。然后，我们通过推测未来来结束本文。

表 1 展示了所提出的天空架构与互联网之间的相似性：路由器类似于服务器，AS 类似于可用区，ISP 类似于云提供商。就像在互联网中，IP 对在同一 ISP 或跨 ISP 的路由器之间路由数据包一无所知一样，构建在跨云层上的应用程序应该对其运行的云一无所知。

IP 协议变成了 compatibility layer

BGP（Border Gateway Protocol，边界网关协议）是一种用于在不同自治系统（AS，Autonomous System）之间交换路由信息的协议。它是互联网的核心协议之一，负责在不同网络之间传递数据包。BGP 的主要功能是选择最佳路径，将数据从一个网络传输到另一个网络。

Compatibility Layer

实现天空计算愿景的第一步是提供一个云兼容性层；即，一个抽象掉云所提供服务的层，使得在这个层之上开发的应用程序可以在不同的云上运行而无需修改。简而言之，兼容性层是一组应用程序可以构建在其上的接口或 API；然后，这个兼容性层可以使用云的一组（可能是专有的）接口移植到每个云上。

其实 POE 这种整合了多种 LLM API 的是不是也算一种 sky computing

在我们的互联网类比中，这类似于 IP 层，它使使用不同底层（L2）通信技术的路由器能够处理 IP 数据包。然而，与 IP 不同，IP 是一个 narrow waist，云兼容性层要宽得多，定义也不那么明确，因为云向应用程序暴露了丰富的（且不断增长的）服务集，包括计算、存储、数据传输等。因此，云兼容性层在精神上更像是一个操作系统（例如 Linux），它管理计算机的资源并向应用程序暴露 API。

IP is the narrow waist 是一个比较有意思的理念

我们如何构建这样一个云兼容性层？虽然每个云都提供了一组专有的低级接口，但今天的用户大多与更高级别的管理和服务接口交互。其中一些是专有的，但越来越多的接口得到了开源软件（OSS）的支持。

这些 OSS 项目存在于软件栈的各个层次，包括操作系统（Linux）、集群资源管理器（Kubernetes [12]，Apache Mesos [31]）、应用程序打包（Docker [10]）、数据库（MySQL [15]，Postgres [17]）、大数据执行引擎（Apache Spark [42]，Apache Hadoop [41]）、流引擎（Apache Flink [26]，Apache Spark [42]，Apache Kafka [5]）、分布式查询引擎和数据库（Cassandra [4]，MongoDB [14]，Presto [18]，SparkSQL [22]，Redis [19]）、机器学习库（PyTorch [37]，Tensorflow [24]，MXNet [27]，MLFlow [13]，Horovod [40]，Ray RLlib [33]）以及通用分布式框架（Ray [36]，Erlang [25]，Akka [1]）。

此外，由 OSS 创建者创立的大量公司已经出现，为多个云提供托管服务。例如 Cloudera（Apache Hadoop）、Confluent（Apache Kafka）、MongoDB、Redis Labs、HashiCorp（Terraform，Consul）、Datastax（Cassandra）和 Databricks（Apache Spark，MLFlow，Delta）。这些发展使得企业如果使用这些基于多云 OSS 的产品，相对容易从一个云切换到另一个云。

其实现在 iceberg 等等使用 parquet 应该也是类似的理念把

虽然 OSS 在软件栈的大多数层提供了解决方案，但一个明显的差距是存储层。每个云提供商都有自己的专有高度可扩展存储版本。例如 AWS 的 S3 [2]、微软的 Azure Blob Storage [7]和谷歌的 Cloud Storage [11]。尽管如此，已经有几种解决方案为 Azure 的 Blob Storage 和谷歌的 Cloud Storage 提供 S3 兼容 API，例如 S3Proxy [20]和 Scality [21]。一些云提供商提供自己的 S3 兼容 API，以帮助客户从 AWS 过渡到他们自己的云。在下文中，我们假设兼容性层提供的存储 API 允许跨云读取数据。

因此，我们认为在纯技术基础上实现一个广泛可用的兼容性层是容易实现的。问题在于市场是否会支持这样的努力，因为虽然兼容性层对用户有明显的好处，但它自然会导致云提供商的商品化，这可能不符合他们的利益。我们将在第 7 节讨论激励问题。

Intercloud Layer

兼容性层只是实现天空愿景的第一步。即使兼容性层允许用户在不同的云上运行应用程序而无需修改，用户仍然需要决定在哪个云上运行应用程序。因此，用户仍然负责在不同的云之间进行性能/成本权衡。这类似于要求互联网用户为其域间流量显式选择 AS 路径，这将是一项繁重的任务。

为了解决这个问题，互联网使用 BGP 进行 AS 级路由决策，这些决策对用户是透明的。类似地，天空架构应该实现一个跨云层，将云提供商从用户中抽象出来；也就是说，用户不应该知道应用程序运行在哪个云上（除非他们明确想要知道）。跨云层在兼容性层之上实现，如图 1 所示。

跨云层必须允许用户指定他们的作业应该在哪里运行的策略，但不需要用户做出关于作业放置的低级决策（但如果用户愿意，可以允许他们这样做）。

intercloud 还是需要考虑不同的性能、成本和隐私等等

(1) A uniform naming scheme for OSS services.

(2) A directory service which allows cloud providers to register their services, and applications to select a service based on their preferences.

(3) An accounting and charging mechanism across clouds.

Service Naming Scheme 命名方案来标识该实例，尽管一个自然的可能性是利用 DNS 来命名这些服务实例。此外，我们需要将元数据与每个这样的服务实例关联起来。这样的元数据应包含如何调用服务、云提供商的名称、位置、软件或 API 版本、硬件类型等。此外，我们可能还希望添加动态信息，如定价、负载和可用性。

Directory service 需要特定服务的应用程序必须找到满足其要求和偏好的服务实例。这就需要一个目录服务。

Accounting and charging ，用户的应用程序可以在许多云中的一个或甚至在多个云上同时运行，每个云必须对使用的资源进行会计处理。如果每个云都进行计费，每个用户都需要在每个云上拥有账户。我们建议一个替代方案，每个用户与第三方经纪人（可能是云提供商之一）签约，该经纪人在所有云上都有账户，并累积费用，然后将每个用户的付款分配回各个云。

其实最大的问题是，谁来做 sky computing?

the issue is whether the market will produce one?

Peering Between Clouds

跨云层旨在在最能满足其需求的云（或云）上运行作业。如果作业涉及大数据集，就像许多常见的云工作负载一样，这将需要将数据移动到计算发生的云上

流量和机器比谁更加贵？

还是说数据移动才是贵的

Speculations About The Future

如上所述，虽然兼容性层几乎没有技术障碍，但它会使云计算更像一种商品。

此外，虽然大型现有云提供商可能不会对兼容性层感到高兴，但我们预计较小的云提供商会拥抱这样的层。

其实确实，不少云 DB 都会支持 aws/azure/gcp 多种云，但应该是为了满足不同客户的需求

而不是真的愿意去做大一统，不同技术兼容还是满困难和繁琐的

还是太理想，但确实可能慢慢的大家会往这个方向走