Edge Computing in 2017: Why Latency to Frankfurt is Killing Your Real-Time Apps
Let’s be honest for a second. The "Cloud" marketing machine has done a fantastic job convincing CTOs that dumping everything into AWS eu-central-1 (Frankfurt) or eu-west-1 (Ireland) is the answer to every infrastructure question. But for those of us staring at ping output and analyzing packet captures at 3 AM, the reality is starkly different. Physics doesn't care about your SLA.
If your users are in Oslo and your server is in Frankfurt, you are fighting a losing battle against the speed of light. That 30-40ms round-trip time (RTT) might seem negligible for a WordPress blog, but for the emerging wave of Industrial IoT (IIoT) and high-frequency trading platforms we see developing across the Nordics, it’s an eternity. In 2017, "Edge Computing" isn't just a Gartner buzzword anymore; it is a structural necessity for survival.
The Problem: The "Long Haul" Data Pattern
I recently consulted for a maritime logistics firm here in Norway. They were streaming telemetry data from vessel sensors—hundreds of metrics per second—directly to a centralized SQL cluster in Ireland. The result? Packet loss over the public internet caused gaps in their time-series data, and the TCP retransmissions saturated their uplink.
They didn't need a bigger cloud instance. They needed to stop treating the internet like a reliable LAN.
Use Case 1: The IoT Aggregation Layer
Instead of fire-hosing raw data across the continent, the battle-tested pattern is to deploy an aggregation node closer to the source. By spinning up a lean VPS in Oslo (ideally peering at NIX—the Norwegian Internet Exchange), you create a buffer zone.
The architecture looks like this:
- Sensors publish to a local Edge VPS via MQTT.
- Edge VPS filters noise, aggregates data, and performs initial validation.
- Edge VPS pushes clean, compressed batches to the central cloud for long-term storage.
Here is how we set up a robust Mosquitto bridge on a CoolVDS instance running CentOS 7. This configuration acts as the "store-and-forward" mechanism. If the link to the central cloud drops, the Edge node queues the messages. No data loss.
Mosquitto Bridge Configuration (/etc/mosquitto/conf.d/bridge.conf)
# Define the bridge connection to the central datacenter
connection bridge-to-cloud
address 198.51.100.10:1883
# Authentication for the bridge
remote_username edge_node_01
remote_password your_secure_password
# Topics to sync
# Pattern: topic direction qos local-prefix remote-prefix
topic sensors/# out 1 local/ topic/
# Queue configuration - CRITICAL for reliability
cleansession false
# If internet cuts, queue messages on disk
qos 1
To back this up, we use InfluxDB (v1.2) locally on the edge node for real-time monitoring of the data stream before it leaves Norway. This allows local engineers to see dashboards via Grafana without waiting for data to round-trip to Ireland.
# Installing the TICK stack components on CentOS 7
cat <Use Case 2: Intelligent Micro-Caching
Another scenario where "Edge" beats "Cloud" is high-traffic content delivery. We aren't talking about standard CDNs that serve static JPEGs. We are talking about dynamic content caching. If you are running a Magento store or a heavy Drupal site targeting Norwegian customers, rendering PHP in Frankfurt adds latency on top of the Time To First Byte (TTFB).
By placing a reverse proxy on a CoolVDS NVMe instance in Oslo, you can implement micro-caching. This serves dynamic pages as static HTML for short periods (e.g., 5 seconds). It absorbs traffic spikes—like those during Black Friday or tax return season—without hitting your backend database.
Here is a production-ready Nginx snippet we use to protect backends. Note the use of proxy_cache_use_stale. This is the "undead" mode: if your backend crashes, the edge node keeps serving the last known good version of the site.
Nginx Edge Cache Config
http {
# Define the cache path. 10GB max size, ample for most edge nodes.
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_edge_cache:100m max_size=10g inactive=60m use_temp_path=off;
server {
listen 80;
server_name edge-node.coolvds.com;
location / {
proxy_pass http://backend_upstream;
# Cache Configuration
proxy_cache my_edge_cache;
proxy_cache_valid 200 302 5s; # Micro-cache for 5 seconds
proxy_cache_valid 404 1m;
# The magic: Serve stale content if backend is erroring
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
# Add header for debugging
add_header X-Cache-Status $upstream_cache_status;
}
}
}
Pro Tip: When using Nginx as an edge balancer, always tune your worker rlimit. In/etc/nginx/nginx.conf, setworker_rlimit_nofile 65535;. The default Linux limit of 1024 file descriptors will choke under load, causing "502 Bad Gateway" errors even if your CPU is idle.
The Hardware Reality: NVMe vs. Spinning Rust
In 2017, many providers are still selling you VPS instances backed by SATA SSDs or, heaven forbid, SAS drives in RAID 10. For edge computing, where I/O latency translates directly to queue depth spikes, this is unacceptable.
When you are processing MQTT streams or shuffling cache files, disk I/O is often the bottleneck. We benchmarked this extensively. A standard SATA SSD array often caps out at 500-600 MB/s shared across neighbors. In contrast, the NVMe storage we implemented standard across all CoolVDS nodes pushes 3000+ MB/s. When your message queue starts filling up because the network is down, that write speed difference is what saves your data from being dropped.
Benchmarking I/O with Fio
Don't take my word for it. Run this fio command on your current host. If your IOPS are under 10k, you aren't ready for edge workloads.
yum install -y fio
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=1G --readwrite=randwrite
The Compliance Angle: GDPR is Coming
We cannot ignore the elephant in the room. The General Data Protection Regulation (GDPR) enforcement date is set for May 2018. That is less than a year away. If you are processing personal data of Norwegian citizens, relying on US-owned cloud providers with data centers outside the EEA is becoming a legal minefield.
Hosting your edge nodes physically in Norway isn't just a performance decision anymore; it's a risk mitigation strategy. Keeping data within the jurisdiction of the Norwegian Datatilsynet until it is anonymized gives you a significantly stronger compliance posture.
Conclusion
Edge computing in 2017 is about pragmatism. It's about recognizing that while the centralized cloud is great for storage and heavy lifting, it sucks at real-time responsiveness and data sovereignty.
Whether you are building an IoT mesh for the oil sector or just trying to get your TTFB under 50ms for a local e-commerce site, you need compute power that is physically close to your users. You need raw KVM virtualization to avoid the "noisy neighbor" problems of containers, and you need NVMe storage to handle the bursts.
Don't let latency dictate your architecture. Deploy a high-performance, local edge node on CoolVDS today and keep your packets inside Norway where they belong.