The "Serverless" Lie: Why Your Architecture Needs Iron, Not Just Code

Let’s clear the air immediately: "Serverless" is a marketing term for "Someone Else's Computer." In 2025, that usually translates to "Someone Else's Expensive, Opaque, High-Latency Computer located in a different legal jurisdiction." For a Norwegian CTO or a DevOps lead managing critical infrastructure, relying entirely on public cloud FaaS (Function as a Service) is often a strategic error. You trade control for convenience, and eventually, you pay the tax—either in monthly invoices that scale poorly or in latency figures that frustrate users in Oslo.

I have spent the last decade debugging distributed systems. I've watched teams migrate to AWS Lambda only to realize their "cost-saving" architecture costs 3x more than a well-tuned cluster of VPS instances once they hit 50 requests per second. The solution isn't to abandon the event-driven pattern; it's to own the infrastructure that runs it.

This guide details how to implement a Private Serverless Architecture using Kubernetes (K3s) and OpenFaaS on high-performance infrastructure. We will focus on the Nordic context, where data sovereignty (GDPR/Schrems II) and latency to NIX (Norwegian Internet Exchange) are critical.

The Architecture: Private FaaS on KVM

The goal is to replicate the developer experience of serverless (deploy code, not servers) without the vendor lock-in. To do this effectively in 2025, we use a lightweight Kubernetes distribution on top of high-frequency compute instances. The stack looks like this:

• Infrastructure: CoolVDS NVMe Instances (KVM virtualization, not container-based).
• Orchestrator: K3s (v1.31+).
• FaaS Framework: OpenFaaS or Knative.
• Ingress: Traefik or NGINX with strict tuning.

Pro Tip: Avoid "noisy neighbor" issues inherent in shared hosting or public cloud FaaS. When a function scales from 0 to 1, you need immediate CPU access. We use CoolVDS because KVM ensures the CPU cycles you pay for are actually yours, preventing the "steal time" lag that plagues container-based VPS providers.

Step 1: The Base Layer & Kernel Tuning

Before installing K8s, the OS must be prepped for high packet throughput. Standard Linux distributions are tuned for general use, not for handling thousands of ephemeral function calls. On your CoolVDS node (running Debian 12 or Ubuntu 24.04), apply these sysctl modifications to handle high connection churn.

# /etc/sysctl.d/99-serverless.conf

# Increase the range of ephemeral ports for high concurrency
net.ipv4.ip_local_port_range = 1024 65535

# Allow reuse of sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1

# Maximize the backlog for incoming bursts (essential for cold starts)
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Increase file descriptors for high density of containers
fs.file-max = 2097152
fs.inotify.max_user_instances = 8192
fs.inotify.max_user_watches = 524288

Apply these with sysctl -p. Without this, your API gateway will choke long before your CPU hits 100%.

Step 2: Deploying the Control Plane

We use K3s because it strips away the bloat of upstream Kubernetes, making it ideal for VDS environments where every megabyte of RAM counts. Initialize the cluster on the master node:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik --flannel-backend=wireguard-native" sh -

Note the --flannel-backend=wireguard-native flag. Security inside the cluster is non-negotiable. Using WireGuard ensures low-overhead encryption between your worker nodes, which is crucial if you are spanning your cluster across multiple zones for redundancy.

Step 3: Implementing OpenFaaS

OpenFaaS remains the standard for private serverless in 2025 due to its simplicity and robust community support. We will deploy it using arkade, the preferred CLI tool installer.

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

# Install OpenFaaS with basic auth
arkade install openfaas \
  --load-balancer 
  --set gateway.replicas=2 \
  --set queueWorker.replicas=2

Once deployed, you have a functional FaaS platform. However, the default configuration is too passive for production. You need to adjust the Timeouts and KeepAlive settings in the Gateway to prevent premature connection drops during heavy processing.

# faas-netes/values.yaml snippet
gateway:
  readTimeout: "65s"
  writeTimeout: "65s"
  upstreamTimeout: "60s"
  replicas: 2
  # Critical for NVMe performance leverage
  resources:
    requests:
      memory: "120Mi"
      cpu: "100m"
    limits:
      memory: "500Mi"
      cpu: "1000m"

Comparison: Public Cloud vs. CoolVDS Implementation

Step 4: The Data Layer & NVMe I/O

Serverless functions are stateless, but your application is not. You need a state store. In 2025, deploying a Redis Cluster or NATS JetStream alongside your functions is the standard pattern for asynchronous processing. This is where hardware matters immensely.

If you run a database or a message queue on standard SSDs (or worse, network-attached block storage with low IOPS limits), your functions will sit idle waiting for I/O. This is the hidden killer of serverless performance.

At CoolVDS, we utilize local NVMe storage with direct PCI express lanes to the CPU. Here is how you verify your disk throughput before deploying your state store:

# Install fio for benchmarking
apt-get install -y fio

# Run a random read/write test simulating DB loads
fio --name=random_rw \
    --ioengine=libaio \
    --rw=randrw \
    --bs=4k \
    --numjobs=4 \
    --size=1G \
    --runtime=60 \
    --group_reporting

You should be looking for IOPS well above 50,000 for random 4k reads. If your current provider gives you 3,000 IOPS, they are bottlenecking your entire architecture.

Legal & Compliance: The Norwegian Context

Since the Schrems II ruling and subsequent tightening of data transfer regulations by Datatilsynet, hosting customer data (PII) on US-owned cloud infrastructure has become a legal minefield. Even if the data center is in Frankfurt or Stockholm, the ownership invokes US extraterritorial jurisdiction.

By hosting your serverless stack on CoolVDS, you ensure that the physical hardware and the legal entity controlling it are within the European Economic Area (EEA), simplifying your GDPR compliance posture significantly. You are not just buying a server; you are buying risk mitigation.

The Verdict

Serverless patterns are powerful. They decouple logic from infrastructure and allow teams to move fast. But abstracting the server does not mean you should ignore it. The best performing "serverless" architectures in 2025 are those running on private, dedicated KVM clusters where the engineer controls the kernel, the network stack, and the hardware resources.

If you are tired of varying latency, opaque billing, and cold starts that kill your conversion rates, it is time to repatriate your functions.

Ready to build? Don't let slow I/O kill your SEO. Deploy a test K3s cluster on a CoolVDS NVMe instance in 55 seconds and see the difference raw power makes.