microcosm VS home-ops

For reference, this is roughly what I have... still not looking to sell today (that also takes time and brain cycles) but this is what I wrote in an email to someone enquiring by email after I posted this morning:

So I wasn't looking to sell when I wrote the comment on HN, but the gist is: 8 years ago I created a platform for forums, it's a PostgreSQL database with a Go API layer. It's multi-tenant by default, so hosting many forums on a single server or cluster is trivial. That much is solid, and well maintained. But... I am not a front-end person and with that in mind I had the frontend built in Python + Django originally... it has no database, it's a pure veneer over the API just to use common templating for making the HTML. This part has not been maintained... it's 8 years out of date, Python 2.

The platform I run has a number of sites on it, and I'm loosely aware that over the years other people had spun up instances of their own (it was open source, but feeling responsible for the lack of updates I hid that recently).

Examples of sites using it:

* https://www.lfgss.com (the biggest site on it)

* https://pignolefixe.microco.sm/ (a french site)

* https://forum.espruino.com (something to do with arduino and javascript)

* https://forum.islington.cc (a pretty strong site)

* https://forum.rapha.cc/ (a private members club)

A common theme is cycling.

The entire thing is secure, privacy focused, very low effort to run. There are no adverts, no tracking, no stats... but web logs say that I served 1.5M HTTP requests in the last 24 hours (to now) and that's behind a well configured Cloudflare cache (those not signed in hit cache for 5 minutes, only those signed in get dynamic HTML).

So that's why I have... a forum platform. Oh... what differentiates this forum platform? It has events... in fact the platform is bespoke, the idea when I started it was to have things like classifieds, events, polls, forms, wiki all be native top-level content within a forum. I never liked on vBulletin or Reddit how you'd have to leave the forum to collaborate beyond conversations so I was trying to bring it all into the forum (and thus compete with MeetUp, eBay, etc... who don't have communities and wish they did).

I still don't know if I'm necessarily looking to sell... but if we get to the point that the frontend server fails in some horrible way, the Python + Django being 8 years old probably means the effort to get it working is too much. I did realise this, and started a frontend in Go to replace the Django one (I can maintain Go code) https://github.com/buro9/microcosm but you can see the lack of progress... I joined fast growing startups and my career accelerated too, that doesn't leave time for side projects.

This is incredibly popular a take, and this anti-k8s is rapidly upvoted almost every time.

The systemd hate has cooled a bit, but it too functions as a sizable attractor for disdain & accusation hurling. Let's look at one of my favorite excerpts from the article, on systemd:

> Fleet was glorious. It was what made me decide to actually learn how to use systemd in earnest. Before I had just been a "bloat bad so systemd bad" pleb, but once I really dug into the inner workings I ended up really liking it. Everything being composable units that let you build up to what you want instead of having to be an expert in all the ways shell script messes with you is just such a better place to operate from. Not to mention being able to restart multiple units with the same command, define ulimits, and easily create "oneshot" jobs. If you're a "systemd hater", please actually give it a chance before you decry it as "complicated bad lol". Shit's complicated because life is complicated.

Shits complicated because life is complicated. In both cases, having encompassing ways to compose connectivity has created a stable base - starting point to expert/advanced capable - that allowed huge communities to bloom. Rather than every person being out there by ourselves, the same tools work well for all users, the same tools are practiced with the same conventions.

Overarching is key to commanlity being possible. You could walk up to my computer and run 'systemd cat' on any service on it, and quickly see how stuff was setup (especially on my computers which make heavy use of environment variables where possible); before every distro and to a sizable degree every single program was launched & configured differently, requires plucking through init scripts to see how or if the init script was modified. But everything has a well defined shape and form in systemd, a huge variety of capabilities for controlling launch characteristics, process isolation, ulimits, user/group privileges, special tmp directories is all provided out of the box in a way that means there's one man page to go to, and that's instantly visible, so we don't have to go spelunking.

The Cloud Native paradigm that Kubernetes practices is a similar work of revelation, offering similar batteries included capabilities. Is it confusing having pods, replicasets, and services? Yes perhaps at first. But it's unparalleled that one just POSTs resources one wants to an API-server and let's the system start & keep that running; this autonomic behavior is incredibly freeing, leaving control loops doing what humans have had to shepherd & maintain themselves for decades; a paradigm break turning human intent directly into consistent running managed systems.

The many abstractions/resource types are warranted, they are separate composable pieces that allow so much. Need to serve on a second port? Easy. Why are there so many different types? Because computers are complex, because this is a model of what really is. Maybe we can reshuffle to get different views, but most of that complexity will need to stay around, but perhaps in refactores shapes.

And like systemd, Kubernetes with it's Desired State Management and operators, it creates a highly visible highly explorable system; any practitioner can walk up to any cluster and start gleening tons of information from it, can easily see it run.

It's a wrong hearted view to think that simpler is better. We should start with essential complexity & figure out simultaneously a) how to leverage and b) how to cut direct paths through our complex capable systems. We gain more by permitting and enabling than by pruning. We gain my by being capable of working at both big and small scales than we gain by winnowing down/down scoping our use cases. The proof is in the pudding. Today there's hundreds of guides one can go through in an hour to setup & get started running some services on k3s. Today there's a colossal communities of homelab operators sharing helm charts & resources (ex: https://github.com/onedr0p/home-ops), the likes of which has vastly outclassed where we have stood before. Being afraid of & shying away from complexity is a natural response, but i want people to show that they see so many of the underlying simplicities & conceptions that we have gotten from kube that do make things vastly simpler than the wild West untamed world we came from, where there weren't unified patterns of API servers & operators, handling different resources but all alike & consistent. To conquer complexity you must understand it, and I think very few of those with a true view of Kubernetes complexity have the sense that there are massive opportunities for better, for simpler. To me, the mission, the goal, the plan should be to better manage & better package Kubernetes to better onboard & help humans through it, to try to walk people into what these abstractions are for & shine lights on how they all mirror real things computers need to be doing.

(Technical note, Kubernetes typically runs 0 vm's, it runs containers. With notable exceptions being snap-in OCI runtimes like Firecracker and Kata which indeed host pods as vms. Kine relies on containers are far more optimizable; works like Puzzlefs and Composefs CSIs can snap-in to allow vastly more memory-and-storage-efficient filesystems to boot. So many wonderful pluggable/snappable layers; CNI for networking too.)

These are great operational wins. Agreed very much that having autonomic (can fix itself) systems at your back is a massive game changer. De-crustifies the act of running things.

The other win is that there's a substantial cultural base to this way to go. Folks have been doing selfhosting for ages, but everyone has their own boutique setup some their way. A couple tools and techniques could be shared, but mostly everyone took blank slate configs & built their own system up, & added their own monitoring & operational scripts.

https://github.com/onedr0p/home-ops is a set of helm scripts and other tools that is widely widely used, and there's a lot more like it. It's a huge build out, using convention and a common platform to enable portable knowledge & sharing.

Self hosting did not have intellectual scale out at it's back, before Kubernetes came along. Docker and ansible and others have been around, but theres never been remotely the success there has been today in empowering users to setup & run complex services.

We really have clawed out of the server-hugging jungle &started building some villages. It's wonderful to see.

Going thru this repo https://github.com/onedr0p/home-ops

Take a look at my open source GitOps repo managed by Flux here: https://github.com/onedr0p/home-ops

Im fully onboard with the geneneral idea as a target.

Right now it's for early early adopters. Hosting stuff is still a painm But we are getting better at hosting stuff, finding stable patterns, paving the path. Hint, it's not doing less, it's not simpler options: it's adopting & making our own industrial scale tooling. https://github.com/onedr0p/home-ops is a great early & still strong demonstration; the up front cost od learning is high, but there's the biggest ecosystem of support you can imagine, and once you recognize the patterns, you can get into flow states, make stuff happen, with extreme leverage far beyond where humanity has ever been. Building the empowered individual is happening, and we're using stable good patterns that will mean the individual isnt so off on their own doing ops- they'll have a lot more accrued human experiene at their back, their running of services isnt as simple to understand from the start but goes much much further, is much more mature & well supported in the long run.

My Kubernetes cluster, deployments, infrastructure provisioning is all available over here on Github.

For example: https://github.com/onedr0p/home-ops/pull/4528