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

211–220 of 338 posts

Re: The Cult of Kubernetes

#211

Post by 0xdeadbeefbabe »

parasubvert wrote: post #193
wayoutthere wrote: post #185

Earlier quoted context omitted.

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 collaborat…

> “I’m a dev and am too important to be paged”

Also sounds too important to be dev.

Re: The Cult of Kubernetes

#212

Post by auvrw »

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…

> this isn’t what Kubernetes is really for.

i'm guessing that writing dyson in Nim is a tacit acknowledgement of that: if this were something geared toward production ecosystems, it would be in golang like kubernetes? although there is the helm luafication, so perhaps dyson is part of a fringe of non-golang k8s auxilliaries.

another way to implement this is with a 'static CMS' where there are still static pages except built into a situated deploy. the 'cultish' (cultic? anyway) aspect of k8s appears to be to phrase all the things in terms of k8s constructs rather than using k8s constructs as a foundation and abstracting out.

i learned about 'rollout' from the CI portion of this post, although initial attempts to search for a comprehensible description of it fail.

Re: The Cult of Kubernetes

#213

Post by xg15 »

perfunctory wrote: post #200
goatinaboat wrote: post #186

Earlier quoted context omitted.

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."

I think one root cause is that the two demands Dev usually have for Ops (keep the system protected and up-to-date and keep the developed software working in a well-defined environment) are sometimes directly conflicting - and developers don't always seem to realise this can be the case.

E.g. you could imagine some extreme case in which dependency X, version N has a critical vulnerability - but at the same time, the developed software relies on exactly version N being present and will break horribly on any other version.

You'd need Dev and Ops to actively work together to solve this problem and no amount of layering or containerization would get you around that.

Re: The Cult of Kubernetes

#214

Post by asdfman123 »

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…

The main problem is that smaller shops are adopting the fads of very large tech companies, but the large tech companies usually adopted those tools to deal with the kinds of scale that the smaller shops just don't have.

Re: The Cult of Kubernetes

#215

Post by xena »

auvrw wrote: post #212
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…

> this isn’t what Kubernetes is really for. i'm guessing that writing dyson in Nim is a tacit acknowledgement of that: if this were something geared toward production ecosystems, it would be in golang like kubernetes? although there is the helm luafication, so perhaps dyson is part of a fringe of non-golang k8s auxilliaries. another way to implement this is with a 'static CMS' where there are still static pages excep…

Honestly dyson is just something I wrote for myself to see how difficult it would be to write. I don't expect anyone else to use it. The tool is also a punny name, because you'd need to terraform a dyson sphere before you(r apps) can live in it.

I just wanted something with easy templating syntax like this: https://github.com/Xe/within-terraform/blob/master/dyson/src...

The fact that cligen (https://github.com/c-blake/cligen) exists too makes it super easy for me to define subcommands of the thing: https://github.com/Xe/within-terraform/blob/master/dyson/src...

Re: The Cult of Kubernetes

#216

Post by asdfman123 »

usgroup wrote: post #12

I think devs often make bad decision makers because in some sense tech is often an addiction rather than a pragmatic choice. The cycle of picking a tech, jumping ship to it, religiously evangelising it, riding the wave and then jumping ship to the next related tech is typical in my opinion. I try hard to correct for this bias but sometimes struggle with exactly the same thing. There's just something about wanting to…

Actually trying all promising new technologies is another full time job, or at least take 20 hours a week.

Most developers just don't want to be left behind, so they pick up whatever is trendy at the moment. It's completely rational, because knowing what is trendy getting you hired.

However, implementing what's trendy, without carefully weighing pros and cons*, is what's dangerous.

Re: The Cult of Kubernetes

#217

Post by gerbilly »

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 WebSphere reinvented then, along with all the management complexity and the expensive consultants?

Great analogy.

Re: The Cult of Kubernetes

#218

Post by asdfman123 »

vonmoltke wrote: post #110
twic wrote: post #83

Earlier quoted context omitted.

Is this really true? There are plenty of job openings for people who are good at maintaining Java Spring apps!

They also pay a fraction of what the jobs "hip" companies pay, and often come along with developers Being treated as second-class citizens.

Is that true, or are you inadvertently comparing the cost of living between SF and other major cities?

Hip technologies are being used in SV, and they have to pay tons of money just to keep the talent pool large and circulating.

Older technologies are used in other cities, and there the market forces aren't so crazy.

But a good Java dev can make plenty of money in SV, and a Go developer will make a competitive salary by Dallas standards but not by SV standards (and probably have a harder time finding a new job).

Re: The Cult of Kubernetes

#219

Post by asdfman123 »

humbleMouse wrote: post #178

These posts about kubernetes are so ridiculous. Installing kubernetes on multiple servers is not difficult, and understanding the components is pretty straightforward if you've ever worked on a distributed system. If you don't want to be in the "cult", dont use it. Meanwhile i'll be writing service and deployment yamls and avoiding all the proprietary expensive aws bs.

It's not difficult if it's your full time job. The learning curve is punishing though if you're trying to learn it from 9-12 AM on Saturday.

Re: The Cult of Kubernetes

#220

Post by asdfman123 »

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.

Question: why hasn't someone come up with a simple interface that abstracts away the tricky bits if you just want to deploy a blog?

I think MS is trying to make tools like this for the C# world, but I haven't seen them yet.

Post reply on HN