The "Serverless" Lie We All Bought

We were promised a utopia. "Just write code," they said. "Forget about servers," they said. Three years later, you are staring at an AWS bill that looks like a mortgage payment, debugging 800ms cold starts that are killing your conversion rates, and worrying if the Datatilsynet (Norwegian Data Protection Authority) is going to audit your data transfers to US-east-1.

Serverless as a concept is brilliant. It decouples code from infrastructure. But Serverless as a service (FaaS) from the hyperscalers is often a trap. It trades operational complexity for vendor handcuffs.

If you are a CTO or Lead DevOps in Oslo today, you don't need Amazon's servers to run serverless patterns. You need architecture that handles scale without the latency tax or the legal gray areas of Schrems II. Here is how we build a private, sovereign serverless platform on standard Linux VDS nodes.

The Architecture: Why Bare-Metal Performance Matters

When you run your own FaaS (Function-as-a-Service) platform, the underlying hardware stops being an abstraction. It becomes the bottleneck. Containers need to spin up in milliseconds. This requires two things: raw CPU cycles and blisteringly fast disk I/O.

Most budget VPS providers oversell CPU. If you try to schedule 50 pods on a "shared" vCPU, your functions will hang. This is why for this architecture, I stick to CoolVDS. Their KVM isolation is strict—no CPU stealing—and the local NVMe storage allows Docker images to be pulled and unpacked almost instantly.

The Stack

• Infrastructure: 3x CoolVDS NVMe Instances (Ubuntu 22.04 LTS).
• Orchestrator: K3s (Lightweight Kubernetes).
• FaaS Engine: OpenFaaS.
• Ingress: Traefik (bundled with K3s).

Step 1: The Cluster Foundation

We aren't deploying full K8s; it's overkill for a mid-sized setup. K3s is a certified Kubernetes distribution designed for production workloads with low overhead.

First, initialize your master node on your primary CoolVDS instance. Note the --flannel-backend=host-gw flag. Since CoolVDS offers low-latency private networking between instances, we use host gateway routing for better performance than VXLAN encapsulation.

# On Node 1 (Master)
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --flannel-backend=host-gw --tls-san=YOUR_PUBLIC_IP" sh -

# Extract the token for workers
cat /var/lib/rancher/k3s/server/node-token

Join your worker nodes (the other two VDS instances) to create a high-availability pool.

# On Node 2 and 3
curl -sfL https://get.k3s.io | K3S_URL=https://NODE_1_IP:6443 K3S_TOKEN=MY_TOKEN sh -

Pro Tip: Always configure `vm.max_map_count` in `/etc/sysctl.conf` if you plan to run Elasticsearch or heavy logging stacks alongside your functions. Set it to `262144` to avoid OOM kills later.

Step 2: Deploying OpenFaaS

OpenFaaS is the industry standard for container-native serverless. It’s simple, robust, and works perfectly on K3s. We will use `arkade`, a CLI tool designed to manage Kubernetes apps, to install it.

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

# Deploy OpenFaaS with basic auth enabled
arkade install openfaas \
  --load-balancer 
  --set=faasIdler.dryRun=false

Check your pods. On a CoolVDS instance with NVMe, the `gateway` and `queue-worker` pods should reach `Running` status in under 20 seconds. If you were on standard SATA SSDs, you’d still be waiting for container extraction.

kubectl get pods -n openfaas
# Output should look like:
# NAME                READY   STATUS    RESTARTS   AGE
# gateway-7d8...      1/1     Running   0          35s
# nats-6d5...         1/1     Running   0          35s
# queue-worker...     1/1     Running   0          35s

Step 3: The Cold Start Problem

In public cloud serverless, a "cold start" is when the provider has to boot a microVM for your code. In our private cloud, a cold start is simply the time it takes Kubernetes to schedule a pod.

To mitigate this, we tweak the `autoscaler` profiles. OpenFaaS allows you to keep "warm" replicas.

Create a function definition `stack.yml`:

version: 1.0
provider:
  name: openfaas
  gateway: http://127.0.0.1:8080
functions:
  image-resizer:
    lang: python3
    handler: ./image-resizer
    image: registry.gitlab.com/mycompany/image-resizer:latest
    labels:
      com.openfaas.scale.min: 1  # Keep 1 copy always running
      com.openfaas.scale.max: 20
      com.openfaas.scale.factor: 20
    annotations:
      com.openfaas.health.http.path: /_/health

Keeping `scale.min: 1` ensures zero latency for the first request. The cost? A few megabytes of RAM. On a CoolVDS plan with 8GB or 16GB RAM, this is negligible compared to the cost of lost users waiting for an AWS Lambda to wake up.

Data Sovereignty and The Norwegian Advantage

This is where the business case solidifies. By hosting this stack on CoolVDS servers located in Oslo or nearby European data centers, you bypass the headache of third-country data transfers.

If you process personal data (PII) through a US-owned FaaS provider, you are navigating a legal minefield regarding the CLOUD Act. Hosting it yourself on European infrastructure ensures your data stays within the EEA, satisfying even the strictest interpretation of GDPR.

Performance Benchmark: Latency

The Verdict

Serverless isn't about abandoning servers; it's about mastering them so you can ignore them. By building your own substrate on K3s and OpenFaaS, you gain:

1. Fixed Costs: No surprise bills when a function goes into an infinite loop.
2. Data Control: 100% GDPR compliance.
3. Hardware Access: Need a GPU for inference? Just add a GPU node to your CoolVDS cluster. Try doing that easily on Lambda.

You don't need the cloud giants. You need reliable, fast iron and the Linux command line.

Ready to take back control? Spin up a high-frequency NVMe instance on CoolVDS today and deploy your first function in under 5 minutes.