Live data from Hacker News

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

archive.is

111–120 of 134 posts

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

#111
post #102

Earlier quoted context omitted.

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.

Unfortunately temp-or-contract-to-hire is automatically the bottom 1/3 of available people. A CHRO thought this was a brilliant solution to the six-month searches those silly people in IT kept complaining about.

Been there, done that, it doesn’t work in practice. We had to unwind nearly all of them after a few weeks, and all the on boarding wasted copious amounts of time for existing staff.

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

#112
post #105

Earlier quoted context omitted.

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.

> There is varying support for Kubernetes resources

I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.

I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.

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

#113

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…

In Germany we have a probation period of 6 months in which both partys can resign at any time, no questions asked.

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

#114
post #76

This might be the most short sighted article I have ever read. One of humanity's greatest achievements was the creation of the intermodel shipping container( https://en.wikipedia.org/wiki/Intermodal_container ). We literally would not live in the world of convenience we have today without it. But imagine what the curmudgeon of the day had to say about this. "Why do I need to use this specific container? This containe…

The shipping container was a solution to a problem.

Kubernetes? The jury's still out on that.

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

#115
post #12
post #6

Earlier quoted context omitted.

The youngsters in my work keep sticking everything on docker to avoid packaging problems. I just makes running coed in a stepthrough debugger impossible so far (I know its possible but I haven't had the time to make it work yet). One step forward two steps back.

Recently started working with other younger devs and I feel like every single application they write starts with a docker compose scaffolding. Containers have uses but they're being treated like silver bullets and building new levels of unnecessary complexity in many cases.

[deleted]

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

#116
post #105

Earlier quoted context omitted.

You did not.

> There is varying support for Kubernetes resources I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room. I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.

> I dunno, EKS not having built-in support for Ingress objects is a pretty large and obvious elephant in the room.

Which is actually not a big deal. K8s ingress objects are not very flexible, and most users in my experience tend to use customized solutions (e.g. ambassador) where you use a Network Load Balancer. Ingress objects are fully supported in GKE.

> I'm not playing this game. I've stated my experiences and suggested the level of interaction I've had with the platforms in dollar figures enough to be comfortable with what I'm saying here.

You started playing this "game" by dropping numbers on how many $$s you've managed and asking that other believe you because of that. I was simply asking you to provide specific instances of the pain you're stating you see. The one instance you've provided isn't really that big of a deal.

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

#117
post #108

Earlier quoted context omitted.

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

Nah, not bye karm at all. I realize that's how devops is supposed to work. It's just that I've never seen it work that way IRL.

I suspect that the ideal of devops is only practical in very small companies. Past a certain scale, social factors become at least as important as technical ones in deciding how responsibilities will be divided. It's hard to feel confident about that having never seen "bonafide devops" even being attempted anywhere but on paper, though.

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

#118

If I use Docker, I get to put "Docker" on my resume for the next job; if I use bash scripts I don't. If I use React, I get to put "React" on my resume; if I use vanilla JS I don't. If I use Kubernetes, I get to put "Kubernetes" on my resume. If I use AWS, I get to put that on my resume, if I just spin up a Linux instance using Linode or etc, I don't Of course, I would have to convince my boss to let me do all of thes…

> and the basic reason is that both devs and managers want to pretend they are working at FAANG, so that someday they will work there.

Strongly disagree. The reason they prefer Docker is that nobody wants to read your bash script. They want a standardized set of tools they can familiarize themselves with using curated examples and a large community.

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

#119
post #7

I completely agree. My team has spent the last several years building software we then deploy with Docker and Kubernetes, and looking back I think that our software would have been much better deployed as statically-linked binaries on simple Linux servers. We're writing in Go, which means we already have the statically-linked binaries, which means we have a single file which needs to get deployed. What does Docker bu…

> with a few dozen-line shell scripts to copy binaries around,

Sounds like you're looking for Ansible.

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

#120
His arguments seem week. I’ve used both docker and k8s for couple of years now. Sure there is a learning curve but because shit is consistent and sane we’ve been able to have better uptimes, and our pages went significantly down(self healing and auto-scaling properties of k8s are a god send).

Before we used to fab-ssh into the servers, manually ask some human at softlayer to provision new servers, bash script install things, and use native package managers like pip install. Fun fact. Pip is not deterministic. Until package-lock came, npm wasn’t deterministic. Things that worked in dev and staging would end up borking prod and we’d be serving 500s. Other language package managers had similar issues.

I see docker as just a glorified package manager. Make a docker file, build an image, run the same image in prod/dev/stage for consistency.

That is a huge timesaver.

Post reply on HN