You saved $35 a month but spent 3x as much time maintaining and tweaking your self hosting. I guess we know how much your time is worth!
That said, I barely need to maintain most of my home infrastructure. I have CI/CD scripts do the bulk of maintainership for me these days.
After all, can you really write a good application without knowledge of how it will be deployed, and the challenges users face deploying things on specific platforms (eg. Windows, baremetal linux, kubernetes, docker, etc)? I would argue that you'd often write naive applications that gimp itself in unexpected ways depending on how the user intends to use it, without that knowledge. Depending on what types of applications you tend to write, this might be less of a valuable point to you. For example a static site web dev probably wouldn't be as interested in the infrastructure, they just need a server that can bind on ports 80/443. But I see a lot of incredibly naive applications written by potentially naive software developers out there.
Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother?
If you think you can do both and create a “really good” app, or even product, well then you’re likely a genius. It depends on the depth, breadth and consistency of that “knowledge”—some people simply overestimate their capacity while others underestimate their potential. By poking around in Kubernetes is it deep enough for production or only broad enough to impress someone who’s deeper yet not broader? By reading the docs and textbooks and learning from people, would that be enough for production?
I said I hoped to forget that ops stuff because I have other duties to attend to and there’s too much variance and unreliability in those ops tasks, you need to make a context switch, hence IaC, hence managed, so you as a non-operator can focus on your tasks. Infrastructure and platforms are commodity goods now.
Many enterprises and companies use Kubernetes as at least _one_ of their deployment targets. So if you're a provider of software that has paying companies consuming it, does it matter if kubernetes is "deep enough for production"? It's being used in production, so I would argue, yes, from the perspective of a software provider, kubernetes is in fact deep enough for production. Though to one of your other points, define deep enough, because that statement seems like a moving target depending on who you talk to. But in general, if a piece of software doesn't work well in kubernetes, it's because the authors of that software hadn't considered any setup other than running as a monolith systemd service with an sqlite db for state. That will move me into the next quote:
> Define “knowledge” you’re referring to. I have checklists for my ops. Define “really” and “good”. That sounds like perfectionist maxims without ground. Your listing of deployment targets can be extended by any BSD system, Android, iOS, IoT SoCs—what’s the point? If that’s your business requirement then you do it, if not then why bother?
Knowledge is a fairly generic term, isn't it. It's a placeholder word for a series (or bucket) of facts about one or several domains. "Really" is a nuanced word that means different things depending on how it's used. For example, in my sentence fragment, "can you really write," I'm using the word 'really' to express disbelief in one's ability to perform the context. On the word "good" we can use context clues to extrapolate that I probably am using the word "good" to mean one that supports a wide variety of deployment targets with ease because you often do not know how your product consumer's infrastructure looks, but you can probably guess that if its intended deployment target is a linux server, these days, it should probably also be well supported in Docker and Kubernetes. So that is "good." There are a bucket of other concepts that make a piece of software "good" as well that I'll merely touch on for the sake of brevity, such as being well tested, generally lacking unchecked exceptions, runtime panics, is well performant when ran for long periods of time, etc.
Though, to be honest, I think you probably could have used context clues to come up with rough definitions of those words yourself, and I suppose your purpose was to glean what I think those words mean. In my opinion, the exercise seemed a bit more tedious than maintaining infrastructure though.
Well, yeah, I’d rather not waste my time. Time is money.
Anyway, this is a pick your poison scenario, probably. So, don't let me try to tell you one way is the best way.
It has probably contributed zero directly to my software engineering career, however, there are moments where a deep understanding of the quicksand under my app foundations can help, and shortcut strange debugging sessions and the like.
The time I spend is recreational for me. I can see where others, particularly Ops professionals, are horrified at the idea of doing lib and OS maintenance/updating for fun. It's a very yuckable yum :D
“Oh, I remember doing this a year ago in my homelab… it was a mistake.”
Otherwise, that time is his free time and he can do what he likes.