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

The full-time job of keeping up with Kubernetes

gravitational.com

Post reply on HN
Print view View original

111–120 of 237 posts

Re: The full-time job of keeping up with Kubernetes

#111

Post by [deleted] »

gouggoug wrote: post #40
mbrumlow wrote: post #24

Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another. As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things…

I don't think your comment applies at all to Kubernetes. K8s truly simplifies dev-ops and even the smallest team and website can greatly benefit from it. I speak from 7 years of experience managing my company's infrastructure's website: Before kubernetes, I ran my company's stack on very cheap bare metal from OVH. It was great while it lasted, but as the company grew and my team grew, it's become harder and harder to…

[deleted]

Re: The full-time job of keeping up with Kubernetes

#112

Post by nitwit005 »

gouggoug wrote: post #40
mbrumlow wrote: post #24

Every time a new framework or tool comes out and everybody jumps on it. I always wonder if somebody will realize that you are trading one set of problems and work for another. As engineers we really need to stop supporting these sort of effort and take the time to help each other become better engineers that write and maintain our own code. We need to promote learning and mastering the underlying concepts that things…

I don't think your comment applies at all to Kubernetes. K8s truly simplifies dev-ops and even the smallest team and website can greatly benefit from it. I speak from 7 years of experience managing my company's infrastructure's website: Before kubernetes, I ran my company's stack on very cheap bare metal from OVH. It was great while it lasted, but as the company grew and my team grew, it's become harder and harder to…

> Over time, your production staging and dev all become entirely heterogeneous.

I've found that this is simply the reality, excepting test-only environments. Developers need to be able to run the applications out of an IDE, compiled with special instrumentation, or whatever else they need to do. It's not possible to support every combination of what they need.

Also, there's some significant developer overhead sometimes. I had another team give me a set of VMs for their product, so I could test a new config. It was great in that it was just like production, but not so great in that it was just like production. How do I log into these VMs? How does authentication work? Where are things located on the VMs? How do I generate an updated VM? You end up having to train everyone in dev ops, because you've handed them a copy of production.

Re: The full-time job of keeping up with Kubernetes

#113

Post by cookiecaper »

shruubi wrote: post #35

This article concerns me, especially considering the first thing you see is "There is no such thing as Kubernetes LTS (and that’s fantastic)". What is so great about running your infrastructure on a platform that has no intention of ensuring long-term stability? Irregardless of how well backward-compatibility is maintained, the idea that we should all move our infrastructure to something that lacks the fundamental pr…

No LTS is fantastic -- as long as you don't expect me to put it in production. ;)

k8s is a tale of woeful, hilarious levels of platform immaturity jammed down the public's throat by the Google PR machine. I believe Kubernetes is a centerpiece in Google's cloud play against Amazon (I don't think it will be successful), and that this consideration drives a lot of the particular weirdness and distortion that exists around it.

It'd be a whole different ball game if they discouraged production use and told people "We can't even commit to keeping this up to date for one single year, whereas all other enterprise vendors offer 5 years or more, you'd be silly to think this was ready for prime time." But they don't, because then you don't have starry-eyed brogrammers saying "DUDE, we gotta get on k8s so we can be like my homies in Mountain View, aw man, it's so awesome! It says Google Cloud is the best way to get Kubernetes, call 'em up!"

I feel sorry for anyone who was naive enough to say "Well, if Google does it, so do I!" and jumped headfirst into this bear trap, making themselves collateral damage in a pissing contest between two megacorps.

Source: I work with people who decided to move our entire infrastructure to Kubernetes. We have now run virtually everything on k8s for over a year. I'd feel sorry for them, but they left the company some time later, so now I just feel sorry for me. :)

Re: The full-time job of keeping up with Kubernetes

#114

Post by flukus »

purerandomness wrote: post #98
halayli wrote: post #85

Earlier quoted context omitted.

true but you don’t have to go that far. React, webpack, and sometimes well maintained packages that depend on unmaintained packages suffer from this. I am not picking on web dev, it’s a general problem.

It's a relatively new problem caused by an influx of inexperienced programmers who have to experience these problems first-hand. They do learn, but they can't teach what they learned because of the ever increasing influx of new, unexperienced programmers. I highly recommend this talk by Uncle Bob (have a tea and a foot bath, it's long): https://www.youtube.com/watch?v=ecIWPzGEbFc

I don't think it's just the influx of new developers, it's too many rockstars that only work on green fields applications, they can't and don't learn the long term consequences of their decisions. Not all of them are new programmers, they're just the epitome of 5 times 2 years of experience.

Re: The full-time job of keeping up with Kubernetes

#115

Post by sedachv »

ehnto wrote: post #92
StillBored wrote: post #8

Earlier quoted context omitted.

Some of this is caused by lack of backwards compatibility too. In the past once you picked a library you could be pretty sure that the API's you depend on wouldn't change much, and then only with a major release which would come with adequate documentation detailing the important changes. These days the throw away and rewrite/refactor crowd is in such power that if you don't spend 1/2 your time tracking the commits y…

The dependency trees in many projects are out of control too. It was part of the reason I wanted to move on from my last position. We were spending so much time chasing infrastructure dependency changes that it began to feel like a treadmill that was slowly increasing speed. At some point I got tired and couldn't find the heart to debug yet another vagrant up failure, knowing that fixing it will probably break someth…

> until you eventually hire a sadist/devops guy.

I try to drop in and follow the devops scene from time to time; after all, a lot of my work ends up getting handled by this stuff, and sometimes you need to fix things yourself. From my point of view, listening to a devops talk is listening to a long monologue consisting of a chain of mostly food-related, seemingly unconnected English words ("Chef Cucumber Puppet Jenkins Salt") that somehow "run" on top of another. None of them are modular, none of them are interchangeable, there are no standards, whatever you write for one of the food-related items will not work with another food-related item, or the same food-related item of a different vintage. The shelf-life of the food-related items seems to be about 3 years.

From an outsider's perspective it feels that, aside from Nix, there has not been any theoretic or standards progress in this field since Mark Burgess' time.

Re: The full-time job of keeping up with Kubernetes

#116

Post by robocat »

jstimpfle wrote: post #23
lkrubner wrote: post #3

Earlier quoted context omitted.

I wish I could give you more upvotes. You are describing a somewhat hidden psychology, which I think provides a rational basis for much of "Not Invented Here" psychology. We tend to think that "Not Invented Here" psychology is irrational, but in fact, the loss of control over possibly crucial technology is an important cost, which makes all of us stop and re-consider whether we really want to use some software develo…

And it's not only that - Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. It's a sad state when otherwise very intelligent people think it's bad practice to use plain C and a clean OS API that has been stable for decades (because that was somehow "magic" und impossible to understand and error-prone), and advise y…

Concatenating two paths is difficult if you care about any of the following: security, multiple OS's, Unicode (multiple code units, validity, combining characters), file system restrictions, etc.

Your "two decades" maybe holds for Linux, but what about Windows or MacOS???!

I have seen too many people use string concatenation.

I think an intelligent person would recommend to use the normal library (appropriate for your language, assuming it is well written) since usually your program will be doing many other filename/path manipulations too.

Re: The full-time job of keeping up with Kubernetes

#117

Post by gouggoug »

cookiecaper wrote: post #108
botskonet wrote: post #61

Earlier quoted context omitted.

I hadn't considered the benefits for dev/local instances... I've known about Kubernetes for some time, but my current job never deploys anything that Kubernetes could improve, so I put it aside and hoped to someday get a chance to toy with it. I've setup vagrant images pre-loaded with our app for several non-developers to use locally but it sounds like Kubernetes would be a far better way to manage those as well as s…

Kubernetes can't run the local images for your devs (Kubernetes must operate over a cluster; minikube spins up a virtual one). You're just thinking of containers. I saw another comment that did this just a minute ago. Is k8s-hysteria getting so out of control that it's consuming Docker whole? Seems like it may be. ----- EDITING IN RESPONSE TO GOUGGOUG ----- HN's limitation on my post rate has kicked in. Response to g…

I'm not sure what your comment is about. I'll glance over the first 3 sentences since I'm not sure at all what you are trying to say and jump directly to the fourth one:

> Is k8s-hysteria getting so out of control that it's consuming Docker whole? Seems like it may be.

This confuses me the most. K8s and Docker are complementary technologies, not in opposition to each other. Maybe some less advanced users using k8s don't realize that it heavily uses docker (or rkt, or whatever container runtime you could think of), but how is that an issue? That doesn't mean there's a k8s-hysteria going on.

Re: The full-time job of keeping up with Kubernetes

#118

Post by dralley »

shruubi wrote: post #35

This article concerns me, especially considering the first thing you see is "There is no such thing as Kubernetes LTS (and that’s fantastic)". What is so great about running your infrastructure on a platform that has no intention of ensuring long-term stability? Irregardless of how well backward-compatibility is maintained, the idea that we should all move our infrastructure to something that lacks the fundamental pr…

>"There is no such thing as Kubernetes LTS (and that’s fantastic)"

OpenShift?

Re: The full-time job of keeping up with Kubernetes

#119

Post by bazfoo »

jweir wrote: post #75
brudgers wrote: post #19

Earlier quoted context omitted.

A description of -- not a name for -- is corporate control of an open source project. Trying to keep up with Angular or Kubernetes or Go is not a problem at the Google from whence they come because the technologies are primarily used by and hence primarily designed for use by teams. Not individual developers. A team's brain can schedule a time where part of it is training or studying while the rest of it is making pr…

I disagree on Go. Go is well designed and takes upgrading into consideration. Upgrades very rarely break anything. You should just be able to recompile that 1.3 code on 1.8, etc.

I concur with the sentiment.

The risk is still there for dependencies, but it helps that the community for the most part follows "a little copying is better than a little dependency" as an adage.

Re: The full-time job of keeping up with Kubernetes

#120

Post by jacques_chester »

yeukhon wrote: post #102

Kubernetes’ governance is becoming like Openstack and (I know this is controversial), I hate Openstack, especially because it tried so hard to be “AWS” compatible, and APIs are so awkward to use. Cloudfoundry is better in terms of governance and project’s direction. Many of the main developers work full time at Pivtoal. But it is hard to run your own CF without significant investment like access management and “painl…

> Cloudfoundry is better in terms of governance and project’s direction.

The Cloud Foundry Foundation rules are very different from CNCF's and intentionally take DNA from Pivotal Labs. It has strengths and weaknesses.

> etcd is a pain in the entire CF stack in my experience

It's either been removed from CFAR, or is close to it, I lost track. A lot of time was spent before it was decided that etcd doesn't play nicely with BOSH.

It's come back into Cloud Foundry land via CFCR, as a Kubernetes dependency. Very nostalgic.

Post reply on HN