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

61–70 of 134 posts

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

#61

Post by mywittyname »

k__ wrote: post #24
rossdavidh wrote: post #20

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…

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 unreasonable to expect HR/recruiters to keep abreast of an ever expanding list of technologies and their analogs because that's not their core competency. Unless they are repeatedly told that GCP experience is worth like 70% of AWS experience (replace the values and technologies as you see fit), they aren't going to know that.

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

#62

Post by falcolas »

pm90 wrote: post #55
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.

Using managed kubernetes solutions alleviates most of the hair pulling.

Speaking as someone using EKS: No, no it doesn't. The only thing we really handed over to someone else was the challenge of running a control plane. We still have to roll our own node images (for compliance reasons, the default images are insufficiently secure), still have to work directly with AWS to get larger etcd clusters, still have to manage the cluster itself...

The trouble has barely been below the threshold of pain to just run our own control plane.

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

#63

Post by falcolas »

nickthemagicman wrote: post #37
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.

Well it's contained the hair-pulling and rage to just the kubernetes administrators instead of the whole organization. :P

No, the rage extends to the developers too. Writing all of the yaml for a full service requires a fair bit of understanding of what's going on in k8s. And helm templating.

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

#64

Post by jskrablin »

matteuan wrote: post #17
vorpalhex wrote: post #11

Oh geez, having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services sounds like a disaster. Instead we have a single workflow for docker, whether it's going out to AWS or Kubernetes and all the services use an identical flow. Integration testing is a cinch since it's running actual, version matched postgres/redis/etc on the CI nodes which…

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.

Docker file produces what basically is a software package with all the required dependencies. Deploy it to some Docker host and it will most likely run. It will run on a developer laptop, a VM or in K8s/Mesos/Nomad cluster. Add some docker compose files and you'll be able to run your whole service locally with all the external dependencies if you think that's a good idea. Extra bonus is... target system requires Docker daemon only. So no extra work to support Ruby/Java/Go/Python runtimes.

Alternatively you can go and package tar files. Or create Debian/Red Hat/Nix/whatnot compatible packages and manage dependencies via a package manager. You can go with Snap or Flatpak to achieve ~ the same. However Docker images produced by the said Docker files will most likely just run on any of the said OSes with no or little additional work and probably on the OSX and Windows too. And people will be pretty happy that running docker build $some_opts will (likely) give them a working app/(micro)service and that they don't have to mess with $some_packaging_system to rebuild and test stuff locally. So I guess Docker files provide some extra flexibility even if the maintenance burden is matched to the one required for maintaining bash scripts.

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

#65

Post by forgottenpass »

I don't trust people who like their software tools. I can trust some of the people who believe that their usecase justifies the cost of a tool, as long as they can also articulate it's limitations. If someone doesn't understand the environment and problem a tool solves well enough to rattle off a laundry list of good, bad and ugly design decisions, then their baseline analysis doesn't have any utility.

It's a subtle distinction, because once someone is primed that these are the two options, everyone thinks they're in the second category. You have to give someone enough rope and hope they offer up how much they "love" their toys.

I like this article because the container toolset ecosystem needs criticism to evolve. And we don't see enough of it.

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

#66

Post by shadowgovt »

matteuan wrote: post #42
shadowgovt wrote: post #27

Earlier quoted context omitted.

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

You judge "with respect" my experience instead of answering to the argument. So why is it easier with Docker?

Because a Docker config makes it hard to accidentally wipe your filesystem instead of building a Docker image. Shell scripts make that less difficult (and any solution using shell to do something similar to Docker will have a bespoke layer of in-house code that should be correct but will require maintenance by your team to make sure nobody makes a change that turns it into a filesystem-eater).

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

#67

Post by rjkennedy98 »

pc86 wrote: post #49
mattxxx wrote: post #39

Docker may be over-used, but, when managing hundreds of instances of machines, it's really useful to have deploys/redeploys/updates: - Immutable (the instance is effectively frozen as an image) - Has dependencies baked in (don't have to worry about whether the app was run on xenial/bionic,etc.) - Identical (people are disincentivized to make ad-hoc modifications to instances)

> when managing hundreds of instances of machines Well there's the rub. Most developers aren't going to manage hundreds of machines. My current company has thousands of customers, over a hundred employees, and makes tens of millions in profit. We've got two dozen servers (VMs) and obviously less than that in actual machines. The scale at which you need hundreds of instances is probably when it does make sense to use…

A lot of developers work in big companies.

My last company had 2400 OpenShift cpu cores assigned just to unused OpenShift projects. I'm sure the number of used OpenShift cores was in the tens of thousands.

For instance just a Kafka consumer that needs to sync a few billion records to cassandra and ElasticSearch by itself may use 50 cores.

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

#69

Post by skube »

notacoward wrote: post #40
ex_amazon_sde wrote: post #15

Earlier quoted context omitted.

Amazon (and other FAANGs) use OS packages and do not use Docker nor Kubernetes or anything with all that complexity. This is a deliberate choice, at least in Amazon.

Maybe you know how it is at Amazon, but your statement is definitely not true for two other FAANGs. It's well known that Kubernetes is the open-source version of tools that already existed within Google, and Kubernetes itself is part of some public-facing products. I work at Facebook, and we most definitely do have our own equivalent of Kubernetes. It's awful in all of the same ways IMO. We also build fat binaries (a…

That's a lie. Was Borg replaced by kubernetes?

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

#70

Post by dariusj18 »

mumblemumble wrote: post #47
vorpalhex wrote: post #11

Oh geez, having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services sounds like a disaster. Instead we have a single workflow for docker, whether it's going out to AWS or Kubernetes and all the services use an identical flow. Integration testing is a cinch since it's running actual, version matched postgres/redis/etc on the CI nodes which…

> having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services At the last place I worked that had a truly tight devops operation, it was 3 DevOps people maintaining infrastructure for 200+ unique services. And most that infrastructure was building really useful junk that I've never seen available elsewhere, like daily email reports telling…

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