Cloud Computing: Concepts, Architectures, and Emerging Frontiers

Cloud Computing Briefing Document

Date: October 26, 2023
Subject: Comprehensive Overview of Cloud Computing Concepts, Architectures,
Management, Security, and Emerging Trends
Source: Excerpts from "Module 116 -289.pdf"
--------------------------------------------------------------------------------
Executive Summary
This briefing document provides a detailed review of cloud computing, drawing
insights from modules 116-289 of the provided source. It covers foundational
concepts, specialized mechanisms, fundamental and advanced architectures, cloud
management systems, cost metrics, service quality, security, privacy, trust issues,
and emerging trends like Mobile Cloud Computing, Big Data, Multimedia Cloud, SDN,
and Fog Computing. A central theme is the continuous evolution of cloud
computing, its inherent complexities, and the ongoing efforts to address challenges
related to performance, reliability, security, and trust. The document also highlights
NIST recommendations and best practices for both cloud providers and consumers.
--------------------------------------------------------------------------------
Section 1: Core Cloud Concepts and Mechanisms
Cloud computing fundamentally promises "virtually unlimited IT resources" which
are provisioned from "multiple physical servers located in a single or multiple data
center/s." These resources, while virtualized, cannot be provided by a single
physical server.
1.1. Resource Cluster Mechanism (Module 116):
• Definition: Groups multiple IT resources (physical or virtual) to function as a
single unit.
• Benefits: Increases "Computing capacity, Load balancing, Availability" of
clustered IT resources.
• Connectivity: High-speed communication links are crucial for "Workload
distribution, Task scheduling, Data sharing, System synchronization."
• Types:
◦ Server Cluster: Consists of physical or virtual servers; virtualized clusters
support VM migration for scaling and load balancing.
◦ Database Cluster: Ensures redundancy and synchronizes data across
instances, useful for "active-active and active-passive failover systems."
 ◦ Large Dataset Clusters: Partitions and distributes large datasets without
compromising integrity or accuracy; nodes process workloads independently.
◦ Additional Types: Load Balanced Cluster (implements load balancing) and HA
Cluster (implements failover).
1.2. Multi-Device Broker (Module 117):
• Transforms messages from heterogeneous consumer devices into a standard
format for cloud services and converts response messages back to device-specific
formats.
1.3. State Management Database (Module 117):
• Temporarily stores "state data of software programs" (e.g., VM configurations for
PaaS).
• Benefit: Reduces RAM consumption by making services "stateless," allowing
infrastructure to scale in when activity pauses and restore state by scaling out when
activity resumes.
1.4. Remote Administration System (Module 118):
• Provides APIs and tools for providers to develop online portals (Usage and
Administration Portal, Self-Service Portal).
• Capabilities: "Management controlling of Cloud IT resources," "IT resources
usage reports," service configuration, IT resource provisioning/release, monitoring
status, usage, performance, QoS/SLA fulfillment, cost management, user account
management, and capacity planning. Consumers can also build front-end
applications using these APIs.
1.5. Resources Management System (Module 119):
• Utilizes Virtual Infrastructure Manager (VIM) for creating and managing virtual IT
resources.
• Tasks: Managing VM templates, allocating/releasing virtual IT resources,
starting/pausing/resuming/terminating resources, coordinating resources for
replication, load balancing, and failover, implementing usage/security policies, and
monitoring operational conditions.
• Accessible directly by provider staff via VIM console, and by consumers/their
administrators via the Remote Administration System's API calls.
1.6. SLA & Billing Management Systems (Module 120):
• SLA Management: Monitors SLA compliance using agents that collect data
based on predefined metrics, including "pinging the service to evaluate the 'down'
time if occurs." Data is accessible via usage and administrative portals.
• Billing Management: Collects and processes service usage data for invoicing
and accounting. Supports "pay-as-you-go" and various pricing models (pay-per-use,
flat rate, per allocation, custom). Billing can be pre-usage or post-usage.
--------------------------------------------------------------------------------
Section 2: Fundamental Cloud Architectures
These architectures underpin the core functionalities of cloud computing,
emphasizing elasticity and efficiency.
2.1. Resource Pooling Architecture (Module 121):
• Groups identical IT resources into synchronized resource pools.
• Examples of Pools: Physical server pools, VM pools, Cloud storage pools
(file/block based), Network pools (for redundancy, load balancing), CPU pools.
• Structure: Pools can be dedicated per resource type, sub-grouped, or divided
into "sibling pools" (independent, isolated, diverse resources) and "nested pools"
(drawn from a larger pool, same resource types).
• Isolation: Resource pools for different consumers are isolated.
• Associated Mechanisms: Audit monitor, Cloud Usage Monitor, Hypervisor,
Logical Network Perimeter, Pay-Per-Use Monitor, Remote Administration System,
Resource Management System, Resource Replication.
2.2. Dynamic Scalability Architecture (Module 122):
• Provides dynamic allocation of resources from pools, supporting horizontal and
vertical scaling, and dynamic relocation.
• Scaling is "preconfigured and according to some preset thresholds."
• Key Mechanisms: Automated Scaling Listener (ASL) and Resource Replication
Mechanism, complemented by Cloud Usage Monitor and Pay-Per-Use Monitor.
2.3. Workload Distribution Architecture (Module 123):
• Aims to prevent "Over-utilization of IT resources to prevent the loss in
performance" and "Under-utilization of IT resources to prevent the over
expenditure."
• Distributes workload based on load balancing algorithms across VMs, cloud
storage, and services.
• Accompanied by: Audit monitor, Cloud usage monitor, Logical network
perimeter, Resource cluster, Resource replication.
2.4. Service Load Balancing Architecture (Module 123):
• Specific to workload distribution for Cloud services, deploying multiple instances
with a load balancing system.
• Load balancer can be external or integrated (one instance acts as master).
• Requires: Cloud usage monitor, Resource cluster (with active-active failover),
Resource replication.
2.5. Elastic Disk Provisioning Architecture (Module 124):
• Addresses billing models that charge for allocated storage rather than used
storage.
• Implements "dynamic storage provisioning based billing" where "The user is
charged only for the consumed storage" using "thin-provisioning."
• Requirements: Thin-provisioning software on VMs coordinating with hypervisor,
Cloud usage monitor, Resource replication (for converting thin to static storage),
Pay-per-use monitor.
2.6. Redundant Storage Architecture (Module 124):
• Prevents data loss and service unavailability due to disk or network failure using
redundant storage (active-passive failover).
• Primary and secondary storage are synchronized; a storage device gateway
redirects requests to secondary storage upon primary failure.
• Locations can be geographically dispersed for disaster recovery.
--------------------------------------------------------------------------------
Section 3: Advanced Cloud Architectures
These architectures build upon the fundamental concepts to enhance specific
aspects of cloud operations, primarily focusing on resilience, optimization, and
specialized provisioning.
3.1. Hypervisor Clustering Architecture (Module 125):
• Creates a high-availability cluster across multiple physical servers to prevent
service disruption if a single physical server fails.
• VIM controls operations like live VM migration and heartbeat exchanges.
• Requires shared storage for prompt live-migration.
• Additional Modules: Logical network perimeter, Resource replication module.
3.2. Load Balanced Virtual Server (VM) Instances Architecture (Module
126):
• Balances physical server utilization through VM migration within a hypervisor
cluster, avoiding over/under utilization and maintaining service performance.
• Components: Capacity watchdog/monitor system, Cloud usage monitor, Live VM
migration module, Capacity planner.
• Integrates: Automated scaling listener, Load balancer, Logical network
perimeter, Resource replication.
3.3. Non-Disruptive Service Relocation Architecture (Module 127):
• Ensures continuous service availability during high load or scheduled updates.
• Achieved through service duplication (temporary replication, then synchronization,
with requests diverted) or permanent service migration.
• VM migration depends on shared or local storage; shared storage simplifies the
process.
• Key Modules: Automated Scaling Listener, Load balancer, Hypervisors, VMs,
Cloud storage device, Cloud usage monitor, Pay per use monitor, Resource
replication, SLA management system, SLA monitor.
3.4. Zero Downtime Architecture (Module 128):
• Implements a failover system to dynamically shift VMs from a failed physical
server to another without interruption.
• Requires VMs to be stored on shared storage.
• Additional Modules: Cloud usage monitor, Logical network perimeter, Resource
cluster group (active-active clusters), Resource replication.
3.5. Cloud Balancing Architecture (Module 128):
• Failover system implemented "across multiple clouds" to improve performance,
scalability, availability, reliability, and load balancing.
• Requires an Automated Scaling Listener (ASL) to redirect requests to multi-cloud
redundant service instances based on scaling/performance needs, and a Failover
system to coordinate failure information with ASL.
3.6. Resource Reservation Architecture (Module 129):
• Addresses resource contention by assuring a minimum volume of IT resources
(single, portion, or multiple) for each consumer.
• Ensures pools maintain an "unborrowable" resource volume.
• The Resource Management System is utilized, managing borrowing across pools.
• Additional Modules: Cloud usage monitor, Logical network perimeter, Resource
replication.
3.7. Dynamic Failure Detection and Recovery Architecture (Module 130):
• Automated system for failure diagnosis and solution selection.
• Establishes a "resilient watchdog/module" with predefined events and runtime
logic to select recovery routines.
• Generates alarms for undefined events.
• Core Functions: Monitoring, Identifying an event, Executing reactive routines,
Reporting.
• Allows automated recovery policies (scripts, messages, service restarts).
• Can integrate with failover systems and SLA management.
3.8. Bare-Metal Provisioning Architecture (Module 131):
• Provisions physical servers on demand without pre-installed OS or hypervisor.
• Servers require remote management access (built-in ROM, chipset, or expansion
slot) for OS/hypervisor installation, accessible via Remote Administration System.
• Automated bare-metal provisioning allows centralized, mass server deployment
by consumers through self-service portals and Resource Management System.
3.9. Rapid Provisioning Architecture (Module 132):
• Automates IT resource provisioning to save time, reduce errors, and increase
throughput (e.g., provisioning 50 VMs simultaneously).
• Components: Centralized control module, server templates, server images (for
bare-metal), applications/PaaS packages, OS/application baselines, customized
scripts.
• Process: Consumer requests via self-service portal, module selects/initiates VM
with template, baselines applied, VM ready.
3.10. Storage Workload Management Architecture (Module 133):
• Ensures even distribution of Logical Unit Numbers (LUNs) across cloud storage
devices.
• Implemented via storage capacity system and storage monitoring module.
• Additional Modules: Cloud usage monitor, Load balancer, Logical network
perimeter.
3.11. Direct I/O Architecture (Module 134):
• Allows VMs to directly access physical I/O devices without hypervisor intervention,
mitigating I/O virtualization bottlenecks.
• Requires compatible physical server CPU.
• Additional Modules: Cloud usage monitor, Logical network perimeter (to restrict
direct I/O VMs), Pay-per-use monitor.
• Direct I/O Logical Unit Number Access Architecture: VMs directly access
LUNs or block-level storage.
3.12. Dynamic Data Normalization Architecture (Module 135):
• Addresses data duplication issues (storage time/space, backup, cost,
synchronization).
• Implements "data de-duplication by preventing the consumers to store replicated
data" for block and file storage.
• Analyzes data blocks, generates hash codes, and stores pointers to existing blocks
if duplicates are found, otherwise saves new blocks. Applicable to backup storage.
3.13. Elastic Network Capacity Architecture (Module 136):
• Dynamically scales network bandwidth, often on a per-user basis with separate
network ports.
• Components: Automated scaling listener (monitors traffic), elastic network
capacity controller, resource pool of network ports.
• Can configure virtual switches to use more physical uplinks or employ direct I/O
for VMs.
3.14. Cross Storage Device Vertical Tiering Architecture (Module 137):
• Dynamically shifts LUNs to storage devices with higher capacity (requests/second,
data handling).
• Not constrained by free space on the current physical device.
• Components: Automated scaling listener (monitors LUN requests), storage
management modules.
• Maintains connectivity and data availability during migration.
3.15. Intra Storage Device Vertical Data Tiering Architecture (Module 138):
• Applies vertical scaling within a single cloud storage device, optimally using
different disks with varying features/capacities.
• Disks are graded; LUNs are moved to higher-grade disks based on performance
requirements.
• Components: Automated scaling listener (monitors LUNs), storage management
software.
3.16. Load Balanced Virtual Switches Architecture (Module 139):
• Addresses network congestion and packet loss due to single physical uplinks.
• Implements network load balancing for physical servers and virtual switches using
multiple physical uplinks (multiple NICs per server).
• Uses link aggregation to distribute traffic, avoiding bottlenecks and maintaining
VM availability if an uplink fails.
3.17. Multipath Resource Access Architecture (Module 140):
• Provides "multiple access routes/paths to and from a Cloud IT-resource" for
resiliency in case of physical link failure.
• Avoids costly and time-consuming failover system execution if only a link fails.
3.18. Persistent Virtual Network Configuration Architecture (Module 141):
• Ensures that VM migration to another physical server retains its network
configuration and port number.
• Implemented through a "central virtual switch spanning over multiple physical
servers," storing VM network configurations centrally.
3.19. Redundant Physical Connection for Virtual Servers Architecture
(Module 142):
• Adds resiliency by incorporating redundant hardware (e.g., NICs) in an active-
passive manner.
• If the primary device fails, the secondary takes over, transparently to hosted VMs.
Virtual switch is configured to use all redundant NICs, but only one is active.
3.20. Storage Maintenance Window Architecture (Module 143):
• Allows maintenance of cloud storage devices without disrupting data availability.
• Temporarily copies data (e.g., LUNs) to a secondary device via live migration.
• Storage service gateway forwards requests to the secondary storage during
maintenance; data is moved back transparently.
--------------------------------------------------------------------------------
Section 4: Cloud Management and Ecosystems
This section delves into how cloud resources are managed, how different cloud
entities interact, and the various perspectives of providers and consumers.
4.1. Cloud Federation (Module 144):
• Interconnection of cloud computing infrastructures of two or more providers for
load balancing.
• One provider (buyer) buys services from another (seller), either temporarily or
permanently.
• Benefits: Revenue for seller, capacity extension for buyer without new hardware.
• VMs and data can migrate across clouds, transparently to buyer's consumers.
• Types: Horizontal (expanding IaaS, PaaS, SaaS services) or Vertical (e.g., Provider
A hosts Provider B's SaaS/PaaS on its IaaS). Can also be hybrid.
• Buyer's consumer SLAs are followed over the seller's infrastructure.
4.2. Workload Placement in Federated Clouds (Module 145):
• Federation addresses resource shortages and latency issues when a single cloud
cannot meet request deadlines.
• Decisions for processing excess requests are based on: revenue, cost to other
providers, and deadline vs. remote provider latency.
• Can reduce network latency by fulfilling requests through the closest provider in a
region.
4.3. Cloud Brokerage (Module 146):
• A third-party intermediary (broker) helps consumers find appropriate cloud
providers.
• Benefits: Saves consumer time/effort in searching, works closely to understand
consumer needs (business process, provisioning, budget).
• Provides a list of suitable providers, may negotiate on consumer's behalf, and
even settle contracts.
• Additional Services: API/GUI for resource handling, encryption/data transfer
assistance, advisory services.
4.4. Cloud Provider's Perspective (Modules 147-149):
• IaaS (Module 147): Provides VMs and cloud storage, along with OS, RAM, CPU,
storage. Uses VM images, bare-metal provisioning, VM snapshots. Spans multiple
data centers with VLANs for isolation. Leverages resource pools, management
systems, replication, multipath access, resource reservation, and various monitors
(pay-per-use, SLA). Cloud security (encryption, authentication, authorization) is
fundamental.
• PaaS (Module 148): Offers ready-made environments for developers (software
tools, SDKs). Simulates cloud environments with security for testing. Aids
multitenancy and autoscalability. Uses ASL, load balancers, non-disruptive service
relocation, and failover for reliability. Pay-per-use and SLA monitors collect data.
• SaaS (Module 149): Characterized by concurrent users. Relies on scalability,
workload distribution, non-disruptive service relocation. Each deployment is unique
in logic, resource needs, and workloads (e.g., Wikipedia, Google Talk, email). Access
mediums include mobile apps (via multi-device broker), REST/Web services (with
APIs). Requires service load balancing, dynamic failure detection/recovery, storage
maintenance window, elastic resource/network capacity, and cloud balancing
architectures. Security features are layered on underlying IaaS.
4.5. Cloud Consumer’s Perspective (Modules 150-152):
• IaaS (Module 150): Accesses VMs via remote terminal (RDP, SSH). Cloud storage
can connect to VM or local device. Administrative rights include controlling
scalability, VM lifecycle, network settings (firewall, perimeter), storage attachment,
failover, SLA monitoring, basic software/OS, VM image selection,
password/credential management, and costs. Managed via portals or CLI.
• PaaS (Module 151): Receives software libraries, frameworks, APIs, databases,
cloud emulation. Administrative rights include login management for developed
services, tool selection in ready-made environments, storage device selection, cost
monitoring, and deployment of scaling/load balancing/replication. SLA monitoring is
also a control.
• SaaS (Module 152): Has the "least administrative privileges and the least
responsibilities." API calls enable widespread integration (e.g., Google Maps). Free
services may gather background data. Limited runtime configurations controllable
include usage cost, SLA monitoring, and security configurations.
4.6. Inter-Cloud Resource Management (Module 153):
• "Cloud of Clouds" - analogous to the Internet's "network of networks."
• Addresses situations where providers have idle resources or resource shortages.
• The "ultimate future of Cloud federation," with major tech giants actively working
on it. Aims to overcome interoperability, communication, security, and workload
migration issues.
--------------------------------------------------------------------------------
Section 5: Cost Metrics, Service Quality, and SLAs
Understanding the financial and performance aspects of cloud services is critical for
both providers and consumers.
5.1. Cost Metrics and Pricing Models (Modules 154-158):
• Business Cost Metrics (Module 154):
◦ Upfront Costs: Initial investment (high for on-premises, low for leased cloud).
◦ On-going Costs: Running costs (licensing, electricity, labor). Long-term cloud
costs can exceed on-premises.
◦ Additional Costs: * Cost of Capital: Higher for large capital arranged
quickly. * Sunk Costs: Already spent on existing IT infrastructure; can make cloud
leasing harder to justify. * Integration Costs: Time and labor for integrating cloud
solutions. * Locked-in Costs: Dependency on a single provider due to lack of
interoperability.
• Cloud Usage Cost Metrics (Module 155):
◦ Network Usage: Inbound/outbound traffic (bytes), static IP usage, virtual
firewall processing. Many providers don't charge for inbound traffic.
◦ VM Usage: Number of VMs, usage of allocated VMs (static, pay-per-use,
feature-based).
◦ Cloud Storage Device Usage: Amount of storage used (on-demand, hourly
basis), sometimes I/O operations.
 ◦ Cloud Service Usage: Subscription duration, number of users, number of
transactions.
• Total Cost of Ownership (TCO) Analysis (Module 156): Case study
demonstrates how cloud solutions can have lower upfront costs but potentially
higher monthly ongoing costs compared to on-premises solutions, emphasizing a
need for multi-year analysis.
• Cost Management Considerations (Module 157): Cost management spans
the entire service lifecycle (design, deployment, contracting, provisioning,
decommissioning). Pricing models are influenced by market, overhead, resource
sharing, and can include fixed/variable rates, discounts, customization, negotiations,
and payment options.
• Case Study: Pricing Offerings (Module 158): Illustrates different VM
configurations with hourly pay-per-use rates and 1-year term pricing (upfront +
hourly pay-per-use), highlighting price variations based on OS and VM
specifications.
5.2. Service Quality Metrics and SLA Guidelines (Modules 159-165):
• General Service Quality Metrics (Module 159): Quantifiable, repeatable,
comparable, and obtainable.
◦ Availability: Uptime (e.g., 99.5%), downtime duration (e.g., 1 hr max).
◦ Reliability: Probability of failure-free service (e.g., Mean-Time Between
Failures, Service Reliability Rate).
◦ Performance: Capacity (network bandwidth, storage size, VM features, web
application requests/min).
◦ Scalability: Elastic capacity, maximum capacity, adaptability to workload
fluctuations (e.g., storage/server horizontal/vertical scalability).
◦ Resiliency: Ability to recover from operational disturbance (Mean-Time to
Switchover, Mean-Time System Recovery).
• SLA Guidelines for Consumers (Module 165):
◦ Mapping test-cases to SLAs to ensure alignment with consumer requirements.
◦ Clearly understanding the scope of SLA (what's covered/uncovered).
◦ Documenting all guarantees at proper granularity.
◦ Clearly defining penalties and reimbursements.
◦ Considering independent third-party SLA monitoring.
◦ Addressing data archives and deletion assurance for monitored data.
--------------------------------------------------------------------------------
Section 6: CloudSim - Cloud Simulation Environment
CloudSim is introduced as a vital tool for researchers and practitioners in cloud
computing.
6.1. Introduction (Module 166):
• A free simulation environment for testing research, theories, and procedures
without requiring real data centers.
• Uses:
◦ IaaS/PaaS users can "tune up performance bottlenecks."
◦ Providers can "test various policies related to resource leasing, pricing and
workload management."
• Documentation, setup, and tutorials are freely available.
6.2. Configuration (Module 167):
• Requires Java 8 or newer.
• Simple setup (unpack folder).
• Includes coded examples and video tutorials.
6.3. Example Code and Architecture (Module 168):
• Emulates a virtualized data center with hosts (physical servers) and VMs.
• Workload Unit: "Cloudlet."
• Broker Entity: Executes Cloudlets on the data center.
• Cloud Information Service (CIS): Registry of data centers. Broker retrieves
information from CIS.
• Hosts have properties (processors, RAM); VMs share hosts; VMs can schedule
multiple Cloudlets.
• Policy Objects:
◦ VM-allocation policy: Data center allocates VMs to hosts.
◦ VM-scheduler policy: Host allocates resources.
◦ Cloudlet-scheduler policy: VM schedules Cloudlets.
• Policies can be space-shared or time-shared.
--------------------------------------------------------------------------------
Section 7: Cloud Security, Privacy, and Trust
A substantial portion of the modules addresses the critical aspects of security,
privacy, and trust in the cloud environment, highlighting challenges and
mechanisms.
7.1. Computer Security Overview (Module 169):
• Definition: "The protection afforded to an automated information system in order
to attain the applicable objectives of preserving the integrity, availability and
confidentiality of information system resources."
• Privacy: The right of an individual to control information collection, storage, and
disclosure. Key terms: Data controller, data processor, data subject. Privacy is a
human right in Europe, traditionally about avoiding harm in America.
7.2. Confidentiality, Integrity, and Availability (CIA) (Module 170):
• Confidentiality: Authorized access and disclosure only (e.g., student grades).
• Integrity: Guarding against unauthorized modification/destruction (e.g., patient
allergy info).
• Availability: Timely and reliable access (e.g., authentication service).
• Authentication: Proving user identity (password, PIN, biometrics, tokens).
• Authorization: Verifying access rights of an authenticated user.
7.3. Computer Security & Trust (Module 171):
• Trust: A psychological state of accepting risks based on positive expectations of
behavior. Broader than security as it includes experience and criteria.
• Types of Trust:
◦ Hard Trust: Security-oriented (authentication, encryption, CIA).
◦ Soft Trust: Non-security oriented (human psychology, brand loyalty).
• Online services often have lower trust than offline. Trust in cloud computing can
be "Persistent trust (long term) and Dynamic trust (short term)." Enhanced through
security elements.
7.4. Computer Security Basics (Modules 172-177, 183-187):
• Cryptography (Module 172): Science of providing information security through
secret communication (converting data to unreadable format). Functions: Privacy,
Authentication, Integrity, Non-repudiation, Exchange of crypto keys.
• Authentication & Access Control (Module 173): Authentication methods
(what user knows, possesses, is). Access control limits authenticated user
actions/privileges, enforced by software module based on organizational policy.
Access control requires authentication.
• Malware (Module 174): Malicious software compromising CIA (e.g., Adware,
Backdoor, Keyloggers, Rootkit, Spyware, Trojan horse, Virus, Worm, Zombie/bot).
• Denial of Service (DoS) Attacks (Module 175): Floods servers/networks,
making IT resources unavailable. Difficult to recover. Symptoms: degraded network
performance, website inaccessibility, high spam volume. Remedies: ISP help, DoS
detection tools. Victims: application/DNS servers.
• Intrusion Detection & Firewalls (Module 176):
◦ Firewall: Hardware/software to block unauthorized access, filter harmful traffic
(packet filtering, stateful inspection).
◦ Intrusion Detection System (IDS): Detects intrusion attempts, malicious
activity, or policy violations; alerts administrators but cannot block traffic.
• Buffer Overflow Attacks (Module 177): Occurs when a program writes more
data than a memory buffer allows, overwriting adjacent memory. Can lead to
attacker control or system crash. More common in C/C++; C# and Java reduce this
risk.
• Encryption (Module 183): Transforms plaintext to protected, non-readable
ciphertext using a cipher and encryption key. Counters eavesdropping, malicious
intermediaries, insufficient authorization, overlapping trust boundaries.
◦ Symmetric Encryption: Single key for encryption/decryption (secret key
cryptography).
◦ Asymmetric Encryption: Two keys (public/private key pair); public key
encrypts, private key decrypts. Ensures confidentiality but not sender authenticity.
• Hashing & Digital Signatures (Module 184):
◦ Hashing: Derives a fixed-length "message digest" from a message. Used to
verify message integrity; any alteration results in a mismatch.
◦ Digital Signatures: Verifies authenticity and integrity of messages/software;
digital equivalent of handwritten signature. Encrypted hash code and algorithm
form the signature. Used by cloud consumers for request authenticity.
• Public Key Infrastructure (PKI) (Module 185): Manages asymmetric
encryption keys systematically. Relies on digital certificates (binding public key to
owner, signed by Certificate Authority). Dependable for asymmetric encryption,
identity management, and defending against malicious threats.
• Identity and Access Management (IAM) (Module 186): Policies and
procedures to manage user identities and access privileges. Components:
Authentication, Authorization, User management, Credential management. IAM
assigns user privileges via access control policies, unlike PKI.
◦ Single Sign-On (SSO): Saves consumers from signing into multiple services; a
security broker creates a persistent security context.
• Cloud-based Security Groups (Module 187): Logical groups with separate
security policies, acting as network perimeters. Safeguard against DoS, insufficient
authorization, overlapping trust boundaries.
• Hardened Virtual Server Images (Module 187): Removing unnecessary
software/ports, disabling root access/guest login, and services from VM templates to
enhance security.
7.5. Internet Security (Module 178):
• Deals with internet-based threats: unauthorized access (system, email, website,
banking), viruses, social engineering.
• Secure Socket Layer (SSL): Security protocol for encrypting web browser-web
server communication. Website shares security certificate (from CA) with browser,
which then generates a session key for encrypted communication (HTTPS).
7.6. Wireless Network Security (Module 179):
• Secures wireless communication from unauthorized access. Threats:
eavesdropping, traffic modification/retransmission, DoS attacks on access points.
• Protocols:
◦ Wired Equivalent Privacy (WEP): Old standard, many flaws, easily cracked.
◦ Wi-Fi Protected Access (WPA): Interim alternative to WEP, uses enhanced
RC4 (TKIP), backward compatible.
◦ Wi-Fi Protected Access 2 (WPA2): Most secure standard (IEEE 802.11i),
replaces RC4-TKIP with AES and CCMP. Allows seamless roaming.
7.7. Operating System and Virtualization Security (Module 180):
• OS Security: Planning (purpose, users, data), secured BIOS, patching/updates,
removing unnecessary components, configuring users/groups/permissions, installing
security tools, whitelisting applications.
• Virtualization Security: Isolation/monitoring of guest OSs, security of OS
images/snapshots. Achieved by clean hypervisor install, administrative access
control, preventing guest OS modification of hypervisor, proper virtual-to-physical
device mapping, and network monitoring.
7.8. Threat, Vulnerability & Risk (Module 181):
• Threat: Potential security breach (manual/automatic), exploits vulnerabilities.
• Vulnerability: Security weakness that can be exploited (insufficient protection,
configuration deficiencies, policy weaknesses, user error, hardware/software flaws,
poor architecture).
• Risk: Possibility of harm/loss. Measured by threat level and number of
vulnerabilities; expressed as probability of threat occurring or expected loss.
7.9. Threat Agents (Module 182):
• Factors capable of carrying out an attack (internal/external, human/software).
• Types: Anonymous Attacker, Malicious Service Agent, Trusted Attacker (legitimate
consumer launching attacks), Malicious Insider (current/previous employee with
administrative rights).
7.10. Privacy Issues for Cloud Computing (Modules 188-195):
• Lack of User Control (Module 188):
◦ Infrastructure Ownership/Control: User lacks control over underlying
infrastructure, leading to risk of theft/misuse/unauthorized sale of data.
◦ Access & Transparency: Unclear if provider accesses user data, or if
unauthorized access is detectable.
◦ Data Lifecycle Control: No confirmation of data deletion (even for terminated
accounts); no "must-erase liability."
◦ Changing Provider: Difficulty retrieving data fully or ensuring deletion by
previous provider.
◦ Notification & Redress: Unclear responsibility for unauthorized access.
• Lack of Training and Expertise (Module 189): Shortage of STEM-skilled
personnel can lead to security issues and poor privacy decisions. Increased mobile
device usage by employees can introduce privacy threats (e.g., unattended laptops
with unencrypted data). Public cloud access requires care.
• Unauthorized Secondary Usage (Module 190): High tendency for data to be
used without authorization (e.g., selling statistics for ads is legal, selling sales data
to competitors is illegal). Difficult to verify illegal secondary usage.
• Complexity of Regulatory Compliance (Module 191): Global nature of cloud
makes compliance with regional laws complex. Data replication across locations and
providers, rapid provisioning, and cross-border movement of data in transit pose
challenges for legal location-boundary adherence.
• Addressing Transborder Data Flow Restrictions (Module 192): Many
countries (EU/EEU, Australia, Canada) restrict personal data flow. Transfer requires
"adequate protection" or agreements (e.g., US Safe Harbor, model contracts). Cloud
computing often struggles to comply with these restrictions.
• Litigation (Module 193): Cloud Service Providers (CSPs) may be forced to hand
over consumer data due to court writs (e.g., US Patriot Act). Private entities can
mitigate this via legal agreement clauses.
• Legal Uncertainty (Module 194): Cloud computing outpaces legal frameworks,
leading to uncertainties about privacy rights (e.g., legal consent for anonymizing
data, applicability of transborder laws to anonymized data).
• Conclusions on Privacy (Module 195): Global privacy uncertainty. Cloud
globalization demands new security frameworks with accountability. Compliance
with transborder data flow, unknown data processing/storage locations, and assured
data deletion/virtual storage discarding are major challenges.
7.11. Security Issues for Cloud Computing (Modules 196-205):
• Gap in Security (Module 196): Lack of user control introduces risks due to
potential insufficient effort by providers. SLAs often lack consumer-mandated
security provisions. Responsibility shifts with service model (IaaS consumers have
more). Difficulty in ensuring standardized security with supply chains. Providers
often take no liability for data deletion, loss, or alteration; terms favor provider.
• Unwanted Access (Module 197): From governments (e.g., US Patriot Act),
inadequate supply chain security, malicious employees, or other tenants if data is
not adequately separated. Cloud storage is more prone to risk than processing due
to longer exposure.
• Vendor Lock-in (Module 198): Lack of interoperability standards (hypervisors,
APIs, data formats, M2M) makes security frameworks difficult across heterogeneous
environments. Hard to migrate data or services between providers or in-house.
• Inadequate Data Deletion (Module 199): No surety that deleted data is truly
non-recoverable, exacerbated by duplicate copies or shared virtual disks.
Reallocation of VMs in IaaS/PaaS can lead to data persistence issues. For SaaS, data
is deleted when subscription ends.
• Compromise of the Management Interface (Module 200): Remote access
via Internet increases risk, as vulnerabilities in browsers/remote access can grant
broad malicious access.
• Backup Vulnerabilities (Module 201): Multiple data copies across locations
introduce vulnerabilities. Data loss possible before backup, subset separation, or
key loss. Some traditional backup services completely lose data on non-payment.
Cloud services generally show more resiliency.
• Isolation Failure (Module 202): In multi-tenant SaaS, logical/virtual partitioning
can fail, allowing other tenants to access sensitive data. Virtualization-based attacks
can compromise hosting servers, exposing all hosted VMs.
• Missing Assurance and Transparency (Module 203): Providers take less
liability for data loss. Consumers need assurance regarding data safety, warnings
for attacks/loss. Existing frameworks may not cover frequent data accesses or
isolation failures. No compensation for data loss incidents. Private cloud offers best
assurance.
• Inadequate Monitoring, Compliance and Audit (Module 204): Consumers
need to audit data processing for policy compliance, but cloud complexity makes it
difficult. Providers should implement internal/external monitoring. "Right to audit"
for regulated consumers. Full audit trail in public cloud remains unsolved.
• Conclusions on Security (Module 205): Numerous issues depend on
service/deployment models. Cloud audit is an open issue. Cloud adoption doesn't
necessarily worsen security; can be outsourced to experts. Major issue is finding a
provider with suitable controls for security, monitoring, and audit.
7.12. Trust Issues for Cloud Computing (Modules 206-210):
• Trust in the Clouds (Module 206): Cloud consumers must extend traditional
trust boundaries to providers. Trust relies on information from trusted entities
(auditors, experts, reputable companies). Critical for sensitive data.
• Lack of Consumer Trust (Module 207): Surveys show significant concern over
unauthorized secondary usage (70% Europeans). Trust influenced by reputation
(29%), recommendations (27%), trial experience (20%), contract (20%). Depends on
compatibility between provider's data protection and consumer expectations.
Enterprises concerned about security (70%), SLA (75%), vendor lock-in (79%),
interoperability (63%).
• Weak Trust Relationships (Module 208): Supply chain mechanisms with
subcontractors can jeopardize security/privacy and weaken trust. Non-transitive
trust along the service delivery chain. Lack of transparency; consumer may not
know subcontractor identity. "On-demand" and "pay-as-you-go" models may rely on
weak trust due to rapid onboarding of new providers.
• Lack of Consensus About Trust Management Approaches (Module
209): No consensus on trust management. Trust measurement is challenging due to
contextual representation. Need for standardized trust models for accountability
and evaluation. Existing models are inadequate or partial. Lack suitable metrics for
accountability and evidence for verification.
• Trust Conclusions (Module 210): Trust is a key concern for all stakeholders,
inhibiting widespread adoption. Fears of unwanted/unauthorized access and
secondary usage. Lack of user control. Trade-offs between privacy, security,
compliance, costs, and benefits. Trust mechanisms must propagate through the
service chain. Trust measurement models need development.
--------------------------------------------------------------------------------
Section 8: Open Issues in Cloud Computing
Acknowledging that cloud computing, despite its benefits, presents ongoing
challenges.
8.1. Overview (Module 212):
• Cloud is not a universal solution; not suitable for all applications.
• Failures and security compromises are inherent in complex systems like cloud.
• These issues do not disqualify cloud but highlight the need for techniques to
address, reduce, and isolate them. NIST highlights further issues.
8.2. Computing Performance (Module 213):
• Real-time applications demand high performance and predictability. Cloud faces
issues similar to other distributed computing forms.
• Latency: Unpredictable for Internet-based communications.
• Offline Data Synchronization: Problematic for updates with multiple data
copies; requires version control, collaboration, synchronization.
• Scalable Programming: Legacy applications need updates to leverage cloud
scalability.
• Data Storage Management: Consumers need control over data lifecycle and
intrusion information.
8.3. Cloud Reliability (Module 214):
• Probability of failure-free service. Depends on provider infrastructure and
connectivity. Difficult to measure due to complexity.
• Factors: Network Dependence (unreliability of Internet, attacks), Safety-Critical
Processing (applications that can harm human life, e.g., avionics, nuclear controls,
medical devices, are not suitable for cloud).
8.4. Economic Goals (Module 215):
• Cloud offers economic benefits (saving upfront/maintenance costs, economies of
scale) but has economic risks.
• SLA Evaluation: Lack of automated compliance mechanisms needs common
templates for quick overview, aiding manual audit decisions.
• Portability of Workloads: Need for reliable/secure mechanisms for data transfer
to/from cloud and porting workloads between providers are open issues.
• Interoperability between Cloud Providers: Causes vendor lock-in fear.
• Disaster Recovery: Requires recovery plans for hardware/software disasters to
mitigate economic/performance losses.
8.5. Compliance (Module 216):
• Compliance with laws and security procedures. Consumer is responsible, but
provider implements.
• Lack of consumer visibility into provider's security. Consumers may request
monitoring.
• Assurance needed from providers regarding compliance with laws (e.g., health
info, payment security).
• Forensics Support: Crucial for incidence response (attack type, extent, damage,
legal info). Provider responsible for SaaS, consumer for IaaS.
8.6. Information Security (Module 217):
• Related to confidentiality, integrity, availability.
• Measures: Administrative controls (user authority), Physical controls (storage
device security), Technical controls (IAM, encryption, audit).
• Public/private clouds have typical exposures. Providers may offer physical data
separation and monitoring for security compliance.
8.7. Approaches to Addressing Privacy, Security and Trust Issues (Module
218):
• Three Dimensions:
1. Innovative Regulatory Frameworks: To facilitate cloud operations and solve
issues.
2. Responsible Company Governance: Provider intent to safeguard data,
proven through audit.
3. Supporting Technologies: Privacy enhancement, security mechanisms,
encryption, anonymization.
• Combining these can reassure consumers and build provider trust.
--------------------------------------------------------------------------------
Section 9: Disaster Recovery in Cloud Computing
Addresses various threats and how cloud solutions mitigate them, emphasizing
resiliency.
9.1. Understanding Threats and Mitigation (Modules 219-225):
• Disk Failure (Module 219): Electro-mechanical devices fail.
◦ Traditional: Backup on separate storage (risk of backup loss, time-consuming
recovery).
◦ RAID: Multiple disks, data distributed, easy disk replacement, but still needs
backup for full RAID destruction.
◦ Cloud-based: Enhanced data replication (often default/free), remote backup
site (advantage over onsite), readily available backup (reduced downtime).
• Power Failure/Disruption (Module 220): Surges damage, blackouts lose
unsaved data.
◦ Traditional: Surge protectors (limited), expensive in-house UPS/generators,
shifting data to another site (expensive/time-consuming).
◦ Cloud-based: Providers have better/shared-cost power backups. Cloud
mechanisms may auto-shift data to remote sites on other power grids for long
outages.
• Computer Viruses (Module 221): Downloads, shared drives.
 ◦ Traditional: Anti-virus, user privilege restriction, firewalls.
◦ Cloud-based: Difficult for non-cloud viruses to penetrate due to virtualization
complexity. Providers ensure reasonable security.
• Fire, Flood & Disgruntled Employees (Module 222):
◦ Fire/Flood: Destroy computing
resources/data/backup. * Traditional: Insurance, backup, special fire-
extinguishing. * Cloud-based: Consumer freed from fire prevention/recovery costs;
provider manages. Choose providers outside flood zones.
◦ Disgruntled Employees: Viruses, file deletion, password
leaks. * Traditional: Access control, backup. * Cloud-based: IDaaS (Identity as a
Service) with single sign-on can quickly exclude terminated employee access.
• Lost Equipment & Desktop Failure (Module 223): Loss of device means
data/identity loss. Desktop failure means user offline.
◦ Traditional: Backup, strong passwords (for lost devices); alternative desktop
and data restore (for failed desktops).
◦ Cloud-based: Data synced over multiple devices, accessible from online
interface/other synced devices. If desktop fails, user can log in from any other
computer to resume work.
• Server Failure & Network Failure (Module 224):
◦ Server Failure: * Traditional: Redundant servers. * Cloud-based: IaaS/PaaS
providers offer 99.9% uptime via server redundancy and failover.
◦ Network Failure: * Traditional: 3G/4G hotspots, redundant Internet
connections. * Cloud-based: Consumers need redundant connections; providers
ensure 99.9% uptime via redundant connections.
• Database System Failure & Phone System Failure (Module 225):
◦ Database Failure: Affects dependent applications. * Traditional: Backup
(downtime) or replication (complex, minimal/no downtime). * Cloud-based: Cloud
storage/database systems use replication and failover to minimize downtime.
◦ Phone System Failure: * Traditional: Limited solutions to reduce
impact. * Cloud-based: Reliable, failure-safe phone systems using internal
redundancy.
9.2. Measuring Business Impact, Disaster Recovery Plan (DRP) Template
(Module 226):
• Risk reduction has costs; investment is limited. IT staff should classify risks by
impact and probability.
• DRP formal documentation: overview, goals, events covered, risk analysis,
mitigation techniques.
--------------------------------------------------------------------------------
Section 10: General Recommendations by NIST & Migration to Cloud
Guidance for consumers and providers to ensure effective and secure cloud
adoption.
10.1. General Recommendations by NIST (Modules 227-230):
• Management (Module 227):
◦ Migrating Data: Clear plan for data return upon service termination.
◦ Continuity of Operations: Provider should meet consumer DRP parameters
for business-critical software/data. Demand compensation for interruptions.
Otherwise, host critical applications locally.
◦ Compliance: Provider implements necessary legal/ISO/audit controls.
◦ Administrator Staff: Provider's internal procedures must protect against
malicious insiders.
◦ Licensing: Proper licensing for proprietary software.
• Data Governance (Module 228):
◦ Data Access Standards: Generic interfaces/adaptors for
portability/interoperability.
◦ Data Separation: Proactive measures for sensitive/non-sensitive data
separation.
◦ Data Integrity: Use checksums and replication.
◦ Data Regulations: Provider must comply with all applicable data regulations.
◦ Data Disposition: Provider offers data deletion mechanisms and proof.
◦ Data Recovery: Examine provider's backup/archiving/recovery procedures.
• Security & Reliability (Module 229):
◦ Consumer-side Vulnerabilities: Harden consumer platforms to avoid client-
based attacks.
◦ Encryption: Strong encryption for web sessions, data transfer, storage.
◦ Physical Security: Assess provider's physical security, prefer providers with
multiple geographically diverse installations.
◦ Authentication: Use advanced authentication procedures.
◦ Identity & Access Management: Visibility into provider's IAM capabilities and
consumer tools for authentication/authorization.
 ◦ Performance Requirements: Benchmark application performance pre-cloud
to set requirements post-cloud.
• VMs, Software & Applications (Module 230):
◦ VM Vulnerabilities: Provider ensures mechanisms against attacks from other
VMs, host, network; IDS/IPS, VLANs.
◦ VM Migration: Plan for migration across providers.
◦ Time/Safety-critical Software: Avoid public clouds due to unreliable
response time and unconfirmed reliability.
◦ Application Development Tools: Prefer tools with integrated security
features.
◦ Application Runtime Support: Ensure dependable libraries for
performance/functionality.
◦ Application Configuration: Configurable for secured environments (VLANs),
integratable with security frameworks.
◦ Standard Programming Languages: Prefer clouds supporting standardized
languages/tools.
10.2. Migrating to the Cloud (Modules 231-233):
• Define System Goals and Requirements (Module 231): Well-planned
migration starts with defining: data security/privacy, site capacity, scalability,
uptime, business continuity/disaster needs, budget, OS/programming language,
cloud type (public/private/hybrid), multi/single-tenancy, data backup, client device
support, training, API, data export, reporting.
• Protect Existing Data and Know Application Characteristics (Module
232): Backup data before migration. Agree on periodic backup plan. Finalize data
lifecycle/disposal terms. Include regulatory requirements in agreement. Know
application IT resource requirements (demand periods, users, storage,
database/replication, RAM, bandwidth, caching).
• Establish Realistic Deployment Schedule, Review Budget, Identify IT
Governance Issues (Module 233):
◦ Deployment Schedule: Allow time for training/testing (e.g., beta-release).
◦ Budget Review: Compare TCO (in-house vs. cloud) considering running cost,
payroll, licensing, maintenance.
◦ IT Governance: Align cloud with business strategy, identify controls (in/out-of-
cloud), define access control policies, understand provider's error/event logging and
performance monitoring tools.
--------------------------------------------------------------------------------
Section 11: Designing Cloud-based Solutions
Focuses on the considerations and metrics essential for building effective cloud
applications.
11.1. Identify Functional and Non-functional Requirements (Module 234):
• Essential for design phase. Personal meetings help. Early error/omission
identification saves cost/time.
• Functional: Specific system tasks.
• Non-functional: Quality metrics (performance, reliability, maintainability).
11.2. Cloud Solution Design Metrics (Modules 235-238):
• Accessibility (Module 235): Maximize user access or restrict to authorized
users.
• Audit (Module 235): Logging/exception handling at critical points for later audit.
• Availability (Module 235): Identify uptime requirements, use redundant
deployment.
• Backup (Module 235): Consider backup cost/restore time. Review/renegotiate
provider policies.
• Existing & Future Capacity (Module 236): Evaluate current IT resource needs
for initial deployment and scaling.
• Configuration Management (Module 236): Application interfaces render
content based on OS, browser, device.
• Deployment (Module 236): Address OS, browser, device issues for initial and
future updates.
• Environment (Green Computing) (Module 236): Design for power efficiency
to reduce carbon footprint.
• Disaster Recovery (Module 236): Identify risks, configure cost-effective
mitigation.
• Interoperability (Module 236): Possibility of data exchange between different
cloud solutions.
• Maintainability (Module 236): Design for reusability (loose coupling) to lower
maintenance cost.
• Performance (Module 237): Reduce graphics, network operations, use caching,
identify/address bottlenecks.
• Price (Module 237): Consider short/long-term budget for scalability, DR,
performance features.
• Privacy (Module 237): Implement privacy assurance (especially for sensitive
data), for internal/external unauthorized access, replicated databases, and backups.
• Portability (Module 237): Design for portability to other platforms; prefer
generic/OpenSource APIs.
• Recovery (Module 237): Features to recover from user error, bugs, power
outage (beyond disaster recovery).
• Reliability (Module 238): Design for hardware failure (redundant config based
on MTBF) or acceptable downtime.
• Response Time (Module 238): Minimize, especially for online forms/reports.
• Robustness (Module 238): Continuous working despite errors/failures;
complemented by monitoring for timely alarms.
• Security (Module 238): Consider cloud security/privacy issues during design.
• Testability (Module 238): Develop test cases for functional/non-functional
requirements.
• Usability (Module 238): Improve via prototyping and user reviews.
--------------------------------------------------------------------------------
Section 12: Cloud Application Scalability
Strategies for ensuring cloud applications can handle varying workloads efficiently.
12.1. Review Load Balancing Process (Module 239):
• Cloud solutions must scale up/down. Scaling out means new resources, scaling up
means upgrading.
• Load balancer is essential for horizontal scaling, distributing workload (client
requests) to acquired IT resources.
• Allocation patterns: round robin, random, complex algorithms.
12.2. Application Design (Module 239):
• Balanced design: neither no-scaling nor unlimited scaling.
• Explore horizontal and vertical scaling individually or in combination.
12.3. Optimization Techniques (Modules 240-241):
• Minimize Objects on Key Pages (Module 240): Reduce graphics/animations
on frequently visited pages for faster loading.
• Selecting Measurement Points (Module 240): Apply scaling to 20% of code
that performs 80% of processing.
• Analyze Database Operations (Module 240): Read operations can use
replicated databases (horizontal scaling). Write operations require synchronization
across replicas. Use database statistics for horizontal scaling decisions.
• Evaluate System's Data Logging Requirements (Module 240): Monitor
system logging's disk/CPU consumption; tune periodically.
• Capacity Planning vs. Scalability (Module 241): Both must be in harmony.
Capacity planning is for specific time needs; scalability is for increasing workload.
• Diminishing Return (Module 241): Avoid scaling beyond the point of
performance improvement.
• Performance Tuning (Module 241): Beyond scaling, tune performance by
reducing graphics, page load time, response time. Use caching (faster disks, RAM
for rendering, optimizing code with 20/80 rule).
--------------------------------------------------------------------------------
Section 13: Cloud Resource Scheduling
Discusses the allocation of IT resources to meet user processing requests.
13.1. Overview (Module 242):
• Two Steps:
1. Resource Provisioning: Gathering/reserving IT resources based on expected
workload.
2. Resource Scheduling: Algorithmic allocation of workload among provisioned
resources.
• Benefits: Reduces execution cost/time, energy consumption, fulfills QoS
(reliability, security, availability, scalability).
• Conflict: Providers maximize profit/resource usage; consumers minimize
cost/time.
13.2. Scheduling Types (Modules 243-253):
• Cost Based (Module 243): Prioritizes cost/budget constraints. First-come, first-
served, with QoS/time constraints. Can lead to starvation.
• Time Based (Module 244): Prioritizes processing deadlines. Resources allocated
to jobs with fastest approaching deadlines. May miss deadlines or be expensive.
• Cost & Time Based (Module 245): Hybrid approach to balance cost and
deadline violations.
• Bargaining Based (Module 246): Resource market where providers make
offers, users negotiate. Aims for low cost and meeting deadlines if successful.
• Profit Based (Module 247): Aims to increase provider profit by reducing cost or
increasing simultaneous users. Must consider SLA violation penalties.
• SLA & QoS Based (Module 248): Avoids SLA violations and maintains QoS.
Suitable for homogeneous tasks with predictable workload/completion time.
• Energy Based (Module 249): Aims to save energy at data center level. Prefers
task distribution with least energy consumption.
• Optimization Based (Module 250): Perfecting algorithms for maximum benefit
(revenue, lower communication overhead, output/energy efficiency, reduced
completion time). Computational time can be a drawback for time-critical jobs.
• Priority Based (Module 251): Avoids task starvation; classifies tasks (type,
user, resource needs) to allow preemption of low-priority tasks. Aging factor can
raise low-priority tasks.
• VM Based (Module 252): Scheduling based on overall demand of applications
hosted on a VM. If a VM faces starvation, it can migrate to another server. No
guarantee destination host won't also run out.
• Hybrid Based (Module 253): Resource scheduling may lead to hybrid cloud
formation for additional resources. Requires careful selection of tasks/resources for
budget/deadline.
--------------------------------------------------------------------------------
Section 14: Mobile Cloud Computing (MCC)
Explores the intersection of mobile devices and cloud computing.
14.1. Introduction & Overview (Module 254):
• Mobile devices are resource-constrained (processing, memory, storage, battery).
• Cloud computing offers unlimited IT resources.
• Definition: MCC is an infrastructure where data storage and processing happen
outside the mobile device. "Mobile cloud applications move the computing power
and data storage away from mobile phones and into the cloud."
14.2. Need for MCC (Module 255):
• Addresses mobile device resource shortages for applications like Optical Character
Recognition (OCR), data sharing (e.g., disaster images), and collecting/processing
sensor readings from multiple devices.
14.3. Applications of MCC (Module 256):
• Mobile Commerce: Addresses bandwidth, device config, security complexities.
• Mobile Learning: Overcomes high device/data plan costs, bandwidth/storage
limits (renders large tutorials, faster processing, battery efficiency).
• Mobile Healthcare: Remote patient monitoring, timely guidance for
emergencies, security, privacy.
• Mobile Gaming: Game engine executes on cloud, mobile device only handles
screens.
14.4. MCC Architecture (Module 257):
• Mobile devices connect to mobile networks via base stations (access points, BTS,
satellite).
• Base stations link devices to mobile network services (authentication,
authorization, accounting).
• Requests delivered to cloud via Internet, handled by cloud controllers.
14.5. Mobile Cloud Models (Module 258):
• Mobile device accessing cloud-hosted application (e.g., email via 3G).
• Mobile devices providing resources to others in a peer-to-peer cloud.
• Mobile devices connected to "cloudlets" (multi-core computers near devices)
which are connected to remote cloud servers.
14.6. Advantages of MCC (Module 259):
• Extended battery lifetime (offloading workload).
• Improved data storage capacity and processing power.
• Improved reliability (cloud backup/DR features).
• Dynamic provisioning and scalability.
14.7. Cost Benefit Analysis (Module 260):
• Evaluates total investment vs. MCC benefits.
• Considers performance, energy conservation, quality when deciding to offload.
• Uses data on device energy, network throughput, app characteristics to decide
local vs. cloud execution for battery conservation.
• Security/privacy requirements can also drive task migration.
14.8. Security Issues (Module 261):
• Adds to general cloud security/privacy issues.
• Key areas: Mobile devices themselves (attacks, malware), Mobile network
(wireless security), Vulnerabilities in mobile cloud applications (security/privacy
bugs).
14.9. Issues and Challenges (Modules 262-268):
• Communications (Module 262):
◦ Low Bandwidth: Scarce radio resources.
◦ Availability: Signal loss, congestion, network failure affect service availability.
◦ Heterogeneity: Diverse mobile devices/wireless technologies challenge high-
availability, scalability, energy efficiency.
• Computing (Module 263):
◦ Offloading Decisions: Must be efficient; inefficient offloading can deplete
battery faster than local execution.
◦ Static Offloading: Decisions made at task start; may fail if dynamic
parameters change.
◦ Dynamic Offloading: Decisions based on runtime conditions (bandwidth,
congestion, battery).
◦ Offload only if time/battery cost is lower than local processing.
• End User Related (Module 264):
◦ Incentives: Needed for mobile devices to share resources (monetary or
common interest).
◦ Presentation Issues: Heterogeneity makes UI development difficult; limited
mobile display area.
◦ Service Availability/Performance Assurance: Signal loss, network errors,
battery depletion pose challenges.
• Data Access (Module 265):
◦ Challenges with low bandwidth, signal loss, battery life.
◦ Expensive accessing files (data cost, delays, energy).
◦ Need optimized data access patterns, use of mobile cloudlets as file caches.
◦ Interoperability: Challenge across heterogeneous devices/platforms; prefer
generic data representation.
• Miscellaneous (Modules 266-267):
◦ Performance: Optimized workload offloading is key. If using surrounding
devices, performance depends on available resources.
◦ Resource Management: Different techniques for acquiring resources from
cloud, cloudlets, or local mobile device.
◦ Processing Power: Efficiently utilize cloud's huge processing power for mobile
tasks.
◦ Battery Consumption: Offloading large code can be more energy efficient
than local processing; small code may be less efficient.
• Overall Challenges (Module 268): Mobility support while assuring connectivity
(cloudlets help but are limited). Ad-hoc mobile cloud creation depends on capable
devices/cost-benefit. Ongoing security assurance (privacy, trust). Managing
incentives for resource lenders.
14.10. MCC vs. Cloud Computing (Module 269):
• Shared: Both depend on remote usage of IT resources.
• Cloud Computing: Traditionally provides IaaS, PaaS, SaaS for single users to
enterprises. Multiple deployment models (private, public, community, hybrid).
• Mobile Cloud Computing: More focused on cloud-based applications over
mobile devices, dealing with connectivity, security, performance. Accessed by
individuals for personal computing. Can be set up over Cloud, Cloudlets, or ad-hoc
mobile devices.
--------------------------------------------------------------------------------
Section 15: Big Data Processing in Clouds
Explores the synergy between cloud computing and the challenges of managing
massive datasets.
15.1. Overview of Big Data (Module 270):
• Definition: "Enormous volume of data that cannot be processed through
traditional database technologies."
• Characteristics (3Vs): "Data volume is huge," "Data may not be categorized
into regular relational databases," "The data is generated, captured and processed
at high speed."
• Alternative Definition: "A set of techniques and technologies that require new
forms of integration to uncover large hidden values from large datasets that are
diverse, complex, and of a massive scale."
15.2. Characteristics of Big Data (4Vs) (Module 271):
• Volume: Continually rising.
• Variety: Heterogeneous data types (sensors, smartphones, social networks;
video, audio, image, text; structured, semi-structured, unstructured).
• Velocity: Speed of data transfer and constant change in content.
• Value: Analysis can generate valuable information.
15.3. Relationship between Cloud Computing and Big Data (Module 272):
• Cloud infrastructure can fulfill big data storage and processing requirements (large
fault-tolerant databases, parallel/distributed algorithms).
• Cloud storage can host Big Data, with local processing, or entirely cloud-based
applications.
• Popular Models:
◦ Distributed Map Reduce: Popularized by Hadoop.
◦ NoSQL: For non-relational, non-tabular storage (e.g., Cassandra, Hbase,
MongoDB).
 ◦ SQL RDBMS: For relational tabular storage.
• Traditional big data tools (e.g., Hadoop, NoSQL) can be deployed over cloud.
15.4. Big Data on Cloud Case Studies (Module 273):
• SwiftKey: Smart prediction for mobile keyboards; collects terabytes of data. Uses
Amazon S3 and EC2 to host Hadoop.
• Halo Game: Collects game usage data for player ranking. Uses Windows Azure
HDInsight Service (Hadoop-based).
• Nokia: Collects terabytes of data for analysis. Uses Teradata Enterprise Data
Warehouse, Oracle/MySQL data marts, visualization, and Hadoop.
15.5. Big Data Storage and Data Processing in Clouds (Module 274):
• Popular Platforms: Hadoop and Spark.
• Hadoop: Open-source, Java-based, for batch jobs. Components: Hadoop
Distributed File System (HDFS) and MapReduce.
• Spark: Compatible with Hadoop data sources, suitable for machine learning,
faster than MapReduce. Cannot execute concurrent Reduce methods like
MapReduce.
• Hadoop MapReduce is currently more popular for Big Data processing in clouds.
15.6. Challenges & Issues of Big Data processing on Cloud (Module 275):
• Scalability Assurance: For rising volume.
• Availability Assurance: Of any data within Big Data stored on cloud.
• Data Quality: Data-source verification is challenging (e.g., mobile phones).
• Heterogeneous Data Handling: Simultaneously managing diverse data is
challenging.
• Privacy Issues: Data mining can reveal sensitive/personal info. Lack of
established laws.
--------------------------------------------------------------------------------
Section 16: Multimedia Cloud Computing
Focuses on delivering multimedia content through cloud infrastructure.
16.1. Overview & Introduction (Module 276):
• Internet multimedia is an emerging service (Web 2.0).
• Cloud computing provides processing and storage for rich media content.
• Advantages: Scalable IT resources, fault-tolerant infrastructure.
• Challenges: Rendering diverse multimedia types/formats/services, maintaining
QoS across heterogeneous devices/users/content.
16.2. Architecture & Processing (Module 277):
• Multimedia Edge Cloud (MEC): Cloudlets physically close to consumers to
reduce latency.
• Multiple geographically distributed MECs connected to central servers via Content
Delivery Network (CDN).
• MECs provide multimedia services and maintain QoS.
16.3. Cloud-aware Multimedia Applications & Rendering (Module 278):
• Storage: Providers like IOmega, AllMyData.
• Sharing: Uploaded content can be shared; cloud-client link often more robust
than client-client.
• Multimedia Authoring: Services/tools for editing, merging, enhancing
multimedia on cloud.
• Rendering: Creation of images/multimedia for user devices. Cloud can perform
rendering for less capable devices to maintain QoS/minimize delay.
--------------------------------------------------------------------------------
Section 17: Emerging Network Paradigms (SDN & Fog Computing)
These sections explore advanced networking concepts that integrate closely with
cloud principles.
17.1. Introduction to SDN (Software Defined Networking) (Module 279):
• Traditional IP networks: Device-specific commands, hard to implement high-level
policies, almost no dynamic response/reconfiguration. Control plane and data plane
bundled. Reduces flexibility/innovation.
• SDN: New paradigm separating control plane from data plane.
• Switches become forwarding-only devices. Control plane handled by software
controller.
• Controller directly controls data plane devices via APIs like OpenFlow.
17.2. History of SDN (Module 280):
• Roots in 1980s-90s with Network Control Point (NCP) technology (AT&T).
• Active Networks (computational/packet modification at nodes).
• Network virtualization (hypervisor-like environment for network infrastructure).
• OpenFlow-based network OS (ONOS) for easier administration/protocol
deployment.
17.3. Network Virtualization (Module 281):
• Each computer needs at least one L2 NIC (pNIC), VMs have vNICs.
• vNICs on host interconnected by virtual switch (vSwitch) which connects to pNIC.
• Multiple pNICs connect to physical switch (pSwitch).
• Standards for NIC virtualization (e.g., IEEE 802.1BR for physical Ethernet switch
virtualization).
• VLANs can span data centers; VM migration across data centers is possible.
Modern processors allow software-based network devices.
17.4. Architecture of SDN (Module 282):
• Four Characteristics:
1. Separation of control and data planes: Switches forward based on tables
created by controller software.
2. Centralization of control plane: Controller software manages a subset of
the network.
3. Programmable control plane: Controller software controllable via API calls,
enabling rapid policy implementation.
4. Standardized APIs: Southbound API (OpenFlow) for forwarding devices;
Northbound APIs for network applications (not yet standardized).
17.5. SDN In Cloud (Module 283):
• Ongoing research; virtualization software vendors integrate SDN.
• Centralized controllers (e.g., Beacon) handle high flow rates, meeting
enterprise/data center needs.
• SDN helps monitor, filter, manage network traffic (virtual/physical) within cloud
data centers.
17.6. Future of SDN (Module 284):
• Challenges: Controller/switch design, scalability/performance, controller-service
interfacing (Northbound API), virtualization/cloud service applications (SDN-based
cloud infrastructure).
• Future directions: Information-centric networking, enabling heterogeneous
networking with SDN.
17.7. Fog Computing (Module 285):
• Emerging paradigm extending cloud computing to the "edge of the network."
• Provides data, computing, storage, application services to end-users at network
edge devices (set-top boxes, access points).
• Supports Internet of Everything (IoE) applications demanding real-time/predictable
latency and mobility.
• Candidate for beyond 5G networks, "defusing of Cloud among the client devices."
• "Huge number of heterogeneous, ubiquitous and decentralized devices
communicate and potentially cooperate... without intervention of third parties."
• Network virtualization and SDN will be essential components.
--------------------------------------------------------------------------------
Section 18: Cloud Gaming and Course Conclusion
18.1. Cloud Gaming (Module 286):
• Four Building Blocks: Input, Game logic, Networking, Rendering.
• Traditional: Internet gaming servers exchange info, other modules on user
devices.
• Cloud Hosted: I/O module on user device, rest on cloud.
• Benefits: Easy deployment, reduced player cost/time, flexible business models
(pre-pay, post-pay, pay-per-play).
18.2. Conclusion & End of Course (Modules 287-287.5):
• Cloud computing is an ongoing, ubiquitous phenomenon requiring periodic
updates.
• This course provides an "in-depth study" of cloud computing, its building blocks,
deployment/service models, mechanisms, architectures, management, security,
privacy, and trust issues.
• It covers open issues, disaster recovery, NIST recommendations, migration
strategies, design principles, scalability, and resource scheduling.
• Introduces specialized topics like Mobile Cloud Computing, Big Data, Multimedia
Cloud, SDN, and Fog Computing.
• Aims to be a foundation for advanced courses and a source of knowledge.