Serverless Patterns on Independent Infrastructure: Avoiding the Public Cloud Trap

Let’s cut through the marketing noise. "Serverless" is often just a polite way of saying "someone else's computer, with an unpredictable billing cycle." In 2019, every CTO I speak with in Oslo is obsessed with Lambda or Google Cloud Functions. They love the idea of scaling to zero. But what happens when you scale to a million? You get a bill that looks like a mortgage payment, and you realize your latency is at the mercy of a "noisy neighbor" in a massive data center in Frankfurt.

I have spent the last decade optimizing high-load systems across the Nordics. The reality is that for predictable, high-performance workloads, the public cloud serverless model is flawed. It introduces cold starts—that 200ms to 2-second delay while the provider spins up a container—which is unacceptable for real-time applications.

There is a better architecture pattern: Private FaaS (Functions as a Service). By deploying an open-source serverless framework on top of high-performance KVM VPS instances, you regain control over the hardware, the network, and the bill. You get the developer velocity of serverless with the raw I/O performance of bare metal.

The Architecture: Private FaaS on CoolVDS

We are going to implement a serverless stack using OpenFaaS running on Docker Swarm. Why Swarm in 2019? Because for teams smaller than 50, Kubernetes is often over-engineering that eats RAM for breakfast. Swarm is lightweight, built into the Docker engine, and runs incredibly fast on CoolVDS instances.

This setup leverages the NVMe storage standard on CoolVDS to eliminate the I/O bottleneck during container image pulls—the primary cause of slow function scaling.

1. Infrastructure Provisioning

You need a cluster. Don't run this on a single node if you want reliability. We will use three CoolVDS instances within the Norway zone to ensure low latency for local users and compliance with data residency norms.

• Manager Node: 4 vCPU, 8GB RAM (The brain)
• Worker Node 1: 2 vCPU, 4GB RAM (Compute)
• Worker Node 2: 2 vCPU, 4GB RAM (Compute)

Initialize the Swarm on the manager:

$ docker swarm init --advertise-addr $(hostname -i)
Swarm initialized: current node (dxn1...) is now a manager.

To add a worker to this swarm, run the following command:
    docker swarm join --token SWMTKN-1-49nj1cmql0n5rus... 192.168.1.10:2377

Run the join command on your CoolVDS worker nodes. Once they are linked, you have a unified compute fabric.

2. Deploying the Serverless Framework

OpenFaaS is the pragmatic choice here. It’s container-native and doesn't force you into a proprietary language run-time.

$ git clone https://github.com/openfaas/faas
$ cd faas && ./deploy_stack.sh

Attempting to create credentials for gateway..
[Credentials created]
Deploying stack...
Updating service func_gateway (id: ...)
Updating service func_prometheus (id: ...)
Updating service func_alertmanager (id: ...)

This script deploys the API Gateway, Prometheus for metrics (which drives the auto-scaling), and NATS for asynchronous queueing.

Pro Tip: On standard HDD VPS providers, the `deploy_stack.sh` step can time out because etcd and Prometheus struggle with disk write latency. On CoolVDS NVMe drives, this completes in under 12 seconds. Storage speed matters more than CPU frequency in microservices.

3. Tuning the Network Layer

The default network settings in Linux are conservative, designed for the dial-up era. For a serverless environment handling thousands of ephemeral connections, we need to tune the `sysctl.conf` on all nodes.

Open `/etc/sysctl.conf` and apply these settings to prevent port exhaustion and reduce latency:

# Allow more connections to queue up
net.core.somaxconn = 4096

# Reuse closed sockets faster (TIME_WAIT state)
net.ipv4.tcp_tw_reuse = 1

# Increase range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65000

# Maximize the backlog for incoming packets
net.core.netdev_max_backlog = 2000

Apply with `sysctl -p`. Without these, your API Gateway will choke under load long before your CPU hits 100%.

The Function Pattern: Image Processing

Let's look at a real-world scenario: resizing images for a Norwegian e-commerce site. In a public cloud, you upload to S3, trigger a Lambda, and pay for every millisecond. Here, we stream the data directly to our function.

Create a Python function:

$ faas-cli new --lang python3 image-resizer

Edit `image-resizer/handler.py`. Note that we are importing `Pillow` (PIL fork) for processing. Since this runs in a container, we control the dependencies completely.

from PIL import Image
import io

def handle(req):
    try:
        # Read image bytes from request
        image_data = io.BytesIO(req)
        img = Image.open(image_data)
        
        # Resize operation
        img = img.resize((128, 128), Image.ANTIALIAS)
        
        # Save to buffer
        out_buffer = io.BytesIO()
        img.save(out_buffer, format="JPEG", quality=85)
        
        return out_buffer.getvalue()
    except Exception as e:
        return str(e)

Build and deploy to your local CoolVDS registry:

$ faas-cli build -f image-resizer.yml
$ faas-cli deploy -f image-resizer.yml

Performance: The NVMe Difference

When this function is invoked for the first time on a new node, Docker must pull the image. This is the bottleneck. On a legacy SAN or SATA SSD, a 200MB Python image takes 3-5 seconds to pull and extract. That is 5 seconds of latency for your user.

On CoolVDS, our benchmarks show NVMe read speeds exceeding 2000 MB/s. The image pull and extraction happen in sub-second timeframes. This allows you to set aggressive auto-scaling rules (scaling down to 1 replica) without fearing the "cold start" penalty that plagues AWS Lambda.

Data Sovereignty and GDPR

We cannot ignore the legal reality in Europe. Since May 2018, GDPR has changed how we architect systems. Moving data to US-controlled regions can be legally complex. By hosting your serverless infrastructure on CoolVDS in our Oslo or European data centers, you ensure that the data processing pipeline remains within the jurisdiction you control. You are not relying on a murky "Region" definition; you know exactly which physical rack your data resides on.

Summary

Public cloud serverless is a rental model; Private FaaS is an ownership model. For predictable workloads, heavy data processing, or strict compliance requirements, the private model wins on TCO and performance.

Don't let your architecture be dictated by a billing department's fear of servers. Take control of the stack.

Ready to build your own FaaS cluster? Deploy a high-performance, NVMe-backed instance on CoolVDS today and experience the difference raw I/O makes to your container latency.