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

The Cult of Kubernetes

christine.website

Post reply on HN
Print view View original

191–200 of 338 posts

Re: The Cult of Kubernetes

#191

Post by meowface »

dkhenry wrote: post #184
wayoutthere wrote: post #127

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything need…

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it.

Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult-y bits. Containers, serverless/FaaS, and Kubernetes can be pretty great if you're the plane pilot dropping the cargo on the island rather than the cult living on it, and future stuff will probably be even better.

Re: The Cult of Kubernetes

#192

Post by swsieber »

Fiahil wrote: post #107
swsieber wrote: post #36

Earlier quoted context omitted.

So you're running bare metal k8s at home? What do you use for storage? That's my biggest question in how to move frok minikube at home to a true cluster.

Raid 1, 4tb, NAS with NFS :)

Thanks! That should be enough to get me going in the right direction, hopefully to a working setup :)

Re: The Cult of Kubernetes

#193

Post by parasubvert »

wayoutthere wrote: post #185
falcolas wrote: post #164

Earlier quoted context omitted.

K8s is writing config files just like Python is writing Python Syntax. If you don't understand the underlying mechanism, either with Python or K8s yaml files, you're going to have a very bad time. Somewhat ironic side note - Asking folks to write K8s config files is exposing too much complexity for some developers I work with. And I kind of get it. Properly setting up a service with changing environment variables, se…

Yeah, fully integrated “DevOps” at scale is a pipe dream. You will always have some segregation of dev and ops because the scope of knowledge is so different, especially today where “Ops” often means “expert in XXX cloud vendor’s product portfolio and how our operating model uses the features”. What we call “DevOps” is really a delicate balance of giving the dev teams enough rope to hang themselves while child-proofi…

I don’t think DevOps leaders are claiming DevOps should be fully integrated so much as there should be a culture of collaboration and empathy, shared metrics and incentives, and preference for end to end automation... rather than antagonistic “throw it over the wall”, “I’m a dev and am too important to be paged” behaviour, etc., which has nothing to do with skill specialization.

Good contracts lead to good collaboration. Kubernetes provides the foundation for a solid end to end contract for managing complex systems automatically. It’s incomplete, but extendable.

Re: The Cult of Kubernetes

#194

Post by xena »

zemo wrote: post #145
wayoutthere wrote: post #127

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…

> complaining that running a blog on Kubernetes is too complex think you're really missing the point here. Why do you think this was included in the post? https://twitter.com/dexhorthy/status/856639005462417409

I run more than just my blog. I'm also moving discord and IRC bots there too.

Re: The Cult of Kubernetes

#195

Post by 013a »

geggam wrote: post #144
lukasLansky wrote: post #29

Kubernetes is our one shot at having the universal vendor-neutral cluster interface. The fact that it's time consuming to do simple things directly against it doesn't surprise me in the same way I'm not surprised that writing todo app directly against POSIX abstraction would be time consuming. It's a great way to learn how these interfaces work though.

but it isnt vendor neutral because you have to setup the k8s cluster differently in each cloud

https://cluster-api.sigs.k8s.io/

Re: The Cult of Kubernetes

#196

Post by parasubvert »

wayoutthere wrote: post #148
zemo wrote: post #145

Earlier quoted context omitted.

> complaining that running a blog on Kubernetes is too complex think you're really missing the point here. Why do you think this was included in the post? https://twitter.com/dexhorthy/status/856639005462417409

Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.

Except Kubernetes has sucked all the oxygen up in the industry and has had a subset of adherents that trash the alternatives such as Heroku, Cloud Foundry, etc.

As such, people do expect it to replace Heroku.

Re: The Cult of Kubernetes

#199

Post by wayoutthere »

meowface wrote: post #191
dkhenry wrote: post #184

Earlier quoted context omitted.

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything need…

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…

Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case.

Even Google only released K8s because they thought it would push people towards GCP — which it didn’t because it was too easy for AWS to implement a similar service using Google’s open source tech. The open source freemium model for infrastructure tech is pretty much dead as a result of this kind of activity.

Re: The Cult of Kubernetes

#200

Post by perfunctory »

goatinaboat wrote: post #186
perfunctory wrote: post #173

Earlier quoted context omitted.

> “do what you want, as long as k8s is up, what you run in your pods is your problem, not ours” Until somebody cyberattacks those pods and steals all personal data of your users because the devs didn't bother to apply security patches. But hey, it's not your problem. You are not responsible for the pods. k8s is still up.

But hey, it's not your problem. You are not responsible for the pods. k8s is still up. But that has always been true. If a dev leaves a SQL injection for example in the code and it got penetrated, absolutely no one would blame the sysadmin for that.

In the case of sql injection the responsibility indeed weighs more on devs. But often it's a grey area. What about upgrading openssl lib for example, or patching Struts framework (see Equifax hack)?

My interpretation of DevOps is that it's one team with shared responsibility and not "shove your stuff in that pod and don't bother me."

Post reply on HN