Cloud Computing
Buying servers forces an organization to choose capacity before it knows exactly how much it will need. Cloud computing changes that relationship: computing, storage, and networking can be requested when needed and released when demand falls.
The Operating Model
A cloud service usually combines five ideas:
- Resources are available through self-service interfaces or APIs.
- Services are reachable over a network.
- The provider allocates resources from a shared pool.
- Capacity can grow or shrink with demand.
- Usage is measured so cost can follow consumption or reservation.
These properties matter together. A hosted server that still requires a person to provision every change is remote infrastructure, but it does not provide the full on-demand cloud operating model.
Responsibility Moves Between Service Models
Cloud services differ mainly in where the responsibility boundary sits.
| Model | Customer primarily manages | Provider primarily manages |
|---|---|---|
| Infrastructure as a service | Operating systems, runtime, application, and data | Physical hardware and virtualization |
| Platform as a service | Application code and data | Runtime, operating system, and infrastructure |
| Serverless compute | A deployable function or application | Provisioning, runtime capacity, and scaling |
| Software as a service | Configuration and use of the application | The complete application stack |
Moving down the table reduces direct infrastructure work, but it also gives the provider more control over runtime behavior and available configuration. The best abstraction is the one that removes work the application does not need to own.
Elastic Does Not Mean Automatic
A provider may make more capacity available quickly, but the application still needs a scaling design. Stateless work is easier to duplicate than stateful work, and incoming traffic must be distributed across healthy instances. Data placement, quotas, startup time, and downstream bottlenecks can all limit elasticity.
Cloud computing therefore changes how capacity is acquired; it does not remove the need to design for distributed-system boundaries, unreliable networks, or geographic placement.