The "Serverless" Lie We Tell Ourselves

It has been over a year since the Schrems II ruling shattered the illusion of the Privacy Shield, yet I still see CTOs in Oslo signing off on architectures that pipe sensitive Norwegian user data directly into US-owned managed functions. We treat "Serverless" as a magic wand for scalability, ignoring that it is primarily a billing model designed to maximize vendor lock-in.

As a technical leader, your job isn't just to chase the latest trend. It's to ensure your infrastructure is legal, performant, and predictable. When you build entirely on AWS Lambda or Azure Functions, you are renting logic execution at a premium while losing control over the underlying metal. For a startup in Silicon Valley, that's fine. For a Norwegian enterprise dealing with Datatilsynet and strict data residency requirements, it is a liability.

There is a better pattern. It involves decoupling the Developer Experience (DX) of serverless from the Infrastructure Restrictions of the public cloud. By running a Function-as-a-Service (FaaS) layer on top of high-performance, local Infrastructure-as-a-Service (IaaS), we get the best of both worlds: code-centric deployment and total data sovereignty.

The Architecture: FaaS on Bare-Metal Performance

The pattern we are seeing gain traction among pragmatists in 2021 is the "Bring Your Own Serverless" approach. Instead of relying on opaque cloud providers, we deploy a lightweight Kubernetes distribution (like K3s) on top of a robust Virtual Dedicated Server (VDS), and run OpenFaaS or Knative on top.

Why do this? Latency and IOPS.

Public cloud functions suffer from "cold starts." When a function hasn't run in a while, the provider has to spin up a micro-container, load your runtime, and execute. On a standard public cloud, you have zero control over the disk speed underlying that container. If you are on a CoolVDS instance, you are running on local NVMe storage. The I/O throughput difference is massive, effectively killing cold start latency.

Step 1: The Foundation

For this architecture, we don't need a massive cluster. A single vertical slice of a high-performance server often outperforms a distributed mesh of cheap instances due to network overhead. We start with a CoolVDS instance running Ubuntu 20.04 LTS.

Pro Tip: When selecting your VPS specs, prioritize RAM over CPU cores for FaaS. Each function container has a memory overhead. A 4 vCPU / 8GB RAM setup is the sweet spot for a production-grade OpenFaaS gateway handling moderate traffic. Ensure `swappiness` is set to 1 or 0 in `/etc/sysctl.conf` to prevent latency spikes from disk paging.

Step 2: The Orchestrator

We avoid full-blown Kubernetes (K8s) for single-node or small-cluster deployments. It's too heavy. K3s is a certified Kubernetes distribution built for IoT and Edge computing, but it is perfect for VDS environments because it strips out the cloud-provider bloat.

Here is the automated install for K3s, disabling the default Traefik ingress (we will configure our own ingress controller later for finer control):

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

# Verify the node is ready (takes about 30 seconds on NVMe)
sudo k3s kubectl get node

Step 3: The Serverless Layer (OpenFaaS)

OpenFaaS is currently the industry standard for self-hosted serverless. It's container-native, meaning any Docker image can be a function. This eliminates the "Lambda limits" on libraries or binary sizes.

We use `arkade`, a tool by Alex Ellis, to manage the charts. It simplifies the complexity of Helm.

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

# Deploy OpenFaaS with basic auth enabled
arkade install openfaas --load-balancer

# Check the rollout status
kubectl rollout status -n openfaas deploy/gateway

Handling Data Persistence and Latency

One of the biggest lies in serverless is that "state doesn't matter." It always matters. Your functions need to talk to a database. If your function is in a cloud region in Stockholm (or worse, Ireland) and your database is in Oslo, you are adding 15-40ms of round-trip time (RTT) to every single query.

By hosting your FaaS layer on CoolVDS in our Norwegian datacenter, your logic sits on the same network backbone as your database. For local Norwegian traffic, the latency from the NIX (Norwegian Internet Exchange) to our racks is negligible.

However, performance tuning the database is critical. Since we are in control of the VDS, we can tune the kernel and database config specifically for the bursty nature of serverless connections. Here is a snippet for MySQL 8.0 optimization on a node with 8GB RAM, ensuring we don't OOM (Out of Memory) when 100 functions hit the DB simultaneously:

[mysqld]
# /etc/mysql/my.cnf

# 70% of RAM for InnoDB buffer pool is standard, 
# but with K3s running, dial it back to 50%
innodb_buffer_pool_size = 4G

# Critical for high connection churn from FaaS
max_connections = 500
thread_cache_size = 50

# Ensure durability but allow slight buffer for write speed
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 16M

The Compliance Advantage (Schrems II)

The elephant in the room is GDPR. Following the Schrems II verdict in 2020, relying on Standard Contractual Clauses (SCCs) to justify data transfers to US-owned cloud providers is risky. Legal teams are scrambling.

When you deploy OpenFaaS on CoolVDS:

1. Data Residency: The disk is in Norway. The RAM is in Norway. The backup is in Norway.
2. Legal Entity: You are contracting with a Norwegian entity, reducing exposure to the US Cloud Act.
3. Encryption: You control the keys. Unlike managed cloud KMS where the provider technically holds the master key, here you can implement LUKS encryption on the partition level.

Deploying a Function

The beauty of this setup is that your developers don't need to know about the infrastructure. They just use the CLI. Let's deploy a simple Python function that processes a GDPR deletion request.

# Pull the templates
faas-cli template store list
faas-cli new --lang python3 gdpr-delete

# The handler code (handler.py)
# def handle(req):
#     user_id = req
#     # Logic to purge user from local DB
#     return "User {} purged from Oslo node.".format(user_id)

# Build and deploy
faas-cli up -f gdpr-delete.yml

Cost Analysis: Cloud vs. CoolVDS

Let's look at the TCO. With AWS Lambda, you pay per 100ms. It sounds cheap until you have a function that polls an API or processes image uploads. A single runaway loop can cost thousands. Furthermore, you pay for NAT Gateways ($0.045/hr + data processing) just to let your functions talk to the internet securely.

Conclusion

Serverless is a powerful architectural pattern, but it shouldn't come at the cost of your legal compliance or your budget predictability. By moving the abstraction layer to your own infrastructure, you gain the agility of FaaS without the handcuffs.

We built CoolVDS to provide exactly this kind of foundational strength—raw KVM virtualization backed by enterprise NVMe storage, connected directly to the Nordic backbone. It is the blank canvas your DevOps team needs to build compliant, high-speed platforms.

Ready to own your architecture? Deploy a K3s-ready NVMe instance on CoolVDS today and bring your data home.