Docker lets you have a standard easy to run reproducible description of a system (service + all dependencies) as code for any service. It's a fat-binary for anything that is also the build env for that binary. Not all languages support native fat-binaries and even those that do you still need a way to reproducibly build that binary (CI doesn't count because local testing builds can't reproduce it).
Docker is a dangerous gamble which we will regret (2018)
41–50 of 134 posts
Re: Docker is a dangerous gamble which we will regret (2018)
#42Earlier 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…
You judge "with respect" my experience instead of answering to the argument. So why is it easier with Docker?
Re: Docker is a dangerous gamble which we will regret (2018)
#43Earlier 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.)
Question is, if it is worth the hassle to setup for e.g. a small team with maybe 1-2 apps/services.
I think docker is great (although I'm more exited about the future prospects of WASM+WASI), but as a default choice for every single project, in my opinion it often adds more accidental complexity to the system than the value it really adds
Re: Docker is a dangerous gamble which we will regret (2018)
#44If 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…
Re: Docker is a dangerous gamble which we will regret (2018)
#45The 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 si…
>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
"devops" has made the same slide to meaninglessness as "agile." At one point they might have meant something about the philosophy of getting a job done. They don't anymore. They're buzzwords for a bunch of mutually-incomparable ideas, and as long as we pretend there is still meat in the concepts we're just lending buzzwords credibility.
"devops" is a verbal pyrbar for whatever change management already wanted to make, and shouldn't be seen as much more than a string of characters to get a resume through a regular expression.
Re: Docker is a dangerous gamble which we will regret (2018)
#46If 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.
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.
Re: Docker is a dangerous gamble which we will regret (2018)
#47Oh 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 me about every error that was logged on any services that my team maintained, and a cool little web UI that monitored our message bus and generated a visualization of which services (and instances) were listening to what.
The actual deployment and process management infrastructure wasn't very complicated, either, based on what I saw from poking around in their source control. They were able to shave a whole lot of unnecessary complexity by enforcing rigid standards about how each process would be packaged and configured and whatnot, regardless of implementation language. It was up to the developers who wanted to take on $hot_new_langauge to figure out how make it behave right.
And that gets to my real worry about Docker. It's a way of dealing with messes, not by cleaning them up, but by sweepi^H^H^H^H^H^H hiding it behind an abstraction. It's like that meme image that floated around a while back - "But it works on my machine." "Then we'll ship your machine." And that's how Docker was born.
Which isn't to say that this is useless - I use Docker all the time, chiefly to do things like making sure I'll never have to manually futz around with managing multiple concurrent PostgreSQL installs ever again - but, at least in production, it still feels to me like high tech duct tape and chewing gum.
Re: Docker is a dangerous gamble which we will regret (2018)
#48I 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…
You can use PEX for Python.
At my previous job, we used a python script to rsync files -- very, very simple. I think it would have been much more difficult and error-prone with Dockers.
Re: Docker is a dangerous gamble which we will regret (2018)
#49Docker 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 something like Docker.
Re: Docker is a dangerous gamble which we will regret (2018)
#50If 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…
[deleted]