Cloud Basics Overview — ☁️ Advanced Cloud Models and Architecture

Cloud Computing Models: Detailed Analysis

IaaS (Infrastructure as a Service)

The cloud provider manages infrastructure; you manage everything from the OS up.

Responsibility Matrix:

You Manage          Provider Manages
─────────────────   ─────────────────
Applications        Servers
Databases           Storage Systems
Middleware          Networking
Runtime             Power/Cooling
OS                  Physical Security
Data

Examples:

• AWS EC2 (virtual machines)

• Google Compute Engine

• Azure Virtual Machines

• DigitalOcean

• Linode

Architectural Patterns:

1. Lift-and-Shift (Legacy): Move on-premise app to cloud VM unchanged

- Pros: Faster migration, minimal code changes

- Cons: Doesn't leverage cloud benefits, high operational overhead

- Use case: Legacy applications with predictable workloads

2. Containerized IaaS: Run containers on IaaS (DIY Kubernetes)

- Pros: More control than managed services

- Cons: Operational burden of managing Kubernetes

- Use case: Complex applications needing custom Kubernetes setup

3. Multi-region IaaS: Deploy across regions

- Pros: Disaster recovery, global reach

- Cons: Data replication complexity, networking latency

- Use case: Mission-critical global applications

Cost Model: Pay per hour/month for VM + storage + bandwidth

PaaS (Platform as a Service)

Provider manages infrastructure AND platform. You manage applications and data only.

Responsibility Matrix:

You Manage          Provider Manages
─────────────────   ─────────────────
Applications        OS
Data                Databases (optionally)
Code                Middleware
                    Runtime
                    Servers
                    Storage

Examples:

• AWS Elastic Beanstalk

• Google App Engine

• Azure App Service

• Heroku

• Firebase Hosting

Architectural Patterns:

1. Standard PaaS Deployment: Push code, forget infrastructure

```

git push heroku main

→ Automatic scaling

→ SSL/TLS included

→ Monitoring built-in

```

- Pros: Fastest time to market, no ops overhead

- Cons: Limited customization, vendor lock-in

- Use case: Startups, MVPs, rapid development

2. PaaS + Microservices: Each service deployed independently

- Pros: Scalability per service, polyglot tech

- Cons: Service discovery complexity

- Use case: Growing applications with multiple services

3. Hybrid PaaS: Mix PaaS and IaaS for different components

- Pros: Flexibility, cost optimization

- Cons: Operational complexity

- Use case: Large enterprises with mixed workloads

Cost Model: Pay per app + resource consumption (memory, disk, requests)

SaaS (Software as a Service)

Provider manages everything. You just use the software.

Examples:

• Google Workspace (Gmail, Docs, Sheets)

• Microsoft 365 (Office, Teams)

• Salesforce (CRM)

• Slack (Communication)

• Figma (Design)

Integration Patterns:

1. Direct Integration: Use SaaS APIs directly

```

Your App → Slack API → Send messages

Your App → Google Calendar API → Create events

```

2. Middleware Integration: Connect SaaS via middleware

```

Your App → Zapier/Make → Multiple SaaS platforms

```

3. Custom OAuth: SaaS as authentication provider

```

User clicks "Login with Google/GitHub"

→ OAuth flow → Your app authenticated

```

Cost Model: Per user/month, per request, or hybrid

Shared Responsibility Model Deep Dive

Traditional On-Premise:

Your Responsibility (100%)
├─ Applications
├─ Data
├─ Middleware
├─ OS
├─ Virtualization
├─ Storage
├─ Networking
├─ Infrastructure
├─ Physical Security
└─ Facilities

IaaS (AWS EC2):

Your Responsibility          Provider Responsibility
├─ Applications              ├─ Virtualization
├─ Data                      ├─ Storage Systems
├─ Middleware                ├─ Networking
├─ OS                        ├─ Infrastructure
│                            ├─ Physical Security
│                            └─ Facilities

PaaS (App Engine):

Your Responsibility          Provider Responsibility
├─ Applications              ├─ OS
├─ Data                      ├─ Middleware
│                            ├─ Runtime
│                            ├─ Databases
│                            ├─ Scaling
│                            ├─ Monitoring
│                            └─ Infrastructure

SaaS (Salesforce):

Your Responsibility          Provider Responsibility
├─ Data (within SaaS)        ├─ Everything else
├─ Access control
└─ Integrations

Cloud Architecture Principles

1. Elasticity vs Scalability

Scalability: System grows with demand permanently

• Traditional: Buy servers to handle peak load

• Cloud: Pay for peak but scale down during low periods

Elasticity: System automatically adjusts to demand

• AWS Auto Scaling: Add instances when CPU > 70%

• Remove instances when CPU < 30%

• Results in 60-80% cost savings

2. Availability vs Durability

Availability: System is up and running (uptime percentage)

• 99.9% = 8 hours/year downtime

• 99.99% = 52 minutes/year downtime

• 99.999% = 5 minutes/year downtime

Durability: Data doesn't get lost (data protection)

• S3 offers 99.999999999% durability (11 nines)

• Unlikely to lose single object over 100 million years

3. Consistency vs Availability (CAP Theorem)

CAP Theorem: Can't have all three:

• **Consistency:** All nodes see same data

• **Availability:** Always accessible

• **Partition Tolerance:** Works despite network failures

Tradeoff choices:

• SQL Databases: Consistency + Availability (lose partition tolerance)

• NoSQL Databases: Availability + Partition Tolerance (eventual consistency)

Real-World Architecture Evolution

Stage 1: Startup (Traditional IaaS)

Single VPC with 3 servers
├─ Web server
├─ App server
└─ Database server
Cost: $300/month
Uptime: 95% (database crashes)

Stage 2: Growth (Containerized)

Multiple availability zones
├─ Load balancer
├─ 5-10 app containers (auto-scaling)
├─ Multi-region databases
└─ CDN for static assets
Cost: $1,500/month
Uptime: 99.5%

Stage 3: Scale (Microservices)

Kubernetes across 3 regions
├─ User service (auto-scales 5-50 pods)
├─ Order service (auto-scales 10-100 pods)
├─ Payment service (dedicated 20 pods)
├─ NoSQL database (multi-region)
├─ Message queue (Kafka)
└─ Data warehouse (BigQuery)
Cost: $50,000+/month
Uptime: 99.99%

Performance Optimization Considerations

Latency

Factors:

• Distance to server (300km = 1ms latency)

• Network hops

• Database query time

• API call overhead

Optimization:

• Use CDN for static assets (move content closer)

• Caching layers (Redis, Memcached)

• Database optimization (indexes, query optimization)

• Async operations (don't wait for slow operations)

Throughput

Bottlenecks:

• Bandwidth limits

• Database connection pool limits

• CPU cores available

• Memory available

Optimization:

• Horizontal scaling (more servers)

• Connection pooling

• Async/non-blocking operations

• Message queues (Kafka, RabbitMQ)

Compliance and Regulatory Considerations

Global Regulations:

• GDPR (EU): Data residency, right to be forgotten

• HIPAA (Healthcare): Encryption, audit logs

• PCI-DSS (Payments): Network isolation

• SOC 2 (Security): Regular audits

Cloud provider compliance:

• AWS: Compliant with HIPAA, PCI-DSS, SOC 2, FedRAMP

• GCP: GDPR, HIPAA, PCI-DSS compliant

• Azure: Strong EU GDPR compliance

Vendor Lock-in Strategies

High Lock-in (Proprietary):

• Firebase (Firestore, Realtime Database)

• AWS Rekognition (AI vision)

• GCP BigQuery (data warehouse)

• Pros: Optimized, powerful

• Cons: Can't migrate without rewriting

Low Lock-in (Standards):

• PostgreSQL on RDS (standard SQL)

• Docker containers (OCI standard)

• Kubernetes (open source)

• Pros: Portable

• Cons: Less optimization

Hybrid Strategy:

• Use proprietary for unique needs (AI/ML)

• Use standard tech for core application

• Result: Best of both worlds

Key Takeaways

• ✅ IaaS maximum control, highest operational overhead

• ✅ PaaS fastest development, less operational burden

• ✅ SaaS minimal overhead, maximum vendor lock-in

• ✅ Shared responsibility varies by model

• ✅ Elasticity key to cloud cost optimization

• ✅ CAP theorem influences architecture choices

• ✅ Vendor lock-in vs performance tradeoff