← All posts
6 min read

What Is Cloud Computing? Rented, Programmable Infrastructure

#technology#cloud-computing#infrastructure#computer-science
📑 On this page

When a company says it is "moving to the cloud," no application floats into the sky. Its code and data still run on processors, memory, disks, cables, and buildings.

What changes is how those computing resources are obtained and operated.

Cloud computing provides computing resources over a network with on-demand provisioning, programmable control, shared infrastructure, and measured usage.

A cloud provider operates physical data centers at large scale. Customers rent services and configure them through consoles, command-line tools, and APIs.

A concrete example: creating a server

Without cloud infrastructure, a team may need to:

  1. Estimate future capacity.
  2. Purchase a physical server.
  3. Wait for delivery.
  4. Install it in a suitable facility.
  5. Configure power, networking, storage, and an operating system.
  6. Replace hardware when it fails.

In a cloud platform, the team can request a virtual machine in minutes:

Region: Chennai-compatible nearby region
Operating system: Linux
CPU: 4 virtual cores
Memory: 16 GB
Storage: 100 GB

The machine is still backed by physical hardware. The provider has already purchased, installed, networked, and automated that capacity.

On-demand provisioning

Cloud resources can generally be created and removed without waiting for a provider employee to perform each action.

This enables:

  • Temporary test environments
  • Rapid experiments
  • Automated disaster recovery
  • Extra capacity for traffic peaks
  • Repeatable infrastructure deployment

On-demand does not mean unlimited. Accounts have quotas, regions have finite capacity, and some specialized hardware may be scarce.

The important property is that provisioning is exposed as a repeatable service rather than a long manual procurement process.

Infrastructure becomes programmable

Cloud platforms expose APIs for servers, networks, storage, identity, databases, and many other services.

That means infrastructure can be described as code:

Create a private network.
Create two application instances.
Allow HTTPS traffic through a load balancer.
Store database backups for 30 days.

Automation improves consistency and reviewability. The same definition can create development and production environments with controlled differences.

It also creates risk: a faulty script can misconfigure or delete resources quickly. Version control, access limits, reviews, and tested recovery remain necessary.

Shared infrastructure and isolation

Cloud providers serve many customers using large shared fleets.

Virtualization and access controls isolate workloads so one customer can use a portion of a physical system without controlling another customer's workload.

Sharing improves utilization. A provider can spread varying demand across many customers rather than every organization buying enough hardware for its own maximum possible peak.

Isolation is a security boundary that depends on hardware, hypervisors, operating systems, network controls, and provider processes. Customers must still configure their accounts and applications securely.

Measured usage

Cloud services commonly charge based on consumption, such as:

  • Virtual-machine seconds or hours
  • Stored gigabytes per month
  • Database capacity
  • Number of requests
  • Data transferred
  • Function execution time

Usage pricing can turn large upfront purchases into operating expenses and make small experiments affordable.

It does not guarantee lower cost. Continuously running oversized resources, unnecessary data transfer, idle environments, and poorly understood managed services can become expensive.

Cloud cost management requires visibility, budgets, ownership, and architecture suited to the billing model.

Elasticity versus scalability

Scalability is the ability to add capacity while preserving useful behavior.

Elasticity is the ability to adjust capacity as demand changes, often automatically and in both directions.

A system may be scalable but not elastic if engineers must manually add servers. A serverless function may be highly elastic because the platform starts more execution environments as events arrive.

Elasticity is valuable for variable workloads, but sudden scaling can expose downstream limits such as database connections or third-party API quotas.

Regions and availability zones

Cloud providers group infrastructure geographically.

A region is a broad location. An availability zone is an isolated facility or group of facilities within a region, designed with separate failure boundaries.

Location affects:

  • User latency
  • Legal and regulatory requirements
  • Service availability
  • Disaster-recovery design
  • Price
  • Data-transfer cost

Placing two copies in one failure domain is less resilient than distributing them across independent zones.

Service models divide responsibility

Common models include:

  • Infrastructure as a Service: Rent virtual machines, networks, and storage while managing operating systems and applications.
  • Platform as a Service: Deploy application code to a managed runtime.
  • Software as a Service: Use a complete application operated by the provider.
  • Managed services: Use databases, queues, analytics, or identity systems with much of their operation handled by the provider.

As the provider manages more layers, the customer gains convenience but has less low-level control and may face stronger product-specific constraints.

Public, private, hybrid, and multi-cloud

A public cloud provides shared provider-operated services to many customers.

A private cloud applies cloud-style automation and self-service to infrastructure dedicated to one organization.

A hybrid design connects cloud resources with an organization's own facilities. Multi-cloud means using services from more than one cloud provider.

These labels do not guarantee good architecture. Multiple environments increase networking, identity, observability, skill, and consistency challenges.

Use them when requirements justify the complexity, not simply to avoid committing to a decision.

The shared responsibility model

The provider secures and operates certain underlying layers. Customers remain responsible for how they configure and use the service.

For a virtual machine, the customer may manage:

  • Operating-system updates
  • Application security
  • User accounts
  • Network rules
  • Data protection
  • Backups

For a managed database, the provider may handle hardware and database patching, while the customer still controls users, schemas, queries, retention, and data classification.

"The provider handles security" is never a complete answer.

Cloud does not remove operations

Managed services reduce specific operational tasks, but systems still need:

  • Architecture
  • Monitoring
  • Incident response
  • Capacity planning
  • Security review
  • Backup testing
  • Cost management
  • Dependency and quota awareness

Operational responsibility moves toward configuration, automation, and service integration. It does not disappear.

When cloud is a good fit

Cloud services are useful when teams value:

  • Fast provisioning
  • Global reach
  • Variable capacity
  • Managed capabilities
  • Automated infrastructure
  • Reduced hardware ownership

Owning infrastructure may still fit specialized hardware, predictable large-scale workloads, strict physical requirements, limited connectivity, or existing investments.

The choice should compare total cost, control, reliability, skills, and risk over time.

Knowledge check

  1. What changes when an application moves to the cloud?
  2. Why is cloud infrastructure considered programmable?
  3. How does elasticity differ from scalability?
  4. Why can consumption pricing increase rather than reduce cost?
  5. What responsibilities remain with a customer using a managed service?

The one idea to remember

The cloud is not an absence of computers. It is real data-center capacity offered as programmable, on-demand, measured services, with operational responsibility divided between provider and customer.