Serverless Sovereignty: Implementing FaaS Patterns on Bare-Metal VPS in Norway

Let's clear the air immediately: "Serverless" is a lie. There are always servers. The only variable is whether you control them or if you're renting time slices on a black box owned by a US mega-corp.

For many Norwegian CTOs and developers, the allure of AWS Lambda or Google Cloud Functions fades rapidly when faced with three realities: Cold starts, unpredictable billing, and Datatilsynet (The Norwegian Data Protection Authority). If you are processing personal data of Norwegian citizens, piping it through a function hosted in Frankfurt—or worse, a region with ambiguous data residency guarantees—is a compliance minefield post-Schrems II.

I recently audited a fintech setup in Oslo. They were bleeding money on API Gateway and Lambda costs for a simple notification service. The latency was erratic, swinging from 30ms to 2000ms due to cold starts. We migrated them to a self-hosted FaaS (Function as a Service) architecture on CoolVDS instances. The result? 12ms consistent latency to NIX (Norwegian Internet Exchange), full GDPR compliance, and a 60% reduction in monthly burn.

Here is how you build a sovereign serverless architecture without the vendor lock-in.

The Architecture: K3s + OpenFaaS on NVMe

To replicate the developer experience of "git push deploy" without the overhead of heavy enterprise Kubernetes, we use K3s (lightweight Kubernetes) combined with OpenFaaS. This stack runs exceptionally well on high-performance VPS architecture where you have dedicated CPU cycles.

Why underlying hardware matters

In a serverless pattern, functions appear, do work, and die. This creates massive I/O pressure. Containers are constantly being created and destroyed. If your host uses standard SSDs or, god forbid, spinning rust, your "serverless" platform will choke. You need NVMe storage. On CoolVDS, the direct NVMe pass-through via KVM ensures that container hydration happens in milliseconds, not seconds.

Step 1: The Base Infrastructure

Assuming you have a CoolVDS instance running Ubuntu 22.04 LTS (standard for 2023), we first need to tune the kernel for high-churn container workloads. Default Linux settings are too conservative for FaaS.

Add the following to /etc/sysctl.conf:

# Increase the number of incoming connections
net.core.somaxconn = 4096

# Allow for more PIDs (essential for thousands of short-lived containers)
kernel.pid_max = 65535

# Optimize for low latency over throughput
net.ipv4.tcp_low_latency = 1

# Fast recycling of TIME_WAIT sockets
net.ipv4.tcp_tw_reuse = 1

Apply these changes with sysctl -p. If you were on a shared hosting plan or a restrictive container service, you wouldn't be able to touch these flags. This is why VPS Norway solutions are superior for custom architecture.

Step 2: Deploying the Control Plane

We will use K3s because it removes the bloat. It allows us to turn a single robust VPS into a cluster orchestrator.

curl -sfL https://get.k3s.io | sh -

# Verify the node is ready
k3s kubectl get node

Next, we install OpenFaaS using arkade (the preferred installer in 2023):

curl -sLS https://get.arkade.dev | sudo sh

arkade install openfaas

This deploys the gateway, queue worker, and Prometheus for auto-scaling metrics. The beauty here is that the data never leaves your server. It stays right there in the Oslo datacenter.

Step 3: The Function Pattern

Let's look at a practical pattern: Async Webhooks with Retry Logic. In a public cloud, you'd wire up SQS to Lambda. Here, we use the built-in NATS Streaming queue in OpenFaaS.

Here is a Python 3 function structure geared for this setup:

from flask import Flask, request
import json
import os

app = Flask(__name__)

@app.route("/", methods=["POST"])
def handle():
    req = request.get_json()
    
    # Simulate processing logic
    if "order_id" not in req:
        return json.dumps({"error": "Missing order_id"}), 400
        
    # In a real scenario, this connects to a local DB
    # showing the benefit of low latency internal networking
    process_order(req["order_id"])
    
    return json.dumps({"status": "processed", "region": "no-oslo-1"})

def process_order(oid):
    # Mock IO operation
    pass

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

But the magic isn't in the Python code; it's in the stack.yml configuration where we define the constraints. We want to ensure that a "noisy neighbor" function doesn't eat all the CPU on our VPS.

provider:
  name: openfaas
  gateway: http://127.0.0.1:8080

functions:
  order-processor:
    lang: python3-http
    handler: ./order-processor
    image: registry.private.coolvds.net/order-processor:latest
    environment:
      write_debug: true
    limits:
      memory: 128Mi
      cpu: 0.2
    requests:
      memory: 64Mi
      cpu: 0.1
    annotations:
      com.openfaas.scale.min: 1
      com.openfaas.scale.max: 20

Pro Tip: Always set com.openfaas.scale.min: 1 if latency is critical. This keeps one "hot" container ready, eliminating the cold-start penalty entirely. You pay the same for the VPS anyway, so utilize the RAM!

Handling Ingress and Security

Exposing the OpenFaaS gateway directly is reckless. We need Nginx to sit in front, handling SSL termination and rate limiting. This is crucial for ddos protection.

Inside your /etc/nginx/sites-available/faas:

upstream openfaas {
    server 127.0.0.1:8080;
}

server {
    listen 80;
    server_name faas.your-domain.no;

    location / {
        proxy_pass http://openfaas;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        
        # Buffer settings are critical for async workloads
        proxy_buffering on;
        proxy_buffer_size 128k;
        proxy_buffers 4 256k;
        proxy_busy_buffers_size 256k;
    }
}

The Economic Argument: Cloud vs. CoolVDS

Let's look at the numbers. Running a managed Kubernetes cluster plus Function invocations on a major hyperscaler gets expensive fast once you leave the free tier.

Why Local Latency Wins

When your function needs to talk to a database, the physical distance matters. If your VPS is in Oslo, and your users are in Bergen or Trondheim, the round-trip time (RTT) is negligible. If your function is in Stockholm (AWS eu-north-1) and your database is a managed instance in Frankfurt, you are adding 30-40ms of pure physics to every query.

With CoolVDS, you can run the database on the same private network (or even the same host via Docker) as your functions. Communication happens over the loopback interface or a private vSwitch. It is instant.

Final Thoughts

Serverless is a powerful architectural pattern, but it shouldn't cost you your data sovereignty or your budget. By leveraging container orchestration tools available in 2023, you can build a resilient, event-driven system that complies with Norwegian regulations and runs on iron you control.

You don't need a hyperscaler to scale. You need solid architecture and fast disks.

Ready to build? Don't let IO wait states kill your performance. Deploy a high-frequency NVMe instance on CoolVDS today and experience the difference raw power makes.