Unit 2: Cloud Computing and Cloud Migration - Subjective Questions

Cloud computing is a model that provides convenient, on-demand network access to a shared pool of configurable computing resources, such as servers, storage, networks, applications, and services. These resources can be rapidly provisioned and released with minimal management effort.

The five essential NIST characteristics are:

• On-demand self-service: Consumers can provision resources automatically without requiring direct interaction with the service provider.
• Broad network access: Services are available over a network and can be accessed using devices such as laptops, smartphones, and tablets.
• Resource pooling: Computing resources are pooled to serve multiple consumers using a multi-tenant model.
• Rapid elasticity: Resources can be scaled up or down quickly according to demand.
• Measured service: Resource usage is monitored, controlled, and reported, enabling metered or pay-per-use billing.

The principal cloud deployment models are:

• Public cloud: Infrastructure is owned and operated by a third-party provider and shared among many customers. Examples include Amazon Web Services, Microsoft Azure, and Google Cloud.
• Private cloud: Infrastructure is dedicated to one organization. It may be hosted on the organization's premises or managed by an external provider. It offers greater control, customization, and security.
• Community cloud: Infrastructure is shared by organizations with common security, regulatory, or operational requirements. For example, several government departments may share a government-focused cloud.
• Hybrid cloud: Two or more distinct clouds are connected to support data and application portability. For example, sensitive records may remain in a private cloud while a public cloud handles temporary workload peaks.

The appropriate model depends on cost, control, security, compliance, scalability, and integration requirements.

The three principal cloud service models differ in the level of control retained by the customer:

• Infrastructure as a Service (IaaS): Provides virtual machines, storage, and networking. The customer manages the operating system, middleware, applications, and data. Examples include Amazon EC2 and Azure Virtual Machines.
• Platform as a Service (PaaS): Provides a managed application platform, including the operating system, runtime, middleware, and development tools. The customer primarily manages applications and data. Examples include Google App Engine and Azure App Service.
• Software as a Service (SaaS): Provides complete applications through a browser or client interface. The provider manages the entire technology stack. Examples include Salesforce and Microsoft 365.

Comparison: IaaS offers the greatest customer control but requires more administration. PaaS simplifies development and deployment, while SaaS offers ready-to-use software with the least infrastructure control.

The NIST cloud computing model organizes cloud computing into characteristics, service models, deployment models, and actors.

Service models:

• IaaS: Virtualized processing, storage, and networking resources.
• PaaS: Managed platforms for developing and deploying applications.
• SaaS: Complete applications delivered as services.

Deployment models:

• Public cloud
• Private cloud
• Community cloud
• Hybrid cloud

Major actors:

• Cloud consumer: Uses cloud services.
• Cloud provider: Makes cloud services available and manages the infrastructure.
• Cloud broker: Negotiates, aggregates, or manages services from multiple providers.
• Cloud auditor: Independently assesses security, performance, privacy, and compliance.
• Cloud carrier: Provides network connectivity between consumers and providers.

Together, these components establish a standard vocabulary and framework for designing, comparing, and governing cloud environments.

Scalability is the ability of a system to increase or decrease its overall capacity to accommodate a long-term change in workload. It may be:

• Vertical scaling: Adding more CPU, memory, or storage to an existing machine.
• Horizontal scaling: Adding more machines or service instances.

Elasticity is the ability to provision and release resources rapidly, often automatically, in response to short-term workload changes.

For example, permanently adding servers to support organizational growth is scalability, while automatically adding instances during a sales event and removing them afterward is elasticity.

Both are important because scalability supports sustained growth, whereas elasticity prevents over-provisioning and reduces cost during fluctuating demand.

The Cloud Cube Model, proposed by the Jericho Forum, evaluates cloud formations using four dimensions:

• Internal or External: Indicates whether cloud resources are located within or outside the organization's security boundary.
• Proprietary or Open: Describes whether the cloud uses provider-specific technologies or open standards that improve portability.
• Perimeterised or De-perimeterised: Indicates whether security depends mainly on a traditional network boundary or follows data and identities beyond that boundary.
• Insourced or Outsourced: Identifies whether cloud services are operated by the organization or by an external provider.

An organization can place a proposed cloud environment within this multidimensional cube to assess control, ownership, security, portability, and management responsibility. For example, an external, proprietary, outsourced cloud may be easy to adopt but can create vendor lock-in, whereas an internal, open, insourced cloud provides more control but requires greater investment and operational expertise.

The Seven-Step Migration Model provides a systematic approach for moving an application to a cloud environment:

1. Conduct cloud migration assessment: Study business goals, costs, risks, security, compliance, and cloud suitability.
2. Isolate dependencies: Identify application, data, operating system, middleware, network, and external-service dependencies.
3. Map components to cloud services: Determine which components can use IaaS, PaaS, SaaS, storage, database, or messaging services.
4. Re-architect and implement changes: Modify tightly coupled, stateful, or hardware-dependent components when necessary.
5. Leverage cloud characteristics: Introduce elasticity, automation, resource pooling, monitoring, and measured usage.
6. Test the migrated application: Verify functionality, performance, security, integration, resilience, and data correctness.
7. Iterate and optimize: Monitor production behavior, correct problems, control cost, and progressively migrate remaining components.

The process is iterative because discoveries during testing or operation may require earlier architectural decisions to be revisited.

A cloud migration assessment should evaluate the following factors:

• Business value: Expected benefits, total cost of ownership, return on investment, and migration urgency.
• Application suitability: Architecture, age, workload variability, performance needs, and dependence on specialized hardware.
• Technical dependencies: Databases, middleware, identity systems, networks, external APIs, and other applications.
• Data requirements: Volume, sensitivity, location, consistency, retention, and transfer time.
• Security and compliance: Access controls, encryption, auditing, privacy, and data-residency obligations.
• Availability requirements: Recovery objectives, service-level agreements, backup, and disaster recovery.
• Organizational readiness: Skills, operating procedures, governance, and support capabilities.
• Provider risks: Vendor lock-in, service limits, pricing changes, portability, and exit strategy.

The outcome should be a migration priority, target architecture, risk register, cost estimate, and migration plan.

Common cloud migration strategies include:

• Rehosting: Moving an application with minimal modification, often called lift and shift. It is fast but may not exploit cloud-native capabilities.
• Replatforming: Making limited changes, such as replacing a self-managed database with a managed database, without redesigning the complete application.
• Refactoring: Redesigning the application to use cloud-native services, automation, and elastic architectures. It provides long-term benefits but requires more time and risk.
• Repurchasing: Replacing an existing application with a SaaS product.
• Retaining: Keeping an application in its current environment because migration is currently unsuitable or unnecessary.
• Retiring: Decommissioning applications that no longer provide sufficient value.
• Relocating: Moving an entire virtualized environment to compatible cloud infrastructure with few application-level changes.

Selection depends on business value, technical complexity, migration deadlines, cost, compliance, and the expected lifetime of the application.

Virtual machine migration is the transfer of a virtual machine's execution environment, including its state, memory, storage, and configuration, from one physical host to another.

• Cold migration: The virtual machine is powered off or suspended before migration. Its storage and configuration are transferred while it is inactive. This approach is simpler and provides a consistent state, but it causes noticeable downtime.
• Live migration: The virtual machine continues running while most of its state is transferred. Only a short pause is required for final synchronization and switching execution to the destination host.

Cold migration is suitable for planned maintenance where downtime is acceptable. Live migration is preferred for load balancing, hardware maintenance, and service continuity, although it requires compatible hosts, sufficient bandwidth, and careful state synchronization.

Pre-copy migration transfers memory pages while the virtual machine continues running on the source host. Pages modified during transfer are marked dirty and copied again in later rounds. The VM is briefly stopped when the remaining dirty pages and processor state are transferred.

• Advantages: The source retains an up-to-date VM state until switchover, making recovery easier if migration fails.
• Limitations: Frequently modified pages may be transmitted repeatedly, increasing migration time and network traffic.

Post-copy migration briefly stops the VM, transfers essential processor state to the destination, and resumes execution there. Missing memory pages are fetched from the source on demand while remaining pages are transferred in the background.

• Advantages: Each page is generally transferred once, avoiding repeated copying.
• Limitations: Page faults can reduce performance, and failure after switchover is harder to recover from because the VM state is distributed across both hosts.

Pre-copy is widely used because of its lower failure risk, while post-copy can be beneficial for workloads with high memory-write rates.

Major challenges in live VM migration include:

• High memory size and rapid page modification
• Limited network bandwidth and high latency
• Migration of local storage and attached devices
• Compatibility between source and destination processors or hypervisors
• Preservation of active network connections
• Security of VM state while it is being transferred
• Failure handling during migration

Important performance measures are:

• Total migration time: Time from initiation until migration completes.
• Downtime: Period during which the VM cannot serve requests.
• Transferred data: Total volume sent, including retransmitted dirty pages.
• Application degradation: Reduction in throughput or increase in response time during migration.
• Energy and resource overhead: CPU, memory, network, and power consumed by the migration.

An effective migration mechanism minimizes downtime and application degradation without generating excessive traffic or increasing failure risk.

Cloud middleware is a software layer that connects applications, operating environments, data sources, and cloud services. It hides distribution and platform differences and provides common services to application components.

Its major functions include:

• Communication: Provides messaging, remote calls, event delivery, and service invocation.
• Integration: Connects applications, databases, APIs, and services across public and private environments.
• Resource management: Supports resource discovery, scheduling, provisioning, and load balancing.
• Data management: Handles data access, caching, synchronization, and transformation.
• Security: Provides authentication, authorization, encryption, and policy enforcement.
• Reliability: Supports transactions, retries, fault handling, and message durability.
• Monitoring: Collects metrics, logs, traces, and usage information.
• Portability: Reduces direct dependence on provider-specific interfaces through common abstractions.

Examples include message brokers, API gateways, integration platforms, service meshes, and distributed application runtimes.

Cloud middleware integrates distributed and heterogeneous applications by providing a common communication and management layer.

• Protocol mediation: Converts between protocols such as HTTP, messaging protocols, and provider-specific interfaces.
• Data transformation: Maps different schemas, encodings, and message formats.
• Service discovery: Allows components to locate available service instances dynamically.
• Asynchronous messaging: Decouples producers and consumers through queues or publish-subscribe systems.
• API management: Exposes standardized interfaces and applies access control, throttling, and versioning.
• Transaction coordination: Maintains consistency across multi-step distributed operations using suitable transaction or compensation patterns.
• Security federation: Connects different identity systems through tokens and federated authentication.
• Observability: Correlates logs, metrics, and traces across multiple services.

These capabilities allow independently developed components to communicate without requiring each component to implement every integration concern.

A cloud data migration process commonly includes:

1. Discovery and profiling: Identify data sources, volume, quality, sensitivity, ownership, and dependencies.
2. Target design: Select cloud storage or database services and define schemas, partitions, encryption, and access controls.
3. Mapping and transformation: Map source fields to target fields and define cleansing or format conversions.
4. Initial transfer: Move the bulk dataset using online transfer or physical transfer appliances.
5. Incremental synchronization: Capture and apply changes generated after the bulk copy.
6. Validation: Compare record counts, checksums, constraints, samples, and business totals.
7. Cutover: Pause or redirect writes, apply final changes, and switch applications to the target.
8. Monitoring and decommissioning: Observe the target, retain rollback capability, and retire the source after approval.

Integrity controls include encryption, checksums, transaction logs, reconciliation reports, access auditing, backups, repeatable migration scripts, and a tested rollback plan.

Bulk data migration transfers a large, finite dataset in batches. It is commonly used for initial database loading, archival migration, backup movement, and one-time system replacement.

• It can use high-throughput parallel transfer or physical storage appliances.
• It is easier to validate as a bounded dataset.
• It may require a maintenance window if the source continues to change.

Streaming data migration continuously transfers records or change events as they are generated. Technologies such as change data capture, message brokers, and event streams are commonly used.

• It supports low-downtime migration and continuous replication.
• It is suitable for sensor data, transaction events, logs, and systems that cannot stop accepting updates.
• It must address event ordering, duplicate delivery, late events, backpressure, and checkpoint recovery.

A common migration combines both: a bulk transfer creates the baseline, and a stream carries subsequent changes until cutover.

Streaming migration introduces several challenges:

• High and variable arrival rates: Sudden traffic increases can overload consumers.
• Network latency or interruption: Events may arrive late or transmission may temporarily fail.
• Ordering: Parallel processing can change the order of related events.
• Duplicate delivery: Retries can cause an event to be processed more than once.
• Data loss: Failures can occur before an event is durably stored.
• Schema evolution: Event formats may change while producers and consumers are active.
• Security and privacy: Data must be protected during transmission and storage.

Suitable solutions include durable message brokers, partitioning, buffering, backpressure, checkpointing, replayable logs, idempotent consumers, unique event identifiers, schema registries, encryption, and monitoring of consumer lag. Exactly-once outcomes may be approximated through transactional writes or achieved at the application level using idempotency and deduplication.

Cloud interoperability is the ability of applications, services, and platforms in different cloud environments to communicate, exchange data, and use the exchanged information correctly.

Cloud portability is the ability to move an application, workload, or dataset from one cloud environment to another with limited modification.

The distinction is:

• Interoperability focuses on cooperation between systems that may remain in different environments.
• Portability focuses on movement between environments.

For example, an application in one cloud invoking an identity or analytics service in another cloud demonstrates interoperability. Moving the complete application and its data to the second provider demonstrates portability.

Both depend on standard APIs, portable data formats, compatible identity mechanisms, documented interfaces, automation, and reduced dependence on proprietary services.

Major barriers to cloud interoperability include:

• Proprietary APIs: Providers expose different interfaces and service behavior.
• Incompatible data formats: Schemas, metadata, and storage representations may differ.
• Different identity systems: Authentication tokens, roles, and access policies may not map directly.
• Network differences: Addressing, routing, firewalls, and service discovery vary between environments.
• Semantic differences: Services with similar names may provide different guarantees.
• Operational differences: Monitoring, deployment, billing, and service-level agreements are provider-specific.
• Regulatory restrictions: Data location and privacy rules may limit cross-cloud exchange.

Methods for improving interoperability include open standards, RESTful APIs, standard data formats, containers, infrastructure as code, API gateways, federated identity, middleware adapters, portable messaging protocols, and abstraction layers. Organizations should also maintain data export procedures, test cross-cloud recovery, document dependencies, and define a practical provider exit strategy.

A suitable migration approach would include the following steps:

1. Assess the application: Identify business goals, workload patterns, dependencies, sensitive data, compliance obligations, and recovery requirements.
2. Choose component placement: Keep highly sensitive or latency-dependent components in the private environment and place elastic web or processing tiers in the public cloud.
3. Create portable architecture: Use containers, standard APIs, open data formats, externalized configuration, and infrastructure as code. Isolate provider-specific services behind well-defined interfaces.
4. Establish connectivity: Configure encrypted private links or VPNs, network segmentation, DNS, identity federation, and unified access policies.
5. Migrate data: Perform a bulk initial copy, validate it with checksums and business totals, and then use change data capture for continuous synchronization.
6. Migrate and test applications: Rehost or replatform low-risk components first. Test functionality, performance, security, resilience, and interoperability.
7. Perform controlled cutover: Reduce DNS lifetime, synchronize final changes, redirect traffic gradually, and retain a rollback path.
8. Optimize operations: Implement monitoring, autoscaling, cost controls, backup, disaster recovery, and periodic portability tests.

This phased approach minimizes downtime through continuous synchronization and gradual traffic shifting, while open interfaces and portable deployment definitions reduce vendor lock-in.