Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You might not need Kubernetes

blog.jessfraz.com

Post reply on HN
Print view View original

141–150 of 319 posts

Re: You might not need Kubernetes

#141

Post by diminoten »

toomuchtodo wrote: post #137
diminoten wrote: post #136

Earlier quoted context omitted.

The only misunderstanding that's taking place here is how unproven you think the tech being discussed is. 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…

We disagree k8s is solid, so no further discussion is necessary. 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. [1] https://news.ycombinator.com/item?id=18408813

For the people reading this who might be on the fence about k8s and its "solidness", keep in mind that hostility like what's being shown here is exactly the kind of thing that holds good tech back. Don't fall for this evidence-less claim, look at what people are accomplishing and the issues they're running into.

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.

Re: You might not need Kubernetes

#142

Post by sebringj »

It was interesting to note about workers and using web assembly together within V8 as this scenario could bypass the need for complexity and memory overhead, while combining different programming languages on the server-side. Not that it could replace Kubernetes as that is an amazing technology but if you are in a scenario where your tech could fit within workers, could be interesting. https://blog.cloudflare.com/introducing-cloudflare-workers/. I was amazed to think web assembly would be used for that purpose but i guess it does make sense in reading about how it is put together.

Re: You might not need Kubernetes

#143

Post by diminoten »

toomuchtodo wrote: post #137
diminoten wrote: post #136

Earlier quoted context omitted.

The only misunderstanding that's taking place here is how unproven you think the tech being discussed is. 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…

We disagree k8s is solid, so no further discussion is necessary. 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. [1] https://news.ycombinator.com/item?id=18408813

I questioned (misleading word, I did genuinely question as in I was unsure, not question as in demonstrate skepticism) the IRC client's maturity with a ton of caveats about myself and my admitted paranoia in this specific area.

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?

Re: You might not need Kubernetes

#144

Post by toomuchtodo »

diminoten wrote: post #143
toomuchtodo wrote: post #137

Earlier quoted context omitted.

We disagree k8s is solid, so no further discussion is necessary. 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. [1] https://news.ycombinator.com/item?id=18408813

I questioned (misleading word, I did genuinely question as in I was unsure, not question as in demonstrate skepticism) the IRC client's maturity with a ton of caveats about myself and my admitted paranoia in this specific area. 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…

I question why you push an immature technology so hard in a public forum, that is all.

Re: You might not need Kubernetes

#145

Post by diminoten »

toomuchtodo wrote: post #144
diminoten wrote: post #143

Earlier quoted context omitted.

I questioned (misleading word, I did genuinely question as in I was unsure, not question as in demonstrate skepticism) the IRC client's maturity with a ton of caveats about myself and my admitted paranoia in this specific area. 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…

I question why you push an immature technology so hard in a public forum, that is all.

And I question why you care more about going home at the end of the day than delivering the best product to your clients.

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. :/

Re: You might not need Kubernetes

#146

Post by toomuchtodo »

diminoten wrote: post #145
toomuchtodo wrote: post #144

Earlier quoted context omitted.

I question why you push an immature technology so hard in a public forum, that is all.

And I question why you care more about going home at the end of the day than delivering the best product to your clients. 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. :/

> And I question why you care more about going home at the end of the day than delivering the best product to your clients.

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!

Re: You might not need Kubernetes

#147

Post by diminoten »

toomuchtodo wrote: post #146
diminoten wrote: post #145

Earlier quoted context omitted.

And I question why you care more about going home at the end of the day than delivering the best product to your clients. 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. :/

> And I question why you care more about going home at the end of the day than delivering the best product to your clients. 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 litera…

Because you signed a contract with your employer/client saying you'd do that? Unless you're hourly...

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.

Re: You might not need Kubernetes

#148

Post by viraptor »

gambler wrote: post #114
dcosson wrote: post #98

Earlier quoted context omitted.

I really think that running a LAMP server for the average beginning developer these days would be just as complicated, maybe more complicated, than running a single deployment on Google Kubernetes Engine. You have to know about package managers and init systems and apache/nginx config files and keep track of security updates for your stack and rotate the logs so the hard drive doesn't fill up. If you already know how…

>I really think that running a LAMP server for the average beginning developer these days would be just as complicated, maybe more complicated, than running a single deployment on Google Kubernetes Engine. Back when I first started doing web dev I went from knowing nothing about server setups or Unix (i.e. running off managed hosting) to a reasonably secure FreeBSD server with a working content management system in 3…

I believe you believed that :-) But realistically, after over a decade of doing effectively DevOps, I'm still learning about mistakes I made before. In 3 days you may get something running and learn basics, but likely it's a false sense is security...

Re: You might not need Kubernetes

#149

Post by pathseeker »

dcosson wrote: post #98
combatentropy wrote: post #19

Some day I would like a powwow with all you hackers about whether 99% of apps need more than a $5 droplet from Digital Ocean, set up the old-fashioned way, LAMP --- though feel free to switch out the letters: BSD instead of Linux, Nginx instead of Apache, PostgreSQL instead of MySQL, Ruby or Python instead of PHP. I manage dozens of apps for thousands of users. The apps are all on one server, its load average around…

I really think that running a LAMP server for the average beginning developer these days would be just as complicated, maybe more complicated, than running a single deployment on Google Kubernetes Engine. You have to know about package managers and init systems and apache/nginx config files and keep track of security updates for your stack and rotate the logs so the hard drive doesn't fill up. If you already know how…

>Side note - couldn't you make a similar argument about any kind of further abstraction? "Question for all you hackers out there - do you really need HTTP requests with their complicated headers and status codes and keepalive timeouts? I run several apps just sending plain text over TCP sockets and it works fine."

No, because the end users already have an HTTP browser. Your analogy doesn't work because switching between k8s and lamp stacks is invisible to your users where dumping HTTP means you need dedicated clients.

Re: You might not need Kubernetes

#150

Post by m_mueller »

jerf wrote: post #132
wpietri wrote: post #87

Earlier quoted context omitted.

As somebody who has his own colocated server (and has since Bubble 1.0), I definitely agree that the old-fashioned way still works just fine. On the other hand, I've been building a home Kubernetes cluster to check out the new hotness. And although I don't think Kubernetes provides huge benefits to small-scale operators, I would still probably recommend that newbs look at some container orchestration approach instead…

"5 years on, I know that I did a bunch of things for a bunch of reasons, but I don't really remember what or why." For my home servers, I've settled on "a default install of distro $X and an idempotent shell script that sets everything up for me". You have to use discipline to do everything in the shell script rather than simply fix the problem, but if you can do that, you end up with documentation as to how your ser…

docker image definitions are idempotent as a matter of principle. creating an idempotent shell script is non trivial IMO - e.g. what return code is returned from package manager XY when something is already installed etc.
Post reply on HN