Stop Treating Your Infrastructure Like a Pet

I still remember the Tuesday afternoon our main e-commerce monolith decided to deadlock. It wasn't a traffic spike. It was a single, poorly written SQL query in the reporting module that locked the `orders` table. Because everything was bundled into one massive WAR file, the checkout process died along with the reporting tool. We lost thousands in revenue in 45 minutes.

That is why we break things apart. But let's be honest: moving to microservices replaces coding complexity with operational complexity. Instead of one broken app, you now have twenty broken services shouting at each other.

If you are engineering for the Nordic market, you have two additional constraints: strict data residency requirements (thanks to the upcoming GDPR enforcement next year) and the need for extreme stability. Here is how to architect this without losing your mind, using patterns that are production-ready today.

1. The API Gateway Pattern: Your First Line of Defense

Do not let your clients (mobile apps, front-end SPAs) talk directly to your backend services. It exposes your internal architecture and creates security nightmares. In 2017, Nginx is still the king here, though Kong is getting interesting. We stick to Nginx for its raw speed and low footprint.

The Gateway handles SSL termination, rate limiting, and routing. This offloads heavy lifting from your microservices, allowing them to focus on logic.

Here is a battle-tested nginx.conf snippet for an API gateway routing to three distinct services (Auth, Cart, Inventory):

http {
    upstream auth_service {
        server 10.10.0.5:8080;
        server 10.10.0.6:8080;
    }

    upstream cart_service {
        server 10.10.0.10:3000;
    }

    server {
        listen 80;
        server_name api.coolvds-client.no;

        # Security headers are not optional
        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-XSS-Protection "1; mode=block";

        location /auth/ {
            proxy_pass http://auth_service;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $host;
        }

        location /cart/ {
            proxy_pass http://cart_service;
            # Timeout settings are crucial for microservices
            proxy_connect_timeout 5s;
            proxy_read_timeout 10s;
        }
    }
}

Pro Tip: Keep your timeouts short. If the Cart service is hanging, fail fast. A 30-second timeout on a backend service will cascade and take down your entire Gateway. Set proxy_read_timeout to the bare minimum needed.

2. Service Discovery: Because Hardcoding IPs is Suicide

In a CoolVDS environment, or any cloud setup, servers are ephemeral. They come up, they die, they get replaced. If you hardcode 10.10.0.5 in your config, you will be woken up at 3 AM.

We use Consul by HashiCorp. It’s robust, distributed, and plays nice with Docker. Unlike Eureka (which is very Java-centric), Consul works with everything.

To start a Consul agent in server mode on your initial node:

docker run -d --net=host --name=consul-server \
    -e 'CONSUL_LOCAL_CONFIG={"skip_leave_on_interrupt": true}' \
    consul agent -server -bind=10.10.0.5 -bootstrap-expect=1 -client=0.0.0.0

Then, your microservices can register themselves via HTTP API or a local agent. When Service A needs to call Service B, it asks Consul for the address, not a static config file.

3. The Infrastructure Reality: I/O and Isolation

This is where most implementations fail. You wrap everything in Docker containers, deploy them to a VPS, and suddenly your database performance tanks. Why?

Noisy Neighbors.

If you use cheap shared hosting or standard OpenVZ containers, you are sharing the OS kernel. If another user on that physical node decides to compile the Linux kernel, your microservices starve for CPU cycles. This causes latency spikes. In a distributed system, latency is additive. If Service A calls B, which calls C, and they all have 50ms jitter, your user waits half a second.

This is why at CoolVDS we strictly use KVM virtualization. Each instance has its own kernel. We also map storage directly to NVMe drives. Microservices are chatty; they log heavily and read configs constantly. Spinning rust (HDD) or even standard SATA SSDs often become the bottleneck during traffic surges.

Deploying with Docker Compose (v3)

For smaller deployments or dev environments, Docker Compose is sufficient before you jump into the complexity of Kubernetes (though v1.6 is looking promising).

version: '3'
services:
  redis:
    image: redis:3.2-alpine
    networks:
      - backend
    sysctls:
      - net.core.somaxconn=1024

  inventory:
    image: myrepo/inventory:v1.4
    deploy:
      replicas: 2
      restart_policy:
        condition: on-failure
    environment:
      - DB_HOST=postgres
      - REDIS_HOST=redis
    networks:
      - backend
    depends_on:
      - redis

networks:
  backend:
    driver: bridge

4. Data Sovereignty and The "NIX" Factor

We are seeing tighter regulations from Datatilsynet here in Norway. With GDPR looming next year, you need to know exactly where your data lives. Hosting on US-owned clouds introduces legal ambiguity regarding the Privacy Shield framework.

Hosting locally isn't just about compliance; it's about physics. Connecting to the Norwegian Internet Exchange (NIX) in Oslo ensures your latency to Norwegian users is under 5ms. If your microservices are distributed across regions, you are introducing network lag that no code optimization can fix.

When you deploy on CoolVDS, you aren't just getting a server; you are placing your workloads physically closer to your customers and legally within a jurisdiction you understand.

Final Thoughts: Start Small

Don't rewrite your entire stack next week. Extract one service—perhaps the notification emailer or image resizer. Put it in a Docker container, stick it behind Nginx, and monitor the hell out of it using the ELK stack (Elasticsearch, Logstash, Kibana).

And if you see high iowait in top, it’s time to move off that legacy hardware.

Ready to test your architecture? Deploy a KVM-based NVMe instance on CoolVDS today and see what real isolation does for your response times.