Live data from Hacker News

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

archive.is

101–110 of 134 posts

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

#101
post #83

Earlier quoted context omitted.

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…

This is assuming technical hiring manager, which may often not be so. Also, a team often wants new hires with all the latest buzzword experience as they are too swamped themselves.

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

#102

Earlier quoted context omitted.

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…

Just hire temps and maybe extend contract. Already overdone and creates helluva toxic and abusive env.

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

#103

Earlier quoted context omitted.

I had that with terraform before Kubernetes anyway.

...aren't them from the same age?

Two different paths that can get you to the same place (but usually don't and surely Kubernetes is the cheaper option month-to-month).

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

#104
post #83

Earlier quoted context omitted.

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…

Maybe have experienced different approaches, but where I've worked, the hiring manager told HR what skillset they needed and HR would fire over resumes for the team to look at and decide who to bring in. Our team decided 100% who to hire and not.

So, basically what you're talking about already happens at every company I've been involved in hiring at. HR posts the job posting from the manager, forwards resumes that look good. The do perform the initial non-technical interview, but teams handle technical interviews as they see fit. HR is only involved to present the offer.

Because of that, I took the parent comment to say that HR should be better at resume fishing. Meaning, they should understand technological equivalencies better, like MySQL and Oracle are somewhat equivalent or related skills but Bash and Elasticsearch are not. This is what recruiters are supposed to do; obviously most are bad at it, but his is largely because few SWE/SysAdmins/DevOps are going to pivot into recruitment.

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

#105
post #92

Earlier quoted context omitted.

Give specific problems you see and I will give you a reasoned reply. I will not engage with hyperbole devoid of facts.

It's help I don't need and didn't ask for. I'm managing several million dollars worth of infrastructure in both. I gave enough detail that anyone familiar enough with both platforms should know some of the issues I'm talking about already.

You did not.

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

#106

Earlier quoted context omitted.

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…

More concise than other responses: HR isn't qualified to hire for technical positions, then, and team members should evaluate other potential team members.

I commented elsewhere, but this is how it works at every job I've ever had and interviewed for. And I'm not some "SV ninja coder" either, I'm just a regular Joe working regular jobs. Hiring manager tells HR to post a job, they send over the resumes that they get, and schedule interviews with anyone who looks good.

With my last three jobs, the involvement with HR was limited to initial phone screen, asking about salary and legal status, then onto the hiring manager for the rest.

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

#107

Earlier quoted context omitted.

Out of curiosity, have you considered using ECS instead? If not, why not? (Disclaimer: I work for AWS as a specialist solutions architect.)

Not that person, but I do a lot of docker at a big enterprise. Sell me.

Drop me a line - eff eye ess see emm eye at amazon dot com :)

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

#108
post #81

Earlier quoted context omitted.

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

devops = dev (you) + ops

P0wning solution together.

Not a position, a role, a team, etc..

Bye karm

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

#109

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?

Maybe I'm particularly unfortunate, but that wasn't my experience at all. It's either bash scripts that make you want to pull your hair out, or yaml files that make you want to pull your hair out.

The same people who wrote these bash scripts are writing yaml files, and with k8s there are infinitely more interesting ways to bork your jobs.

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

#110

Earlier quoted context omitted.

The author addressed exactly this type of comment. I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files. And for the deployment, the alternative given by the author is using fat binary.

> I don't see the real difference in complexity of maintaining 12+ bash scripts instead of the same number of Docker files. With respect, I have to assume your experience is either in an ecosystem with really strongly-established best practices for bash (and someone with the job of enforcing said practices) or your organization has no more than two or three people maintaining those dozen-plus bash scripts (and is on…

Well-written ksh/bash is extremely light-weight, flexible, concise and easy to maintain. Changing shell or OS would be the headache, but easily outweighted by gains if used for the right jobs.
Post reply on HN