Cloud computing and cloud storage

Cloud computing makes configurable processing, storage, networking and software available as remotely operated services that can be provisioned and released on demand. Cloud storage applies this service model to persistent data, commonly through object, block, file or database interfaces. The defining change is not that computers moved into distant buildings. Remote computation, service bureaux, time-sharing and data centres existed earlier. The cloud makes pooled infrastructure programmable through network interfaces, elastic enough to expand or contract quickly, measurable enough to bill as a service, and abstract enough that consumers can use resources without operating the underlying hardware directly. [S01-S04]

NIST characterises cloud computing through on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service, with infrastructure, platform and software service models. [1] These characteristics separate cloud services from ordinary hosting or remote storage by making allocation, scaling and metering part of the product. Amazon S3 and EC2 in 2006 became influential commercial examples of storage and compute exposed through service interfaces. [5][6]

The cloud converts fixed capital into rented capability. A small organisation can obtain infrastructure that once required procurement, floor space, cooling, operators and months of preparation. It can also become dependent on provider identity, APIs, billing, regions, quotas, service limits and outage domains. The abstraction hides physical machinery but does not abolish it. Every “serverless” function still runs on servers; every globally available object still occupies storage media in specific facilities, subject to power, law, geography, operator policy and failure.

The big idea

Cloud computing turns computation and storage into remotely programmable, pooled and metered services. Its defining achievement is elastic allocation through abstraction; its defining risk is that operational simplicity at the customer edge can conceal deep concentration, dependency and responsibility transfer.

| Field | Value | |---|---| | Public title | Cloud Computing and Cloud Storage | | Analytical title | On-Demand Network Access to Pooled, Elastic and Metered Remote Computing and Persistent Storage Services | | Recommended type | Distributed computing, storage and service-delivery infrastructure family | | Primary category | Storage & persistence | | Secondary categories | Processing; transmission; distribution; governance; identity; metering; security; software delivery | | Emergence | Commercial utility-computing and Web-service platforms during the 2000s; broad institutional adoption during the 2010s |

Cloud computing is defined here as an infrastructure and service arrangement in which computing resources are pooled by a provider, exposed through network-accessible interfaces, allocated or released with limited direct operator interaction, scaled according to demand, and measured for governance or billing. Cloud storage is the persistent-data subset of that arrangement, exposing objects, blocks, files, databases or archival stores without requiring the consumer to operate the underlying storage devices directly.

The topic includes public, private, community and hybrid clouds; infrastructure, platform and software services; virtual machines; containers; serverless functions; object, block and file storage; managed databases; regions and availability zones; orchestration; identity and access management; service-level objectives; metering; replication; lifecycle policies; APIs and management consoles.

It excludes ordinary colocation where customers operate their own machines, generic Internet hosting without cloud characteristics, peer-to-peer storage without a cloud service institution, and the physical data centre as a building unless it participates in the pooled service model.

1. Infrastructure becomes programmable

Compute, storage and networks can be requested through software interfaces rather than manual procurement alone.

2. Capacity becomes elastic

Resources can expand and contract with workload, reducing the need to purchase for a guessed peak.

3. Global service deployment accelerates

Applications can be deployed in several regions using standardised provider services.

4. Small organisations gain large-system capability

Teams can rent databases, queues, media processing and storage that once required specialist operations staff.

5. Data becomes remotely persistent across devices

Cloud storage allows information to follow accounts rather than remain bound to one computer or handset.

6. Operations become service boundaries

Providers assume responsibility for some hardware, facilities, patching, replication and availability, while customers retain other responsibilities.

7. Measurement becomes governance

Usage records, quotas and bills regulate access and make resource consumption visible.

8. Concentration becomes systemic

A small number of providers can become hidden dependencies for many unrelated applications, organisations and communications.

• Cloud computing: On-demand network access to pooled configurable computing resources under an elastic and measured service model. [1]
• Cloud storage: Managed remote persistence exposed through service interfaces.
• Resource pool: Provider-managed collection of compute, storage and network capacity allocated among consumers.
• Elasticity: Ability to add or release resources rapidly in response to demand.
• Measured service: Monitoring and accounting of resource use for billing, control or planning.
• IaaS: Infrastructure as a Service; exposes compute, storage and networking primitives.
• PaaS: Platform as a Service; exposes application runtimes, databases or developer services while hiding more infrastructure.
• SaaS: Software as a Service; exposes a complete application through a service interface.
• Public cloud: Shared provider infrastructure offered to external consumers.
• Private cloud: Cloud-style infrastructure dedicated to one organisation.
• Hybrid cloud: Arrangement combining distinct cloud and non-cloud or public/private environments.
• Region: Provider-defined geographic area containing one or more failure-isolated facilities or zones.
• Availability zone: Provider-defined infrastructure grouping intended to reduce correlated failure, not a universal guarantee of physical independence.
• Virtual machine: Software-defined computer environment sharing physical hardware through virtualisation.
• Container: Process-isolation and packaging environment sharing an operating-system kernel.
• Serverless/function service: Execution model in which the provider manages server allocation and the consumer supplies functions or application logic.
• Object storage: Storage model addressing whole objects by key within buckets or containers.
• Block storage: Remotely attached fixed-size storage blocks presented to a computer as a device.
• File storage: Hierarchical file-system interface shared over a network.
• Durability: Probability that stored data remain intact over time.
• Availability: Probability that a service can be accessed when requested. [9]
• Consistency: Rules governing when reads and listings reflect completed writes. [8]
• Replication: Maintenance of multiple copies across devices, facilities or regions.
• Service-level objective/agreement: Target or contractual commitment for availability, latency, durability or support.
• Egress: Data leaving a provider or service boundary, often separately metered.
• Vendor lock-in: Cost or difficulty of moving because of proprietary APIs, data volume, contracts, identity or operational practice.
• Shared-responsibility model: Division of security and operational obligations between provider and customer.

1. Cloud versus data centre

A data centre is a physical facility. A cloud is a service and control model operating across facilities and software layers.

2. Cloud versus hosting

Hosting may provide a fixed server. Cloud computing adds pooled resources, on-demand allocation, elasticity and metering.

3. Cloud storage versus backup

Cloud storage is a location and service model. Backup is a recovery strategy requiring independent copies, retention and tested restoration.

4. Replication versus backup

Replication improves availability and durability but can copy accidental deletion, corruption or hostile changes. Backup preserves recoverable historical state.

5. Durability versus availability

Data may remain intact while temporarily inaccessible, or be highly available before silent corruption is discovered. [9]

6. Consistency versus durability

Consistency governs visibility of changes. Durability governs survival after a successful write.

7. Object versus file storage

Objects are addressed as service resources with metadata; files participate in hierarchical file-system semantics.

8. Region versus legal jurisdiction

A provider region is an engineering and commercial label. Legal control can involve corporate domicile, support access, replication and cross-border obligations.

9. Elasticity versus infinite capacity

Elastic resources still face quotas, supply limits, service limits, rate controls and cost.

10. Serverless versus server-free

Serverless removes server management from the consumer interface, not from physical reality.

11. Provider resilience versus application resilience

A durable regional service does not automatically make the application resilient to bad configuration, credential loss or software defects.

12. Encryption versus exclusive control

Data can be encrypted while providers retain metadata, keys, access paths or operational authority.

13. Synchronisation versus canonical truth

A cloud copy may be authoritative, one replica among several, or a cache. Conflict rules must be explicit.

A consumer authenticates to a cloud service and requests compute, storage or application capability through an API, console or automation tool. A provider control plane authorises the request, selects pooled resources, configures networking and identity, records usage and exposes a service endpoint. Data move through provider networks to storage or execution systems, may be replicated across failure domains, and return to users or downstream services.

| Dimension | Pattern | |---|---| | Participation | Machine-to-machine service calls, administrator control and end-user application access | | Timing | Synchronous requests, asynchronous jobs, event-driven functions and long-lived services | | Persistence | Provider-managed objects, blocks, files, databases, snapshots, replicas and archives | | Topology | Multi-tenant regional infrastructure connected through provider and public networks | | Feedback | Metrics, logs, billing, health signals, events, retries and service reports | | Access | Accounts, roles, keys, policies, network rules, quotas, subscriptions and legal jurisdiction |

| Stage | Function | |---|---| | Consumer and workload | Define desired computation, data and service behaviour. | | Identity and policy layer | Authenticates principals and authorises actions. | | Control plane | Creates, configures, scales and deletes resources. | | Resource scheduler | Maps logical requests onto physical capacity. | | Virtualisation or isolation layer | Separates tenants and abstracts hardware. | | Data plane | Performs actual storage, computation and packet transfer. | | Persistence layer | Writes objects, blocks, files, logs, replicas and metadata. | | Replication and recovery layer | Detects failures, rebuilds copies and restores service. | | Metering and billing | Records use and applies quotas, budgets or charges. | | Observation layer | Exposes logs, metrics, traces, alarms and audit records. | | Network edge and clients | Deliver the resulting service to applications and people. |

The model must record three separate control surfaces:

1. management control plane: where resources are declared;
2. service data plane: where application work occurs;
3. provider operations plane: where the provider maintains infrastructure and can intervene.

Cloud computing inherits several older traditions: utility proposals, service bureaux, mainframe time-sharing, remote data processing, virtual machines, data centres, distributed systems and Web hosting. The novelty lies in combining these traditions with Internet-accessible APIs, large pooled infrastructure, rapid provisioning and measured service.

Time-sharing in the 1960s allowed many users to share expensive computers. Virtualisation allowed several logical machines to share hardware. Internet data centres and application-service providers during the 1990s hosted remote applications. These systems established important components without necessarily providing the full cloud service model.

Amazon launched S3 in March 2006 and EC2 later that year, exposing storage and compute through service interfaces and usage-based pricing. AWS describes S3 as the storage launch that preceded EC2’s remotely accessible processing power. [5][6]

The 2009 Berkeley “Above the Clouds” report defined cloud computing as applications delivered as services over the Internet and the hardware and systems software in data centres that provide those services. It emphasised elasticity, economies of scale and the transfer of risks between users and providers. [4]

NIST’s 2011 definition supplied a widely used comparison framework: five essential characteristics, three service models and four deployment models. [1] Its reference architecture separately identified consumers, providers, brokers, auditors and carriers, making the institutional structure explicit. [2]

During the 2010s, managed databases, container orchestration, content delivery, analytics, machine learning and serverless execution expanded the abstraction. Cloud storage became part of personal communication through phone backup, photo synchronisation, collaborative documents and media libraries.

• Large-scale data centres and reliable power
• High-capacity fibre networks and Internet connectivity
• Virtualisation and process isolation
• Distributed file and storage systems
• Databases and transaction processing
• Commodity servers and storage devices
• Automation, configuration and orchestration software
• Identity, access-control and cryptographic systems
• APIs and Web-service protocols
• Monitoring, logging and metering
• Replication, consensus and failure-detection techniques
• Cooling, physical security and facility operations
• Global billing, contracts and legal compliance
• Skilled operations, security and reliability teams

1. Service bureaux and time-sharing

Remote users rent access to central computation under operator control.

2. Virtualised enterprise computing

Logical machines and storage pools improve utilisation inside organisations.

3. Hosted applications and Internet data centres

Providers operate servers and applications for customers.

4. Programmable utility infrastructure

S3, EC2 and comparable services expose storage and compute through APIs and usage pricing.

5. Standardised cloud vocabulary

NIST and industry frameworks clarify service, deployment and actor models.

6. Managed-platform expansion

Databases, queues, analytics, identity and developer runtimes move into provider-managed services.

7. Container and orchestration era

Applications are packaged and scheduled across pooled infrastructure with more portable control layers.

8. Serverless and event-driven services

Consumers supply functions or declarative logic while providers manage allocation and scaling.

9. Cloud as personal-information substrate

Backups, photographs, messages, documents and identities become synchronised across consumer devices.

10. AI-scale infrastructure

Cloud providers integrate specialised accelerators, model services and enormous data-processing pipelines.

Cloud computing reduces the fixed-capacity and local-operations constraint.

Before cloud services, an organisation often had to purchase machines, estimate peak demand, install storage, configure networks and maintain facilities before an application could scale. Cloud services allow capability to be allocated through software and paid according to use or subscription.

The reduced constraint becomes a new one: dependence on provider interfaces, identity, pricing, capacity, geography and service continuity.

Constraint transition

From owning fixed local infrastructure to renting abstracted capability whose scale, reliability, cost and governance are jointly shaped by provider and consumer.

| Dimension | Assessment | |---|---| | Reach | Global service potential through provider regions and public networks | | Latency | Variable with region, network path, service layer and queueing | | Bandwidth | Very high inside provider networks; expensive or limited at edges and egress boundaries | | Fidelity | Bit-preserving storage can be excellent; application transformations and metadata loss remain possible | | Persistence | Potentially high through replication and lifecycle control; dependent on account, policy and recovery design | | Replication cost | Low operational friction but real storage, transfer and consistency costs | | Accessibility | Simplifies access for developers and organisations, but requires network, payment and expertise | | Portability | Mixed; standard protocols help, proprietary services and large data volumes hinder movement | | Interactivity | Supports low-latency applications, batch processing and asynchronous workflows | | Searchability | High when metadata and indexes are designed; raw objects remain opaque without services | | Editability | High through APIs; immutability and retention can be configured where required | | Scalability | Core strength, though quotas, architecture and cost impose limits | | Authentication | Strong identity and policy systems available; complexity creates misconfiguration risk | | Privacy | Depends on encryption, jurisdiction, provider access, tenancy and customer configuration | | Censorship resistance | Low to moderate; multiple providers exist, but accounts and infrastructure are controllable chokepoints | | Infrastructure dependence | Extremely high and often deliberately hidden from application users | | Auditability | Rich logs and controls possible; provider internals remain partly opaque | | Recovery | Strong if versioning, backups, replicas and tested restore paths are designed explicitly | | Cost predictability | Variable; elasticity reduces capital commitment but can produce volatile bills | | Failure independence | Requires deliberate separation across accounts, zones, regions and providers |

1. Rapid provisioning

Infrastructure can be created in minutes rather than procurement cycles.

2. Elastic capacity

Services can expand during peaks and contract afterward.

3. Managed reliability primitives

Providers supply replication, health checks, backups, queues and regional facilities.

4. Economies of scale

Shared procurement, specialist operations and automated facilities reduce some unit costs.

5. Global deployment

Applications can serve distant users through regional infrastructure and content delivery.

6. Developer leverage

Small teams can use managed databases, identity, analytics and media processing.

7. Cross-device persistence

People can access files and state from several devices.

8. Automation

Infrastructure definitions, policies and deployment pipelines can be versioned and repeated.

9. Disaster-recovery options

Snapshots, replicas and cross-region copies can improve recovery when designed correctly.

10. Experimentation

Temporary resources lower the cost of trials, prototypes and uncertain demand.

1. Global digital services

Cloud infrastructure supports communication, commerce, media, education and public services at large scale.

2. Organisational agility

Organisations can deploy tools without building complete facilities.

3. Collaborative work

Documents, code, media and databases remain synchronised across teams and locations.

4. Scientific computing

Researchers can rent large compute and storage pools for simulations and data analysis.

5. Disaster continuity

Remote replicas can preserve operations when local equipment is lost.

6. Media distribution

Streaming, podcast hosting and social platforms use elastic processing and global storage.

7. Software entrepreneurship

New services can begin with low infrastructure investment and expand if demand appears.

8. Public archives and data access

Large collections can be stored and made available through programmable interfaces.

9. Mobile continuity

Smartphones rely on cloud identity, backup and synchronisation to preserve personal state.

10. Artificial intelligence

Large-scale model training and inference depend heavily on pooled data and specialised compute.

1. Cloud providers

Control facilities, physical hardware, service interfaces, regions, quotas, pricing and parts of the security boundary.

2. Consumers and tenant administrators

Control application architecture, data classification, identity policies and many configuration choices.

3. Brokers and managed-service partners

Aggregate, migrate or operate services across providers.

4. Carriers and network operators

Connect consumers to providers and determine edge latency, cost and reach.

5. Auditors and certification bodies

Assess controls, evidence and compliance claims without necessarily observing every internal event.

6. Software vendors

Build tools, databases and platforms that can deepen or reduce provider dependence.

7. Governments and regulators

Apply data-residency, privacy, competition, security and lawful-access rules.

8. Facility workers and supply chains

Maintain physical machines, power, cooling, chips and cables hidden beneath the abstraction.

9. End users

Often interact with cloud-backed applications without knowing the provider, region or retention rules.

The cloud’s institutional power comes from abstraction. The provider does not merely store bytes; it defines the resource vocabulary through which customers think about storage, computing, identity and failure.

1. Vendor lock-in

Proprietary APIs, managed services, data gravity and staff knowledge make migration costly.

2. Concentrated outages

One provider or region can affect many apparently unrelated services.

3. Responsibility ambiguity

Customers can assume the provider secures configuration that remains their responsibility.

4. Cost volatility

Elastic systems can scale bills as efficiently as they scale workloads.

5. Egress friction

Moving large datasets out can incur time, bandwidth and financial costs.

6. Jurisdictional exposure

Corporate control, data location and support access may cross legal boundaries.

7. Identity chokepoints

Credential loss, account suspension or billing failure can remove access to entire infrastructures.

8. Configuration complexity

Powerful policy systems produce severe mistakes when permissions, networks or retention are misunderstood.

9. False redundancy

Several services can share one account, region, identity provider, network route or control plane.

10. Replicated deletion

Synchronised systems can propagate mistakes rapidly unless versioning and independent backup exist.

11. Provider opacity

Customers cannot inspect every physical placement, operational action or internal dependency.

12. Environmental load

Large facilities consume energy, water, land and hardware, even when efficiency improves.

13. Surveillance and metadata concentration

Providers observe account, network, storage and operational metadata at enormous scale.

14. Skills displacement

Managed services simplify operations while concentrating deep infrastructure knowledge inside providers.

15. Service discontinuation

A provider can retire APIs, regions or products on timelines that do not match preservation needs.

16. Availability theatre

A dashboard may be green while the customer’s identity, DNS, application configuration or data path is broken.

| Relationship | Topic | Reason | |---|---|---| | Predecessor | Time-sharing Time-Sharing | Establishes shared remote computation, accounts, quotas and service access. | | Predecessor | Electronic digital computers Electronic Digital Computers | Supplies programmable processing. | | Predecessor | Magnetic digital storage Magnetic Digital Storage | Supplies large digital persistence and storage hierarchy. | | Predecessor | Database management systems Database Management Systems | Supplies managed shared data and transactions. | | Predecessor | Internet and TCP/IP Internet and TCP/IP | Provides internetwork access to services. | | Related | Smartphones Smartphones | Uses cloud identity, storage, backup and application services. | | Related | Online video and streaming platforms Online Video and Streaming Platforms | Depends on cloud encoding, storage, distribution and analytics. | | Related | Podcasts and on-demand audio Podcasts and On-Demand Audio | Uses cloud hosting, feeds, files and measurement. | | Related | Recommendation Algorithms and Personalised Feeds Recommendation Algorithms and Personalised Feeds | Uses cloud-scale data and model execution. | | Successor | Generative Language Models Generative Language Models | Depends on large-scale storage and specialised computation. | | Successor | Autonomous and Semi-Autonomous AI Agents Autonomous and Semi-Autonomous AI Agents | Uses cloud services as action and state infrastructure. |

Cloud computing extends rather than replaces local computing. Latency, sovereignty, offline operation and control preserve reasons for edge and on-premises systems.

1. The service bureau

Customers still rent capability from specialists rather than owning every machine.

2. Time-sharing accounts

Identity, quotas and metering survive at much larger scale.

3. Data-centre operations

Power, cooling, maintenance and physical security remain indispensable.

4. Mainframe virtualisation

Logical machines continue to share physical hardware through stronger abstraction.

5. Files, blocks and databases

Older storage abstractions survive alongside object services.

6. Backup tapes and offline copies

Cloud adoption does not abolish the value of independent, less-connected recovery media.

7. Capacity planning

Elasticity changes planning but does not eliminate architecture, quotas or budgeting.

8. Operator authority

Someone still controls physical infrastructure, emergency actions and account access.

9. Network geography

Distance, cables and facilities continue to shape latency and sovereignty.

1. Amazon S3

Influential 2006 object-storage service exposing remote persistence through APIs [5][6].

2. Amazon EC2

Influential 2006 elastic virtual-compute service [6].

3. NIST cloud model

Standard comparison framework defining essential characteristics, service models and deployment models [1].

4. NIST reference architecture

Separates consumer, provider, broker, auditor and carrier roles [2].

5. Berkeley “Above the Clouds” report

Analyses elasticity, service delivery and economic transfer in early commercial cloud computing [4].

6. Object versioning and lifecycle rules

Show that durable service still requires explicit retention and recovery configuration [7][10].

7. Strong consistency documentation

Demonstrates that cloud-storage consistency is a stated service property rather than a generic assumption [8].

8. Multi-region application

Illustrates how resilience depends on identity, data replication, routing and recovery, not region labels alone.

• Which historical systems qualify as cloud rather than hosting, utility computing or time-sharing?
• Should cloud storage and cloud computation be split into separate topics after comparative testing?
• How should private-cloud claims be evaluated against NIST characteristics?
• Which metrics best capture portability across providers?
• How should provider control over encryption keys and support access be represented?
• What constitutes genuine failure independence across zones, regions and providers?
• How should environmental cost be allocated among shared tenants?
• Should content-delivery networks receive a dedicated topic?
• How should cloud sovereignty be measured when corporate, legal and physical locations differ?
• When does a managed AI service become a semantic-processing topic rather than cloud infrastructure?

The cloud is a service model, not a weather system. “It is in the cloud” is not a location statement and should never be allowed to sneak through the map unchallenged.

|---|---|---|---| | Cloud computing and cloud storage-C01 | Cloud computing combines on-demand access, broad network access, pooling, elasticity and measured service. | High | S01 | | Cloud computing and cloud storage-C02 | Cloud, data centre and ordinary hosting are not synonymous. | High | S01-S04; conceptual analysis | | Cloud computing and cloud storage-C03 | S3 and EC2 were influential 2006 commercial milestones in storage and compute services. | High | S05-S06 | | Cloud computing and cloud storage-C04 | Durability, availability and consistency are separate storage properties. | High | S08-S09 | | Cloud computing and cloud storage-C05 | Replication does not by itself constitute backup. | High | S07; systems analysis | | Cloud computing and cloud storage-C06 | Elasticity does not mean infinite capacity or predictable cost. | High | S04; operational analysis | | Cloud computing and cloud storage-C07 | Cloud abstractions transfer rather than eliminate responsibility. | High | S02-S03 | | Cloud computing and cloud storage-C08 | Cloud concentration can create correlated dependencies among unrelated services. | High | Architectural analysis |

| Comparison | Main difference | Analytical value | |---|---|---| | Time-sharing | Shared access to a central computer under session and account controls | Shows ancestry in remote pooled computation. | | Colocation | Customer owns or controls machines in another facility | Separates physical location from service abstraction. | | Traditional hosting | Often fixed capacity and manually provisioned servers | Highlights elasticity, APIs and metering. | | On-premises infrastructure | Organisation owns and operates local systems | Contrasts control, capital cost and operational responsibility. | | Peer-to-peer storage | Capacity distributed among participating peers | Contrasts provider institution and central service contract. | | Backup service | Maintains recoverable historical copies | Separates persistence location from recovery design. | | Content-delivery network | Replicates content near recipients for delivery | Shows specialised distribution above origin storage. | | Edge computing | Moves processing nearer devices or data sources | Shows latency and sovereignty limits of central clouds. |

The decisive comparison is between resource ownership and service control. Cloud consumers can command large resources without owning the hardware, while providers can control essential infrastructure without designing the customer’s application.

Cloud computing hides machinery in order to make capability easier to use. Instead of choosing a rack, disk controller, power circuit and cooling plan, the consumer requests an object bucket, database, virtual machine or function. The provider translates that logical request into physical work across facilities, networks, operators and software. This abstraction is one of the great productivity engines of modern information systems.

It is also a machine for moving boundaries. Capital cost becomes operating cost. Hardware administration becomes provider dependency. Local failure becomes regional architecture. A disk becomes an object API. A server becomes a configuration record. Responsibility does not disappear; it migrates into service contracts, identity policy, application design and recovery testing.

The cloud’s most dangerous illusion is that abstraction equals independence from physical reality. Data still occupy media. Signals still cross cables. Facilities still need power and water. Employees still hold privileged roles. Governments still exercise jurisdiction. An “availability zone” is not a force field, and three replicas sharing one bad policy can fail with impressive coordination.

For information transmission, the cloud becomes the invisible middle of Era VI. Smartphones capture and request. Streaming platforms encode and distribute. Podcasts publish files and feeds. Personalised systems store histories and compute rankings. The user sees an elegant interface; the cloud provides the warehouse, factory, railway and accounts department behind it.

Cloud computing turns computation and storage into remotely programmable, pooled and metered services. Its defining achievement is elastic allocation through abstraction; its defining risk is that operational simplicity at the customer edge can conceal deep concentration, dependency and responsibility transfer.