UNIT – III
Virtualization & Programming Models for Cloud Computing
VIRTUALIZATION
1. Introduction to Virtualization
Virtualization is the core enabling technology of cloud computing. It is the process of
creating a virtual (rather than physical) version of something — an operating system,
a server, a storage device, or network resources — so that a single physical resource
can be shared among multiple users or applications, each believing it has exclusive
access to a dedicated resource.
Definition: Virtualization is a technique that abstracts the physical characteristics of
computing resources from the way other systems, applications, or end users interact
with those resources, by inserting a layer of software (called a hypervisor or Virtual
Machine Monitor, VMM) between the hardware and the operating system/application.
Why Virtualization is Needed in Cloud Computing
Resource utilization: Physical servers are often underutilized (5–15% CPU
usage typical). Virtualization allows multiple VMs to run on one physical
machine, maximizing utilization.
Elasticity & scalability: Cloud providers can dynamically provision/de-
provision VMs to meet fluctuating demand.
Isolation: Each VM is isolated from others — a crash or security breach in one
VM doesn't affect others.
Multi-tenancy: Enables multiple customers to securely share the same physical
infrastructure.
Hardware independence: VMs can be moved (migrated) between physical
hosts, aiding load balancing, disaster recovery, and maintenance without
downtime.
Cost reduction: Fewer physical machines needed → savings in hardware,
power, cooling, space, and administration.
Rapid provisioning: New "machines" can be created in minutes from
templates/images instead of days for physical procurement.
Characteristics of Virtualized Environments
Increased security: Guest can be isolated from host and from other guests.
Managed execution: Includes sharing, aggregation, emulation, and isolation.
Sharing: Multiple VMs share the same physical resource.
Aggregation: Multiple physical resources combined and presented as
one (e.g., clustering).
Emulation: A completely different environment is simulated (e.g., an
ARM OS run on x86 hardware).
Isolation: Guest processes/VMs are given the illusion of exclusive
resource access.
Performance tuning: Resources (CPU, RAM) can be allocated/throttled
dynamically.
2. Taxonomy of Virtualization Techniques
Virtualization can be broadly classified based on the level at which the abstraction is
applied:
2.1 Execution Virtualization
Concerned with the virtualization of the "execution environment" for programs.
(a) Process-level virtualization — implemented on top of an existing OS, which
retains control of the hardware.
Example: Multiprogramming/multitasking OS; runtime environments such as
JVM (Java Virtual Machine) or .NET CLR, which virtualize the underlying
instruction set so that programs are portable across hardware.
(b) System-level virtualization — implemented directly on the hardware and does not
(necessarily) need an existing OS. A control program (hypervisor) manages several
guest OS instances on a single physical host.
2.2 Hardware-Level Virtualization (System/Full Virtualization)
A hypervisor sits between hardware and one or more guest operating systems,
emulating the complete underlying hardware (CPU, memory, disk, NIC), allowing
unmodified guest OSes to run.
Types:
Full Virtualization: The guest OS is completely abstracted from the underlying
hardware and is unaware it is virtualized. Requires binary translation for
privileged instructions. Example: VMware ESXi, Microsoft Virtual Server.
Paravirtualization: The guest OS is modified to be "hypervisor-aware" and
makes explicit calls (hypercalls) to the hypervisor instead of executing certain
privileged instructions directly. Gives better performance but requires OS
source modification. Example: Xen (in paravirtualized mode).
Hardware-Assisted Virtualization: Uses CPU extensions (Intel VT-x, AMD-V)
that allow the hypervisor to run guest OSes in a de-privileged mode without
binary translation, improving performance while allowing unmodified guest
OSes.
2.3 Operating System-Level Virtualization
Virtualization capability is built into the OS kernel itself, allowing multiple isolated
user-space instances (called containers) instead of full VMs. All containers share the
same OS kernel.
Lightweight, fast startup, low overhead compared to full VMs.
Examples: Linux Containers (LXC), Docker, Solaris Zones, OpenVZ.
2.4 Other Types of Virtualization
Storage Virtualization: Pooling of physical storage from multiple devices into
what appears to be a single storage device, managed centrally. Example: SAN
(Storage Area Networks), RAID abstraction.
Network Virtualization: Combining hardware and software network resources
into a single, software-based administrative entity (a virtual network).
Example: VLANs, VPNs, SDN (Software Defined Networking).
Desktop Virtualization: The user's desktop environment is separated from the
physical machine and stored on a remote server; accessed remotely (VDI –
Virtual Desktop Infrastructure).
Application Virtualization: An application is encapsulated away from the
underlying OS on which it is executed, allowing it to run in an isolated
environment without traditional installation. Example: Application streaming,
VMware ThinApp.
Server Virtualization: Partitioning a physical server into multiple smaller
virtual servers, each running its own OS. This is the most common form used
in cloud data centers.
3. Hypervisor / Virtual Machine Monitor (VMM)
The hypervisor is the software layer that creates, runs, and manages virtual machines
by abstracting and allocating hardware resources.
Type 1 (Bare-Metal / Native Hypervisor)
Runs directly on the physical hardware, with no underlying host OS.
Offers better performance, security, and stability since there is no OS layer in
between.
Examples: VMware ESXi, Microsoft Hyper-V, Citrix XenServer, KVM.
Predominantly used in enterprise data centers and cloud infrastructures.
Type 2 (Hosted Hypervisor)
Runs as an application on top of a conventional host operating system.
Easier to install/use but has more overhead (extra OS layer) and thus lower
performance.
Examples: VMware Workstation/Player, Oracle VirtualBox, Parallels Desktop.
Typically used for desktop testing, development, and personal use.
Comparison Table
Feature Type 1 (Bare Metal) Type 2 (Hosted)
Runs on Hardware directly Host OS
Performance High Lower (extra OS layer)
Use case Data centers, cloud Desktops, testing
Examples ESXi, Hyper-V, Xen, KVM VirtualBox, VMware Workstation
Security More isolated/secure Less isolated
4. Pros and Cons of Virtualization
Advantages
Efficient hardware utilization
Reduced costs (CapEx and OpEx)
Faster server/workload provisioning
Easy backup, cloning, and disaster recovery via VM snapshots
Live migration of VMs between hosts with minimal downtime
Simplified testing and development (sandboxing)
Better scalability and elasticity for cloud services
Disadvantages
Performance overhead compared to native/bare-metal execution
Single point of failure — if the physical host fails, all VMs on it can be
affected
Increased complexity in management and licensing
Potential security risks: VM escape (a compromised VM affecting host or
other VMs), hypervisor vulnerabilities
"VM sprawl" — uncontrolled proliferation of VMs, making management
difficult
5. Virtualization and Cloud Computing
Virtualization is the foundational technology enabling the cloud computing service
models:
IaaS (Infrastructure as a Service): Virtualized compute, storage, and network
resources are directly offered to users (e.g., AWS EC2, Google Compute
Engine — built on hypervisors like Xen/KVM).
PaaS: Virtualized runtime/platform environments abstract away the OS and
infrastructure.
SaaS: Applications run in virtualized, multi-tenant environments.
Virtualization enables key cloud characteristics defined by NIST: on-demand self-
service, rapid elasticity, resource pooling, and measured service.
PART B: PROGRAMMING MODELS FOR CLOUD COMPUTING
Cloud applications must handle massive scale, distributed data, and parallel
execution. Traditional sequential programming models are inadequate, so specialized
programming models/frameworks have been developed to simplify writing
distributed, parallel, and fault-tolerant applications for the cloud. The three important
models in this syllabus unit are: MapReduce, Cloud Haskell, and general Software
Development approaches in the Cloud.
6. MapReduce
6.1 Introduction
MapReduce is a programming model and an associated implementation for processing
and generating large data sets with a parallel, distributed algorithm on a cluster. It was
introduced by Google (Jeffrey Dean and Sanjay Ghemawat, 2004) to handle web-
scale data processing (e.g., building search indexes).
The most popular open-source implementation is Apache Hadoop MapReduce.
6.2 Core Idea
MapReduce abstracts away the complexity of distributed computing (parallelization,
fault-tolerance, data distribution, load balancing) and lets programmers focus only on
two simple functions:
Map function: Takes an input key/value pair and produces a set of intermediate
key/value pairs.
map(k1, v1) → list(k2, v2)
Reduce function: Takes an intermediate key and a list of all values associated with
that key, and merges/aggregates them to produce a smaller set of output values.
reduce(k2, list(v2)) → list(v3)
6.3 Working / Architecture
The MapReduce execution flow (as in Hadoop) involves the following components
and stages:
Input Splitting: The input dataset (usually stored in a distributed file system
such as HDFS) is divided into fixed-size chunks/splits.
Mapping Phase: Each split is processed by a Mapper, running in parallel on
different nodes of the cluster. Each mapper applies the map() function and
emits intermediate (key, value) pairs.
Shuffling and Sorting: The framework automatically groups all intermediate
values by key and sorts them, redistributing (shuffling) data across the
network so that all values for a given key arrive at the same reducer.
Reducing Phase: Each Reducer receives a key and its list of associated values,
applies the reduce() function, and writes the final output — typically back to
the distributed file system.
Output: Final results are stored (often as multiple output files, one per
reducer).
Key architectural components (classic Hadoop 1.x terms):
JobTracker (Master): Coordinates the job, schedules tasks on TaskTrackers,
monitors progress, and handles failures.
TaskTracker (Worker): Executes individual map/reduce tasks assigned by the
JobTracker and reports status back.
HDFS (Hadoop Distributed File System): The underlying storage layer; splits
and replicates data across nodes for fault tolerance.
(In Hadoop 2.x+/YARN, this is generalized into ResourceManager and
NodeManager.)
6.4 Example: Word Count
A classic illustration of MapReduce:
Input: "the cat sat on the mat"
Map phase (emits):
(the,1) (cat,1) (sat,1) (on,1) (the,1) (mat,1)
Shuffle & Sort (group by key):
the → [1,1]
cat → [1]
sat → [1]
on → [1]
mat → [1]
Reduce phase (sums values):
the → 2
cat → 1
sat → 1
on → 1
mat → 1
6.5 Fault Tolerance
Data blocks are replicated (typically 3x) across nodes in HDFS.
If a mapper/reducer task or node fails, the master re-schedules the task on
another available node using replicated data — this is transparent to the
programmer.
Speculative execution: slow-running ("straggler") tasks may be duplicated on
other nodes, and whichever finishes first is used.
6.6 Advantages
Simplifies distributed programming — developers only write map and reduce
logic.
Automatic parallelization, scheduling, and load balancing.
Built-in fault tolerance and data locality optimization (moving computation to
where data resides, not vice versa).
Highly scalable — can process petabytes of data across thousands of
commodity machines.
6.7 Limitations
Not suited for iterative algorithms (e.g., machine learning, graph algorithms)
since each MapReduce job reads/writes to disk — leads to high latency for
multi-pass jobs. (This limitation led to the development of Apache Spark,
which uses in-memory computation.)
Not ideal for real-time/stream processing (batch-oriented).
Overhead of shuffle/sort phase can be significant for smaller jobs.
Rigid two-phase structure not natural for all problem types (e.g., complex
joins, graph traversal).
6.8 Applications
Log analysis, search index building (Google's original use case), data mining, sorting
large datasets, machine learning on large data (via iterative wrapping), ETL (Extract-
Transform-Load) pipelines.
7. Cloud Haskell
7.1 Introduction
Cloud Haskell is a domain-specific language (DSL), implemented as a set of libraries
in Haskell (a purely functional programming language), for writing programs for a
distributed computing environment (including cloud clusters) with explicit support for
concurrency and fault tolerance.
It was inspired heavily by Erlang's concurrency and distribution model, adapted to
Haskell's strong static type system and functional purity.
7.2 Motivation
Traditional imperative distributed programming is error-prone (shared mutable
state, race conditions, complex failure handling).
Functional programming's emphasis on immutability and pure functions
makes reasoning about concurrent/distributed programs easier and less error-
prone.
Haskell's strong type system catches many errors at compile time, improving
reliability of distributed applications — an important property for cloud-scale
systems where failures are common.
7.3 The Actor / Process Model
Cloud Haskell adopts the Erlang-style actor model:
Computation is structured as many lightweight, independent processes (not OS
processes — cheap, user-level, "green threads").
Processes do not share memory; they communicate exclusively via
asynchronous message passing.
Each process has a unique Process ID (PID), which can be used by other
processes (local or remote) to send it messages.
This model naturally maps to distributed systems, since local and remote
message passing are treated uniformly.
7.4 Key Features / Building Blocks
Processes: Created using spawn, which starts a new lightweight process
(possibly on a remote node) and returns its PID.
Message Passing: Using send (asynchronous, non-blocking) to deliver
messages to a PID, and expect/receiveWait to receive/pattern-match on
incoming messages.
Serializable Closures: One of Cloud Haskell's key innovations — because
Haskell functions are normally not serializable, Cloud Haskell provides a
mechanism (Closure type, via Template Haskell) to serialize function
references + their captured environment so that code (not just data) can be sent
to and executed on remote nodes. This enables dynamic, remote spawning of
computations.
Fault Tolerance / Monitoring: Borrowing Erlang's "let it crash" philosophy —
Processes can link to each other: if one crashes, linked processes are
also terminated (or notified), enabling coordinated failure handling.
Processes can monitor other processes and receive notification
messages if the monitored process dies, without being terminated
themselves.
This supports building supervisor hierarchies that automatically restart
failed components, improving system resilience — critical for long-
running cloud services.
Typed Channels: Cloud Haskell also supports typed channels as an alternative
to raw PID-based messaging, providing additional compile-time safety.
Node/Transport Abstraction: The underlying transport layer (e.g., TCP) is
abstracted, so the same program logic works whether processes are on the
same machine or distributed across a cloud cluster.
7.5 Architecture (Layers)
Application layer: User-written Haskell code using the Cloud Haskell process
API.
Cloud Haskell (distributed-process library): Provides the process abstraction,
message-passing primitives, closures, and fault-tolerance mechanisms.
Network Transport layer: Pluggable backend (e.g., network-transport-tcp) that
handles actual data transmission between nodes.
7.6 Advantages
Strong compile-time type safety reduces runtime distributed-system bugs.
Functional purity + immutability simplify reasoning about concurrent
behavior.
Location transparency: sending a message to a local or remote process uses the
same API.
Built-in fault-tolerance primitives (linking/monitoring) suited to unreliable
cloud environments.
Composable and elegant compared to lower-level socket programming.
7.7 Limitations
Smaller ecosystem/community compared to mainstream distributed
frameworks (e.g., Hadoop, Spark, Akka).
Steeper learning curve due to Haskell's functional paradigm.
Performance tuning for very large-scale clusters can be less mature than
industrial systems like Erlang/OTP itself.
7.8 Comparison: Cloud Haskell vs Erlang
Aspect Erlang Cloud Haskell
Paradigm Dynamically typed, Statically/strongly typed, purely
functional functional
Concurrency Actor model (native) Actor model (library-based)
model
Type safety Runtime Compile-time
Fault tolerance OTP supervisors ("let it Process linking/monitoring (similar
crash") philosophy)
Maturity Very mature, battle-tested Newer, research/library-driven
(telecom)
8. Software Development in the Cloud
8.1 Overview
Cloud computing changes not just how applications are deployed, but also how they
are developed. "Software development in the cloud" refers to designing, coding,
testing, and deploying applications specifically to leverage distributed, elastic, multi-
tenant cloud infrastructure — as well as using cloud-based tools/platforms to carry out
the development process itself.
8.2 Traditional vs. Cloud-Based Development
Aspect Traditional Development Cloud-Based Development
Infrastructure Fixed, in-house servers On-demand, elastic, provider-
managed
Scalability Manual, hardware-limited Automatic/horizontal scaling
Deployment Manual, slow Automated (CI/CD), rapid
Cost model CapEx (upfront hardware) OpEx (pay-as-you-go)
Team Local/VPN-bound Globally distributed, browser-based
collaboration IDEs
Failure handling Application assumes Must design for partial failure,
reliable infra statelessness
8.3 Characteristics Required of Cloud Applications
Developers must design applications keeping in mind:
Statelessness (where possible): So that any instance of the application can
handle any request, enabling load balancing and horizontal scaling.
Elasticity-awareness: Applications should scale out/in automatically as load
changes.
Fault tolerance: Since cloud infrastructure uses commodity hardware,
applications must gracefully handle node/service failures (retry logic,
redundancy, circuit breakers).
Loose coupling: Components (often microservices) communicate via well-
defined APIs/message queues rather than tight in-process calls.
Multi-tenancy support: Applications may need to securely isolate
data/processing for multiple customers sharing the same deployment.
Security & compliance: Data protection, identity/access management,
encryption, given shared/public infrastructure.
8.4 Cloud Programming Platforms/Environments (PaaS)
Platform-as-a-Service offerings provide frameworks, libraries, and APIs abstracting
away infrastructure management, letting developers focus purely on application logic:
Google App Engine (GAE): Supports Python, Java, Go, PHP; automatic
scaling; integrates with Google's Datastore.
Microsoft Azure (Cloud Services / App Service): .NET-centric but supports
multiple languages; integrates with Azure's storage, messaging, and AI
services.
Aneka: A .NET-based PaaS platform (from Manjrasoft) supporting multiple
programming models (Task, Thread, MapReduce) for building cloud
applications — often referenced academically alongside Google App Engine
and Azure.
AWS Elastic Beanstalk / Lambda: Application deployment and serverless
execution platforms.
8.5 Development Approaches in the Cloud
Serverless/Function-as-a-Service (FaaS): Developers write small, event-
triggered functions (e.g., AWS Lambda, Azure Functions); the cloud provider
manages all underlying infrastructure and scaling.
Microservices architecture: Applications decomposed into small,
independently deployable services, each often containerized (Docker) and
orchestrated (Kubernetes) — a natural fit with cloud elasticity and
virtualization.
DevOps and CI/CD: Continuous Integration/Continuous Deployment pipelines
automate build, test, and release processes, essential for rapid iteration in
cloud-native development.
APIs and Web Services: RESTful APIs / SOAP web services are the primary
means of exposing and consuming cloud-hosted functionality.
8.6 Challenges in Cloud Software Development
Distributed debugging and testing: Harder to reproduce issues that arise only
under distributed/concurrent conditions.
Latency and network dependency: Application performance is affected by
network variability between distributed components.
Data consistency: Trade-offs between consistency, availability, and partition
tolerance (CAP theorem) in distributed data stores.
Security: Multi-tenant environments increase the attack surface; need for
robust authentication, authorization, and encryption.
Vendor lock-in: Reliance on provider-specific APIs/services can make
migration between cloud providers difficult.
Cost management: Elastic scaling, if not carefully monitored, can lead to
unexpectedly high operational costs.
UNIT - II Cloud Deployment Models, Cloud Service Models, Technological Drivers
for Cloud Computing: SOA and Cloud, Multicore Technology, Web 2.0 and Web 3.0,
Pervasive Computing, Operating System, Application Environment