Beyond the Hype: Architecting a Fail-Proof Hybrid Cloud Strategy for 2013

Let’s be honest for a moment. The marketing departments at Amazon and Rackspace want you to believe that moving your entire infrastructure to their "Cloud" solves every uptime problem you have. They sell the dream of infinite scalability and five nines of availability.

They are lying to you.

If you were watching the outages in Northern Virginia last year, or the EBS failures that took down half the startup ecosystem, you know the truth. Relying on a single vendor—no matter how big—is a single point of failure. As a CTO, I don’t care about marketing buzzwords. I care about TCO (Total Cost of Ownership) and sleeping through the night.

In Norway, we have a unique set of challenges. We have the Data Protection Directive (95/46/EC) to worry about, and latency to US-based or even Irish data centers can kill the user experience for local customers. The solution isn't to abandon the cloud, but to adopt a Hybrid Strategy: keep your data Sovereign and fast on CoolVDS in Oslo, and use public clouds for burstable compute.

The Latency & Sovereignty Argument

Physics is stubborn. Round-trip time (RTT) from Oslo to AWS eu-west-1 (Ireland) usually sits around 30-45ms. That’s acceptable for a blog, but for a transactional database or a high-frequency trading platform? It’s an eternity.

Furthermore, the Norwegian Data Inspectorate (Datatilsynet) is becoming increasingly strict about where personal data resides. While the Safe Harbor framework currently allows data transfer to the US, many Norwegian enterprises prefer the legal safety of keeping the users table on Norwegian soil. This is where a high-performance VPS in Oslo becomes the anchor of your architecture.

The Architecture: "Core + Burst"

Here is the setup I deployed for a media client last month:

• The Core (CoolVDS): Two High-Performance SSD KVM instances in Oslo. These host the Master Database and the primary Application Logic.
• The Burst (AWS/Rackspace): On-demand instances that spin up only when traffic spikes.
• The Glue: OpenVPN and HAProxy.

1. The Network Link (OpenVPN)

Don't expose your database port (3306) to the public internet. It’s asking for trouble. We use a simple OpenVPN tunnel to bridge the CoolVDS instances with the public cloud nodes.

# On the CoolVDS Server (VPN Server)
apt-get install openvpn
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
source ./vars
./clean-all
./build-ca
./build-key-server server
./build-dh

This creates a secure, private tunnel where latency is the only penalty, not security.

2. Database Performance: IOPS is King

This is where most cloud providers fail. Standard cloud storage is often networked spinning rust (magnetic storage). It suffers from the "noisy neighbor" effect. If another VM on the same physical host decides to compile a kernel, your database I/O tanks.

At CoolVDS, we use local RAID-10 SSDs. In 2013, SSD storage is a premium feature elsewhere, but it's standard here. The difference in MySQL transaction speeds is night and day.

Pro Tip: When configuring InnoDB on an SSD-backed VPS, ensure you disable the innodb_flush_neighbors setting. SSDs don't have seek time, so optimizing for contiguous writes is unnecessary overhead.

# /etc/mysql/my.cnf optimizations for SSD
[mysqld]
innodb_buffer_pool_size = 4G
innodb_flush_neighbors = 0
innodb_io_capacity = 2000
innodb_read_io_threads = 8
innodb_write_io_threads = 8

3. Load Balancing with HAProxy

HAProxy 1.4 is the workhorse of this setup. It runs on our CoolVDS nodes and directs traffic. If the local nodes are overwhelmed, it bleeds traffic over to the cloud nodes.

# /etc/haproxy/haproxy.cfg

global
    log 127.0.0.1 local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http-in
    bind *:80
    default_backend servers

backend servers
    balance roundrobin
    # Primary CoolVDS Nodes (Low Latency)
    server app1 10.8.0.1:80 check weight 100
    server app2 10.8.0.2:80 check weight 100
    
    # Cloud Burst Nodes (Higher Latency, only used when needed)
    server cloud1 192.168.1.5:80 check weight 10 backup

By using the backup flag or lower weights, we ensure that 95% of the traffic is served from the high-speed Oslo nodes, and we only pay for the external cloud bandwidth when absolutely necessary.

Configuration Management with Puppet

Managing servers across two different providers manually is suicide. We use Puppet to ensure that the nginx.conf on a CoolVDS node is identical to the one on a Rackspace node.

Here is a basic manifest to ensure NTP is running (crucial for database replication logging):

class ntp {
  package { 'ntp':
    ensure => installed,
  }

  service { 'ntp':
    ensure  => running,
    enable  => true,
    require => Package['ntp'],
  }

  file { '/etc/ntp.conf':
    source  => 'puppet:///modules/ntp/ntp.conf',
    notify  => Service['ntp'],
    require => Package['ntp'],
  }
}

The Verdict: Reliability Costs Less Than You Think

A multi-provider strategy sounds expensive, but it actually lowers TCO. Because CoolVDS offers generous bandwidth and fixed monthly pricing, you handle your base load there cheaply. You avoid the unpredictable "pay-per-IOPS" bills that other providers spring on you.

You don't need to be Google to have redundancy. You just need to be pragmatic.

If you are ready to build a stack that survives the next big outage, start by securing your core infrastructure.

Don't let slow I/O kill your SEO. Deploy a high-performance SSD instance on CoolVDS in Oslo today.