Back

Unit_4_Cloud_Computing_Architecture

Loading views...
← PreviousNext →

Unit 4: Cloud Computing Architecture and Service Models

4.1 Introduction: What is a Cloud?

"Cloud computing is a utility-oriented and Internet-centric way of delivering IT services on demand. These services cover the entire computing stack: from hardware infrastructure packaged as virtual machines, to software services such as development platforms and distributed applications."

Key Insight: A Cloud is not tied to one specific hardware type. It can be:

  • A massive datacenter (hundreds of thousands of servers)
  • A cluster (dozens to thousands of nodes)
  • A heterogeneous distributed system (PCs, workstations, servers mixed together)

In all cases, hardware resources are virtualized to:

  1. Isolate workloads from each other
  2. Exploit the infrastructure to maximum efficiency

4.2 Cloud Reference Model (Layered Architecture)

The entire cloud stack can be organized into layers:

+------------------------------------------------------------------+
|  CLOUD APPLICATIONS (SaaS)                                       |
|  Social Computing | Enterprise ISV | Scientific | CDNs           |
+------------------------------------------------------------------+
|  CLOUD PROGRAMMING ENVIRONMENT & TOOLS (PaaS)                   |
|  Web 2.0 | Mashups | Distributed Programming | Workflows        |
+------------------------------------------------------------------+
|  CLOUD HOSTING PLATFORMS — CORE MIDDLEWARE (IaaS)               |
|  QoS Negotiation | Admission Control | Pricing | SLA Mgmt       |
|  Monitoring | Execution Management | Metering | Accounting      |
+------------------------------------------------------------------+
|  CLOUD RESOURCES / INFRASTRUCTURE                                |
|  VM + VM Management + Deployment                                 |
|  Physical Servers | Storage | Networking                         |
+------------------------------------------------------------------+
                          |
          Autonomic Cloud Economy / Adaptive Management
          (Elastic auto-scaling governs the entire stack)

The layers map to service models:

  • Bottom = IaaS (Infrastructure)
  • Middle = PaaS (Platform)
  • Top = SaaS (Software)

IaaS(M): A variant that provides only the management layer (software), without physical infrastructure. Plugs into other IaaS providers for the actual hardware.

Pure PaaS: Only the middleware layer is offered. Customer must supply their own infrastructure.

4.3 Infrastructure-as-a-Service (IaaS) — Deep Dive

4.3.1 What IaaS Delivers

IaaS gives you raw, virtualized computing infrastructure on demand:

Resource What you get Example
Virtual Compute VM instances (choose vCPU, RAM, OS) AWS EC2 t3.medium = 2 vCPU, 4 GB RAM
Virtual Storage Raw disk OR object store AWS EBS (disk), AWS S3 (objects)
Virtual Networking Firewall, VPC, load balancers, DNS AWS VPC, Security Groups

You manage: Everything from the OS upward — software, security patches, applications.

Provider manages: Physical hardware, power, cooling, network fabric, hypervisors.

Pricing: Typically $/hour based on VM size.

4.3.2 IaaS Reference Architecture (3 Layers)

+--------------------------------------------------+
|  USER INTERFACE LAYER                            |
|  Web Portal | REST API | Web Services | CLI       |
|  (Web 2.0 technologies: RESTful APIs, mashups)   |
+--------------------------------------------------+
|  INFRASTRUCTURE MANAGEMENT SOFTWARE LAYER        |
|  +----------+  +-----------+  +---------------+  |
|  |Scheduler |  | Pricing / |  |  Monitoring   |  |
|  |(allocates|  | Billing   |  | (tracks usage)|  |
|  | VMs)     |  +-----------+  +---------------+  |
|  +----------+  +-----------+  +---------------+  |
|  |Reservation|  |QoS / SLA |  | VM Image Repo |  |
|  |(future VM |  |Management|  | (templates)   |  |
|  | bookings) |  +-----------+  +---------------+  |
|  +-----------+  +-----------+  +---------------+  |
|  | VM Pool   |  |Provisioning| (3rd party IaaS)|  |
|  | Manager   |  +-----------+  +---------------+  |
|  +-----------+                                    |
+--------------------------------------------------+
|  PHYSICAL INFRASTRUCTURE LAYER                   |
|  Datacenter Clusters | Desktop Grids              |
|  + External (3rd party) IaaS resources           |
+--------------------------------------------------+

Component Descriptions:

Component Role
Scheduler Core of IaaS management. Decides which VM runs on which physical server and when. Coordinates with all other components.
Pricing/Billing Tracks each VM instance's resource usage and calculates cost. Data used to charge users.
Monitoring Continuously tracks VM health, CPU/memory usage, uptime. Used for SLA enforcement and reporting.
Reservation Stores records of past, running, and future-scheduled VM instances.
QoS/SLA Management Maintains repository of service level agreements. Works with Monitoring to ensure VMs meet promised quality.
VM Image Repository Catalog of pre-built VM images (OS + software stack) users can launch. Users may also upload custom images.
VM Pool Manager Keeps track of all currently live/running VM instances across the infrastructure.
Provisioning If local resources are insufficient, requests VMs from external (3rd party) IaaS providers.

4.3.3 Pre-packaged VM Images (Common Types)

Instead of starting from a blank OS, users can choose pre-configured images:

Image Type Contents Use Case
LAMP Stack Linux + Apache + MySQL + PHP Web application hosting
Web Server Nginx/Apache pre-configured Static content, proxy server
Database Server MySQL/PostgreSQL optimized Database backend
Custom Image User's own uploaded image Proprietary software stacks

4.3.4 IaaS Solution Types

Type What's provided Examples
Complete IaaS Physical infra + management software + UI Amazon EC2, GoGrid, Rackspace, Joyent, Terremark
IaaS(M) — Management Only Management software + UI only (no hardware) Eucalyptus, OpenNebula, VMware vCloud, Enomaly, Elastra

Why IaaS(M) exists: An organization may already own servers (a cluster or datacenter). They install IaaS(M) software on top to give cloud-style self-service access to their own hardware.

4.3.5 Benefits of IaaS

For the Provider:

  • Better hardware utilization (multiple VMs per server)
  • Secure isolation of customer workloads
  • Centralized management at scale

For the Customer:

  • No capital expenditure on hardware
  • Reduced administration and maintenance cost
  • Full customization — choose OS, install any software
  • Pay only for what you use

4.4 Platform-as-a-Service (PaaS) — Deep Dive

4.4.1 What PaaS Delivers

PaaS provides a managed development and deployment platform. You write code; the platform handles everything else.

  Developer writes code
          |
          | deploy with one command / API call
          v
  +----------------------------------+
  |    PaaS MIDDLEWARE LAYER         |
  |  - Deploys your app              |
  |  - Configures load balancers     |
  |  - Provisions databases          |
  |  - Scales automatically          |
  |  - Monitors and heals            |
  +----------------------------------+
          |
          v
  Physical/Virtual Infrastructure
  (You never see or manage this)

You manage: Application code and data only.

Provider manages: Servers, OS, runtime, scaling, databases, load balancing.

4.4.2 PaaS Reference Architecture

+--------------------------------------------------+
|  WEB INTERFACE / PROGRAMMING API & LIBRARIES     |
|  Web Portal | REST API | SDK | CLI Tools          |
+--------------------------------------------------+
|  PaaS CORE MIDDLEWARE                             |
|  +------------------+  +---------------------+   |
|  | Application Mgmt |  | Elasticity & Scaling|   |
|  | (deploy, start,  |  | (auto-scale up/down)|   |
|  |  stop, update)   |  +---------------------+   |
|  +------------------+  +---------------------+   |
|  | Runtime Resources|  | QoS/SLA Management  |   |
|  | Management       |  | & Billing           |   |
|  +------------------+  +---------------------+   |
|  | User Management  |                             |
|  +------------------+                             |
+--------------------------------------------------+
|  PHYSICAL INFRASTRUCTURE / IaaS PROVIDERS        |
+--------------------------------------------------+

4.4.3 Essential Characteristics of PaaS (Charrington's Criteria)

# Characteristic Explanation
a Runtime Framework The "software stack" that executes user code. Enforces policies set by user and provider.
b Abstraction Focus is on the application, not VMs. You deploy apps, not machines.
c Automation Auto-deploys, auto-scales, auto-configures. No manual VM management needed.
d Cloud Services Built-in APIs for databases, caches, queues, email, etc. These are the key differentiators.

4.4.4 PaaS Classification (3 Categories)

Category Description Examples
PaaS-I Fully web-hosted dev environment. Visual/rapid-app development. Middleware + Infrastructure. Force.com, Longjump
PaaS-II Scalable runtime for web applications. Uses provider APIs built on standard runtimes. Google AppEngine, Heroku, Engine Yard, Joyent Smart Platform
PaaS-III Full distributed application development platform, not just web apps. Microsoft Azure, Manjrasoft Aneka, DataSynapse, Appistry Cloud IQ

4.4.5 PaaS Development Models Compared

Model Approach Flexibility Examples
Visual/4GL Drag-and-drop component assembly in browser Low code-level control Force.com, Longjump
Language-based Full programming in Java/Python/Ruby, then deploy to cloud High control Google AppEngine, Azure
Open-standards Use any framework, provider is transparent Maximum portability Heroku, Engine Yard

4.4.6 Vendor Lock-in Problem

This is the #1 concern with PaaS:

  TRADITIONAL APP:                    PAAS APP:
  Code runs on standard               Code uses provider-specific APIs
  Java/Python runtime                 (e.g., Google Datastore API)
          |                                   |
          v                                   v
  Can run on ANY server            ONLY runs on Google AppEngine
  
  Migration: Easy                  Migration: Must rewrite data layer!
PaaS Solution Lock-in Level Reason
Force.com Very High Proprietary language (Apex), proprietary DB
Google AppEngine Moderate Industry-standard Java/Python, but proprietary Datastore
Azure Moderate .NET standard, but Azure-specific storage/services
Heroku / Engine Yard Low Open-source Ruby/Node, standard databases
Appistry Cloud IQ Very Low Fully open standards

4.4.7 Financial Value of PaaS

Phase IaaS saves money on PaaS additionally saves money on
Development Nothing Dev environment, SDK, testing tools
Deployment Hardware Deployment automation, configuration
Operations Hardware, admin Scaling, monitoring, database management
Technology upgrades Nothing Provider upgrades runtime automatically

4.5 Software-as-a-Service (SaaS) — Deep Dive

4.5.1 What SaaS Delivers

SaaS delivers complete, ready-to-use applications over a web browser. No installation. No maintenance.

  User opens browser
          |
          | https://app.example.com
          v
  +----------------------------------+
  |   APPLICATION (fully hosted)     |
  |   - No installation needed       |
  |   - Auto-updated by provider     |
  |   - Multi-tenant (shared)        |
  |   - Access from any device       |
  +----------------------------------+
  User manages: Nothing (just uses the app)
  Provider manages: Everything

Key Property — Multi-tenancy:

  TRADITIONAL SOFTWARE:              SaaS (Multi-tenant):
  Company A: installs app            Company A: uses SaaS app --+
  Company B: installs app            Company B: uses SaaS app --+--> ONE instance
  Company C: installs app            Company C: uses SaaS app --+    shared, isolated
  
  3 separate installations            1 installation, 3 isolated tenants
  3x maintenance cost                 1x maintenance cost (provider)

4.5.2 SaaS Formal Definition (SIIA, 2001)

"In the software as a service model, the application is deployed from a centralized data center across a network providing access and use on a recurring fee basis. Users 'rent', 'subscribe to', or 'are granted access to' the applications from a central provider."

4.5.3 Application Service Provider (ASP) → SaaS Evolution

Feature Traditional ASP SaaS
Delivery Hosting packaged software Web-native application
Customization Limited Rich (inject components, design workflows)
Integration Manual, expensive API-driven, marketplace (e.g., AppExchange)
Development Provider-controlled Extensible by third parties
Interface Basic web Full Web 2.0 (rich browser app)

Four Core ASP/SaaS Characteristics:

  1. Product sold = application access (not a license)
  2. Application is centrally managed
  3. Service is one-to-many (one app serves many customers)
  4. Delivered as an integrated solution under contract (SLA)

4.5.4 SaaS 2.0

The evolution of SaaS brought SaaS 2.0 — not new technology, but a new business model:

  • SLA-driven infrastructure and application platform
  • Focus on rapid business objective achievement (not just rapid deployment)
  • Ecosystem of interconnected services: SaaS apps integrate third-party components
  • Each component has its own SLA and pricing — customers choose which services to include
  • Result: SaaS market becomes a network of providers rather than isolated products
  SaaS 2.0 App:
  [Core CRM] + [Payment Plugin] + [Analytics Plugin] + [Email Plugin]
       |              |                   |                  |
   Salesforce    Stripe API          Mixpanel API       SendGrid API
   (main SLA)   (own SLA)          (own SLA)          (own SLA)
   
   Customer picks which plugins to add. Each is priced and guaranteed separately.

4.5.5 SaaS Examples by Category

Category Examples Key Features
CRM Salesforce, RightNow, NetSuite Customer/contact management, pipelines
Office Google Docs, Zoho Office Documents, spreadsheets, presentations in browser
Social Networking Facebook, LinkedIn Connect users, host 3rd party plugins
Content Storage Box.net File storage + integrations with other SaaS
Project Mgmt Clarizen.com Team tasks, timelines, resource planning

4.6 XaaS — Everything as a Service

XaaS is the principle that every component of the computing stack can be delivered as a service:

  X         = ANYTHING
  XaaS      = Anything-as-a-Service
  
  IaaS      = Infrastructure as a Service (VMs, storage, network)
  PaaS      = Platform as a Service (development platform)
  SaaS      = Software as a Service (end-user apps)
  DaaS      = Desktop as a Service (virtual desktops, e.g., AWS WorkSpaces)
  DBaaS     = Database as a Service (e.g., AWS RDS, Google Cloud SQL)
  STaaS     = Storage as a Service (e.g., Dropbox, AWS S3)
  NaaS      = Network as a Service (e.g., SD-WAN, AWS Direct Connect)
  FaaS      = Function as a Service / Serverless (e.g., AWS Lambda)

XaaS enables composition: An IaaS provider (Amazon EC2) runs under a PaaS (Google AppEngine-compatible) platform that hosts a SaaS app (a CRM) — all from different vendors, all integrated via standard APIs.

4.7 Types of Clouds (Deployment Models)

4.7.1 Public Cloud

  INTERNET
     |
     +-- Customer 1 --------+
     |                      |
     +-- Customer 2 --------+----> PUBLIC CLOUD DATACENTER
     |                      |      (owned by Amazon, Google, etc.)
     +-- Customer N --------+
     
  Open to anyone. Multi-tenant. Massive scale.

Key Characteristics:

  • Open to the general public — anyone can sign up
  • Multi-tenant: One infrastructure serves thousands of customers simultaneously
  • Multi-region: Geographically distributed datacenters (AWS: us-east-1, us-west-1, eu-west-1)
  • Availability Zones: Within a region, multiple isolated datacenters for fault tolerance
  • Elastic: Designed to scale to virtually infinite capacity

Benefits:

  • Instantly available, no procurement needed
  • Lowest cost per unit (provider's economies of scale)
  • Handles massive peak loads

Drawbacks:

  • Loss of control over where data physically resides
  • Legal/regulatory risks (US Patriot Act can compel access to data on US servers)
  • Not suitable for highly confidential data (government, military)

Examples: Amazon EC2/S3, Google AppEngine, Salesforce.com, Microsoft Azure (public).

4.7.2 Private Cloud

  ORGANIZATION'S FIREWALL
  +------------------------------------------+
  |                                          |
  |  Private Cloud Infrastructure            |
  |                                          |
  |  [Datacenter/Cluster] + [IaaS(M) or PaaS]|
  |                                          |
  |  +------+  +------+  +------+           |
  |  | Dept1|  | Dept2|  | Dept3|           |
  |  +------+  +------+  +------+           |
  |  (each dept gets self-service access)    |
  +------------------------------------------+
  External access = BLOCKED

Key Characteristics:

  • Cloud infrastructure is owned and operated within the organization's premises
  • Access limited to internal users (departments, employees)
  • Instead of pay-as-you-go: internal chargeback (departments billed proportionally)

Benefits over Public Cloud:

Benefit Explanation
Data sovereignty Sensitive data never leaves the organization's premises
Regulatory compliance Easier to comply with HIPAA, PCI-DSS, government rules
Security assurance Security team controls all infrastructure
Cost savings on existing infra Leverages hardware already purchased
Test environment Test new apps on private cloud before public cloud deployment

Software Stack for Private Cloud:

  PaaS Solutions: DataSynapse, Aneka, Zimory Pools, Elastra CloudServer
       |
  IaaS(M): Eucalyptus, OpenNebula, VMware vCloud, OpenPEX, InterGrid
       |
  Hypervisor: KVM, Xen, VMware ESXi
       |
  Physical: Datacenters, Clusters, Desktop Grids

Key Products:

  • Eucalyptus: Open-source. AWS-compatible API. Supports Xen, KVM, VMware.
  • OpenNebula: Open-source. Supports KVM, Xen, VMware. Modular — can add Haizea scheduler.
  • VMware vCloud: Commercial. Proprietary. Industry-standard in enterprise.
  • Aneka: PaaS layer. Runs on heterogeneous hardware. Supports bag-of-tasks, MapReduce.

Major Limitation: Cannot elastically scale beyond physical hardware you own.

4.7.3 Hybrid Cloud

  NORMAL LOAD:                         PEAK LOAD (Cloud-bursting):
  +------------------+                 +------------------+
  |  PRIVATE CLOUD   |                 |  PRIVATE CLOUD   |
  |  [All workloads] |                 |  [Base workload] |
  +------------------+                 +------------------+
                                               |
                                               | overflow (burst)
                                               v
                                       +------------------+
                                       |  PUBLIC CLOUD    |
                                       | (temp resources) |
                                       +------------------+
                                       Released when load drops

Definition: A Private Cloud extended with public cloud resources when needed.

Cloudbursting: The practice of temporarily acquiring public cloud VMs to handle demand spikes, then releasing them when demand returns to normal.

Example (Aneka):

  1. Organization has 50 private servers.
  2. During peak, 50 servers aren't enough.
  3. Aneka's provisioning service automatically rents 20 EC2 VMs from AWS.
  4. Jobs run across private + public resources transparently.
  5. When peak ends, EC2 VMs are released. Billing stops.

Scheduling Complexity: The scheduler must optimize two costs:

  • Local cost: Using private (already-paid) infrastructure
  • External cost: Renting public VMs (real money, per-hour)
  • Strategy: Fill private resources first; rent public only when needed.

Tools:

  • OpenNebula + Haizea: Cost-based scheduler for hybrid clouds
  • InterGrid: Peer-network distributed scheduler spanning private + public resources
  • Aneka: Built-in provisioning service with budget-aware scheduler

4.7.4 Community Cloud

Definition (NIST):

"The infrastructure is shared by several organizations and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party."
  COMMUNITY CLOUD
  +------------------------------------------------+
  |                                                |
  |  [Govt Agency 1] [Govt Agency 2] [Private Org] |
  |        \               |              /         |
  |         \              |             /          |
  |          +-- SHARED COMMUNITY CLOUD INFRA --+  |
  |                    |         |               |  |
  |             [App Services] [Dev Platforms]   |  |
  |                  [3rd Party Public Cloud]    |  |
  +------------------------------------------------+
  All members share common concerns (security policy, compliance)

Key Differences from other cloud types:

Feature Public Private Community
Users Anyone One org One industry/sector
Data sharing No control No sharing Controlled sharing
Admin domain One provider One org Multiple orgs
Examples AWS OpenNebula Healthcare cloud

Candidate Sectors:

Sector Community Cloud Use Case
Media Industry Collaborative content production (video rendering, large file movement) across studios and partners
Healthcare Share anonymized patient data for research; keep private data in private cloud
Energy Bundle solutions for grid management across different energy providers
Public Sector Government agencies share infra for citizen services (invoice approval, public hearings)
Scientific Research Science Clouds — share HPC resources across universities for big experiments

Community Cloud Properties:

  • Openness: No vendor dependency; fair competition
  • Community-driven scaling: More members = more resources
  • Graceful Failures: No single provider = no single point of failure
  • Democratic control: Community votes on policies
  • Green: Harnesses underutilized resources of member machines

4.8 Cloud Deployment Comparison Summary

Feature Public Private Hybrid Community
Ownership 3rd party Organization Both Multi-org
Access Anyone Internal only Internal + burst Members only
Security Lower Highest Medium Medium-High
Elasticity Near-infinite Limited Good Moderate
Cost model Pay-per-use CapEx (owned) Mixed Shared
Compliance Difficult Easy Moderate Designed-in
Setup complexity None High Very High High
Example users Startups, developers Banks, government Enterprises Healthcare, govt

4.9 SPI Model Comparison: IaaS vs. PaaS vs. SaaS

Dimension IaaS PaaS SaaS
You manage OS, middleware, apps, data Apps, data Nothing
Provider manages Hardware, network, hypervisor + OS, runtime, scaling + Apps
Flexibility Maximum Medium Minimal
Vendor lock-in risk Low (standard VMs) Medium-High (proprietary APIs) Medium (data portability)
Dev skill needed Systems engineering Application development None
Scaling managed by You Provider (auto) Provider (auto)
Use case Custom infrastructure Cloud-native apps End-user productivity
Primary user Infra engineers Developers Business users
Pricing $/hour per VM /request or /resource $/month/user

Navigation

← PreviousNext →