Escaping the Vendor Trap: Building a High-Performance Serverless Architecture with OpenFaaS on KVM

Let's get one thing straight immediately: "Serverless" is the most disingenuous marketing term of the last decade. There are always servers. The only variable is whether you control them, or if you're renting execution time by the millisecond from a giant conglomerate that reserves the right to throttle your CPU when your code actually needs it.

For many engineering teams in Oslo and Bergen, the allure of AWS Lambda or Google Cloud Functions is strong. It promises zero administration. But as we move through 2019, the cracks in that promise are widening. Cold starts on Java or .NET functions can hit 3-5 seconds. Debugging distributed traces across proprietary black boxes is a nightmare. And then there's the bill. At scale, "pay per invocation" often costs significantly more than provisioned IOPS on robust VPS infrastructure.

If you are serious about performance and data sovereignty (a massive concern here in Norway under GDPR), the superior pattern isn't abandoning servers—it's abstracting them on your own terms. We are going to look at deploying OpenFaaS on top of Docker Swarm running on high-performance KVM instances. This gives you the "serverless" developer experience without the vendor lock-in or the latency penalty of routing traffic through Frankfurt.

The Architecture: Why KVM Matters for Functions

When you trigger a function, a container spins up, executes code, and dies (or pauses). This churn is I/O intensive. If your underlying infrastructure is based on shared OpenVZ containers or oversold magnetic storage, your functions will hang. The container runtime needs to pull layers and write logs instantly.

This is where the "CoolVDS Factor" becomes architectural, not just promotional. We utilize KVM (Kernel-based Virtual Machine) virtualization with NVMe storage. Unlike container-based virtualization, KVM provides a dedicated kernel and reserved resources. When you throw a sudden spike of 1,000 requests at your OpenFaaS gateway, the underlying NVMe drive handles the I/O storm without the "noisy neighbor" effect common in budget hosting.

Phase 1: The Foundation

We will use Docker Swarm for this setup because, frankly, Kubernetes is still overkill for many teams in 2019 unless you have a dedicated ops person. Swarm is built into Docker and works flawlessly for managing function replicas.

First, ensure your Docker engine is updated (18.09+ is recommended). On your CoolVDS instance running Ubuntu 18.04 LTS:

# Initialize Swarm on the manager node
docker swarm init --advertise-addr $(hostname -i)

# Install the OpenFaaS CLI
curl -sL https://cli.openfaas.com | sudo sh

# Clone the OpenFaaS logic
git clone https://github.com/openfaas/faas
cd faas && ./deploy_stack.sh

This script deploys the core components: the Gateway, NATS (for async messaging), Prometheus (metrics), and the AlertManager. Once deployed, you have a functioning serverless platform running inside Norway, likely pinging under 10ms to your local users.

Phase 2: Defining the Function Stack

Managing functions requires a YAML definition. This is your infrastructure-as-code. Let's create a Python 3 function that handles image resizing—a classic heavy CPU task that costs a fortune on public clouds due to execution time billing.

faas-cli new --lang python3 image-resizer --prefix your-docker-org

This generates a `stack.yml`. We need to tune this for production. In 2019, standard timeouts are often too short for heavy processing. We need to override the environment variables.

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

functions:
  image-resizer:
    lang: python3
    handler: ./image-resizer
    image: your-docker-org/image-resizer:latest
    environment:
      write_debug: true
      read_timeout: 60  # Extend execution window
      write_timeout: 60
    labels:
      com.openfaas.scale.min: 2    # Always keep 2 warm containers (No cold starts!)
      com.openfaas.scale.max: 15   # Cap auto-scaling to prevent resource exhaustion

Note the `com.openfaas.scale.min: 2` label. This is the killer feature. Public cloud providers charge you extra for "provisioned concurrency" to avoid cold starts. On your own VPS, it costs you nothing but a few megabytes of RAM to keep these hot and ready.

Phase 3: Tuning the Gateway (Nginx)

The OpenFaaS gateway sits behind Nginx (or acts as a reverse proxy). A common issue we see with clients migrating from shared hosting is 504 Gateway Timeouts. This isn't the code failing; it's the proxy giving up.

If you are running a custom Nginx ingress in front of your function cluster, you must align the timeouts. Here is a snippet for your `nginx.conf` optimization block:

server {
    listen 80;
    server_name functions.yourdomain.no;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        
        # Critical for long-running functions (PDF generation, transcoding)
        proxy_read_timeout 300s;
        proxy_connect_timeout 300s;
        proxy_send_timeout 300s;
        
        # buffer optimization for heavy payloads
        client_max_body_size 50M;
        client_body_buffer_size 128k;
    }
}

Pro Tip: Monitor your `iowait` metrics using `sar -d 1 5` while load testing. If you see iowait spike above 5-10% during function scaling, your storage is the bottleneck. This is why we equip CoolVDS nodes with enterprise NVMe. Standard SSDs often choke on concurrent container extraction.

The Data Sovereignty Advantage

We cannot ignore the legal landscape. With GDPR in full effect since last year, Norwegian businesses are under scrutiny. When you use AWS Lambda, you are often subject to the US CLOUD Act, regardless of where the data center is located. By hosting OpenFaaS on CoolVDS, your data remains on hardware physically located in secure data centers, governed by Norwegian law and the oversight of Datatilsynet.

Performance: A Quick Benchmark

We ran a simple `ab` (Apache Benchmark) test against a "Hello World" Python function. One setup was on a standard US-East Lambda function (accessed from Oslo), the other on a CoolVDS NVMe instance in Europe.

Conclusion

Serverless is a powerful architectural pattern, but it shouldn't mean surrendering control of your infrastructure. By combining the orchestration of OpenFaaS with the raw, dedicated power of KVM and NVMe storage, you build a platform that is faster, cheaper at scale, and legally compliant.

Don't let latency kill your application's user experience. Spin up a high-performance CoolVDS instance today, deploy Docker Swarm, and take back control of your functions.