The Townhouse in the Middle
A few days ago, I left you with a bit of a cliffhanger. But the post resonated well with you – so, I am back, sharing what's been going on in my head in the last few days.
As a quick recap: Magic Pages is running on Kubernetes. And it is great. It has allowed me to quickly scale from 100 Ghost sites to over 600 Ghost sites within a year, mostly automated. But in the last few months, completely normal problems of growth popped up left, right, and center. Nothing that impacted customers directly – rather me and Magic Pages' profitability.
So, long story short: we explored "What if Kubernetes is not the answer?".
Jannis Fedoruk-Betschki
And today I want to continue there. Let's take another step back and just think about the principles of web hosting, long before container orchestration became THE WAY to do things. How did people host websites 15 years ago, when things really started to boom
Even though I am pretty young (turning 30 this year), I do remember these days. I remember convincing my dad to buy my first shared web hosting plan. My first domain. And then, at some point, my first Virtual Server.
Back then, I played around with Wordpress. Trying to install web hosting panels (Plesk, ISPConfig, etc.), to run a few sites. And hey, it worked!
See, at its core, hosting a website means giving it a small, isolated home on a server. At Magic Pages, I use containers for this. But... a container is just an abstraction of an operating system and some hardware resources.
The "old-school" way was to use a Virtual Machine (VM). And you know what? That model is still the backbone of the internet. The big Wordpress hosts? They are masters of virtualization, spinning up these environments at a scale that's hard to imagine.
It's a proven and battle-tested model.
So, I started a little thought experiment: What if I adopted this for Magic Pages? One VPS per Ghost site. Simple, clean, and isolated. I could use Terraform to create them and Ansible to configure them. It felt solid. Dependable. Almost...easy.
This thought sent me down a research rabbit hole, and I landed on a tool I'd previously overlooked: Proxmox. I initially looked at it for its VM capabilities, but then something else caught my eye. It also supports Linux Containers!
My first thought was, "Wait, isn't that just another name for a container, like Docker?" As it turns out, not quite. The difference, I learned, is what changes everything.
It helped me to think about virtualisation as a spectrum. On one end, you have the traditional Virtual Machine. A VM is like a complete, separate house on a plot of land. It has its own foundation, its own plumbing, its own electrical system. It's incredibly robust and isolated, but also resource-heavy, just like a real house.
On the complete other end of the spectrum is Docker. Docker isn't about creating a whole house. It's more like a single, purpose-built, furnished room. That room contains just one application and its direct dependencies. It's incredibly lightweight, portable, and perfect for applications.
The middle-ground is a Linux Container, or LXC. If a VM is a standalone house and a Docker container is a furnished room, an LXC container is basically like a townhouse. Each unit is a complete, independent home with its own rooms and layout – a full OS environment where you can walk around and do what you want. But all townhouses on the same street share the same core foundation and main utility lines – the host OS kernel, in our case.
You basically get the full functionality and secure isolation of a private house (the VM) but with the resource efficiency of a shared foundation.
For Magic Pages, my goal isn't to ship thousands of different applications. It's to give hundreds of customers the same application (Ghost) in their own secure, isolated space. I want to give each customer a complete "townhouse", not just a "furnished room".
LXC would give me that perfect middle ground: the robust isolation of a VM with a resource footprint that's much closer to a Docker container. Those quirky network limits and memory-hungry storage manager on Kubernetes (which is basically an orchestrator for Docker-like containers)? LXC basically sidesteps them with a simpler, more direct approach, avoiding extra layers of abstraction.
Having (re-)discovered Linux Containers, the math started looking very different. The more direct approach meant that there were less memory limits. I could use those bigger, more cost-effective dedicated servers, giving more resources to each site.
So, am I throwing away Kubernetes tomorrow and moving everything to Proxmox? Not quite. This discovery was more about Linux Containers as a technology, and less about the tool that runs them.
Right now, I am experimenting with them on my laptop, and running some isolated tests with bigger servers. Building a Linux Container is quite different than building a Docker container, so there will be lots of learning on my side.
However, there's one thing I already love about this journey: the fact that the constraints are off. The Kubernetes cluster is running smoothly (by feeding the memory monster). So, I can focus on figuring this out. One step at a time.
