The full-time job of keeping up with Kubernetes • Hacker News Board

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

#231

Post by cookiecaper » Sat, Feb 03, 2018, 3:55 AM UTC

jacques_chester wrote: post #226

cookiecaper wrote: post #133

Earlier quoted context omitted.

You still have to define the state to solidify, whether that state is represented by a Docker image or not. That means you still have to script the system before you can crystallize it. Any mistakes you make are still there, so the fact that your scripts are mistake-prone doesn't change anything either way. k8s doesn't help you there, it just adds a nice thick new layer of stuff to break. Snapshotting state in opaque…

I agreed with you until the conspiracy theory. Sort of a self-fulfilling thing, that.

There was no theory until my account was rate-limited for posts suggesting that people not use databases on Kubernetes. These were ruled too "tedious" by dang; they rate-limited my account and marked my post at [0] as off-topic. Maybe I just missed the part of the guidelines that said not to be too dry when discussing container orchestration.

It's not really self-fulfilling if it's already happened; I think that's just called "information about an event".

I think my view that humans are imperfect (yes, even the super-fancy humans at YC, who do have a horse in this race as investors in Docker Inc.) and will censure things they dislike is plenty justifiable given the events. That's especially the case if these people are being pressured to take that action by other high-status individuals.

For the record, dang has explicitly disclaimed my theory, rather suggesting that asking people not to run their database in Kubernetes constitutes a flame war. I don't have the link to that handy but I'm sure it wouldn't be hard to find for an interested party.

The reader is free to ascribe motives as they see fit.

[0] https://news.ycombinator.com/item?id=14453705

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

#232

Post by scarface74 » Sat, Feb 03, 2018, 2:32 PM UTC

Combining my brief time trying to put together a proof of concept with Kubernetes and reading articles like this, I'm so glad I chose Hashicorp's Nomad. It's simpler to configure, more versatile (shell scripts, executables, and Docker containers) and a decent third party UI - HashiUI. With Consul, configuration is dead simple.

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

#233

Post by mooreds » Sat, Feb 03, 2018, 10:37 PM UTC

protoplant wrote: post #223

mooreds wrote: post #183

Earlier quoted context omitted.

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

I am glad I read this just now, I was jumping from hoop to hoop. and not only hoops but craft paradigms, reminds me of the Fred Brooks idea "There is no silver bullet". Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity." He also state…

Glad it helped. Brooks should be required reading for every developer: software is hard.

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

#234

Post by collyw » Mon, Feb 05, 2018, 2:53 PM UTC

oblio wrote: post #196

collyw wrote: post #170

Earlier quoted context omitted.

Most places only need a fraction of the functionality of Jira.

Most developers underestimate the complexity of any project :) Especially one that becomes a crucial component of a company's workflow (as is the case for bug trackers in any properly run software company).

I would say its more of the case that developers unnecessarily make projects more complex than needed. Certainly on the last couple of projects I have inherited.

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

#235

Post by SatvikBeri » Mon, Feb 05, 2018, 10:07 PM UTC

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…

Recently, I spent some time trying to run several machine learning jobs simultaneously across AWS machines. This was a fairly simple use case: all the jobs were totally independent of each other, you could run them by calling a Python function with different parameters.

I'm mostly a stats guy and not much of a programmer. I got a hacky, do-it-myself version using Python scripts up and running with about two hours of work, and learned about Python threads for the first time in the process, a tool that I can reuse in many different areas.

I then tried to do this the "right" way, which according to Amazon is to use Docker and the AWS tools ECR, Batch, and SQS. It took me about 10 times as long to get that working. Yes, this offers much, much more functionality - but most of it is stuff I didn't need. The only real gain I got was my models running about 20% faster, and the knowledge I learned is ephemeral.

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

#236

Post by crb » Tue, Feb 06, 2018, 12:39 PM UTC

hueving wrote: post #217

crb wrote: post #88

Earlier quoted context omitted.

> The people that work on upstream k8s in Google (Tim et al) have a pretty limited overlap with the Google Cloud people that run GKE. I happen to be in the building so I sat in on an engineering review for a proposed new GKE feature today. Tim was there, as was Brian Grant, and pretty much everyone else you've heard of (in the room or on the VC). There were also a good number of PMs, SREs, and the leads/engineers wor…

Engineering review is not the same thing as reviewing and writing code. I've seen countless projects with sound designs riddled with implementation bugs due to people not fully understanding the intent of certain systems. Sitting in a room during a high level engineering review falls squarely under "limited overlap".

Well, you can trust me that it doesn't, or you can send me your CV for a referral.

Plus, there's this: https://www.quora.com/What-is-Googles-internal-code-review-p.... But you'll just complain that the OWNERS aren't the right people, and I'll just comment that they are.

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

#237

Post by nu-world-odor » Tue, Feb 06, 2018, 6:16 PM UTC

collyw wrote: post #234

oblio wrote: post #196

Earlier quoted context omitted.

Most developers underestimate the complexity of any project :) Especially one that becomes a crucial component of a company's workflow (as is the case for bug trackers in any properly run software company).

I would say its more of the case that developers unnecessarily make projects more complex than needed. Certainly on the last couple of projects I have inherited.

Let's not forget that coupled with the complexity is the failing business cases bro!! the business units fail--yeah. JIRA is just some vast snowflake.