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

201–210 of 237 posts

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

#201

Post by bpicolo »

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…

> even the smallest team and website can greatly benefit from it

I don't think that's true. You have to be at least large enough to justify reasonable investment in microservices.

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

#202

Post by drdaeman »

lomnakkus wrote: post #81
drdaeman wrote: post #41

Earlier quoted context omitted.

I think there is a difference between knowing the tech enough to list in in a resume, and actually using it. I sort of know K8s. I have experimented with it, have set up a few smaller but nonetheless "real" clusters, I have ran various apps on them, have broken them with various sorts of fault conditions, have tried to repair them. Without this I wouldn't be able convince myself my opinion of K8s is even remotely clo…

> I think there is a difference between knowing the tech enough to list in in a resume, and actually using it. Of course, but the difference doesn't tend to come across on a recruiter's spreadsheet. Nowadays, I only go by personal recommendations/references. Just as an aside, and as an offer of XP: Tech A is largely irrelevant unless you have to execute in, say, 1 month. Success almost never depends on the tech -- it…

> Success almost never depends on the tech -- it mostly depends on people.

Of course, that's true. But my understanding is, the technology choice is not about succeeding or failing - a good team with good plans can succeed with just about any tech that can somehow do the job. It's about costs. Complex but featureful tech may drive development costs down, but may also result in significantly higher maintenance costs.

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

#203

Post by notyourday »

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.

For 99% of companies, including the ones employees post here container and container orchestration is a resume driven development of devops/engops/sre/seniordevs caused by improper hiring, improper vetting of ideas and personnel and fixation on cargo cults.

It is no different from cargo culting in sales where a perfectly functioning company slowly but surely building up brings in a CRO (can you imagine this showed up as a title?! ) who says "We will sell differently! Give me account managers! Give me sales development representatives! Give me customer happiness coordinators and we will sell to enterprise accounts at 50x contract value!" So the company hires a hundred people in those roles and it does look like the contracts are creeping up. So the CRO says "I know! The issue is that we are spedning too much time on paperwork. Hire me salesops! And give me all these Sales Force integrations! And special IT people reporting to me operating these new tools" So the company hires more people for those roles, burning through millions of dollars in salaries but at the end... the new customers are still just a trickle.

Eventually CRO gets fired and most of the people who got hired on that push are gone as well as millions of dollars are spent. If they spent those millions on Google ads or Facebook ads they would have definitely gotten more revenue but plain Google ads and plain Facebook ads are not sexy.

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

#204

Post by jstimpfle »

Klathmon wrote: post #198
jstimpfle wrote: post #180

Earlier quoted context omitted.

> Or maybe Windows has mounted or network sharing, a Unix filesystem... In which case your program better deal with long paths (or just fail?) 260 bytes is long. I've never seen a \\?\ path in the wild, and I don't want to. It's a misdesign (well, I'm sure the designer didn't want to design it...). But I'm repeating myself... I can't practically deal with paths longer than, say, 64 characters (can't read them, let al…

That is such an awful toxic viewpoint to take. "Fix my paths"!? Fix your software! I work from a network share that is about 70 chars long to get to my one project's folder. The beauty of hierarchical file systems is that I can cognitively ignore all the previous paths and just work from there. However when your software doesn't work because "the solution is a misdesign", it's not my path that is wrong, it's your sof…

> 70 chars

Still supported by 260-byte filepaths. Asking nevertheless: Why? The path to the network share should be easy to abbreviate.

More philosophically: I'm sorry that you can't use file systems because most support only filenames up to 256 bytes. I'm sorry that you can't use the web because most browsers only support URLs up to 2048 bytes. I'm sorry that you can't use a keyboard because they have only 8-bit scancodes. I'm sorry that you can't use the network because frames can only be so big. I'm sorry that you can't watch a movie because a disc fits only so many bytes.

It's truly a toxic world.

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

#205

Post by gaius »

ionforce wrote: post #72
flukus wrote: post #66

Earlier quoted context omitted.

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

> Bug trackers are one of those areas where a lot of companies should build there own. This sounds insane. I have not worked at a place where the workflow was so holy and important that it couldn't be captured in a near default JIRA install. Most of the customization asks I've seen with JIRA come from dysfunctional organizations that demand new swimlanes like "QA" and "product approval" and "spec design".

I have not worked at a place where the workflow was so holy and important that it couldn't be captured in a near default JIRA install

JIRA out-of-the-box is surprisingly sane - most people who hate JIRA really hate the custom workflows their own organisation has inflicted on them.

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

#206

Post by jstimpfle »

notyourday wrote: post #199
robocat wrote: post #116

Earlier quoted context omitted.

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

> Your "two decades" maybe holds for Linux, but what about Windows or MacOS???! Is my target application going to run on Linux? If so, then I do not care about Windows or MacOS, just like I do not care about CBM64 or Amiga. My goal is not to write an awesome system that wins design awards in handling of obscure edge cases thrown at it in a coffee shop by hipster developers. My goal is to build a system that solves my…

...and since you wrote straightforward code not relying on obscure platform-specific technicalities, even if you wanted to port it later, the port of the filesystem code was just a few #ifdef's away.

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

#207

Post by sethammons »

bpicolo wrote: post #200
kuschku wrote: post #158

Earlier quoted context omitted.

On the other hand, dependency management in go in any sane way is such a byzantine task that it takes ages to get working, and even then it still doesn't. Given an empty set of environment variables, setting up a new go project with dependencies and all in a way that people cloning it later on can also use the dependencies in a single command, without vendoring dependencies, without building custom scripts, is imposs…

It's impossible with first party tools, but I've had a great experience with Glide. That said, go drives me up a wall. Using interface{} to muck with JSON and typecast every step of the way is just my nightmare. It's inelegant in every way

Type cast every step of the way? Methinks you are either doing something wrong or dealing with unstructured json.

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

#208

Post by Klathmon »

jstimpfle wrote: post #204
Klathmon wrote: post #198

Earlier quoted context omitted.

That is such an awful toxic viewpoint to take. "Fix my paths"!? Fix your software! I work from a network share that is about 70 chars long to get to my one project's folder. The beauty of hierarchical file systems is that I can cognitively ignore all the previous paths and just work from there. However when your software doesn't work because "the solution is a misdesign", it's not my path that is wrong, it's your sof…

> 70 chars Still supported by 260-byte filepaths. Asking nevertheless: Why? The path to the network share should be easy to abbreviate. More philosophically: I'm sorry that you can't use file systems because most support only filenames up to 256 bytes. I'm sorry that you can't use the web because most browsers only support URLs up to 2048 bytes. I'm sorry that you can't use a keyboard because they have only 8-bit sca…

>Still supported by 260-byte filepaths.

Because now programs that thought "260 is enough" now only have 190 left, and i've seen (and had software not work with) several pieces of software that have more than that. Because the assumption is that this is a solved problem on all OSs, and that 260 is no longer a hard limit.

>Asking nevertheless: Why? The path to the network share should be easy to abbreviate.

Because that doesn't actually solve the problem. I can abbreviate it on my connection, but not on the server, and if the server is running some poorly written software, it will choke when from my point of view i'm only using 190 characters. As for why, it's segmented by country/company/department/team/name/employeeid/

Then it is my folder, where I have things like clientInformation/[softwarePackage]/[client]/[testFiles|documentation|uniqueArchitecture]

Just the example without any real names is over 100 already. I just went and looked, I was being conservative with my 70-character estimate, a few of my folders are over 180 characters long just to the [client] part of my path.

Also why abbreviate it when we can write software that can handle that for us? Why should I need to shorten my paths to potentially confusing and misleading names just so some people can ignore solved problems in the name of "complexity". Not to mention that abbreviation isn't really a "solution" (what happens when there are collisions? Now you need a complicated "maintained and interpreted by humans" system to manage it, that's not simpler, that's more complex).

I'm honestly not going to respond to the rest, because we both know that those are strawman arguments.

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

#209

Post by jstimpfle »

Klathmon wrote: post #208
jstimpfle wrote: post #204

Earlier quoted context omitted.

> 70 chars Still supported by 260-byte filepaths. Asking nevertheless: Why? The path to the network share should be easy to abbreviate. More philosophically: I'm sorry that you can't use file systems because most support only filenames up to 256 bytes. I'm sorry that you can't use the web because most browsers only support URLs up to 2048 bytes. I'm sorry that you can't use a keyboard because they have only 8-bit sca…

>Still supported by 260-byte filepaths. Because now programs that thought "260 is enough" now only have 190 left, and i've seen (and had software not work with) several pieces of software that have more than that. Because the assumption is that this is a solved problem on all OSs, and that 260 is no longer a hard limit. >Asking nevertheless: Why? The path to the network share should be easy to abbreviate. Because tha…

No strawmans in the slightest. Exactly the same kind of very real (and not really solveable) "problems".

It's beyond me how far removed from reality these arguments are. You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes), and they could easily be fixed (which would be a win on all non-technical fronts as well), but still you're complaining for no good reason. You clearly lack experience with low-level issues - just imagine what a technical mess it is in Windows to support longer paths (I think there is a concept called "junction points" to support them). Please, can we turn to actual problems?

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

#210

Post by Klathmon »

jstimpfle wrote: post #209
Klathmon wrote: post #208

Earlier quoted context omitted.

>Still supported by 260-byte filepaths. Because now programs that thought "260 is enough" now only have 190 left, and i've seen (and had software not work with) several pieces of software that have more than that. Because the assumption is that this is a solved problem on all OSs, and that 260 is no longer a hard limit. >Asking nevertheless: Why? The path to the network share should be easy to abbreviate. Because tha…

No strawmans in the slightest. Exactly the same kind of very real (and not really solveable) "problems". It's beyond me how far removed from reality these arguments are. You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes), and they could easily be fixed (which would be a win on all non-technical fronts as well), but still you're complaining for no good reason. You clearly lac…

But this is solvable! You are the one claiming it's too complex then refusing to use the well tested solutions...

>You have insanely long paths, and that's still miles away from a reasonable limit (256 bytes) but still complaining.

Because that's just the path to a folder, that still doesn't contain any data! unpack an archive from a server in one, and suddenly poorly written software is blowing up because someone used a GUID as a folder name, or there is software running there that assumes "why would paths need to be less than 60 characters!?" and nests files into a bunch of folders using the filesystem as a tree of hashes.

I think the problem here is that these aren't imagined problems, they are problems I've run into in the past year or so. The difference between this and your strawman arguments is that there are solutions to all of those problems as well, but for some reason you don't see them as superfluous.

I don't know why I let myself get roped into a pointless internet argument. "You clearly lack experience with low-level issues"? Man I'd love to see how you determined that from a few comments about file paths...

Post reply on HN