Cloud Computing Fundamentals#

Cloud computing is renting someone else’s computers — but the architecture decisions you make on those rented computers are entirely different from on-premises. This section covers the service models, shared responsibilities, and design principles that underpin every cloud-native system.

Cloud Service Models#

Every cloud provider offers services across a spectrum of abstraction. Understanding where each model sits determines what you manage versus what the provider manages.

┌─────────────────────────────────────────────────────────────────┐
│                    YOU MANAGE EVERYTHING                         │
│   On-Premises                                                    │
│   ┌──────────┬──────────┬──────────┬──────────┬──────────┐      │
│   │ App      │ App      │ App      │ App      │ App      │      │
│   │ Runtime  │ Runtime  │ Runtime  │ Runtime  │ Runtime  │      │
│   │ OS       │ OS       │ OS       │ OS       │ OS       │      │
│   │ Compute  │ Compute  │ Compute  │ Compute  │ Compute  │      │
│   │ Storage  │ Storage  │ Storage  │ Storage  │ Storage  │      │
│   │ Network  │ Network  │ Network  │ Network  │ Network  │      │
│   └──────────┴──────────┴──────────┴──────────┴──────────┘      │
├─────────────────────────────────────────────────────────────────┤
│   IaaS            PaaS           FaaS           SaaS            │
│   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   │
│   │ App    ▲ │   │ App    ▲ │   │ Code   ▲ │   │        ▲ │   │
│   │ Runtime│ │   │        │ │   │        │ │   │        │ │   │
│   │ OS     │Y│   │ Runtime│P│   │ Runtime│P│   │ App    │P│   │
│   │ ───────│O│   │ OS     │R│   │ OS     │R│   │ Runtime│R│   │
│   │ Compute│U│   │ ───────│O│   │ ───────│O│   │ OS     │O│   │
│   │ Storage│ │   │ Compute│V│   │ Compute│V│   │ Compute│V│   │
│   │ Network│ │   │ Storage│ │   │ Storage│ │   │ Storage│ │   │
│   └────────┘ │   │ Network│ │   │ Network│ │   │ Network│ │   │
│              │   └────────┘ │   └────────┘ │   └────────┘ │   │
│   YOU ▲      │              │              │              │   │
│   PROVIDER ─ │              │              │              │   │
└─────────────────────────────────────────────────────────────────┘

Service Model Comparison#

Choosing a Service Model#

Is your team managing the OS and patching today?
├── Yes, and we want to keep control → IaaS
├── Yes, but we'd rather not → PaaS or CaaS
└── We just want to ship code
    ├── Stateless, event-driven → FaaS
    ├── Long-running processes → PaaS or CaaS
    └── Standard business app → SaaS (buy, don't build)

The Shared Responsibility Model#

Security and operations responsibilities split between you and the provider. The split point varies by service model.

The rule: The provider secures the cloud. You secure what you put in the cloud.

Even with SaaS, you are responsible for access control (who can log in), data governance (what data you upload), and compliance (whether using that SaaS meets your regulatory obligations).

Cloud-Native Principles#

Cloud-native is not “running on the cloud.” It means designing systems that exploit the cloud’s unique properties: elasticity, on-demand resources, managed services, and global reach.

The Five Properties of Cloud-Native Design#

1. Designed for automation — infrastructure is code, deployments are pipelines, recovery is scripted
2. Designed for resilience — failure is expected, systems self-heal, no single points of failure
3. Designed for elasticity — resources scale with demand, not with forecasts
4. Designed for observability — every component emits metrics, logs, and traces
5. Designed for loose coupling — services communicate through well-defined interfaces, not shared state

Cloud-Native vs Cloud-Hosted#

The Twelve-Factor App Methodology#

Twelve-factor is a methodology for building applications that deploy cleanly to cloud platforms. Published by Heroku engineers in 2012, it remains the foundation of cloud-native design.

The Twelve Factors#

Beyond Twelve Factors#

Modern cloud-native apps extend the original twelve factors:

Cloud vs On-Premises Decision Framework#

Not every workload belongs in the cloud. Use this framework to make the decision systematically.

Decision Criteria#

Total Cost of Ownership (TCO)#

On-prem TCO is consistently underestimated because it excludes hidden costs:

On-Prem TCO
├── Hardware (servers, storage, networking)
├── Software licences (OS, hypervisor, monitoring)
├── Data centre (power, cooling, space, physical security)
├── Personnel (sysadmins, network engineers, security team)
├── Procurement lead time (weeks to months)
├── Over-provisioning (buying for peak, paying at idle)
├── Refresh cycles (hardware EOL every 3–5 years)
└── Opportunity cost (engineers managing hardware, not building product)

Cloud TCO
├── Compute (on-demand, reserved, spot)
├── Storage (per GB, tiered)
├── Network (egress charges, cross-region transfer)
├── Managed services (per request, per hour)
├── Personnel (cloud engineers, fewer but specialised)
└── Operational overhead (monitoring, cost management)

Hybrid Considerations#

Most organisations land in a hybrid state: some workloads on-prem, some in the cloud. This is fine if it’s intentional — and expensive if it’s accidental.

Good reasons for hybrid:

• Gradual migration (workloads move in waves)
• Data gravity (large datasets are expensive to move)
• Regulatory requirements (specific data must stay on-prem)
• Latency-sensitive edge processing

Bad reasons for hybrid:

• “We’re not sure if cloud works” (it does; test with a non-critical workload)
• “Our team isn’t ready” (invest in training, not in maintaining two platforms)
• “We already bought the hardware” (sunk cost — evaluate future costs, not past spend)

Cloud Provider Landscape#

The three major providers share core concepts but differ in naming and implementation:

Transferable skill: Learn the pattern (object storage, virtual network, managed database), not just the vendor name. The pattern transfers; the CLI flags don’t.

Key Takeaways#

• Cloud service models (IaaS → SaaS) represent a spectrum of abstraction — the higher you go, the less you manage, but the less control you have
• The shared responsibility model defines the security boundary: the provider secures the infrastructure, you secure your data and access
• Cloud-native means designing for automation, resilience, elasticity, observability, and loose coupling — not just “running on a cloud VM”
• The 12-factor methodology provides concrete guidelines for building cloud-portable applications
• Cloud vs on-prem is a business decision driven by demand variability, time to market, data sovereignty, and total cost of ownership
• Learn patterns, not just vendor-specific services — the principles transfer across AWS, Azure, and GCP