Escaping the Vendor Trap: A Pragmatic Multi-Cloud Strategy for Norwegian Enterprises

It has been exactly three months since May 25th—GDPR Day. If you are like most CTOs in Oslo right now, the dust hasn't settled; it has just coated your servers in a layer of anxiety. We have spent the summer auditing data flows, updating privacy policies, and scratching our heads over Article 44.

Here is the uncomfortable reality many are ignoring: putting 100% of your stack into a US-owned hyperscaler (AWS, Google, Azure), even in their Frankfurt or Dublin regions, carries sovereignty risks. The US CLOUD Act is looming. The EU-US Privacy Shield feels flimsy. If you are handling sensitive Norwegian user data—health records, financial transactions, or even basic PII—putting all your eggs in an American basket is a strategic gamble.

The solution isn't to abandon the cloud. It's to stop treating "The Cloud" as a single vendor. This is the era of the Hybrid Multi-Cloud. Keep your raw compute where it's cheap, but keep your data where it's safe—right here in Norway on high-performance infrastructure like CoolVDS.

The Architecture: The "Data Sovereign" Split

We are not talking about complex active-active clusters across providers; the latency between Oslo and Virginia would kill your transactional integrity. We are talking about a Data Residency Architecture.

• Frontend/Stateless Layer: Distributed globally or regionally (AWS/GCP) for edge caching.
• Backend/Data Layer: Anchored in Norway (CoolVDS) for compliance and NVMe performance.
• Orchestration: Managed via Terraform to treat different providers as a unified resource pool.

Pro Tip: Latency matters. The round-trip time (RTT) from AWS Frankfurt (eu-central-1) to Oslo is typically 20-25ms. For a web application, this is negligible if your database queries are optimized. If you are running N+1 query loops, however, this architecture will expose your bad code immediately.

Infrastructure as Code: Terraform v0.11

Manual clicking in dashboards is for amateurs. To manage a multi-provider setup, we use HashiCorp's Terraform. While we wait for the promised improvements in v0.12, the current v0.11 syntax allows us to define our CoolVDS KVM instances alongside AWS resources.

Here is how we structure a hybrid definition. Note the use of the interpolation syntax ${} which is required in our current version.

# provider.tf

provider "aws" {
  region = "eu-central-1"
}

# We use a generic provider or local-exec for CoolVDS interactions 
# if a native provider isn't available in the registry yet.
resource "null_resource" "coolvds_node" {
  provisioner "local-exec" {
    command = "./coolvds-cli create --image='ubuntu-18.04' --plan='nvme-16gb-4vcpu' --location='oslo'"
  }
}

resource "aws_instance" "frontend" {
  ami           = "ami-0bdf93799014acdc4" # Ubuntu 18.04 in Frankfurt
  instance_type = "t2.medium"
  
  tags {
    Name = "hybrid-frontend-01"
  }
}

Secure Networking: Bridging the Gap

You cannot send database traffic over the public internet in plain text. You need a site-to-site VPN. Since CoolVDS provides full KVM virtualization, you have complete kernel control to install strongSwan for an IPsec tunnel.

On your CoolVDS instance (the Data Anchor), you configure /etc/ipsec.conf. This setup ensures that your AWS frontend talks to your Norwegian database through an encrypted tunnel, satisfying Datatilsynet requirements for data transport security.

# /etc/ipsec.conf on CoolVDS (CentOS 7 / Ubuntu 18.04)
config setup
    charondebug="ike 2, knl 2, cfg 2"

conn oslo-to-frankfurt
    authby=secret
    auto=start
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256-modp2048!
    
    # CoolVDS (Left)
    left=%defaultroute
    leftid=185.x.x.x  # Your CoolVDS Public IP
    leftsubnet=10.10.0.0/24  # Local private network

    # Remote Cloud (Right)
    right=35.x.x.x    # AWS VPN Gateway IP
    rightsubnet=172.16.0.0/24 # VPC Subnet

Once the tunnel is established, your AWS instances can connect to your database at 10.10.0.5:3306 as if they were in the same rack.

The Storage Bottleneck: Why NVMe is Non-Negotiable

In 2018, "SSD" isn't enough anymore. Standard SATA SSDs top out around 550 MB/s. When you are aggregating data from multiple cloud frontends, your database I/O becomes the choke point. This is where the "noisy neighbor" effect of massive public clouds hurts you—IOPS are often throttled unless you pay for expensive "Provisioned IOPS".

At CoolVDS, we have standardized on NVMe (Non-Volatile Memory Express). We are seeing read speeds upwards of 3,000 MB/s on our host nodes. If you are running a high-transaction MySQL 5.7 or MariaDB 10.2 database, the switch to NVMe reduces query latency significantly, compensating for the network hop between Oslo and Frankfurt.

Optimizing MySQL 5.7 for NVMe

Don't just install MySQL and leave it. You must configure InnoDB to utilize the high I/O capability of the underlying NVMe storage. Edit your /etc/my.cnf:

[mysqld]
# 70-80% of RAM for the buffer pool
innodb_buffer_pool_size = 12G 

# Utilize the high concurrency of NVMe
innodb_io_capacity = 5000
innodb_io_capacity_max = 10000
innodb_flush_neighbors = 0 # NVMe handles random writes well; no need to sort

The Economic Reality (TCO)

Let's talk numbers. Running a high-memory, high-storage instance on AWS (e.g., i3.large) gets expensive fast, especially when you factor in egress bandwidth costs. By keeping your heavy data storage on a CoolVDS instance, you benefit from a flat-rate pricing model. You are not penalized for disk activity.

Conclusion: pragmatic Paranoia

A multi-cloud strategy in 2018 isn't about over-engineering; it is about risk mitigation. It allows you to tell your Board (and your Data Protection Officer) that your core assets are safe in Norway, while telling your developers they still have access to the global tools they love.

Don't let vendor lock-in dictate your compliance strategy. Build a bridge. Spin up a KVM instance on CoolVDS today, configure your VPN, and take back control of your data.