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

11–20 of 134 posts

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

#11

Post by vorpalhex »

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 get spun up on demand and against the same docker image that'll get pushed out to production.

We haven't had a case of "Well it works on my machine why doesn't it work on yours!?" in a really long time since if it works in docker.. well it works in docker.

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

#12

Post by Frost1x »

collyw wrote: post #6
bilekas wrote: post #4

I have to agree a little bit.. One other thing that bothers me is when I don't WANT to run docker. Some packages/services actually make it tricky to achieve this. With some time being spent reversen engineering. Docker is cool don't get me wrong, but it might be a bit over used sometimes. And I really don't think it needs to be this 1 way solution to everything.

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.

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

#13

Post by leecarraher »

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…

Exactly, docker standardizes something that was an otherwise nightmare to maintain across platforms and organizations. Next we need to standardize the orchestrator, my money is on kubernetes, but I wouldn't say it has won over everyone just yet.

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

#14

Post by clarry »

EamonnMR wrote: post #9
collyw wrote: 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.

I had this problem too when my team first adopted docker, but you can use a conventional debugger if you run your container interactively (with -i.)

Yea, first you just have to get your debugger (and maybe the rest of your toolchain) installed in the container, along with your source code.. and then you run into things like crazy wonky terminal support.

Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.

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

#15

Post by ex_amazon_sde »

zeveb wrote: 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…

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.

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

#16

Post by leecarraher »

I would like to see more vetting in dockerhub and security in general, yes it's based on cgroups which are specifically security minded, but not all docker users are aware of this. A novice user pulling a random docker image, and running default as root is bound to cause some issues.

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

#17

Post by matteuan »

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.

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

#18

Post by freeone3000 »

The author's approach presupposes a devops "person" (side note: if you have a person in charge of ops, that person is an ops person, not a "devops" person, as devops is a process; either your org is on it or they aren't). If you want developers to launch to production with any degree of reliability, you're going to need either a lot of tooling support for your specific workflow, or you're going to use docker and a significant degree of creative blindness. The fat binary approach works great if you can build a fat binary - python and node are nearly diametrically opposed to compiled binaries in general, much less ones that include a list of dependencies. The docker image is the fat binary that our toolchain is set up to build and run.

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

#19

Post by freeone3000 »

clarry wrote: post #14
EamonnMR wrote: post #9

Earlier quoted context omitted.

I had this problem too when my team first adopted docker, but you can use a conventional debugger if you run your container interactively (with -i.)

Yea, first you just have to get your debugger (and maybe the rest of your toolchain) installed in the container, along with your source code.. and then you run into things like crazy wonky terminal support. Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.

Have you tried using the remote debugger interface? Python and Java have rather robust remote debugging support over TCP.

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

#20

Post by rossdavidh »

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 these. But, he also wants to be able to put on his resume that he managed developers who used these things, so that's an easy task. Many of these made perfect sense for the FAANG company they were developed for, but they are used at companies with 0.01% of the number of servers of those companies, 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.

Again, there are valid use cases for all of these, but there are also valid use cases for semi tractor trailers. It doesn't mean I should use one to get my groceries.

Post reply on HN