Hybrid Cloud

Overview

Hybrid cloud architecture combines on-premises infrastructure with public cloud services to create a unified computing environment. Organizations maintain some workloads in private data centers while extending others to cloud platforms like AWS, Google Cloud, or Azure. This architectural pattern addresses requirements that neither pure on-premises nor pure cloud solutions satisfy independently.

The hybrid model emerged from practical constraints: regulatory compliance requiring data residency, existing capital investments in hardware, latency-sensitive applications needing proximity to users, and gradual cloud migration strategies. Rather than forcing an all-or-nothing decision, hybrid cloud treats infrastructure as a continuum where workloads run in their optimal location.

A hybrid cloud system requires three core components: on-premises infrastructure, one or more public cloud platforms, and connectivity layer between them. The connectivity layer handles network routing, identity federation, data synchronization, and workload orchestration across boundaries. Applications must handle distributed deployment, often with components split between locations.

# Configuration for hybrid cloud deployment
class HybridCloudConfig
  attr_reader :on_prem_endpoint, :cloud_endpoint, :vpn_gateway
  
  def initialize
    @on_prem_endpoint = ENV['ON_PREM_API_URL']
    @cloud_endpoint = ENV['CLOUD_API_URL']
    @vpn_gateway = ENV['VPN_GATEWAY_IP']
  end
  
  def route_request(data_classification)
    case data_classification
    when :pii, :regulated
      on_prem_endpoint
    when :public, :analytics
      cloud_endpoint
    else
      determine_optimal_endpoint
    end
  end
  
  private
  
  def determine_optimal_endpoint
    # Route based on current load and availability
    on_prem_healthy? ? on_prem_endpoint : cloud_endpoint
  end
end

Hybrid cloud differs from multi-cloud, where organizations use multiple cloud providers but may not integrate with on-premises systems. The defining characteristic is the bridge between traditional infrastructure and cloud platforms, not simply using multiple cloud vendors.

Key Principles

Hybrid cloud architecture operates on several fundamental principles that govern design and implementation decisions.

Workload Portability enables applications to move between on-premises and cloud environments without modification. Containerization with Docker or Kubernetes provides the primary mechanism for portability, abstracting application dependencies from underlying infrastructure. Applications packaged as containers run identically regardless of location, though performance characteristics may differ.

Data Gravity recognizes that data location influences processing location. Large datasets resist movement due to transfer costs and time. Hybrid architectures place compute resources near data rather than moving massive datasets across network boundaries. A machine learning model might train in the cloud but serve predictions on-premises where the source data resides.

Identity Federation unifies authentication and authorization across boundaries. Users authenticate once and access resources in both locations through federated identity protocols like SAML or OAuth. Directory services synchronize between Active Directory on-premises and cloud identity platforms, maintaining consistent access controls.

Network Connectivity forms the physical foundation. VPN tunnels, dedicated circuits like AWS Direct Connect or Azure ExpressRoute, and SD-WAN solutions provide private, low-latency connections between locations. The network must handle production traffic volumes while maintaining security isolation from public internet.

Orchestration and Management treats distributed infrastructure as a single logical system. Tools like Terraform, Ansible, or cloud-native services provision and configure resources across locations from centralized definitions. Monitoring aggregates metrics from all sources into unified dashboards. Log aggregation collects events from distributed systems for correlation and analysis.

Data Consistency and Synchronization addresses the distributed data challenge. Hybrid applications must handle eventual consistency, replication lag, and conflict resolution when data exists in multiple locations. Some data requires real-time synchronization while other data tolerates delay.

# Data synchronization service for hybrid deployment
class DataSyncService
  def initialize(local_db:, cloud_db:)
    @local_db = local_db
    @cloud_db = cloud_db
    @sync_queue = Queue.new
  end
  
  def sync_record(record, priority: :normal)
    case priority
    when :immediate
      sync_now(record)
    when :normal
      @sync_queue.push(record)
    when :batch
      schedule_batch_sync(record)
    end
  end
  
  private
  
  def sync_now(record)
    # Synchronous replication to cloud
    begin
      @cloud_db.transaction do
        @cloud_db.upsert(record)
        record.update(cloud_synced_at: Time.now)
      end
    rescue CloudConnectionError => e
      # Queue for retry if immediate sync fails
      @sync_queue.push(record)
      raise unless e.retriable?
    end
  end
  
  def schedule_batch_sync(record)
    # Add to batch queue processed every N minutes
    BatchSyncJob.perform_later(record.id)
  end
end

Security Boundaries define trust zones and control data flow between them. On-premises infrastructure typically operates in a trusted zone with physical security. Cloud resources operate in a different trust zone with different security controls. Applications crossing boundaries must authenticate, encrypt in transit, and validate at each boundary crossing.

Cost Optimization balances capital expenditure on owned hardware against operational expenditure for cloud resources. Hybrid models allow organizations to maximize existing hardware investments while adding cloud capacity for variable workloads. Cost-effective hybrid architecture matches workload characteristics to deployment location economics.

Implementation Approaches

Several architectural patterns exist for implementing hybrid cloud systems, each suited to different requirements and constraints.

Network Extension Pattern treats cloud resources as an extension of the on-premises network. A VPN or dedicated connection creates a private network spanning both locations. Resources in the cloud receive private IP addresses from the on-premises network range. This approach minimizes application changes since network topology appears continuous.

The network extension pattern works well for lift-and-shift migrations where applications assume a flat network. However, it couples cloud resources to on-premises network design and may create routing complexity. Latency between locations affects distributed applications. Security boundaries become less clear when network boundaries span physical locations.

API Gateway Pattern exposes on-premises services through API gateways that cloud applications consume. The gateway handles authentication, rate limiting, protocol translation, and routing. Cloud applications call APIs without direct network access to on-premises systems. This creates clear service boundaries and better security isolation.

# API gateway for hybrid cloud service access
class HybridApiGateway
  def initialize
    @on_prem_services = ServiceRegistry.on_prem
    @cloud_services = ServiceRegistry.cloud
    @circuit_breaker = CircuitBreaker.new
  end
  
  def route_request(service_name, request)
    service = resolve_service(service_name)
    
    @circuit_breaker.call(service) do
      if service.location == :on_prem
        route_to_on_prem(service, request)
      else
        route_to_cloud(service, request)
      end
    end
  rescue CircuitBreaker::OpenError
    # Fallback to replica in alternate location
    fallback_service = find_fallback(service_name)
    route_request(fallback_service.name, request)
  end
  
  private
  
  def route_to_on_prem(service, request)
    # Add authentication headers
    request.headers['X-API-Key'] = ENV['ON_PREM_API_KEY']
    
    # Call through VPN tunnel
    response = HTTP.via(@vpn_proxy).post(service.endpoint, json: request.body)
    transform_response(response)
  end
  
  def resolve_service(service_name)
    # Check cloud registry first for performance
    @cloud_services[service_name] || @on_prem_services[service_name]
  end
end

Data Replication Pattern maintains copies of data in both locations with synchronization mechanisms. Write operations may go to one location and replicate to the other, or use multi-master replication with conflict resolution. Applications read from the local copy for performance while background processes handle synchronization.

This pattern suits read-heavy workloads where read performance matters more than write consistency. Data locality improves read performance but introduces consistency challenges. Replication lag means different locations may temporarily see different data states.

Distributed Application Pattern designs applications specifically for hybrid deployment with components distributed across locations. A user interface might run in the cloud for global access while business logic runs on-premises for data governance. Message queues or event streams coordinate between components.

This pattern provides the most flexibility but requires applications designed for distributed deployment. Network partitions, latency, and partial failures become normal operating conditions that applications must handle. Service mesh technologies like Istio provide infrastructure for distributed application communication.

Cloud Bursting Pattern runs applications on-premises normally but overflows to cloud during peak demand. When on-premises capacity reaches limits, additional workload instances launch in the cloud. This maximizes existing infrastructure utilization while providing unlimited burst capacity.

Cloud bursting requires applications that scale horizontally and tolerate running instances in different locations. Load balancers distribute traffic across locations. Auto-scaling policies trigger cloud bursting based on metrics like CPU usage or request queue depth.

# Cloud bursting controller
class CloudBurstController
  def initialize(on_prem_cluster:, cloud_cluster:, thresholds:)
    @on_prem = on_prem_cluster
    @cloud = cloud_cluster
    @thresholds = thresholds
    @burst_active = false
  end
  
  def check_and_scale
    current_load = @on_prem.current_cpu_percent
    
    if should_burst?(current_load) && !@burst_active
      activate_cloud_burst
    elsif should_scale_down?(current_load) && @burst_active
      deactivate_cloud_burst
    end
  end
  
  private
  
  def should_burst?(load)
    load > @thresholds[:burst_trigger] &&
      @on_prem.instances_count >= @on_prem.max_instances
  end
  
  def activate_cloud_burst
    # Launch instances in cloud
    required_instances = calculate_burst_instances
    
    @cloud.scale_up(required_instances)
    update_load_balancer_pool
    @burst_active = true
    
    CloudBurstEvent.log(
      event: :activated,
      instances: required_instances,
      trigger_load: @on_prem.current_cpu_percent
    )
  end
  
  def deactivate_cloud_burst
    # Gracefully drain cloud instances
    @cloud.instances.each do |instance|
      instance.drain_connections
    end
    
    sleep(30) # Allow connection draining
    @cloud.scale_down(0)
    @burst_active = false
  end
end

Edge Computing Pattern places compute resources at network edge locations, often combined with cloud backends for control and analytics. Edge nodes process data locally for low latency while sending aggregated results to cloud storage. This pattern suits IoT deployments and content delivery.

Design Considerations

Selecting hybrid cloud architecture requires evaluating several factors beyond technical capabilities.

Regulatory and Compliance Requirements often drive hybrid cloud adoption. Financial services must keep certain data in specific jurisdictions. Healthcare providers must comply with data residency rules. Government agencies face sovereignty requirements. Hybrid cloud allows regulated data to remain on-premises while other workloads use cloud resources.

Compliance affects architecture decisions. Applications processing regulated data must run entirely on-premises or use cloud regions with appropriate certifications. Data classification becomes critical - systems must route requests based on data sensitivity. Audit logging must track all access to regulated data regardless of location.

Latency Sensitivity determines workload placement. Interactive applications requiring sub-100ms response times may need proximity to users. Database queries expecting local-network latency fail when distributed across WAN links. Real-time processing cannot tolerate variable network latency.

Measure actual latency requirements rather than assumptions. Some applications tolerate higher latency than expected. Profile network latency between locations under various conditions. Consider latency variability, not just average latency. Peak latency matters more than average for interactive workloads.

# Latency-aware service router
class LatencyAwareRouter
  def initialize
    @latency_tracker = LatencyTracker.new
    @thresholds = {
      interactive: 50, # milliseconds
      standard: 200,
      batch: 1000
    }
  end
  
  def route(request)
    service_type = request.metadata[:type]
    threshold = @thresholds[service_type]
    
    candidates = available_endpoints(request.service_name)
    
    # Filter by latency
    suitable = candidates.select do |endpoint|
      @latency_tracker.p95_latency(endpoint) < threshold
    end
    
    # Fallback to any endpoint if none meet threshold
    suitable.empty? ? candidates.first : select_best(suitable)
  end
  
  private
  
  def select_best(endpoints)
    # Choose endpoint with lowest current load
    endpoints.min_by { |ep| ep.current_connections }
  end
end

Cost Structure differs between locations. On-premises infrastructure requires capital expenditure for hardware, facilities, power, and cooling. Cloud resources bill monthly based on consumption. Hybrid architecture should place predictable, steady workloads on owned infrastructure while using cloud for variable demand.

Calculate total cost of ownership including hidden costs. On-premises requires staff for maintenance, upgrades, and support. Cloud reduces operational overhead but increases monthly operating costs. Data transfer between locations adds expense - minimize cross-boundary transfers in architecture design.

Disaster Recovery and Business Continuity benefit from geographic distribution. Hybrid architecture provides natural disaster recovery capability with resources in multiple physical locations. Applications can fail over from on-premises to cloud during outages or vice versa.

Define recovery time objectives (RTO) and recovery point objectives (RPO) for each application. Critical applications may require synchronous replication between locations despite cost and complexity. Less critical applications tolerate asynchronous replication with potential data loss.

Skill Requirements and Team Capabilities affect implementation success. Hybrid cloud requires expertise in multiple domains: traditional infrastructure, cloud platforms, networking, and distributed systems. Teams familiar with on-premises infrastructure must learn cloud-native patterns. Cloud-focused teams must understand on-premises constraints.

Assess team capabilities honestly when planning hybrid architecture. Complex implementations may exceed team skills, requiring training or hiring. Managed services can fill capability gaps - cloud providers offer hybrid management tools requiring less specialized knowledge.

Migration Path and Timeline influences architecture choices. Organizations moving from on-premises to cloud often adopt hybrid as a transition state. The hybrid architecture should facilitate migration rather than creating permanent dependencies on both locations.

Plan migration waves with clear criteria for moving workloads. Start with stateless applications and low-risk systems. Build confidence and capability before moving critical systems. Avoid creating tightly coupled hybrid dependencies that prevent completing migration.

Tools & Ecosystem

Multiple vendors provide platforms and tools specifically for hybrid cloud deployments.

AWS Outposts delivers AWS infrastructure, services, and APIs on-premises. Organizations run EC2 instances, EBS storage, and other AWS services in their data centers using identical APIs to AWS regions. Outposts connects to the nearest AWS region for management and some services. This provides consistent operations across locations but requires significant capital investment for Outposts hardware.

Azure Stack brings Azure services to on-premises environments. Azure Stack Hub provides full-featured Azure platform on-premises. Azure Stack HCI focuses on virtualization and storage. Azure Arc extends Azure management to resources anywhere - on-premises, other clouds, or edge locations. Azure's hybrid tools integrate deeply with Active Directory and Windows Server environments.

Google Anthos enables running containerized applications anywhere with consistent management. Anthos works with on-premises VMware, bare metal, or other clouds. Based on Kubernetes, Anthos provides portability for containerized workloads. Policy enforcement, service mesh, and configuration management work identically across locations.

# Multi-cloud deployment configuration
class MultiCloudDeployer
  def initialize
    @aws_client = Aws::EC2::Client.new
    @azure_client = Azure::ResourceManagement::Client.new
    @gcp_client = Google::Cloud::Compute.new
  end
  
  def deploy_service(service_config)
    deployments = service_config.target_locations.map do |location|
      case location[:provider]
      when :aws
        deploy_to_aws(service_config, location)
      when :azure
        deploy_to_azure(service_config, location)
      when :gcp
        deploy_to_gcp(service_config, location)
      when :on_prem
        deploy_to_kubernetes(service_config, location)
      end
    end
    
    deployments.all?(&:success?)
  end
  
  private
  
  def deploy_to_aws(config, location)
    # AWS-specific deployment
    @aws_client.run_instances(
      image_id: config.ami_id,
      instance_type: location[:instance_type],
      subnet_id: location[:subnet_id],
      user_data: encode_user_data(config)
    )
  end
  
  def deploy_to_kubernetes(config, location)
    # Kubernetes deployment for on-prem or Anthos
    K8sClient.new(location[:cluster]).create_deployment(
      name: config.name,
      replicas: location[:replicas],
      image: config.container_image,
      env: config.environment_variables
    )
  end
end

HashiCorp Terraform provisions infrastructure across multiple clouds and on-premises systems. A single Terraform configuration can describe resources in AWS, Azure, on-premises VMware, and bare metal systems. Terraform maintains state of all managed resources regardless of location, enabling consistent infrastructure as code across hybrid environments.

Red Hat OpenShift provides enterprise Kubernetes that runs identically on-premises, in cloud, or at edge locations. OpenShift includes additional platform services beyond Kubernetes: integrated CI/CD, service mesh, monitoring, and developer tools. Organizations deploy OpenShift clusters in each location with consistent application deployment processes.

VMware Cloud Foundation extends VMware virtualization to cloud environments. Organizations running VMware on-premises can use VMware Cloud on AWS, Azure VMware Solution, or Google Cloud VMware Engine. This enables vMotion of virtual machines between on-premises and cloud, using existing VMware expertise and tools.

Kubernetes Federation coordinates multiple Kubernetes clusters across locations. Federation controls which clusters run which workloads, manages configuration across clusters, and handles service discovery between clusters. Applications deploy to federated clusters using standard Kubernetes APIs while federation handles multi-cluster concerns.

# Kubernetes multi-cluster deployment
require 'kubeclient'

class KubernetesFederationManager
  def initialize(cluster_configs)
    @clusters = cluster_configs.map do |config|
      {
        name: config[:name],
        client: Kubeclient::Client.new(
          config[:api_url],
          'v1',
          ssl_options: config[:ssl_options]
        ),
        region: config[:region]
      }
    end
  end
  
  def deploy_federated_service(service_spec)
    # Deploy to all clusters with region-specific configuration
    @clusters.map do |cluster|
      deployment = create_deployment_spec(service_spec, cluster[:region])
      
      cluster[:client].create_deployment(deployment).tap do |result|
        create_service_entry(cluster, service_spec)
      end
    end
  end
  
  private
  
  def create_deployment_spec(base_spec, region)
    # Customize deployment for region
    spec = base_spec.deep_dup
    spec[:metadata][:labels][:region] = region
    spec[:spec][:replicas] = replicas_for_region(region)
    spec
  end
  
  def create_service_entry(cluster, service_spec)
    # Register service in global service registry
    ServiceMesh.register(
      service: service_spec[:name],
      cluster: cluster[:name],
      endpoints: discover_pod_ips(cluster, service_spec[:name])
    )
  end
end

Service Mesh Technologies like Istio, Linkerd, or Consul manage service-to-service communication in hybrid deployments. Service mesh handles encryption, authentication, observability, and traffic routing across cluster boundaries. Applications communicate through the mesh without implementing these concerns directly.

Monitoring and Observability Tools aggregate metrics, logs, and traces from all locations. Prometheus with Thanos provides multi-cluster metrics aggregation. Grafana visualizes metrics from multiple sources. ELK Stack (Elasticsearch, Logstash, Kibana) or Splunk centralize log aggregation. Jaeger or Zipkin trace requests across hybrid boundaries.

Network and Security Tools include VPN solutions like WireGuard or OpenVPN for encrypted connections. SD-WAN products from vendors like Cisco or VMware optimize traffic routing between locations. Cloud Access Security Brokers (CASB) enforce security policies for cloud access. Identity providers like Okta or Auth0 handle federated authentication.

Integration & Interoperability

Connecting on-premises and cloud systems requires solving integration challenges at multiple layers.

Network Layer Integration establishes private connectivity between locations. VPN tunnels provide encrypted connections over internet but may suffer from unpredictable latency and throughput. Dedicated connections like AWS Direct Connect or Azure ExpressRoute offer private, predictable network performance at higher cost.

Configure network routing carefully to avoid traffic tromboning where packets take inefficient paths. Use BGP routing when possible to advertise routes dynamically. Implement redundant connections for reliability - single connection creates a critical failure point.

# Network path health monitoring
class NetworkPathMonitor
  def initialize(paths)
    @paths = paths
    @health_checks = {}
  end
  
  def monitor
    @paths.each do |path|
      Thread.new do
        loop do
          health = check_path_health(path)
          @health_checks[path[:name]] = health
          
          if health[:status] == :degraded
            alert_operations(path, health)
            trigger_failover(path) if health[:latency] > path[:max_latency]
          end
          
          sleep(path[:check_interval] || 30)
        end
      end
    end
  end
  
  private
  
  def check_path_health(path)
    start_time = Time.now
    
    begin
      response = HTTP.timeout(5).get(path[:health_endpoint])
      latency = ((Time.now - start_time) * 1000).round
      
      {
        status: latency > path[:warning_threshold] ? :degraded : :healthy,
        latency: latency,
        packet_loss: calculate_packet_loss(path),
        bandwidth: measure_bandwidth(path)
      }
    rescue HTTP::TimeoutError
      { status: :failed, error: 'timeout' }
    end
  end
  
  def trigger_failover(path)
    # Switch to backup path
    backup = @paths.find { |p| p[:backup_for] == path[:name] }
    RouteTable.update_routes(path[:name], backup[:gateway])
  end
end

Identity and Access Management Integration federates authentication between systems. SAML 2.0 enables single sign-on where users authenticate to on-premises identity provider (like Active Directory) and access cloud resources without separate login. OAuth 2.0 and OpenID Connect provide token-based authentication for API access.

Synchronize user directories between locations or use federation that queries the authoritative source. Azure Active Directory Connect synchronizes on-premises Active Directory to Azure AD. AWS Directory Service provides managed Active Directory in AWS that can trust on-premises AD.

Data Integration Patterns move data between locations based on application requirements. ETL processes extract data from on-premises databases, transform it, and load to cloud data warehouses. Change data capture streams database changes to cloud systems in near real-time. File synchronization tools replicate files between storage systems.

Database replication varies by database system. PostgreSQL logical replication can replicate between on-premises and cloud PostgreSQL. MongoDB Atlas supports hybrid cluster deployments. Most databases require careful configuration of replication lag, conflict resolution, and failover behavior.

# Hybrid database replication manager
class DatabaseReplicationManager
  def initialize(primary:, replica:)
    @primary = primary
    @replica = replica
    @replication_slot = "hybrid_cloud_slot"
  end
  
  def setup_replication
    # Create logical replication slot on primary
    @primary.execute(<<~SQL)
      SELECT pg_create_logical_replication_slot(
        '#{@replication_slot}',
        'pgoutput'
      );
    SQL
    
    # Create publication for tables to replicate
    @primary.execute(<<~SQL)
      CREATE PUBLICATION hybrid_pub 
      FOR TABLE users, orders, products;
    SQL
    
    # Create subscription on replica
    @replica.execute(<<~SQL)
      CREATE SUBSCRIPTION hybrid_sub
      CONNECTION 'host=#{@primary.host} dbname=#{@primary.database}'
      PUBLICATION hybrid_pub
      WITH (slot_name = '#{@replication_slot}');
    SQL
  end
  
  def monitor_replication_lag
    result = @replica.execute(<<~SQL)
      SELECT 
        now() - pg_last_xact_replay_timestamp() AS lag
      FROM pg_stat_replication;
    SQL
    
    lag_seconds = result.first['lag']
    
    if lag_seconds > 60
      alert_lag_exceeded(lag_seconds)
    end
    
    lag_seconds
  end
end

Application Integration connects distributed application components. Message queues like RabbitMQ or Amazon SQS provide asynchronous communication. Event streaming platforms like Apache Kafka distribute events to consumers in multiple locations. RESTful APIs enable synchronous request-response patterns.

Design APIs for network failures and latency. Implement circuit breakers to prevent cascade failures when one location becomes unavailable. Use retries with exponential backoff for transient failures. Consider request timeouts carefully - too short causes false failures, too long blocks threads.

Storage Integration addresses file and object storage across locations. Object storage services like Amazon S3, Azure Blob Storage, or MinIO provide APIs for storing files. Some organizations use cloud storage gateways that cache frequently accessed objects on-premises while storing all objects in cloud.

File synchronization tools like AWS DataSync or Azure File Sync replicate files between locations. Configure synchronization direction and conflict resolution policies. Monitor synchronization lag especially for frequently changing files.

Service Discovery and Registration enables services to find each other across locations. Consul, etcd, or cloud-native service discovery register service instances with location metadata. Applications query service registry to find healthy instances, preferring local instances for performance.

Real-World Applications

Organizations deploy hybrid cloud for various production use cases, each with distinct implementation patterns.

Enterprise SaaS Application combines on-premises core systems with cloud-based customer-facing applications. The architecture keeps customer data and business logic on-premises for compliance while providing globally accessible web interfaces through cloud hosting. API gateways expose necessary on-premises functionality to cloud applications with security controls.

Implementation uses cloud load balancers distributing traffic globally with regional failover. Cloud applications communicate with on-premises APIs through VPN connections with circuit breakers for resilience. Database replication maintains read replicas in cloud regions for query performance while writes go to on-premises primary database.

# Hybrid SaaS request handler
class HybridSaasController < ApplicationController
  before_action :authenticate_user
  
  def customer_data
    # Read from cloud replica for performance
    cache_key = "customer:#{params[:id]}:#{Date.today}"
    
    data = Rails.cache.fetch(cache_key, expires_in: 1.hour) do
      CloudReplica.find_customer(params[:id])
    end
    
    render json: data
  rescue CloudReplica::ConnectionError
    # Fallback to on-premises primary
    data = OnPremDatabase.find_customer(params[:id])
    render json: data
  end
  
  def update_customer
    # Writes must go to on-premises primary
    customer = OnPremDatabase.find_customer(params[:id])
    
    OnPremDatabase.transaction do
      customer.update!(customer_params)
      
      # Invalidate cache in cloud regions
      invalidate_cloud_cache(customer.id)
    end
    
    render json: customer
  rescue OnPremDatabase::Unavailable
    # Queue write for retry
    WriteQueue.enqueue(
      type: :customer_update,
      id: params[:id],
      params: customer_params
    )
    
    render json: { status: 'queued' }, status: :accepted
  end
end

Media Processing Pipeline processes video content using on-premises storage with cloud compute for encoding. Large video files remain in on-premises storage to avoid transfer costs. Encoding jobs launch in cloud for elastic scaling during peak upload periods. Processed files move to cloud CDN for global distribution.

The pipeline uses object storage notifications to trigger encoding jobs. Video metadata and job status synchronize between locations. Partial file processing allows cloud workers to process segments without downloading entire files.

Financial Trading System runs latency-sensitive trading algorithms on-premises near exchanges while using cloud for risk analysis and regulatory reporting. Microsecond latency requirements for trading necessitate on-premises deployment. Historical analysis and compliance reporting tolerate higher latency and benefit from cloud scalability.

Data flows from trading systems to cloud in batches after market close. Real-time market data feeds both on-premises trading and cloud analytics through multicast or message brokers. Cloud analytics generates overnight reports and risk calculations using historical data.

IoT and Edge Computing collects sensor data at edge locations with cloud backend for aggregation and machine learning. Edge devices process data locally for immediate actions. Aggregated data transfers to cloud for long-term storage, analysis, and model training. Updated models deploy from cloud to edge devices.

The architecture minimizes data transfer by filtering and aggregating at edge. Only significant events and summary statistics flow to cloud. Edge devices operate autonomously during network outages, queuing data for later synchronization.

# IoT edge-to-cloud data pipeline
class IoTDataPipeline
  def initialize
    @edge_buffer = EdgeBuffer.new(max_size: 10_000)
    @cloud_uploader = CloudUploader.new
    @aggregator = DataAggregator.new
  end
  
  def process_sensor_reading(reading)
    # Immediate local processing
    if critical_threshold_exceeded?(reading)
      trigger_local_action(reading)
    end
    
    # Buffer for cloud upload
    @edge_buffer.add(reading)
    
    # Periodic aggregation and upload
    if @edge_buffer.ready_for_upload?
      upload_batch
    end
  end
  
  private
  
  def upload_batch
    batch = @edge_buffer.drain
    aggregated = @aggregator.summarize(batch)
    
    # Upload summary, not raw readings
    @cloud_uploader.upload(
      timestamp: Time.now,
      summary: aggregated,
      sample_count: batch.size
    )
  rescue CloudUploader::NetworkError => e
    # Persist locally and retry later
    @edge_buffer.persist_to_disk(batch)
    schedule_retry
  end
  
  def trigger_local_action(reading)
    # Local actuation without cloud dependency
    ActuatorController.adjust(
      device: reading.device_id,
      parameter: reading.parameter,
      value: calculate_correction(reading)
    )
  end
end

Development and Testing Environment maintains production on-premises while using cloud for development environments. Developers spin up cloud environments quickly without waiting for on-premises infrastructure. Production data replicates to cloud with anonymization for realistic testing. CI/CD pipelines run in cloud for parallel test execution.

Development environments mirror production configuration using infrastructure as code. Automated cleanup removes unused cloud resources to control costs. Security policies prevent production credentials in development environments.

Disaster Recovery uses cloud as backup site for on-premises production systems. Regular data backups upload to cloud storage for durability. Critical applications can failover to cloud during on-premises outages. The architecture tests failover procedures regularly to verify recovery time objectives.

Recovery procedures automate infrastructure provisioning and data restoration. Monitoring detects on-premises failures and initiates automatic or manual failover. Applications handle database connection changes during failover.

Reference

Hybrid Cloud Architecture Patterns

Connectivity Options

Data Synchronization Strategies

Security Considerations

Common Deployment Models

Management Tools Comparison

Performance Optimization Checklist

Cost Optimization Strategies

Monitoring Metrics

Migration Phases