Cloud Deployment Models & Virtualization – Detailed Lecture Notes

Chapter 1: Introduction

• Continuation of earlier lectures on cloud architecture; today’s focal point: virtualization and its role in cloud deployments.
• Reminder of previously covered topics:
  • Service models (SaaS, PaaS, IaaS) and how they map to user needs.
  • Deployment models (public, private, hybrid, community).
• Key message: “Cloud” ≈ infrastructure + services + deployment strategy; virtualization underpins almost every facet.

Chapter 2: Public Cloud

• Definition: Infrastructure provisioned for open use by the general public (individuals, SMEs, large enterprises, academic & government bodies).
• Ownership / management:
  • May be owned, managed, operated by a business, academic institution, government agency, or any combination.
  • Physically located at the Cloud Service Provider’s (CSP) premises; NOT at subscriber’s site.
• Popular examples: Google App Engine, Microsoft Azure, IBM Cloud, Amazon EC2, etc.
• Subscription model: “Pay & Use” via the Internet with minimal legal barriers aside from terms-of-service & jurisdictional compliance.

Technical / Operational Features

• Potentially massive compute & storage pools; users leverage the CSP’s global backbone.
• Connectivity: Delivered over the public Internet.
• Multi-tenant environment → diverse pool of benign + malicious actors.
• Workload location transparency: customers do not know which physical server, rack, or data-center holds their VMs or data.
• Risks from multi-tenancy:
  • Same physical host may run workloads of competitors or adversaries.
  • Possible side-channel, covert-channel, reliability, or “noisy neighbor” issues.
• Network dependency: Service availability hinges on continuous Internet connectivity (e.g., IIT Kharagpur must guarantee WAN access if labs run fully on public cloud).
• Limited visibility & control over data security; trust is anchored in SLA/MOU.
• Elasticity illusion: practically unlimited scale—add/remove VMs & storage on demand.
  • Formally: \text{Scale}_{\text{max}} \to \infty (theoretical upper bound – CSP’s perspective).
• Low upfront CAPEX → barrier-free migration; OPEX pay-as-you-go.
• Restrictive default SLAs: small users accept CSP’s terms; large users may negotiate custom SLAs/pricing.

Chapter 3: Private Cloud (On-Site)

• Definition: Infrastructure provisioned for exclusive use by one organisation, encompassing multiple internal business units.
• Ownership / management options:
  • Fully in-house (organisation owns, manages, operates).
  • Third-party manages equipment inside subscriber’s perimeter.
  • Location: on-prem or (rarely) off-prem yet still under subscriber’s jurisdiction.
• Open-source & commercial stacks: Eucalyptus, OpenStack, Ubuntu Enterprise Cloud, VMware Cloud Infrastructure Suite, Microsoft ECI, Amazon VPC, etc.

On-Site Variant Characteristics

• Extended security perimeter: wraps both enterprise network and private-cloud resources.
• Clients (internal departments) still experience location transparency—they don’t see the physical hardware.
• Risks from intra-org multi-tenancy (two research groups sharing same hypervisor).
• Data import/export constraints: campus LAN capacities may bottleneck terabyte-scale transfers.
• Real-time processing limits tied to internal network latency/bandwidth.
• Stronger external-threat security: inherits enterprise firewall, IDS, NAC policies.
• Significant upfront cost:
  • Hardware procurement, datacenter space, power & cooling.
  • Software licenses, staffing, maintenance.
• Finite resource ceiling: cluster sized for expected workload plus safety margin \approx 1.5 \times \text{forecasted demand}; bursts beyond that require new procurement cycles.
• Ongoing IT skill demand: admins must maintain hypervisors, storage, network fabrics, patches.

Chapter 4: Private Cloud (Outsourced / Off-Prem)

• Concept: Organisation leases an isolated slice of a CSP’s infrastructure, but slice is dedicated to that single tenant (logical or physical isolation).
• Two nested security perimeters:
  1. Subscriber’s own perimeter (HQ, branch, VPN gateways).
  2. Provider’s perimeter around the private slice.
• Critical dependency: Secure, high-availability communication channel (VPN/MPLS/IPsec) bridging perimeters.

Pros / Cons & Operational Insights

• Network dependency amplified: if WAN or VPN fails, private cloud invisible.
• Location transparency + multi-tenancy risk still present (neighbouring outsourced private clouds may reside on same hardware).
• Data transfer & performance: governed by WAN throughput; large dataset migration slower than public-cloud “direct connect” services.
• Security posture: generally stronger than public cloud at high level (no random public workloads), but still trusts provider for low-level isolation.
• Upfront cost: modest–significant (less than on-site hardware purchase, but more than simple public-cloud pay-as-you-go due to dedicated resources).
• Elastic potential: CSP often has spare capacity → easier vertical/horizontal scaling compared to on-site private cloud.
• SLA negotiation mandatory: enterprise defines isolation level, compliance needs (HIPAA, GDPR), uptime targets, data-at-rest encryption, audit rights.

Chapter 5: Community Cloud

• Targeted at a specific group of organisations with shared mission, policy, or compliance requirements (e.g., healthcare consortia, research federations, government agencies).
• Deployment modes: public (hosted by common provider) or private (one member hosts for all).
• Ownership/management: one or more orgs, a 3rd-party, or mixed.
• Location: on-prem or off-prem; policies dictated by the collective.
• Use-case mindset: “Let’s combine budgets & align compliance frameworks so we all inherit equivalent controls.”
• Potential permutations (example):
  • Organisations A, B, C form one community; X, Y, Z form another; cross-community projects spawn temporary hybrids (A+B+Z), etc.

Chapter 6: Cross-Cutting Themes & Take-Away Points

• Virtualization is the core enabler for multi-tenancy, elasticity, and workload location abstraction across all models.
• Multi-tenancy trade-off: ↑ utilisation & cost-efficiency, but introduces security & noisy-neighbour risks.
• Network emerges as single point of failure or performance throttle whenever resources leave the premises.
• Elasticity gradient:
  • Public cloud: conceptually \infty.
  • Outsourced private: large but bounded by provider’s carve-out agreement.
  • On-site private: fixed; upgrade cycles add step-wise capacity.
• CAPEX vs OPEX balance:
  • Public: low CAPEX, variable OPEX.
  • On-site private: high CAPEX, moderate predictable OPEX.
  • Outsourced private/community: mid-range CAPEX (setup fees) + subscription OPEX.
• SLA centrality: legal instrument capturing uptime guarantees, data handling, security controls, penalties; level of negotiability correlates with consumer’s bargaining power.
• Compliance & Jurisdiction: data location secrecy in public clouds may conflict with laws requiring data residency; private/community models often adopted to meet such mandates.

Chapter 7: Practical Decision Matrix (Implicit from Lecture)

Closing Remarks

• No single model dominates; organisations often adopt hybrid strategies, e.g. burst from on-site private to public during peak load ("cloud bursting").
• Lecture emphasises understanding nuances (cost, control, security, legal) before migrating workloads.
• Subsequent sessions will dive deeper into virtualization mechanisms and hybrid-cloud orchestration.