or Do you?
EDIT: 99 times out of 100, you don't.
My hesitation and cautiousness doesn't come from being a greybeard curmudgeon, it comes from a healthy dose of skepticism that this is The One True Path that will Solve All The Problems. I am cautiously optimistic it might be a stable, proven ecosystem, eventually. But it isn't today.
When making technology decisions, imagine that you're the one with the pager at 3am and work backwards accordingly.
Using GKE I am horrified by how many times I have to type
gcloud beta ...Experience can be a crutch too, especially in a field that gets upended by new concepts every 3-5 years. I hope you're cognizant of that.
What worked 5 years ago is a joke today, in many cases.
> What worked 5 years ago is a joke today, in many cases.
Postgresql was first released in 1997. Lots of the web still runs on PHP, Python 2, and large amounts of Java. What you call a joke, I call a sustainable business and an amortized cost. No one is paying you to use shiny tools, they're paying you to solve business problems.
Sticking to Python2 is risky. Using a version of Postgres released 5 years ago (9.3) is risky, using legacy PHP is risky, relying on the JVM and Java developers to solve problems that other tech stacks solve faster/better is risky.
What you call a sustainable business with amortized costs I call an un-turnable ship that wastes money dealing with problems that were solved years ago.
If you do recommend software to a business that isn't proven (and Kubernetes is still very much unproven, it's first release was only 3 years ago), and it fails, you should be accountable for your poor judgement.
No one is suggesting you spend sleepless nights troubleshooting beta software in production.
K8s is not beta software, and the fact that you have to misrepresent my position as such is a pretty good indicator that you don't find my actual position (use solid software even if it's new, as long as it's solid, which k8s is) to be objectionable. I wish you'd start there...
You questioned the maturity of an IRC client that was only 3 years old [1]. But that's enough time for Kubernetes to be a mature orchestration framework, to be relied upon as critical infrastructure? Yes, more development resources have been committed to Kubernetes, but that does not make it solid.
And yes, they're two completely different pieces of technology with two completely different sets of eyeballs on them. 3 years for k8s is not the same as 3 years for an IRC client.
> Yes, more development resources have been committed to Kubernetes, but that does not make it solid.
It's a strong indicator of stability, and pretending like it's not kind of tips your hand here, I think.
Do you honestly think the two are even remotely comparable?
If you think I'm affiliated in any way with Kubernetes, you can look into that. I've tied my account on HN to my identity, I'm entirely Googleable.
Also, we're arguing about whether or not it's immature, what you just wrote is textbook begging the question. :/
Because I work to live, not live to work. Why would I give my time away for free to an employer or a client? I suggest proven solutions that require limited or no support outside of business hours. Several of my clients pay overtime to their ops staff when an on call event occurs. Time is literally money.
Your definition of "best" seems to be Kubernetes. My risk-adjusted recommendation is not. No more, no less. Appreciate the discourse!
My definition of "best" isn't k8s, I merely don't exclude technologies just because I've arbitrarily decided to stop learning at some point in time and mask this decision in "skepticism" for all technologies developed after that point in time.
Your risk assessment seems to be calibrated around "was this tech around when I was a technical contributor", and that will continue to hurt your clients/employer for as long as you continue to do it.
Find the positivity about the tech, and see what those people have trouble with. Tons of case studies to demonstrate, resoundingly, that k8s is "solid": https://kubernetes.io/case-studies/ . See what these people struggled with, and that'll give you a better idea of who's right here.