I just don't want to do that, no thanks. I've spent so much time learning about how an OS can solve these problems and these lessons have paid dividends many times over my career. Instead, I will continue to invest in the core foundation. I'm not interested in re-learning these abstractions reading [1]-[5] tutorials plus many more and studying an unrefined, new layer of complicated abstractions built on top of the OS--the OS is difficult enough. I'll only _use_ k8s when it's managed and supported by a team of 10+ engineers, which is what it requires. Plus, it's not just k8s; you have concourse, spinnaker, artifactory, some sort of cluster templating, kops? to template your k8s deployments across DCs and environments, (I don't know what the community uses, we built our own in-house tool). It's all so gross.
My rejection of these systems has lead me to invest in FreeBSD. There was a learning curve and I'm certainly not as fluent in this system as I am with Linux but I'm in a place where I'm in control of the OS and have at my disposal solid, refined tools to help me masterfully construct the infrastructure to solve my problems. And, every time I solve a problem in this space my foundational understanding grows and these lessons will pay dividends into the future, or so I hope.
I'm utilizing FreeBSD because docker / k8s and I'll add systemd to the list, are missing and thus the community solves problems in a different way that better aligns with my values. FreeBSD isn't easier, I've been stumped on problems countless numbers of times but when I find a solution, it scales. What I mean by that is I have a better understanding of a system that can solve a larger class of problems than if I was in the docker / k8s ecosystem.
No, you're way off. Maybe my reaction is extreme, but my problem isn't. What's yucky is that you're trying to convince people that reading five tutorials on k8s will make them productive. No, the problem, and I'll repeat it since you conveniently skipped over it, k8s requires 10+ engineers to maintain and manage, full time.
_I_ don't have 10 engineers and thus it's the wrong tool for me and I've decided to not invest in it.
K8s is certainly a beast and I agree with your posts directionally but just as a counterpoint - as a solopreneur I've been using k8s to run my business workloads (on GKE) for the past 4 or 5 years now. I'm very comfortable with dev and ops and k8s is a force multiplier for me, letting me easily manage much more than I could without it (e.g. due to automation, tooling, community, etc). Building on top of a standardized platform with a huge community has been a big win for me as a solo dev.
I'm not running a very big operation, I only have two nodes which host a few custom webapps and a few dozen WP sites. Running in a single region removes the extra charge for HA GKE, letting me run pretty lean and just pay for the VM, storage and bandwidth. I hardly ever have to spend any time on managing the cluster, it keeps chugging along while I get things done and makes it easy for me to manage app lifecycles. YMMV.
I keep it simple, I tried helm but didn't like it because it added too much complexity. I pull in cert-manager and nginx-ingress to every cluster I run but nothing else. I build my images locally and push to the registry directly, no CI/CD. I focus on the core competencies of k8s and try to stay lean and conservative with adding new tools or components.
This is a very interesting use-case for k8s. Can you expand on it some more? For instance, why did you you pick this over vhosting? You essentially took TESLA's Electric semi-truck, remove the cab, extend the chasis and slap a school bus body on top of it. I think I like it, but I'm wondering how stable it is. how much of set-it-and-forget-it benefit do you get out of it. Sometimes it's best to over-engineer to sleep good at night, knowing the limits will never be tested. This is why XCP-NG beats PROXMOX, because there's less wet nursing involved. Let me know if you have any write-up on this approach that you can share. I'd be interested in reading it.
I'll consider writing a blog post on it but long story short, it's very stable and hands-off when using a managed service. I started off with some DO droplets when I first launched my business and adopted k8s around v1.6. It was a little rough back then but now I spend maybe a few hours a month max on managing my clusters, mostly just upgrading the nodes and core components (cert-manager, nginx-ingress-controller).
I fell in love with it because of the dev and ops experience. Just the shift of perspective from pets to cattle is a big improvement. Deploying via sftp is simple but k8s really helps me with the other aspects (monitoring, logging, scheduled tasks, TLS cert mgmt, blue/green deploys, multiple environments, etc) of managing apps that my clients use regularly and depend on. It's nice having one API platform that can handle all of this and feels more like assembling Lego blocks instead of bespoke solutions for every project.
They're not wrong tbf, you can largely replace K8s with curl and some basic cloud CLI scripts for the majority of cases. Slight hyperbole but I'll never really understand the weird urge to use Borg-lite everywhere.
My rejection of these systems has lead me to invest in FreeBSD. There was a learning curve and I'm certainly not as fluent in this system as I am with Linux but I'm in a place where I'm in control of the OS and have at my disposal solid, refined tools to help me masterfully construct the infrastructure to solve my problems. And, every time I solve a problem in this space my foundational understanding grows and these lessons will pay dividends into the future, or so I hope.
I'm utilizing FreeBSD because docker / k8s and I'll add systemd to the list, are missing and thus the community solves problems in a different way that better aligns with my values. FreeBSD isn't easier, I've been stumped on problems countless numbers of times but when I find a solution, it scales. What I mean by that is I have a better understanding of a system that can solve a larger class of problems than if I was in the docker / k8s ecosystem.
YMMV.