Intercloud Layer

The compatibility layer is just the first step in realising the Sky vision. Even though the compatibility layer allows a user to run an application on different clouds without change, the user still needs to decide on which cloud to run the application. Thus, users are still responsible for making the performance/cost tradeoffs across different clouds. This is akin to requiring an Internet user to explicitly select the AS paths for its interdomain traffic, which would be an onerous task.

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

To address this problem, the Internet employs BGP to make AS-level routing decisions, decisions that are transparent to the user. Similarly, the Sky architecture should implement an intercloud layer that abstracts away cloud providers from users; that is, users should not be aware of which cloud an application is running on (unless they explicitly want to know). The intercloud layer is implemented on top of the compatibility layer, as seen in Figure 1.

为了解决这个问题，互联网使用边界网关协议（BGP）来做出自治系统（AS）级别的路由决策，这些决策对用户是透明的。类似地，天空架构应该实现一个跨云层，抽象化云提供商，使用户无需知道应用程序运行在哪个云上（除非他们明确想知道）。跨云层是在兼容层之上实现的，如图1所示。

The intercloud layer must allow users to specify policies about where their jobs should run, but not require users to make low-level decisions about job placement (but would allow users to do so if they desired). These policies would allow a user to express their preferences about the tradeoff between performance, availability, and cost. In addition, a user might want to avoid their application running on a datacenter operated by a competitor, or stay within certain countries to obey relevant privacy regulations. To make this more precise, a user might specify that this is a Tensorflow job, it involves data that cannot leave Germany, and must be finished within the next two hours for under a certain cost.

跨云层必须允许用户指定有关其作业运行位置的策略，但不要求用户做出关于作业放置的低级决策（当然，如果用户希望，也可以这样做）。这些策略将允许用户表达他们对性能、可用性和成本之间权衡的偏好。此外，用户可能希望避免其应用程序在竞争对手运营的数据中心上运行，或希望在某些国家内运行以遵循相关隐私法规。为了更具体地说明，用户可能会指定这是一个Tensorflow作业，涉及的数据不能离开德国，并且必须在接下来的两个小时内完成，成本也要低于某个特定值。

The intercloud layer might also enable more available and secure applications. Indeed, since it is very unlikely that different clouds experience outages at the same time [23], an application can leverage multiple clouds to mask a single major cloud outage. Furthermore, several recent proposals treat different clouds as distinct trust domains to provide more efficient security solutions for a variety of applications [29, 38, 43].

跨云层还可能使应用程序更具可用性和安全性。实际上，由于不同云同时发生故障的可能性非常小【23】，应用程序可以利用多个云来掩盖单一主要云的故障。此外，最近的几项提案将不同的云视为不同的信任域，以便为各种应用提供更有效的安全解决方案【29、38、43】。

We believe there are no fundamental technical limitations in implementing the intercloud layer on top of the cloud compatibility layer. This is simply because, from a performance perspective, moving jobs across clouds is very similar to moving jobs within the same cloud across datacenters. Once an application has been designed to run across multiple datacenters, the remaining cross-cloud issues can be addressed by the following three functionalities:

我们认为，在云兼容层之上实现跨云层并不存在根本的技术限制。这是因为，从性能角度来看，在不同云之间移动作业与在同一云内跨数据中心移动作业非常相似。一旦应用程序被设计为可以跨多个数据中心运行，剩下的跨云问题可以通过以下三种功能来解决：

(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.

Transfer Business

1. 一个统一的开源服务命名方案
2. 一个目录服务，允许云提供商注册他们的服务，应用程序可以根据偏好选择服务
3. 一个跨云的计费和收费机制

Service Naming Scheme

Aim: 识别在特定云上运行的服务实例

In order to identify a service instance running on a particular cloud we need a naming scheme to identify that instance. There are many possible schemes, and it is not our goal here to advocate for any particular one, though a natural possibility would be to leverage DNS for naming these service instances. In addition, we need to associate metadata with each such service instance. Such metadata should contain how the service should be invoked, the name of the cloud provider, location, software or API version, hardware type, etc. Furthermore, we might also want to add dynamic information like pricing, load, and availability.

服务命名方案

为了识别在特定云上运行的服务实例，我们需要一个命名方案来标识该实例。有许多可能的方案，而我们并不打算在这里倡导任何特定的方案，尽管一个自然的选择是利用DNS来命名这些服务实例。此外，我们需要为每个服务实例关联元数据。这些元数据应包含如何调用该服务、云提供商的名称、位置、软件或API版本、硬件类型等信息。此外，我们可能还希望添加动态信息，如定价、负载和可用性等。

Directory service

Aim: 目录服务提供 查询get / 更新update / 返回指定实例fetch 的服务

An application that requires a particular service must find a service instance that satisfies its requirements and preferences. This calls for a directory service. Each cloud provider will publish its services to this directory by providing its name and metadata information. Furthermore, each cloud provider should periodically update their dynamic metadata, such as the load and spot pricing. In turn, applications should request a particular service expressing its preferences and requirements. Upon receiving such request, the directory service would return an instance satisfying these requirements and preferences. The detailed request schema and the resolution algorithms are outside the scope of this paper, and will require ongoing evolution as user requirements become more expressive.

目录服务

需要特定服务的应用程序必须找到满足其要求和偏好的服务实例。这就需要一个目录服务。每个云提供商将通过提供其名称和元数据信息，将其服务发布到该目录。此外，每个云提供商还应定期更新其动态元数据，如负载和现货定价。反过来，应用程序应请求特定服务，并表达其偏好和要求。收到此请求后，目录服务将返回一个满足这些要求和偏好的实例。详细的请求架构和解析算法超出了本文的范围，并且将随着用户需求的不断发展而持续演进。

Accounting and charging

With Sky computing, a user’s application can run on one of many clouds or even on several clouds at the same time, and each cloud must account for the resources used. If the charging was done by each cloud, each user would need to have accounts on every cloud. We propose an alternative where each user signs up with a third-party broker (which might be one of the cloud providers) who has an account on all the clouds, and accumulates the charges and then distributes payments from each of their users back to the various clouds.

计费和收费

在天空计算中，用户的应用程序可以在多个云上运行，甚至可以同时在几个云上运行，每个云都必须对所使用的资源进行计费。如果每个云都单独收费，那么每个用户都需要在每个云上拥有账户。我们提出一种替代方案，用户与一个第三方中介（可能是其中一个云提供商）注册，该中介在所有云上都有账户，积累费用，然后将每个用户的支付分配回各个云。

While many details remain to be worked out, there do not appear to be any insurmountable technical barriers to achieving a reasonably effective intercloud layer. As with the compatibility layer, the issue is whether the market will produce one.

虽然还有许多细节需要解决，但要实现一个合理有效的云间互通层似乎并不存在任何无法克服的技术障碍。与兼容性层一样，问题在于市场是否会产生这样一个云间互通层。