Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker is a dangerous gamble which we will regret (2018)

archive.is

Post reply on HN
Print view View original

81–90 of 134 posts

Re: Docker is a dangerous gamble which we will regret (2018)

#81

Post by floriol »

mumblemumble wrote: post #77
dariusj18 wrote: post #70

Earlier quoted context omitted.

I think docker/containers are the opposite of abstraction. It's a reduction of variables and creates true predictability across very disparate systems.

It's, at best, semi-consistent. In the Dockerized stack I'm working on right now, individual services are configured using a mishmash of environment variables, files you volume in (each one with a different format), shell scripts you volume in that will modify configuration files on startup, Dockerfiles that create derivative images that replace configuration files with instance-specific configuration, Dockerfiles wi…

What's your opinion on Nix? Would that count as an improvement in determinism?

Re: Docker is a dangerous gamble which we will regret (2018)

#83

Post by magduf »

mywittyname wrote: post #61
k__ wrote: post #24

Earlier quoted context omitted.

The problem is, as so often, the system. If HR goes as low-level in hiring as "React Developer" then people have to play this game. If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.

Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope. If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unr…

The solution seems pretty simple to me: get rid of the HR and recruiters, at least as having much power in deciding who to interview. That's the hiring manager's job. He knows what kind of person he's looking for, so let him make decisions. Why would you let some non-technical person decide who's qualified to be interviews? It makes no sense. At best, have the hiring manager give some very basic things to look for on resumes to the HR person, so they can screen out the people who are obvious wastes of time.

>If we could find a better way, we'd be using it.

It seems to me that the reason it's so bad is because, at many companies, HR people refuse to admit that they're incompetent at hiring technical people, and insist on inserting themselves into the process to a degree which is highly counterproductive. The only thing HR should be doing is helping hiring managers find the people they need, and otherwise staying out of the way. The bulk of the HR person's time should be on other tasks: personnel issues with existing employees, helping new employees get situated, maybe interpersonal issues, etc. The hiring manager can afford to spend an hour a day looking through resumes and giving good ones back to HR to recruit.

Re: Docker is a dangerous gamble which we will regret (2018)

#84

Post by steeve »

maple3142 wrote: post #36
steeve wrote: post #5

The archive link is down and the original article is dead, so I can't read it... The comments on the article are not kind, however [1][2]. 1. https://www.reddit.com/r/devops/comments/8j9yrn/docker_is_th... 2. https://www.reddit.com/r/docker/comments/8jk22u/docker_is_a_...

Maybe you are using CloudFlare dns? It seems like 1.1.1.1 can't correctly resolve archive.is [1] [1] https://news.ycombinator.com/item?id=19828317

Thank you!

Re: Docker is a dangerous gamble which we will regret (2018)

#85

Post by alxlaz »

pm90 wrote: post #56
alxlaz wrote: post #33

Earlier quoted context omitted.

That hasn't been my experience with docker at all. Except for pretty simple projects, I can't remember a single project I've worked on where I could just follow the README/"Here's how to set it up" email/whatever and have it work the first time. Every time a new developer came in, we'd find out that some implicit assumption was baked in somewhere, and finding out where took hours or days because debugging the damn th…

I don’t wanna gaslight you but this doesn’t match my experience at all. I’ve literally never run into issues with something compiling info one version of docker but not another. Image pulling has been a problem sometimes on Kubernetes but you just need to configure the creds correctly and boom it works.

Hey, don't worry :-). Like I said, I'm open to the possibility that I've been doing it wrong this whole time, or that I worked on projects that kept hitting cornercases and their associated bugs. I'm glad that you didn't have to deal with any of the bad parts.

Re: Docker is a dangerous gamble which we will regret (2018)

#86

Post by mumblemumble »

floriol wrote: post #81
mumblemumble wrote: post #77

Earlier quoted context omitted.

It's, at best, semi-consistent. In the Dockerized stack I'm working on right now, individual services are configured using a mishmash of environment variables, files you volume in (each one with a different format), shell scripts you volume in that will modify configuration files on startup, Dockerfiles that create derivative images that replace configuration files with instance-specific configuration, Dockerfiles wi…

What's your opinion on Nix? Would that count as an improvement in determinism?

Shrug.

I'm a developer, so, in a professional setting, I really shouldn't be having much reason to think about system package management.

From my perspective, the important things are that every single server should look identical to my applications, and there should be no room for confusion between me and devops about how to manage them, and their configuration should be standardized and straightforward and documented enough that devops actually owns the configuration, and isn't just acting as a sort of sock puppet for the dev team.

I'm personally of the opinion that less is more: Every time you add a tool, you add more nooks and crannies and places for dust bunnies to collect. So, to that extent, I guess my question is, "How does Nix improve determinism in a way that (say) RPM doesn't?"

If the motivation for the answer answer involves assuming that you've released a Lovecraftian horde of different languages and platforms that each have one or more of their own special snowflake package management systems all crawling all over each other to try and muck with the same global system environment, I'm gonna slam the lid back on that Pandora's box. I'm not gonna try letting them have their fun by hellbanning them to their own private parallel universes where they all get to think that they're mucking with the system environment. An insane asylum with locked doors is still an insane asylum. No, I'd rather kick that whole mess to the curb and instead say that only well-behaved applications that know how to color inside the lines get to run in the shared environments.

Obviously this attitude doesn't work if you're a cloud platform or a smartphone OS or some other agent that isn't able to impose very many rules on the authors of the software that runs on your platform. Thankfully, I am not and have never been a Google, so the KISS principle remains an option for me.

Yeah, I realize that this means I'm swimming against the current. My resumé would probably look a lot better to the (probable vast majority of) companies who are thinking, "Only 357,453 new hires to go until we're as big and complicated as Amazon, better start planning for it now!" if I changed my attitude. Perhaps I'm too old to learn new tricks.

Re: Docker is a dangerous gamble which we will regret (2018)

#87

Post by rossdavidh »

pc86 wrote: post #46
k__ wrote: post #24

Earlier quoted context omitted.

The problem is, as so often, the system. If HR goes as low-level in hiring as "React Developer" then people have to play this game. If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.

HR having any role more substantial than confirming that an applicant can legally work in the US and isn't lying on their resume is the problem.

In other words, only the parts that they are trained and qualified to do, yes. The parts that a developer team lead or team manager would not be good at. Makes sense.

Re: Docker is a dangerous gamble which we will regret (2018)

#88

Post by LoSboccacc »

busterarm wrote: post #26
shadowgovt wrote: post #25

Earlier quoted context omitted.

It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé. If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing func…

Do you actually think Kubernetes infrastructure is built without hair-pulling and rage? If so, I've got some stories for you.

yeah but for fighting with all the details once upfront you get an infinitely replicable environment.

not just scalability but you can have as much test environments, all identical, spinning up with an apply. and the next guy in line can do it too! possibly with a convenient front-end and little understanding, so you can spend your skills elsewhere

not for everyone, sure, but then which tool is?

Re: Docker is a dangerous gamble which we will regret (2018)

#89

Post by digitalsushi »

mywittyname wrote: post #61
k__ wrote: post #24

Earlier quoted context omitted.

The problem is, as so often, the system. If HR goes as low-level in hiring as "React Developer" then people have to play this game. If HR would hire on something more substantial, it wouldn't matter if you did Linode or AWS, React or Angular, Docker or Bash scripts.

Hiring people is difficult, exhausting, time-consuming, and largely a crap shoot, since hiring consists of deducing a person's technical abilities with around 1-2 hours of interaction in a very limited scope. If we could find a better way, we'd be using it. But, as it stands, recruiters and HR have only a few minutes per potential candidate to determine whether or not they meet the hiring manager's criteria. It's unr…

It would be cool if the industry let us play "Confident Applicant's Gambit": I will agree to work for you, dubious but reputable employer, for six weeks to prove my mettle.

At the end of the six weeks, we part ways unless I have clearly demonstrated I am in fact, the genuine article, at which point you owe me back pay, and commence my salary which is about 140% of what you would normally pay someone. Quite a bargain for you.

The intention of this being, the employer is not at risk for slave labor, but the applicant is clearly wasting their time if they know they are not genuinely solving a problem the employer has for the given salary.

Re: Docker is a dangerous gamble which we will regret (2018)

#90

Post by busterarm »

LoSboccacc wrote: post #88
busterarm wrote: post #26

Earlier quoted context omitted.

Do you actually think Kubernetes infrastructure is built without hair-pulling and rage? If so, I've got some stories for you.

yeah but for fighting with all the details once upfront you get an infinitely replicable environment. not just scalability but you can have as much test environments, all identical, spinning up with an apply. and the next guy in line can do it too! possibly with a convenient front-end and little understanding, so you can spend your skills elsewhere not for everyone, sure, but then which tool is?

I had that with terraform before Kubernetes anyway.
Post reply on HN