Does sky computing require every cloud to be identical?

No. The Berkeley proposal works toward useful partial compatibility and broker-mediated placement.

Is using two clouds automatically sky computing?

Not in the stronger research framing; the abstraction and placement role are central.

Is the cheapest compute rate always the best placement?

No. Eligibility, transfer and other relevant costs can change the decision.

AI Glossary / Data engineering and architecture / Advanced

Sky computing

Definition

Sky computing is a vision of using resources across cloud providers through a more unified layer that can place workloads according to requirements and objectives. In the Berkeley research framing, intercloud brokers mediate between users and cloud services. The aim is greater portability and choice, rather than treating every provider as a separate environment that users must manage individually. It does not mean every application can run unchanged on every cloud.

What it means

A user might care about finishing a computation within a deadline, using a suitable accelerator or keeping work in an approved location. Choosing the provider is then part of satisfying those requirements rather than necessarily the first decision. Sky computing proposes an abstraction above individual clouds that can help make such choices. This is especially relevant to discussions of AI workloads with varying hardware needs. The idea should be understood as an architectural and ecosystem direction, not as proof that a universally compatible cloud marketplace already exists or that switching providers is effortless.

How it works

The Berkeley white paper describes users specifying job characteristics, constraints and optimization goals to an intercloud broker, which selects suitable cloud resources and oversees execution. It emphasizes partial compatibility across providers rather than requiring every service to be universally interchangeable. The earlier Stoica and Shenker paper also discusses economic barriers and reciprocal peering. Actual placement still depends on the workload's dependencies and available services. A useful evaluation therefore checks both eligibility and cost: an attractive resource is irrelevant if it cannot meet the job's technical or operational requirements.

Three practical examples

A research team describes the accelerator and memory requirements of an AI experiment so a placement layer can consider compatible resources across providers.
A batch-processing service compares eligible locations using a complete job estimate rather than only the advertised compute rate.
An architecture review tests whether a workload can actually move between two supported environments before treating provider choice as interchangeable.

Think of it this way

Think of a travel planner that selects among transport operators based on destination, timing and other requirements. The planner provides a common point of interaction, but it cannot make every operator serve every destination. Connections and restrictions still matter. Likewise, a computing broker can simplify choices without erasing differences in hardware, services, data placement or application dependencies.

Worked example

Consider an original hypothetical placement choice for a batch job. Candidate A has an estimated compute cost of 40 cost units and no additional transfer cost in this example. Candidate B has compute costing 28 units but requires 15 units of data-transfer cost. Their stipulated totals are 40 and 43 units respectively. B's lower compute figure therefore does not make it cheaper overall. Now suppose an eligibility rule excludes A because the required execution location is unavailable. B may become the eligible option despite its higher total. These invented values are not provider prices or a purchasing recommendation. They demonstrate why a broker must evaluate constraints before comparing the complete costs of feasible choices.

Illustrative case study

In a fictional AI experimentation team, engineers want to run the same training preparation job on more than one cloud. Their first checklist includes only processor and memory requirements. A trial reveals that a supporting service and the input data location also affect portability. The team documents those dependencies, verifies output equivalence in two environments and includes transfer and setup effort in its comparison. It treats a broker as a way to manage supported alternatives, rather than assuming that the presence of a common interface proves compatibility. The scenario illustrates evaluation questions, not a reported deployment or performance result from the cited research.

Common misconceptions and mistakes

Sky computing is not simply a claim that an organization has accounts with several cloud providers. The Berkeley framing emphasizes mediation and workload placement above individual clouds. It also does not imply computing in satellites or aircraft. Another mistake is selecting an environment from an hourly rate while ignoring data movement, setup and required services. The concept does not automatically confer resilience, confidentiality or freedom from provider dependencies. Those outcomes require specific design and evidence. Historical papers present a proposed direction, so their forecasts should not be restated as established facts about the current market.

Business use

The concept helps teams discuss how much provider choice they actually possess. Identify which workloads have portable dependencies and which are closely tied to a particular service. Express placement constraints clearly enough that a broker or engineer can rule out unsuitable alternatives before ranking the rest. For AI workloads, verify hardware compatibility and required data access as part of the same exercise. Evaluate repeatable deployment and recovery behavior alongside headline resource prices. The useful business outcome is a demonstrated set of workable alternatives with understood trade-offs, not merely a larger list of provider names.

Check your understanding

Which toy candidate had the lower compute-only estimate?

Answer: B, at 28 units.

Which had the lower total under the stated costs?

Answer: A, at 40 versus 43.

Why could A still be excluded?

Answer: It failed the stipulated execution-location requirement.

Why did the fictional team test supporting services?

Answer: Hardware compatibility alone did not establish workload portability.

Related terms

Cloud computing
multicloud
intercloud broker
workload portability
data locality
vendor lock-in

Learn next

Describe a fictional job with a hardware requirement, an execution-location constraint and an input-data dependency. Create two hypothetical provider options and assess eligibility before comparing total costs. Then identify one application dependency that could prevent movement despite matching hardware. Explain what evidence would establish a supported alternative rather than a merely plausible one.

Input data

Sources

Sarah Chasins and colleagues, The Sky Above the Clouds: A Berkeley View on the Future of Cloud Computing: https://arxiv.org/pdf/2205.07147 Ion Stoica and Scott Shenker, From Cloud Computing to Sky Computing: https://doi.org/10.1145/3458336.3465301 The cost calculation, travel-planner analogy and AI experimentation case are original educational illustrations. The entry follows the Berkeley research framing, acknowledges a proposed direction and does not present historical forecasts, universal portability or invented costs as current market facts.

Previous: Skolemization Next: Skyline operator