Unit 2: Cloud Computing and Cloud Migration

I. Cloud Computing Foundations

Cloud computing is a model for delivering configurable computing resources over a network as services. It replaces or supplements locally owned infrastructure with resources that can be provisioned rapidly, shared efficiently, measured automatically, and released when no longer required.

• Governing principle: Computing capacity is consumed according to demand rather than permanently installed for a fixed workload.
• Resource abstraction: Virtualization, containers, software-defined networking, and APIs separate services from specific physical hardware.
• Provider-consumer relationship: A cloud service provider operates resources; a cloud consumer requests and uses them under a service-level agreement (SLA).
• Elastic operation: Capacity can expand during demand peaks and contract afterward, improving utilization and cost control.
• Shared responsibility: Security and management duties are divided between provider and consumer, with the division depending on the service model.
• Migration objective: Cloud migration moves applications, data, or infrastructure to a cloud environment to gain scalability, resilience, agility, or economic benefit.
• Core measures:
  • Availability: Percentage of time a service remains operational, such as 99.9%.
  • Latency: Time taken for a request or data unit to travel and receive a response, commonly measured in milliseconds.
  • Throughput: Work or data processed per unit time, such as transactions per second or gigabits per second.
  • Recovery objectives: RTO specifies acceptable recovery time; RPO specifies acceptable data-loss duration.

II. Deployment Models — Location, Ownership, and Access

A. Deployment models

Deployment models classify clouds according to ownership, access, location, and administrative control.

• Public cloud: Infrastructure is operated by a provider and offered to multiple customers over a network; examples include Amazon Web Services, Microsoft Azure, and Google Cloud.
  • Strength: Rapid provisioning without purchasing physical servers.
  • Constraint: Consumers have less control over hardware location and provider-specific operations.
• Private cloud: Cloud infrastructure is dedicated to one organization and may operate on-premises or through a hosting provider.
  • Strength: Greater control over security policies, customization, and regulated data.
  • Constraint: The organization carries higher acquisition, staffing, and maintenance costs.
• Community cloud: Infrastructure is shared by organizations with common requirements, such as government departments or healthcare institutions.
  • Anchor: Members may share compliance controls for a regulation or sector-specific security policy.
• Hybrid cloud: Two or more distinct cloud infrastructures are connected to support data and application portability.
  • Example: A retailer runs ordinary workloads in a private cloud but temporarily uses public-cloud servers during a seasonal demand peak.
• Selection criteria: Data sensitivity, compliance, expected demand, latency, cost, existing systems, and required administrative control determine the suitable model.

III. Service Models — Division of Management Responsibility

A. Service models

Service models define which parts of the computing stack are managed by the provider and which remain the consumer’s responsibility.

1. Infrastructure as a Service (IaaS):
   • Provider responsibility: Physical servers, storage, networking, and the virtualization layer.
   • Consumer responsibility: Operating systems, middleware, applications, configurations, and data.
   • Example: A virtual machine created through Amazon EC2 or Azure Virtual Machines.
2. Platform as a Service (PaaS):
   • Provider responsibility: Infrastructure plus operating system, runtime, scaling facilities, and platform middleware.
   • Consumer responsibility: Application code, application settings, and data.
   • Example: Deploying source code to Google App Engine without managing the underlying operating system.
3. Software as a Service (SaaS):
   • Provider responsibility: The complete application stack and its operation.
   • Consumer responsibility: User access, permitted configuration, and organizational use of data.
   • Example: Microsoft 365 delivered through a browser or client application.
   • Serverless/FaaS extension: Functions execute in response to events, and billing commonly reflects invocations and execution duration; AWS Lambda is an example.
   • Responsibility trend: Moving from IaaS to SaaS reduces consumer administration but also reduces low-level control and portability.

IV. Cloud Characteristics — Operational Properties

A. Cloud characteristics

Cloud characteristics distinguish cloud services from ordinary remote hosting or conventional data-centre outsourcing.

• Demand-driven provisioning: Consumers obtain computing resources without waiting for manual hardware installation.
• Network accessibility: Services are available through standard network mechanisms to clients such as browsers, mobile devices, and workstations.
• Shared capacity: Providers dynamically assign pooled processors, storage, memory, and bandwidth among multiple tenants.
• Elastic scaling: Resources can be added or removed automatically in response to measurements such as CPU utilization or queue length.
• Measured consumption: Metering records usage, including virtual CPU-hours, storage gigabytes, requests, or outbound data transfer.
• Resilience: Redundant instances, availability zones, replication, and automated recovery reduce the effect of component failure.
• Automation through APIs: Infrastructure-as-code tools can repeatedly create networks, machines, and policies from version-controlled definitions.
• Important limitation: Elastic capacity does not guarantee efficient software; a poorly designed database or serial process can remain a bottleneck after scaling.

V. NIST Model — Standard Cloud Definition

A. NIST model

The NIST cloud model, published by the United States National Institute of Standards and Technology in Special Publication 800-145 (2011), organizes cloud computing into characteristics, service models, and deployment models.

• Five essential characteristics: On-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.
• Three service models: SaaS, PaaS, and IaaS identify increasing levels of consumer control from complete software service to configurable infrastructure.
• Four deployment models: Private, community, public, and hybrid cloud describe ownership and access arrangements.
• Actor perspective: Related NIST architecture work identifies roles such as cloud consumer, provider, broker, auditor, and carrier.
• Practical value: The model supplies a common vocabulary for procurement documents, architectural comparisons, security assessments, and SLAs.
• Boundary of the model: NIST classifies cloud arrangements but does not prescribe one vendor, migration method, pricing scheme, or technical implementation.

VI. Cloud Cube Model — Multidimensional Placement

A. Cloud cube model

The Jericho Forum’s Cloud Cube Model evaluates cloud arrangements across four dimensions instead of placing them into only one deployment category.

• Internal versus External: Indicates whether data and processing remain within the organization’s physical boundary or occur outside it.
• Proprietary versus Open: Distinguishes technology tied to vendor-specific mechanisms from systems using open standards that support portability.
• Perimeterised versus De-perimeterised: Contrasts conventional boundary-based protection with security based on identities, encryption, data, and distributed policy enforcement.
• Insourced versus Outsourced: Identifies whether the cloud service is operated by the organization’s own personnel or by an external provider.
• Analytical use: A service may be external, proprietary, de-perimeterised, and outsourced simultaneously; this description exposes risks hidden by the broad label “public cloud.”
• Decision value: Plotting a proposed system across all four dimensions helps assess governance, supplier dependence, security architecture, and data location.

VII. The Seven-Step Migration Model — Controlled Cloud Transition

A. The Seven-Step Migration model

The Seven-Step Migration Model treats migration as an iterative assessment, redesign, transfer, and optimization process rather than a simple relocation of software.

1. Conduct cloud migration assessments: Inventory applications, calculate costs, classify data, evaluate compliance, and establish performance baselines.
2. Isolate dependencies: Identify connections to databases, identity systems, files, devices, libraries, and other applications.
3. Map dependencies to cloud services: Match existing components and messages to suitable compute, storage, database, networking, and integration services.
4. Re-architect where necessary: Modify tightly coupled or stateful components when direct relocation would prevent scalability or resilience.
5. Leverage cloud capabilities: Introduce managed databases, autoscaling, monitoring, queues, caching, or object storage where they provide clear benefit.
6. Test the migration: Validate correctness, security, performance, failover, data integrity, and rollback procedures in the target environment.
7. Iterate and optimize: Monitor actual behavior, right-size resources, remove bottlenecks, control cost, and repeat improvements.
   • Migration strategies: Common choices include rehost, replatform, refactor, repurchase, retain, retire, and relocate; selection occurs during assessment rather than being assumed in advance.

VIII. Virtual Machine Migration — Moving Execution State

A. Virtual machine migration

Virtual machine migration transfers a VM’s disk, configuration, memory state, or execution from one physical host or environment to another.

1. Cold migration:
   • Method: Shut down the VM, transfer its virtual disks and configuration, then restart it at the destination.
   • Trade-off: Implementation is straightforward and consistent, but downtime lasts for the transfer and restart.
2. Live migration:
   • Pre-copy: Memory pages are copied while the VM runs; repeatedly modified pages are resent before a brief final switchover.
   • Post-copy: Execution begins at the destination after minimal state transfer; missing pages are fetched from the source on demand.
   • Trade-off: Pre-copy may resend frequently modified pages, whereas post-copy risks greater disruption if either host fails mid-migration.
   • Requirements: Compatible hypervisors, adequate bandwidth, accessible storage, network continuity, processor compatibility, and synchronized security policies.
   • Uses: Hardware maintenance, load balancing, energy consolidation, disaster recovery, and movement between data centres.
   • Cloud constraint: Different virtual disk formats, network models, machine types, and provider services can prevent direct cross-cloud migration.

IX. Cloud Middleware — Integration and Coordination Layer

A. Cloud middleware

Cloud middleware sits between applications and underlying platforms to provide communication, integration, coordination, security, and resource-management services.

• Communication services: Message brokers, publish-subscribe systems, API gateways, and service buses connect distributed components; Apache Kafka and RabbitMQ are representative technologies.
• Abstraction: Middleware exposes stable interfaces while hiding differences in operating systems, protocols, databases, or provider APIs.
• Service coordination: Discovery, routing, retries, load balancing, workflow execution, and transaction handling support distributed applications.
• Security functions: Identity federation, token validation, authorization, encryption, and audit logging enforce access across services.
• Cloud management: Orchestration platforms schedule workloads, maintain desired state, and recover failed components; Kubernetes performs these tasks for containers.
• Design risk: Excessive middleware layers add latency and operational complexity, while proprietary interfaces can create vendor lock-in.

X. Data Migration and Streaming — Moving Stored and Continuous Data

A. Data migration and streaming

Data migration transfers existing datasets, while streaming continuously processes or replicates events generated during and after migration.

1. Bulk data migration:
   • Process: Extract data, transform schemas or formats, load the target, and verify counts, checksums, constraints, and sample records.
   • Transfer choice: Networks suit moderate datasets; encrypted physical transfer appliances may suit petabyte-scale moves.
2. Continuous streaming:
   • Process: Capture database changes or application events and send them through ordered logs, queues, or stream-processing platforms.
   • Anchor: Change data capture can replicate inserts, updates, and deletes while the source system remains operational.
   • Cutover method: Perform an initial bulk copy, stream subsequent changes, measure replication lag, briefly pause writes, synchronize the remainder, and redirect applications.
   • Integrity controls: Encryption, checksums, access control, schema validation, duplicate handling, ordering rules, and audit trails protect data.
   • Key risks: Bandwidth limits, incompatible schemas, data residency rules, transfer charges, downtime, stale records, and loss or duplication of events.

XI. Interoperability — Cooperation Across Cloud Boundaries

A. Interoperability

Interoperability is the ability of applications, data, identities, and management systems to work across different clouds or between cloud and on-premises environments.

• Technical interoperability: Standard protocols such as HTTP, TLS, DNS, and REST enable systems to exchange requests across heterogeneous platforms.
• Data interoperability: Portable formats such as JSON, CSV, and Parquet reduce dependence on proprietary encodings, though shared semantics remain necessary.
• Workload portability: OCI container images and Kubernetes specifications can simplify deployment across environments, but storage, networking, and managed services still differ.
• Virtual machine exchange: The Open Virtualization Format packages virtual appliances, although providers may require conversion or omit unsupported virtual hardware.
• Identity federation: SAML and OpenID Connect allow users to authenticate through a trusted identity provider across organizational or cloud boundaries.
• Management interoperability: Infrastructure-as-code and cross-cloud monitoring offer consistent workflows, but provider APIs rarely expose identical capabilities.
• Obstacles: Proprietary APIs, different IAM models, egress fees, incompatible SLAs, data regulations, and service-specific architectures create lock-in.
• Practical approach: Use explicit interfaces, portable data models, automated deployment definitions, tested export procedures, and contractual exit provisions where migration is a genuine requirement.