6
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Nov 2023
6 points (100.0% liked)
Self-Hosted Main
504 readers
1 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
For Example
- Service: Dropbox - Alternative: Nextcloud
- Service: Google Reader - Alternative: Tiny Tiny RSS
- Service: Blogger - Alternative: WordPress
We welcome posts that include suggestions for good self-hosted alternatives to popular online services, how they are better, or how they give back control of your data. Also include hints and tips for less technical readers.
Useful Lists
- Awesome-Selfhosted List of Software
- Awesome-Sysadmin List of Software
founded 1 year ago
MODERATORS
10+ years at Google as an SRE. While borg =!= k8s, I've seen my fair share of platforms come and go. The trend seems to reward shifts towards declarative automation rather than imperative orchestration models. In the programming world, you'll hear the term idempotent, similar idea. There is no substitute or wrapper that can take imperative and make it declarative without tons of work. Ansible is imperative where if something goes wrong it is easiest to nuke then try again. K8s is the culmination of various imperative-based automation systems at Google, attempts at replacing them with declarative, then try again, then finally start afresh with an open-source version of borg.
Not many companies need the scale of Google, with thousands of engineers trying to modify production with hardened interfaces that force developers to write their applications in such an opinionated way (stateful applications must use StatefulSet, dynamic configuration should go into a ConfigMap, separate your command line arguments from the command being executed from the environment variables, LoadBalancers are distinct from and are an implementation detail of Services....).
But with the good foundation that k8s provides and imposes, you set yourself up for letting the infrastructure team not care about what is running on what hardware. They can focus on doing hardware, networking, disk swapouts... Ops can focus on service uptime, readiness+liveness probers, standardized monitoring/logging, traffic routing and rollouts. Devs can focus on writing code. These standards reduce the leakage that often happens between these 3 groups.
Taking declarative to the next level, you build CICD pipelines that can take your yaml files in a github repo and automatically push them. To the next level you want to account for importing templates and standard libraries, so you look to Kustomize till you realize that it doesn't give you the building blocks you need. You then start to adopt more declarative models where the source code (both java and json/yaml config files) can be built and the artifacts of that build step are what are fed into k8s, making your github repo the source of truth. Then all production fiddling is done with PRs rather than clicking buttons in an imperative way on some UI.
The more you see automation tools, the more you realize that declarative offers a more robust interface that can be glued to other declarative systems, albiet adding yet another layer of abstraction. This complexity is often not streamlined enough for people on this subreddit, as well as for lots of people writing self-hosted apps. Helm is about as both streamlined and exhaustive as you're going to get.
I agree with many here that learning k8s is best if you're needing to learn it for your job, or you have hopes of getting into the DevOps field.
I am currently setting up my home server using Ansible and I'd say 50% of my time/energy is trying to make it as idempotent as possible. Things like ok I want my service started but I want to restart it if it changed etc.
Although the main downside with k8s is that I don't think you can do much low level/privileged stuff. Like setting up a VPN for a single container, accessing devices for monitoring etc.