I did something kinda silly when I ran for president of my ACM chapter. I promised free web hosting for all members. Why is this silly? We are quite budget constrained due to university spending policy. So how am I going get myself out of this pickle? I’m going to build a homelab capable of running member apps without stepping on my own homelab’s toes.
Step 1) Picking Technology
What is a cloud if not a set of technologies built on an isolation primitive. Early internet ‘clouds’ were built on bare metal and provisioning of individual servers. The next generation of clouds were virtual machines, then came containers which really brought the cloud mainstream. Finally we’re now seeing the use of microVMs and custom language runtimes which power the rise of the serverless cloud. Of these various technologies I’ve had the most experience with containers. Containers are have powered my personal homelab for the past 6 years (Yes I know I was kinda late to the container bandwagon, but I was in middle school, chill). Anyway, because I don’t like to run software that I don’t understand or can’t easily debug I’ve opted to avoid a common orchestration on top of containers, Kubernetes(k8s). Chances are if I dedicated a whole summer to learning k8s I could solve that issue, but I’d rather work my way up to k8s by building things that approximate parts of it. Plus I am not running at a large scale where k8s makes sense or is let alone designed for. There is only so much redundancy I build, before it becomes a side business.
So what will I be using as my orchestration layer on top of containers? I’m building it! To quote Richard Feynman, “What I cannot create, I don’t understand.” So I’m building that. My initial gut feeling told me to use Golang, the same language that Kubernetes is built in and is the language I’m most comfortable with currently. However, due to my most recent class in Programming Language Fundamentals I’ve been very interested in using a functional language to eliminate whole classes of state errors. The language I’ve been fiddling with for the last few years, Gleam seems perfect for this sort of problem. Because it runs on the Erlang Runtime System (ERTS), it provides many of the primitives needed for a distributed reactive system such as concurrency, clustering, and fault-tolerance.
One last piece of technology we need is a reverse proxy that can manage TLS for us. I will again be picking something that I’ve battle tested and have come to trust, Caddy Server. It’s extensible, and crucially, it is configurable through an API at runtime, something I’ve been using to make my homelab feel more like a cloud. Point the domain to the IP, tell Caddy where the service is, and we’re live!
Step 2) Experimentation
I have never combined these technologies in this fashion before so the first few weeks will essentially be me trying to learn how the ERTS does clusters. Then seeing what sorts of side effects I can apply to individual nodes, i.e. starting and stopping containers. Then comes ‘customer’ / member application network isolation. After which I’ve essentially built the system.
Step 3) Making It Approachable
This is both one of my favorite parts and one that I believe is the most important. If the ACM chapter’s ‘cloud’ is not approachable then nobody will use it and I will have built something for just me. While I wouldn’t be too bummed out by that, the impact wouldn’t be the same. The initial goal is to make it so more members could showcase and share their projects.
But what does a cloud need to be approachable? This is essentially the question I’ve been asking a bunch of ACM members to see what their definitions were. Here are a few of the answers:
- One click deploy through GitHub
- Simple to use web interface
- Simple to use command line tool
That work will come last and will likely be a collaboration with others to ensure I’m not building in my assumptions of how the system will work.
Oh and did I mention we’re calling this dotACM, both as a nod to dotCloud,
original makers of Docker, and because we will be making subdomains available to
members, e.g. <project>.<username>.acmosu.org