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