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

61–70 of 237 posts

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

#61

Post by botskonet »

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…

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 staging servers.

Unfortunately my current company is 100% against third-party hosting/involvement so I couldn't even use it for staging - our stagings servers are Windows-based, ancient, and internal...

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

#62

Post by DougWebb »

wmf wrote: post #48
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…

LTS releases aren't really about stability or upgradability; in practice I think they're more often used as an excuse to never upgrade because the risk of applying 2-5 years of changes at once is too high. It sounds like k8s is trying to nudge people into a more continuous deployment model.

The last thing I want from an external supplier of something I depend on is to have them driving my development and release cycle. I'll expend the resources to upgrade to your latest version when it's worth my time and cost.

Edit: I'm speaking to the vendor here, not you, of course...

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

#63

Post by deckard1 »

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…

> Yeah, I went through 3 stages of hiring with $company.

My BS radar goes off when I get asked for a 2nd interview, or any 4 hour group interview. Thanks, but no thanks. They did you a favor.

These interviewers are crazy, and have zero proof their convoluted process produces better hires than a single 30 minute coffee interview. They just don't want to admit they don't know what they are doing. As if the heavens will open up and god himself will shout down "He's the one!", if they just have enough rounds to get there.

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

#64

Post by riazrizvi »

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…

It's usually framed as the Build Vs Buy question. When do you stop your search for an adequate ready-made solution and just build it yourself?

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

#65

Post by jstimpfle »

islanderfun wrote: post #46
kakarot wrote: post #26

Earlier quoted context omitted.

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.

Exactly this. There's a ton of gray here. Have to pick your battles as best as you can. Another example are game engines. Hard deny the value engines like Unreal and Unity provide. They are hard to ignore and have thousands of expert hours put into them.

A good way to pick battles is not to fight most of them. There are so many solutions that don't have any real problems...

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

#66

Post by flukus »

enraged_camel wrote: post #25
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…

Sure, NIH syndrome can be rational for technology that is crucial/central to your system. The problem is it is often used to justify re-inventing even mundane stuff. I once worked with a client who wanted to implement their own bug tracking system. The client’s main product was something totally unrelated.

Bug trackers are one of those areas where a lot of companies should build there own. Everyone has there own workflows and information to capture and end up either conforming their process to the bug tracker or spending more time configuring the bug tracker than they would to build a new system from scratch. Those uber configurable systems always suck to use.

Ones like JIRA can takes weeks to setup for your org and include their own query language. All of this complexity just to do something so simple is not rational.

As long as you don't over engineer it then it's only a days work to get something up and running and it's a great project for interns.

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

#67

Post by maxxxxx »

praseodym wrote: post #37
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.

I think a major leap is much easier to handle and to plan for.

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

#68

Post by halayli »

SteveNuts wrote: post #34
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.

Just to be clear I am not insinuating that new tools and their developers are inferior. But backward compatibility is also very important.

When I am using version 1.9 stable release of a product i’d expect more stability

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

#69

Post by tacticus »

DougWebb wrote: post #62
wmf wrote: post #48

Earlier quoted context omitted.

LTS releases aren't really about stability or upgradability; in practice I think they're more often used as an excuse to never upgrade because the risk of applying 2-5 years of changes at once is too high. It sounds like k8s is trying to nudge people into a more continuous deployment model.

The last thing I want from an external supplier of something I depend on is to have them driving my development and release cycle. I'll expend the resources to upgrade to your latest version when it's worth my time and cost. Edit: I'm speaking to the vendor here, not you, of course...

And you can indeed just sit around on an older version. The vendor in this case just won't bother doing stuff to help you.

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

#70

Post by gouggoug »

mbrumlow wrote: post #52
gouggoug wrote: post #40

Earlier quoted context omitted.

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…

> and no amount of Ansible/SaltStack/Puppet script will save you from this. And I am afrade you missed my point entirely if you are bring up yet again more tools and frameworks. Owning your stack from the top to the bottom - with very few exceptions is what I am suggesting. I too also speak from experience, and have a few years on you -- not that any of that matters. If your environments diverged then you did not own…

I'm curious. Could you describe the kind of infrastructure you manage and the tools do you use? Are all your tools written in house? If so, what will happen when the author leaves the company?
Post reply on HN