we're all talking about self hosting again
or its alternate title: Whoops, I Wrote An Essay
I don't ever post about it on other sites, but I do run this little website. Its hosting software is the stupidest, most fragile collection of tools I have no idea about that works and I'm scared to touch it. I, a person who worked professionally at a real life company hosting and maintaining their web services, don't want to even breathe on my own website's hosting.
And to be perfectly honest, it's not because I couldn't fix it if it broke. It's not because I couldn't figure out what all the tools and layers do. It's because I Don't Want To. I already did that shit at work, the last thing I want to do when I get home is More Work.
|
///
|
Containers kind of suck. Well, ok, they're great for what they were built for, but they kind of suck to use. On their own, containers are just a concept. A complete simplification of the software stack needed to run an application, condensed enough that each application can have its own little stack, just for itself. They, ideally, strip out any unnecessary items in that stack. Simple. Beautiful. Bliss.
Running containers, on the other hand is a clusterfuck of tools built on top of tools with obscure names and complex charts to determine interoperability. Containers kind of exploded over just a couple of years; they became the new hotness in tech. And with this explosion came rapid development. Every kind of tool you could ever need to manage and monitor and coordinate containers, many of which are built using the technology of containers themselves!
What was conspicuously lacking, however, was ways of actually running containers. No, not the container runtimes, or the replacements for Docker, or the clustering, I'm talking about ways for the normal, average, everyday home tech enthusiast to Just Run A Damn Container.
Docker was one of the first big names in containers, and while its legacy lives on in the "Dockerfile"s that every container system seems to still use, Docker itself continues to live on through the merits of being the only viable way for anyone to simply run software in a container on their computer. It's not like there aren't any better options, it's just that all these better options weren't built with the end user in mind; they were built with the system in mind. They were purpose designed to fit cleanly into a complex toolchain and be as configurable and controllable as possible. To be entirely honest, so was Docker, just not as aggressively. Docker at least tried to be available to developers so they could test things locally on their own machine. It was better than nothing.
|
///
|
Ok, where am I going with this disorganized information dump.
I haven't used containers a lot. I'm not an expert on them. If there's things wrong about my above descriptions, which there very well might be, please correct me on them.
But it also means: I am exactly who a solution needs to be created for. I Just Want To Run A Damn Container.
What I am not going to do is run Kubernetes or a bunch of individual will-they-won't-they-autostart-on-boot Docker containers with a janky software stack surrounding them just so they can connect to the internet.
Because that's Work. And unfortunately, I'm allergic to doing Work outside of, well, work.
What I'm trying to get at here, is that the only time I've ever understood containers, the first time I used one and got it, was when I was playing around with Microsoft Azure.
Part 2: This is a Tooling Problem
Containers are cool. Like really cool. They have the potential to simplify running applications to the bare minimum while configuring them using a human readable configuration file format. Unfortunately, it feels like no one who actually works on container tech feels this way.
Tools that are endlessly configurable and slot perfectly into a pipeline are great and cool and amazing but also absolutely useless for the average self-hoster. I imagine a tool that would actually be useful would be more like a controllable service that manages the whole container part behind the scenes. You give it a zip file of your code and a manifest describing what kind of container it runs on, and then configure everything instance specific in a web UI. Like Microsoft Azure, but instead of running your container somewhere in the cloud, you're running it somewhere on your computer. Where? Who cares, you sure don't have to! It's just a container that runs, maybe it runs on startup, maybe it runs on a schedule, maybe it doesn't run at all and just crashes because I didn't write my application code correctly.
And if you don't want to write your own application from scratch and deal with figuring out containers and creating a manifest? It's just an archive file. Who cares where it comes from. Distribute it as part of your open source application's release executables. Register it in an application registry that fledgling self-hosters can browse and pull from.
Not to sound cliché, but we have the technology. The foundation has already been poured, the building blocks are there. The tools just aren't purpose built enough. At least, none of the ones I've found are.
Some problems aren't things that can be fixed by tech or code or tools. Some problems are social, some are interpersonal. This isn't one of them. But no one building container tooling recognizes that this is a problem that needs solving.
Maybe I should add revisiting my side project plans about container tooling to my ever growing list of "things to do Tomorrow". Because apparently no one thinks this problem is worth solving except a bunch of us weirdos on cohost. Alles muss man selber machen.
Anyway, sorry you read through all this. I'm going to bed.