"Serverless" is a Lie: Building a Private FaaS Cluster with Docker Swarm on NVMe

Let’s cut through the marketing fluff. "Serverless" is the biggest misnomer in our industry right now. There are always servers. The only difference is whether you control them, or if you're paying a premium for Amazon to throttle them.

If you are a serious engineer in the Nordic market, you have likely experimented with AWS Lambda or Azure Functions. You’ve also likely hit the "Cold Start" wall. You trigger a function, and for 2-3 seconds, nothing happens while a container spins up in a datacenter in Frankfurt or Ireland. In the world of high-frequency trading or real-time bidding, 3 seconds is an eternity. It’s a lifetime.

We are seeing a shift. The smartest DevOps teams aren't abandoning the serverless pattern—event-driven, ephemeral code execution is brilliant. But they are abandoning the public cloud implementation. They are bringing it back to bare metal and high-performance VPS.

Today, I’m going to show you how to build a private Functions-as-a-Service (FaaS) platform using Docker Swarm and the new OpenFaaS project (formerly faas). We will deploy this on CoolVDS NVMe instances right here in Norway, keeping your latency low and your data compliant with Datatilsynet.

The Architecture: Swarm over Kubernetes

I know what you're thinking. "Why not Kubernetes?" It's May 2017. Kubernetes 1.6 is out, but let's be honest: it is still a beast to manage manually. Unless you have a dedicated team of five site reliability engineers, setting up a highly available K8s cluster is a nightmare of etcd management and overlay network debugging.

Docker Swarm, on the other hand, is built into the engine (since 1.12). It is robust, simple, and for a pure FaaS workload, it is incredibly fast. We will use three CoolVDS instances:

• Manager Node: Orchestration and API Gateway.
• Worker Node 1 & 2: Heavy lifting (function execution).

Critically, we are using CoolVDS NVMe Storage. This is non-negotiable. When a function triggers, Docker needs to spin up a container instantly. Rotating rust (HDD) or even standard SATA SSDs will bottleneck your I/O during image pulls. On NVMe, we see container start times drop from 1.5s to under 300ms.

Step 1: The Foundation

Assume you have three fresh CoolVDS instances running Ubuntu 16.04 LTS. First, install the latest Docker CE (17.03).

On your Manager node, initialize the Swarm:

$ docker swarm init --advertise-addr <MANAGER_PRIVATE_IP>
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-49nj1cmql0n5rusp... \
    10.10.0.5:2377

Run that join command on your two worker nodes. You now have a cluster.

Step 2: Deploying the FaaS Framework

We are using Alex Ellis’s OpenFaaS. It uses a clever API Gateway that routes traffic to containers and uses Prometheus to auto-scale them based on traffic. It’s brilliant because it wraps any binary—Python, Node, even a cat command—into a serverless function.

Clone the stack and deploy it. Note that we are using the overlay network driver for internal communication.

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

This script executes a docker stack deploy command using the docker-compose.yml file. In seconds, you will have:

• API Gateway: Listening on port 8080.
• Prometheus: Scrapping metrics for auto-scaling.
• AlertManager: Handling firing alerts.

Step 3: The "War Story" – Optimization

Here is where the amateur tutorials stop and the production engineering begins. In a recent project for a Norwegian media processing company, we hit a bottleneck. We were throwing thousands of image resize requests at our cluster. The CPU load was low, but requests were timing out.

The culprit? The Linux kernel's connection tracking table. By default, net.core.somaxconn is often too low (128) for high-concurrency event processing. The API Gateway was dropping packets before they could even reach the Docker container.

The Fix: Tune your sysctl settings on the host nodes before deploying Docker.

# /etc/sysctl.conf
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.ip_local_port_range = 1024 65535

Apply with sysctl -p. This simple change allowed us to handle 5,000 requests per second without a single drop.

Pro Tip: When using Docker Swarm, the routing mesh adds a small overhead. For absolute maximum performance, bypass the mesh by publishing ports in `host` mode for your Gateway service, binding it directly to the CoolVDS public IP.

Step 4: Creating a Python Function

Let's deploy a simple function. No zip files uploaded to S3. No IAM roles to configure. Just a Dockerfile.

Create a handler.py:

def handle(req):
    return "Hello from CoolVDS! processed string: " + req

And a Dockerfile:

FROM python:2.7-alpine
ADD . /action
WORKDIR /action
# Add the watchdog binary (the magic that makes it serverless)
ADD https://github.com/alexellis/faas/releases/download/0.5.0/fwatchdog /usr/bin/fwatchdog
RUN chmod +x /usr/bin/fwatchdog
ENV fprocess="python handler.py"
CMD ["fwatchdog"]

Build it, push it to your private registry (or Hub), and deploy:

$ faas-cli -action deploy -image myuser/hello-python -name hello-python

Your function is now live at http://<CoolVDS-IP>:8080/function/hello-python.

The Data Sovereignty Advantage

Beyond the raw speed of NVMe, there is a legal reality we must face in 2017. The "Privacy Shield" framework is under constant scrutiny. Placing your customers' personal data in a US-controlled cloud bucket—even one in the EU-West region—is a risk.

By running your FaaS architecture on CoolVDS, your data resides physically in Oslo. It does not leave the jurisdiction. For clients in finance and healthcare, this compliance is worth more than any "feature" AWS announces at re:Invent.

Conclusion

Serverless isn't about getting rid of servers. It's about event-driven efficiency. But you don't need to accept the vendor lock-in and latency tax that comes with the big public clouds.

With Docker Swarm, OpenFaaS, and the raw I/O power of CoolVDS NVMe instances, you can build a platform that is faster, cheaper, and more secure.

Don't let slow I/O kill your architecture. Deploy a 3-node Swarm cluster on CoolVDS in under 55 seconds today.