写点什么

Spark 核心设计者解读 Sky Computing:关于云计算的未来构想

Ion Stoica

  • 2021-08-25
  • 本文字数:5564 字

    阅读完需:约 18 分钟

Spark核心设计者解读Sky Computing:关于云计算的未来构想

论文作者 | Ion Stoica

编译整理 | Maglish

 

UC Berkely 计算机科学与电气工程教授,AMPLab 共同创始人,Spark的核心设计者 Ion Stoica 在近日召开的操作系统会议 HotOS 上,提出了“Sky Computing”这一构想,展望超越单个云平台的公用计算未来。论文思考了该如何推动目前的差异化云计算平台逐渐发展成为一项公用服务,Stoica 称其为“Sky Computing”。论文提出实现 Sky Computing 的障碍更多来自于经济层面,而不是技术层面,对等互惠则是实现 Sky Computing 的关键步骤。Stoica 从更长远的视角对 Sky Computing 进行了设计,提出将其作为通用软件平台用于未来计算,并考虑技术趋势和市场力量如何在 Sky Computing 的实现中发挥关键作用。

计算公用设施化的愿景

 

20 世纪 60 年代,人工智能之父约翰·麦卡锡提出了把计算能力作为一种像电话一样的公用事业提供给用户的理念,云计算由此起源。麦卡锡的预测颇有先见之明,云计算最终应运而生,作为一种新兴的资源使用和交付模式逐渐为学界和产业界所认知。然而,他在经济学方面的预测却与现实相去甚远。如今电话服务并没有成为一种公用设施,而是由互相竞争的供应商提供。同样地,现在也没有单一的公用计算设施,云计算也是差异化商品。并且,云计算市场已经离商品化越来越远,甚至演变成一系列彼此基本不兼容的专有平台,例如AWS、微软Azure谷歌云等。Stoica 在新论文中提出了使云计算更加商品化的愿景,称之为 Sky Computing。

云计算的历史


因特网的出现迅速带来了全球范围内可以访问的多种服务,包括电子邮件、BBS 和游戏。万维网的出现 z 则带来了搜索、在线零售和社交媒体等新服务的爆炸式增长。为了应对由此产生的大规模服务,这些供应商必须构建数据中心,并设计自己的复杂分布式系统。许多公司都遵循了这条道路,例如雅虎、Google、eBay 和 Amazon。但是创建大规模的基础计算设施代价高昂,阻碍了了大多数公司进入互联网服务市场的脚步。

 

这种情况在 2006 年亚马逊推出 S3 和 EC2 时发生了变化。通过普及计算/存储访问,并且推广“即用即付”商业模式,亚马逊开启了云计算时代。再加上摩尔定律的终结(在本地集群中构建和扩展服务十分昂贵),重新推动了构建公用计算事业的设想。 然而,商业趋势却将云计算推向了不同的方向。

 

在过去十几年中,云计算市场内出现了多个竞争对手。根据最近的一份报告,AWS 现在仅拥有 32% 的市场份额,其次是微软 19%,谷歌 7%,阿里巴巴 6%,其他云平台(如 IBM 和甲骨文)瓜分了剩余 37%左右的云计算市场。这种竞争导致价格越来越低,产品和服务种类不断增加。例如,仅 AWS 一家就提供了超过 175 种产品和服务。这些服务中有许多是专有服务,例如,每个云平台都有自己独特的用于管理集群的 API、对象存储、数据仓库、无服务产品等等。在某个云上开发的应用程序通常不能在不同的云上运行。直到 2021 年,没有一个底层云平台有一套任何人都可以使用的开放标准,云市场的竞争使离公用计算的愿景越来越远。因此现在要解决的问题是,如何朝着计算公用设施化这一目标取得进展?

从互联网的发展中我们能学到什么

 

尽管云计算和互联网在许多方面存在差异,但是互联网的公用设施化为公用计算提供了有用的历史经验。有三个关键的设计决策使互联网能够为大量异构技术(从以太网到 ATM 再到无线)和竞争公司提供统一的接口。第一个是掩盖技术差异的“兼容性”层。 第二种是域间路由,它将 互联网粘合在一起,使其对最终用户来说是一个网络。 第三个是一组经济协议,称之为“对等”层,允许相互竞争的网络合作创建一个统一的网络。

 

为了实现计算公用设施化的愿景,应用程序应该能够在任何云平台上运行(即一次编写,随处运行)。 此外,用户不必管理单个云上的部署,也不应该面临从一个云迁移到另一个云的各种障碍。简而言之,开发人员构建多云应用程序应该像构建在单个云上运行的应用程序一样容易。Stoica 称之为 Sky Computing。使用这个术语是因为公用计算意味着基础计算设施是公用设施,而 Sky Computing 指的是在由多个不同云平台组成的基础设施上构建公用计算的愿景。

 

Stoica 认为互联网解决的这三个设计问题正是从当前的云计算中创建 Sky Computing 所需的思想。Sky Computing 需要一个兼容层来掩盖低级技术差异,一个云间层将作业路由到正确的云,以及一个对等层,允许云之间就如何交换服务达成协议。


表 1 Sky Computing 架构与互联网之间的类比

 

表 1 给出了 Sky Computing 架构与互联网之间的类比性:路由器可类比于服务器,AS 类比于可用区,而 ISP 类比于云供应商。 就像在互联网中,IP 不关心在同一 ISP 或跨 ISP 的路由器之间的路由数据包,构建在云间层上的应用程序不需要在意它所运行的云平台。

兼容层


实现 Sky Computing 愿景的第一步是提供一个云兼容层,通过抽象出云计算服务,使在该层之上开发的应用程序无需更改即可在不同的云上运行。简而言之,兼容层是一组可以构建应用程序的接口或 API,然后可以通过云平台的一组接口将该兼容性层移植到每个云。

 

该层可以类比于互联网中的 IP 层,然而与 IP 层不同的是,云兼容层明显更广泛且定义不明确,因为云平台向应用程序提供了丰富的一组服务,包括计算、存储、数据传输等。 因此,云兼容层更像一个操作系统(例如 Linux),可以管理计算机资源并向应用程序提供 API。

 

如何构建这样一个云兼容层? 虽然每个云平台都提供一组专有的低级接口,但目前大多数用户主要与更高级别的管理和服务接口交互。其中一些是专有的,但已经有越来越多的接口受到开源软件(OSS)的支持。此外,涌现出大量由 OSS 创建者创立的公司,以在多个云上提供托管服务。如果企业的应用程序使用这些基于多云 OSS 的产品,从一种云切换到另一种云就能变得相对容易。

 

兼容层可以从这些 OSS 解决方案中构建出来。例如 Cloud Foundry,是一种开源多云应用平台,支持主要的云供应商以及内部部署集群。 以及 RedHat 的 OpenShift,是一个基于 Kubernetes 的多云和内部部署平台。因此,从纯粹的技术角度来看,实现一个能够广泛使用的兼容层是很容易的。问题是市场是否会支持这一发展。因为虽然兼容层对用户有明显的好处,但它自然会使云平台商品化,这可能不符合供应商的利益。

云间层


兼容层只是实现 Sky Computing 愿景的第一步。即使兼容层允许用户在不同的云上运行应用程序,用户仍然需要决定在哪个云上运行应用程序,需要在不同云之间进行性能/成本权衡。这类似于要求互联网用户为其域间流量明确选择 AS 路径,为了解决这个问题,Internet 使用 BGP 来做出 AS 级别的路由决策。同样,Sky Computing 应该实现一个云间层,从用户中抽象出云供应商;也就是说,用户不需要知道应用程序在哪个云上运行。 云间层是在兼容层之上实现的,如图 1 所示。


图 1 可能的 Sky Computing 架构

 

通过云间层,用户可以指定有关其作业应在何处运行的策略。这些策略允许用户表达他们对性能、可用性和成本之间权衡的偏好。此外,用户可能希望避免他们的应用程序在竞争对手运营的数据中心上运行,或者留在某些国家/地区以遵守相关的隐私法规。并且云间层也可以实现更安全的应用。

 

作者相信在兼容层之上实施云间层没有基本的技术限制。因为,从性能的角度来看,跨云移动作业与跨数据中心移动同一云平台中的作业非常相似。一旦应用程序被设计为跨多个数据中心运行,剩下的跨云问题可以通过以下三个功能来解决: (1) OSS 服务的统一命名方案。 (2) 目录服务,允许云供应商注册他们的服务,并允许应用程序根据他们的喜好选择服务。 (3) 跨云计费机制。

 

服务命名方案:为了识别在特定云上运行的服务实例,需要一个命名方案来识别该实例。 一种方案是利用 DNS 来命名这些服务实例。 此外,需要将元数据与每个这样的服务实例相关联。此类元数据应包含应如何调用服务、云供应商的名称、位置、软件或 API 版本、硬件类型等。此外,可能还需要添加动态信息,如定价、负载和可用性。

 

目录服务:需要特定服务的应用程序必须找到满足其要求和偏好的服务实例,这需要目录服务。 每个云供应商可以通过提供名称和元数据信息将服务发布到该目录。此外,云供应商应定期更新其动态元数据,例如负载和定价。反过来,应用程序应该请求能够表达其偏好和要求的特定服务。收到此类请求后,目录服务将返回满足这些要求和偏好的实例。

 

计账和计费:通过 Sky Computing,用户的应用程序可以运行在多云中的一个云上,甚至同时运行在多个云上,每个云平台都必须对所使用的资源进行核算。 如果每个云平台都进行计费,那么用户需要在每个云上都有账户。有一种替代方案,让每个用户都与第三方签约,并累计费用,然后将每个用户的付款分配回各个云平台。

 

尽管仍有许多细节有待解决,但实现合理有效的云间层并没有不可逾越的技术障碍。与兼容层一样,问题在于市场是否能产生云间层。

对等层

 

云间层旨在最能满足其需求的云(或多个云)上运行作业。如果作业涉及大型数据集,需要将数据移动到将发生计算的云中。目前大多数云平台都有定价政策,将数据传入云中比将数据移出要便宜得多。例如,将数据提取到 AWS 是免费的,而将数据从 AWS 传输出去可能需要 0.05-0.09 美元/GB。作者将这种定价形式称为“数据引力”定价,它驱动用户在当前所在的云平台中处理数据。 尽管如此,对于一些计算资源比数据传输成本高得多的工作,将数据从一个云移动到另一个云仍然是最划算的选择。

 

目前,导出数据的定价政策与数据可能要去的云无关。作者提出了“互惠数据对等”方案,迄今为止还没有看到对此类方案的探索。在这种方案下,云间可以通过建立高速连接互相免费传递数据。使数据传输又快又便宜,降低两个同级云之间的数据重力,并实现更大的工作流动自由。

未来展望

 

虽然兼容性层的实现几乎没有技术障碍,但它会使云计算商品化。因此,作者预计现有的云供应商会抵制兼容层的出现。然而,与其他需要通用协议才能标准化的领域(例如网络中的数据包格式)不同的是,兼容层的软件可以移植到任意云。因此,大型云供应商如果不正式支持兼容层,用户可能会选择使用兼容接口,而不是云供应商的低级接口,以保持可移植性。

 

此外,虽然大型云供应商可能对兼容层不满意,但我们预计小的云供应商会接受这样的层。对于较小的云供应商,提供专有接口可能不如采用更广泛支持的标准。通过这样做,这些较小的供应商能获得更大的市场份额,并可以在价格、性能或各种形式的客户服务方面展开竞争。目前市场上已经出现了这样的情况,谷歌最近发布了 Anthos,是一个基于 Kubernetes 的应用程序管理平台,支持“一次编写,随处运行”。Anthos 已经在 Google Compute Cloud (GCP)和 AWS 上运行,Azure 很快就会跟进。因此,较小的云供应商最好支持 Anthos,而不是用他们自己的专有接口与之竞争。

 

一旦兼容层获得关注,就可以开发云间层。 问题是:谁会从它的发展中受益?作者认为,一旦兼容层和云间层到位,云供应商将分为两类。一部分独立的云供应商试图通过专有接口和数据导出费用来锁定客户。 通常是大型供应商,因此他们有资源提供各种专有服务。 但是,作者认为会有商品化的云平台直接支持兼容层,并同意与其他云平台进行互惠数据互传方案。 这些云平台的供应商作为一个整体,便构成了 Sky Computing,为这些异构和互相竞争的云供应商提供了统一的接口。

 

为什么我们相信 Sky Computing 会实现?它取决于两类供应商的创新性质。在竞争激烈的市场中,独立的云供应商相互竞争,并与 Sky Computing 竞争。而商品化的云供应商也在 Sky 内部相互竞争,并集体与独立供应商竞争。 在权衡方面,独立供应商有更高的利润,但必须全面创新以保持其专有接口的优势。相比之下,商品化供应商的利润率较低,但可以进行一些专有创新。也就是说,供应商可能专门支持一项或多项服务;Sky 中的工作需要从哪项专业服务中受益,便迁移到那里。例如,Oracle 可以提供数据库优化的云,而像 EMC 这样的公司可以提供存储优化的云。此外,硬件制造商也可以直接参与云经济。例如,三星能够提供性价比最高的云存储,而英伟达可以提供硬件辅助的机器学习服务。像 Cerebras Systems 这样的公司可以提供基于其芯片的服务。Cerebras 只需要提供处理服务,客户所需的所有其他服务都可以在现有的云平台中运行。相比之下,现在像 Cerebras 这样的公司只有两种选择:让 AWS、Azure 或 GCP 等大型云供应商之一来部署其硬件,或者构建自己的全功能云。这两条路都是令人望而却步的提议。

 

然而,这种生态只有在云间层可以找到这些加速服务时才会有效,因为大多数个人用户不会了解 Sky 上各种服务的相对性能。 因此,要实现 Sky Computing,需要所设计的三个层都有效:兼容层隐藏云之间的实现差异;云间层自动寻找各种服务的最佳性价比;互惠对等,使数据免费和快速地在云间传递。

 

这篇文章并不是预测专有云会消亡。从长远来看,市场将继续拥有这两种供应商。独立供应商将迎合那些需要更多帮助且价格和性能不是关键因素的客户。然而,大部分计算密集型工作负载更适合 Sky Computing,因为可以实现更多的创新。

 

这一推理路线纯粹是推测性的。目前即使是较小的云平台供应商也没有采用兼容层,因为他们还没有看到这样的层能增加他们的收入(因为每个人都在与更大的云供应商竞争)。 然而,如果这些供应商都同意互惠对等,那么 Sky 将成为与大型专有云的竞争平衡点。

结论


在这篇论文中,Stoica 提出了 Sky Computing 这一构想,介绍了从云计算转变为 Sky Computing 之前必须克服的一些挑战,这将使我们更接近麦卡锡的计算公用设施化概念。 其中一些挑战纯粹是技术性的,并且很可能是可以实现的。然而,为了使经济激励发挥作用,Sky Computing 需要云供应商采用互惠数据对等策略,以便工作负载可以在这个庞大的云集合中轻松迁移。本文旨在确定这是组织云市场的一个关键步骤,并希望为实现 Sky Computing 这一愿景创造动力。


论文原文链接:https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s02-stoica.pdf

2021-08-25 16:434353

评论 1 条评论

发布
用户头像
一种云计算公用方案,对云的使用者来说,解决了他们哪些痛点了?
2021-08-28 12:06
回复
没有更多了
发现更多内容

我用ChatGPT,给RabbitMQ加了个连接池

Java你猿哥

Java 源码 ssm RabbitMQ ChatGPT

直击灵魂!美团大牛手撸并发原理笔记,由浅入深剖析JDK源码

做梦都在改BUG

Java 并发编程 多线程 jdk源码

红旗软件正式发布龙蜥社区版国产高可靠操作系统

OpenAnolis小助手

Linux 开源 龙蜥社区 红旗软件 社区版操作系统

浅谈财务共享未来发展趋势

用友BIP

业财融合 财务共享

发挥数据价值!数据驱动的日志解析与异常检测方法介绍!

嘉为蓝鲸

日志分析 管理日志 日志统计

云图说丨初识商标注册服务

华为云开发者联盟

云计算 后端 华为云 华为云开发者联盟 企业号 5 月 PK 榜

背完这套Java面试八股文,自动解锁面试牛逼症被动技能

Java你猿哥

MySQL redis java面试 java基础 分布式微服务

嘉为蓝鲸CMP多云管理平台解决方案成功入选!

嘉为蓝鲸

多云管理 IT运维 蓝鲸

不吹不黑!阿里新产微服务架构进阶笔记我粉了!理论实战齐飞

做梦都在改BUG

Java 架构 微服务 Spring Cloud

40亿个QQ号,限制1G内存,如何去重?

Java你猿哥

Java ssm 布隆过滤器 BitMap 过滤器

使用 PAI-Blade 优化 Stable Diffusion 推理流程(二)

阿里云大数据AI技术

人工智能 优化 推理 Stable Diffusion 企业号 5 月 PK 榜

企业研发效能度量利器,华为云发布CodeArts Board看板服务

华为云开发者联盟

云计算 后端 华为云 华为云开发者联盟 企业号 5 月 PK 榜

全新一代小度智能屏X9焕新上市 正式开启预售

Geek_2d6073

ps vs top:CPU占用率统计的两种不同方式

极限实验室

Linux 运维 监控系统 INFINI Console

百度工程师移动开发避坑指南——Swift语言篇

百度Geek说

swift 移动端 开发语言 企业号 5 月 PK 榜

AntDB数据库参加开源数据库技术沙龙,分享全栈业务能力

亚信AntDB数据库

AntDB AntDB数据库 企业号 5 月 PK 榜

实例解读华为云数字工厂平台的逻辑模型编排器

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 5 月 PK 榜

Velocity不用愁!Velocity系统的前端工程化之路 | 京东云技术团队

京东科技开发者

Java 前端工程化 Web H5 Velocity.js 企业号 5 月 PK 榜

又爆神作!阿里首发并发编程神仙笔记,差距不止一点点

做梦都在改BUG

Java 并发编程

GitHub上13个高赞Java项目推荐,会一个就能跟面试官谈笑风生

Java你猿哥

Java 微服务 秒杀系统 网约车项目 java项目

SpringBoot 中实现定时任务的几种方式

做梦都在改BUG

Java Spring Boot

涅槃重生!字节大牛力荐大型分布式手册,凤凰架构让你浴火成神

Java你猿哥

架构 Kubernetes 分布式 架构师 分布式架构

为什么老有人想让我们“程序员”失业?征文获奖作品合集

InfoQ写作社区官方

技术专题合集 热门活动 三周年征文

阿里SpringBoot实战手册横空出世!从此不再是易学难精

做梦都在改BUG

Java spring 微服务 Spring Boot 框架

还在服务器上捞日志?试试这款可视化监控系统吧,真香!

Java你猿哥

Java 日志 ssm 监控系统 Frostmourne

理解JVM工作机制(二) 对象的创建

Geek漫游指南

Java JVM Java web

现代应用开发模式:PWA vs 小程序

Onegun

小程序 PWA

Scrum的三个工件(产品Backlog、Sprint Backlog、产品增量 )

顿顿顿

Scrum 敏捷 敏捷开发管理 敏捷开发管理工具

最高奖金100万!第二届广州·琶洲算法大赛火热报名中

飞桨PaddlePaddle

百度飞桨 算法大赛

胜面试官半子!阿里SpringBoot全栈笔记首发,源码实战齐飞

做梦都在改BUG

Java spring 微服务 Spring Boot 框架

Spark核心设计者解读Sky Computing:关于云计算的未来构想_语言 & 开发_InfoQ精选文章