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

181–190 of 237 posts

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

#181

Post by damagednoob »

jstimpfle wrote: post #162
onion2k wrote: post #151

Earlier quoted context omitted.

Time spent not doing our own designs (and instead spent memorizing how to use magical frameworks) is time not spent advancing our technical understanding. That's a false dichotomy. The time it takes to "memorize a magical framework" is far less than the time it'd take to learn how to write code to do what the framework does. Consequently you can learn a framework and some other technical understanding in the same tim…

These are still claims without any context. It mostly depends on how experienced the programmer is. And most importantly, note that one never needs all the functionality from a framework. Typically it's only a very small part, and often the existing functionality in the framework does not match the requirements 100%.

I would think this claim is self-evident

> In the case of some large frameworks it'd be practically impossible to implement what they cover on your own. You simply can't learn the underlying principles and then implement them all in code yourself.

Not even DHH would claim to have been able to build the whole of Rails by himself.

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

#182

Post by crdoconnor »

jstimpfle wrote: post #173
collyw wrote: post #166

Earlier quoted context omitted.

Sure and those of us experienced in writing software tend to avoid reinventing the wheel (in a buggy, untested way). I see the value in learning by building yourself, but from a software engineering point of view, using a tried and tested framework is likely to give you higher quality product in less time.

Well, the framework I was to use last (Qt) had bugs that simply can't be fixed by users (memory leaks, double free leading to segfault when exiting after reloading QML engine) and immature modules (for example translation) and forces complicated types to the user and forces bad architectural decisions to the user and significantly increases compile times... > using a tried and tested framework is likely to give you h…

I don't think reinventing the wheel is the right approach. I think careful analysis of bugs and design deficiencies the likes of which you experienced before jumping in and using the framework is the way to do it.

This is why I absolutely love seeing hate filled developer rants about technology with deep dive analyses and links to bug trackers. That's how I was saved from learning Ruby on Rails back in 2008 when most developers gushed about how awesome it after reacting to its slick marketing and building a tiny website in 5 minutes.

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

#183

Post by mooreds »

lkrubner wrote: post #3
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…

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…

Worth dropping a link to this Joel Spolsky article, where he discusses this concept and talks about the fact that the Excel team (in the 1990s) had their own c compiler:

https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

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

#184

Post by mooreds »

cottonseed wrote: post #132
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…

I also like to ask myself, "Do I want to become an expert at working with external software X, or do I want to become the kind of person who can build software like X?"

That's great. However, how does the time to solve the business problems fit in?

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

#185

Post by zaf »

munin wrote: post #15
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…

The short story version of this was written by Arthur C Clarke in 1951, "Superiority" http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html

Thanks for that! Good story!

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

#186

Post by heavenlyblue »

crdoconnor wrote: post #182
jstimpfle wrote: post #173

Earlier quoted context omitted.

Well, the framework I was to use last (Qt) had bugs that simply can't be fixed by users (memory leaks, double free leading to segfault when exiting after reloading QML engine) and immature modules (for example translation) and forces complicated types to the user and forces bad architectural decisions to the user and significantly increases compile times... > using a tried and tested framework is likely to give you h…

I don't think reinventing the wheel is the right approach. I think careful analysis of bugs and design deficiencies the likes of which you experienced before jumping in and using the framework is the way to do it. This is why I absolutely love seeing hate filled developer rants about technology with deep dive analyses and links to bug trackers. That's how I was saved from learning Ruby on Rails back in 2008 when most…

What did you prefer instead?

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

#187

Post by dozzie »

sedachv wrote: post #115
ehnto wrote: post #92

Earlier quoted context omitted.

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

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

Because there wasn't much progress indeed. IT operations is a field advanced by programmers, and most programmers have very little experience with (or even interest in) system administration, so the progress of the field is mainly governed by clueless outsiders oblivious to all the tools and mechanisms already in use. That's why it's a huge pile of mess.

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

#188

Post by crdoconnor »

heavenlyblue wrote: post #186
crdoconnor wrote: post #182

Earlier quoted context omitted.

I don't think reinventing the wheel is the right approach. I think careful analysis of bugs and design deficiencies the likes of which you experienced before jumping in and using the framework is the way to do it. This is why I absolutely love seeing hate filled developer rants about technology with deep dive analyses and links to bug trackers. That's how I was saved from learning Ruby on Rails back in 2008 when most…

What did you prefer instead?

I learned Django instead. I'm cognizant of its flaws but I'm still relatively happy with it.

I think the designers originally intended it to just be "rails for python" but they recognized the pain caused by rails magic and subsequently worked on making django less magical.

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

#189

Post by spotman »

jstimpfle wrote: post #173
collyw wrote: post #166

Earlier quoted context omitted.

Sure and those of us experienced in writing software tend to avoid reinventing the wheel (in a buggy, untested way). I see the value in learning by building yourself, but from a software engineering point of view, using a tried and tested framework is likely to give you higher quality product in less time.

Well, the framework I was to use last (Qt) had bugs that simply can't be fixed by users (memory leaks, double free leading to segfault when exiting after reloading QML engine) and immature modules (for example translation) and forces complicated types to the user and forces bad architectural decisions to the user and significantly increases compile times... > using a tried and tested framework is likely to give you h…

Writing your own QT sounds like a long road however that would likely not be as fast as making work arounds or providing bug reports or patches.

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

#190

Post by moondev »

cookiecaper wrote: post #104
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…

> I don't think your comment applies at all to Kubernetes. It does. I've deployed and maintained our company's infrastructure on Kubernetes for over a year now. > K8s came as a savior to all my issues: I burned all my old ansible scripts and rewrote all my infrastructure in k8s. This doesn't make any sense. Ansible scripts out changes to make to a system. Kubernetes deals only with opaque images and does not change t…

The thing about k8s is it sort of forces you into best practices, immutable images are built and run instead of ansible or config management duct-taping them together. So he replaced his ansible playbooks that build his apps with Dockerfiles

How are you deploying and maintaining your k8s clusters? There is some bootstrapping for nodes but k8s is distro and cloud agnostic... Stateless golang binaries plus etcd. It seems like you should be singing it's praises in that regard on the provisioning front?

Funny enough there has been some work on "self hosted kubernetes" where even the components themselves are inside k8s. Pretty cool will probably be the future of cluster bootstrapping: https://github.com/kubernetes-incubator/bootkube

I'm curious for your reasons for saying k8s is overvalued. You are the first person I have seen that has worked with it and came away with this opinion!

Post reply on HN