How I built my first SaaS with OpenFaaS

Felipe Cruz

Mar 13, 2021 — 3 min read

My name is Felipe Cruz and I'm the founder of Upblogr, a managed hosting service for Ghost blogs & newsletters. You don't have to be a developer to set up your blog - we take care of the full installation and maintenance for you.

Most of the hosting services for Ghost blogs that I know of involves that someone manually carries out several installation steps - from provisioning the underlying infrastructure to the running software. Having a person doing this job is inevitably not immediate which takes within 24 hours in the best case.

The vision and principal feature of Upblogr is to provide anyone with a Ghost blog up and running in literally 5 minutes 🚀

This is a huge and interesting challenge for a solo-founder with a full-time job like myself. I need to make sure my SaaS will scale and can run without my supervision: I need to find a way to remove as many manual installation steps as possible, automating the provisioning of the infrastructure where the Ghost blog will be running and carry out the full installation afterwards, resulting in a ready-to-go blog.

Why OpenFaaS?

You may be wondering why I chose OpenFaaS instead of other product such as Amazon Lambda or Azure Functions. Well, I have been following Alex Ellis and the OpenFaaS community for many years already and I really love the level of commitment and support they provide in the Slack community.

For me, choosing a technology that solves my problem is as important as it is to know there are great people behind it. Furthermore, I didn't want to be tied to any specific cloud vendor at all, so OpenFaaS was a great option for me.

So, how Upblogr manages to spin your Ghost site in 5 min?

Serverless is fascinating, and OpenFaaS takes it to the next level by deploying your Serverless functions in your Kubernetes cluster with faas-netes.

provisioner-fn: This function is responsible for provisioning the infrastructure and the Ghost installation. It is based on a custom Dockerfile from the OpenFaaS store.

The Dockerfile below is a simplified version of the real one.

FROM ghcr.io/openfaas/classic-watchdog:0.1.5 as watchdog

FROM alpine:3.12

RUN mkdir -p /home/app

COPY --from=watchdog /fwatchdog /usr/bin/fwatchdog
RUN chmod +x /usr/bin/fwatchdog

# Add non root user
RUN addgroup -S app && adduser app -S -G app
RUN chown app /home/app

ENV TERRAFORM_VERSION=0.14.7

# Download Terraform
RUN wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip

# Copy Terraform files and provision script
COPY *.tf .
COPY provision.sh .

USER app

ENV fprocess="xargs /bin/bash provision.sh"

EXPOSE 8080

HEALTHCHECK --interval=3s CMD [ -e /tmp/.lock ] || exit 1

CMD ["fwatchdog"]

Notice the Dockerfile takes a bash script that will be responsible for doing the provisioning:

ENV fprocess="xargs /bin/bash provision.sh"

The script uses Terraform to provision an Ubuntu VM with a 20GB SSD disk in Hetzner Cloud.

Then, in that provisioned VM, it gets immediately installed K3s to deploy the Kubernetes manifests to install Ghost and MySQL and finally, request a certificate with Let's Encrypt under the *.upblogr.com domain.

For "long" running functions that can take up a few minutes, you can increase the timeouts:

 environment:
 write_timeout: 7m # Maximum time to write HTTP response
 read_timeout: 7m # Maximum time to read HTTP request
 exec_timeout: 7m
 upstream_timeout: 6m # Maximum duration of upstream function call - should be slightly less than read_timeout and write_timeout

Just right after a user completes successfully the checkout process, the payment processing platform ends up invoking the provisioner function via an HTTP request.