Serverless Patterns Without the Cloud Tax: A Norwegian CTO’s Guide to FaaS on Infrastructure

Let’s be honest about the state of serverless in 2023. The promise was elegant: code, deploy, and pay only for what you use. The reality, however, often involves a terrifying bill at the end of the month, cold starts that make Java applications unusable, and—for those of us operating in Norway—a legal minefield regarding data sovereignty.

Schrems II killed the idea that we can blindly trust US-based hyperscalers with sensitive Norwegian user data. If you are building for the public sector, healthcare, or finance in Oslo, sending data to a lambda function in eu-central-1 (Frankfurt) still raises eyebrows at Datatilsynet.

As a CTO, I value Total Cost of Ownership (TCO) and compliance over hype. The most pragmatic architecture pattern right now isn't avoiding servers; it's abstracting them on your own terms. We call this Self-Hosted FaaS (Function as a Service).

The Architecture: Why Kubernetes is the New Serverless Platform

You don't need AWS Lambda to do serverless. You need an event-driven control plane. By September 2023, the ecosystem around Kubernetes has matured to the point where running your own FaaS platform is not only feasible, it is often more performant than public cloud offerings.

The pattern is simple:

1. Infrastructure Layer: High-performance Linux VPS (Virtual Private Servers) with low latency.
2. Orchestration: Lightweight Kubernetes (K3s or MicroK8s).
3. FaaS Framework: OpenFaaS or Knative.

This stack gives you the scaling behavior of serverless with the cost predictability of a fixed monthly VPS bill.

Phase 1: The Iron Matter

Serverless relies heavily on rapid container creation. If your underlying disk I/O is slow, your cold starts will be sluggish regardless of how optimized your code is. This is where hardware selection becomes critical. We utilize CoolVDS instances because they provide dedicated NVMe storage paths rather than shared noisy-neighbor spinning disks. When pulling a 500MB container image to start a function, NVMe is the difference between a 200ms start and a 5-second timeout.

Pro Tip: Always place your ingress nodes geographically close to your users. For a Norwegian user base, a CoolVDS instance in a local datacenter will consistently beat a hyperscaler region in Stockholm or Frankfurt on Time-to-First-Byte (TTFB).

Phase 2: The Abstraction Layer

We avoid full-blown K8s for smaller clusters. K3s is production-ready and strips out the bloat. Here is a battle-tested initialization for a controller node on Ubuntu 22.04 LTS.

First, we optimize the kernel for high-throughput networking, essential for the myriad of short-lived connections typical in serverless architectures.

# /etc/sysctl.d/99-serverless-tuning.confnet.ipv4.ip_local_port_range = 1024 65535net.ipv4.tcp_tw_reuse = 1net.core.somaxconn = 65535net.ipv4.tcp_max_syn_backlog = 4096fs.file-max = 2097152

Apply these with sysctl -p. If you skip this, your API Gateway will choke under load long before your CPU maxes out.

Next, install K3s without Traefik (we will use a custom ingress controller for better FaaS routing):

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

Phase 3: Deploying OpenFaaS

OpenFaaS is the pragmatic choice for 2023. It’s lighter than Knative and easier for teams transitioning from monolithic backgrounds. We use Helm to deploy it directly onto our CoolVDS cluster.

# Create namespaces for OpenFaaS core and functionskubectl apply -f https://raw.githubusercontent.com/openfaas/faas-netes/master/namespaces.yml# Add the OpenFaaS helm charthelm repo add openfaas https://openfaas.github.io/faas-netes/helm repo update# Generate a random passwordecho $(head -c 12 /dev/urandom | shasum| cut -d' ' -f1) > password.txtkubectl -n openfaas create secret generic basic-auth \--from-literal=basic-auth-user=admin \--from-file=basic-auth-password=password.txt# Deploy OpenFaaShelm upgrade openfaas --install openfaas/openfaas \    --namespace openfaas  \    --set functionNamespace=openfaas-fn \    --set generateBasicAuth=true \    --set serviceType=LoadBalancer

At this stage, you have a functional serverless platform running on a predictable budget. Your data never leaves the server you control.

The "Scale-to-Zero" Myth vs. Reality

Public cloud marketing loves "scale-to-zero" (paying nothing when idle). In a business context, scale-to-zero is often a bug, not a feature. The latency penalty of waking up a function (Cold Start) hurts user experience.

On a dedicated VPS, you have already paid for the CPU cycles. "Wasting" them on an idle process is better than making a user wait. With CoolVDS, we configure OpenFaaS to keep a minimum replica count of 1 for critical functions.

version: 1.0provider:  name: openfaas  gateway: http://127.0.0.1:8080functions:  payment-processor:    lang: node18    handler: ./payment-processor    image: registry.coolvds.internal/payment:latest    labels:      com.openfaas.scale.min: "1"      com.openfaas.scale.max: "20"    annotations:      com.openfaas.health.http.path: "/health"

Note the com.openfaas.scale.min: "1". This ensures immediate response times. We reserve scale-to-zero only for asynchronous background tasks, like PDF generation or image resizing, where latency is less critical.

Data Persistence and State

Serverless functions are stateless, but your application is not. A common mistake is connecting 500 lambda instances directly to a MySQL database, exhausting the connection pool immediately.

You must use a connection pooler or a proxy. If you are hosting a MySQL or PostgreSQL instance on the same CoolVDS network, optimize the `innodb_buffer_pool_size` to match the RAM availability.

Security & Compliance (The Norwegian Context)

Running this architecture on CoolVDS satisfies the strict requirements of GDPR. You know exactly where the physical drive is located. There is no hidden replication to a US east coast server for "redundancy."

Furthermore, by utilizing private networking between your compute nodes and your database nodes (a standard feature in our setup), you eliminate public internet exposure for your sensitive data layers.

Actionable Advice

If you are currently paying substantial fees for API Gateways and NAT Gateways in the public cloud, calculate your request volume. If you are processing over 5 million requests a month, the crossover point has likely passed.

Start small. Spin up a CoolVDS High-Frequency Compute instance. Install K3s. Deploy a simple webhook handler. Measure the latency from your office in Oslo. You will likely find that raw iron beats virtualized abstractions every time.

Don't let architectural trends dictate your budget. Control your infrastructure, control your costs.