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

31–40 of 237 posts

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

#31

Post by hodl »

crankylinuxuser wrote: post #22
lomnakkus wrote: post #18

Earlier quoted context omitted.

(I haven't read the rest of your post, but I think I can still answer this little snippet...) > Why unavoidable? It's not that one is forced to use some tech... Even though the hyped crowd chants the names so loudly. Peer pressure. Consultant-hiring-pressure, for example: Are you full-stack? "Full stack", now there's a phrase... (EDIT: I honestly do feel that it's a sort of an attack by the sheer meta on the hiring s…

"Yeah, he's a few PDF's shy of a full stack, I tell ya!" side story: Yeah, I went through 3 stages of hiring with $company. Interviews went great, and then I hear back that I didn't show up to the 3rd (much to my surprise). When the HR person checked back in, they said it was an error and instead they were no longer interested in me because I lacked Kubernetes experience specifically. And my resume includes Openstack…

Thats why one must lie in their cv

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

#32

Post by mancerayder »

brudgers wrote: post #19
tw1010 wrote: post #2

There aught to be a name to the tendency that as tools get better and better, the more your time goes from having your mind in technical-space to social and news-space. It's like the authority to create goes from the individual first-principles (by necessity) maker, to the control over development being in the hands of an external group, and then all your time is spent keeping up with what they're doing. A similar th…

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…

These are excellent points and very interesting food-for-thought, the 'organizational thinking' that leads to the tools being terribly complex and steep to learn for individuals.

But don't these tools have product managers, and don't product managers create tools to serve customers?

The only cynical viewpoint that I can think of for artificial (or lazy) complexity is consulting dollars.

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

#33

Post by peterwwillis »

trigger warning: bitter jaded ops person working in a real company

"[...] users are expected to stay “reasonably up-to-date with versions of Kubernetes they use in production.” [...] the upstream Kubernetes community only aims to support up to three “minor” Kubernetes version at a time. [...] if you deployed a Kubernetes 1.6 soon after it came out last March, you were expected to upgrade to 1.7 within roughly nine months or by the time 1.9 shipped in mid-December."

Jesus christ this is so annoying.

Businesses don't have a couple hundred billion dollars sitting around to spend on engineers to look at release notes, compare changes, write new features, write new test cases, fix bugs, and push to prod, every 3 months, just to keep existing functionality for orchestrating their containers.

We have LTS because businesses (and individuals) don't want to have to do the above. They just want a reliable tool. They want the ability to say that if a bug is found in 3 years, it will be fixed, and they can just keep using the tool.

We don't give a crap about "Kubernetes’ domination of the distributed infrastructure world". We don't want to use Kubernetes. We just want an orchestration tool - commodified tooling. We want to stop caring about what we're running. We just want the fucking thing to work, and to not have to jump through hoops for it to work.

"Moving Kubernetes Workloads to New Clusters instead of Upgrading"

UGH. We only do this for bastardized unholy stupid shit like OpenStack. Not only is this not fun, it takes forever (you try moving 50 different clients off the service they've been using for three years), and you have to have duplicate resources. What the fuck is the point of cloud computing and containers and all this bullshit if I have to have double the infrastructure and juggle how it's all used just to upgrade some fucking software?!??!?!

"The Kubernetes-as-a-Service offerings, particularly Google Cloud’s Kubernetes Engine (GKE), are the well-polished bellwethers of what is currently the most stable and production-worthy version of Kubernetes."

Oh. We're supposed to pay Google to run it for us.

....I'm just going to use AWS.

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

#34

Post by SteveNuts »

halayli wrote: post #14

This is a problem I faced using ansible, webpack + js modules, and more. it's a moving ground and you always need to keep up to date with the latest changes often which are breaking. I tend to design my systems so that they work even if I haven't touched a line in a year but when using such tools it's always a pain. I wish things were as stable as a bourne shell and unix environment in general. Not that they achieve…

I wasn't around for it, but I bet you'd say the same thing about Bourne Shell when it was new.

The tools will stabilize as they mature, they're still very new comparatively.

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

#35

Post by shruubi »

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 promise of "updating won't break everything" seems downright irresponsible.

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

#36

Post by crankylinuxuser »

hodl wrote: post #31
crankylinuxuser wrote: post #22

Earlier quoted context omitted.

"Yeah, he's a few PDF's shy of a full stack, I tell ya!" side story: Yeah, I went through 3 stages of hiring with $company. Interviews went great, and then I hear back that I didn't show up to the 3rd (much to my surprise). When the HR person checked back in, they said it was an error and instead they were no longer interested in me because I lacked Kubernetes experience specifically. And my resume includes Openstack…

Thats why one must lie in their cv

Perhaps. But I think it's better, that if they're willing to play those kinds of games that I wouldn't want to work for them anyways.

All tech companies run their own NIH stack in one way or another. If they aren't willing to admit that to themselves, there's not much I can do. It costs time to train to get new people up to speed... and given what kind of arduous journey learning OpenStack is, I figured they would have understood and went "Well you dont know K8N, but you're trainable in this stack.."

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

#37

Post by praseodym »

maxxxxx wrote: post #27

I think this is a symptom of the "release often" philosophy. With yearly or longer releases you could actually keep up and read the release notes. With stuff being released several times a year it's too much work to keep up unless you are deeply into it at the moment. I notice the same with my Android apps. I used to read release notes of new versions but now I have it on auto update and am sometimes surprised that a…

No, it is the symptom of a high velocity project. If Kubernetes were to have yearly releases, the list of changes would be four times as long and upgrade path would be a major leap instead of four minor steps.

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

#38

Post by flyinghamster »

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…

Just trying to keep up with the shifting sands of web programming is a headache in itself. And now we have people wanting to build our whole infrastructure on yet more shifting sand. Argh.

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

#39

Post by jstimpfle »

kakarot wrote: post #26
jstimpfle wrote: post #23

Earlier quoted context omitted.

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…

The most valuable skill is knowing when to externalize your tools. You don't always want to reinvent the wheel every time you need something, when you have deadlines to consider.

Is that in support of using the Boost filesystem API?

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

#40

Post by gouggoug »

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 maintain this infrastructure. And I'm not only talking about our production servers. In reality you have to maintain your prod, your staging, and, worst of all, your local development environment.

Over time, your production staging and dev all become entirely heterogeneous. Each environment ends up running totally different/incompatible versions of all your stack's softwares, and no amount of Ansible/SaltStack/Puppet script will save you from this. All those scripts become a nightmare to maintain and your infrastructure as a whole becomes brittle with, for example, bugs happening only in production, but never on your local dev environment.

K8s came as a savior to all my issues: I burned all my old ansible scripts and rewrote all my infrastructure in k8s. Now my prod, staging and dev env are 99% the same. It saves me a tremendous amount of time and headaches. I taught my team how to use minikube and create a replica of our production with one command line on their local computer.

K8s is far from being just a trendy buzzwordy shiny new cool toy to play with. It solves real world problems that dev ops have. I am so glad this technology exists and I hope to never have to go back to writing ansible/puppet/whatever scripts.

Post reply on HN