don't gitlab/azure devops pipelines make docker irrelevant?
Docker is a dangerous gamble which we will regret (2018)
21–30 of 134 posts
Re: Docker is a dangerous gamble which we will regret (2018)
#22I 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.
I know of a team that spent significant time getting their front-end to run in docker. Because they were having regular problems getting the app to run on the developers machines due to extremely outdated versions it depended on.
Oh no, we have a problem! Lets put the problem in a neat container. Now we have a problem with a layer of abstraction on top, soon to be two problems. Rinse and repeat ...
Re: Docker is a dangerous gamble which we will regret (2018)
#23I 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.
Fire and Motion.[1]
[1]:https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Re: Docker is a dangerous gamble which we will regret (2018)
#24If 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.
Re: Docker is a dangerous gamble which we will regret (2018)
#25If 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…
It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé.
If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing function to cause standards to exist in that abstraction layer for doing a specific task (creating and managing deployable artifacts).
React vs. JS and Kubernetes vs. "Our previous sysadmin's solution built with hair-pulling and rage before they quit to embrace the life of the humble riverboat captain" follow the same pattern. The frameworks and toolchains listed are standards that allow someone who has solved that common business use-case at one organization to solve that use-case at another org with minimal spin-up time (vs. the time to learn bespoke solutions to do the same thing). Many people having the same problem domain to solve is how standards come to exist.
Re: Docker is a dangerous gamble which we will regret (2018)
#26If 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…
It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé. If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing func…
Do you actually think Kubernetes infrastructure is built without hair-pulling and rage?
If so, I've got some stories for you.
Re: Docker is a dangerous gamble which we will regret (2018)
#27Oh 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.
> 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 its way to a headache when two of those people retire at the same time and your org tries to on-board someone new to read those scripts).
Re: Docker is a dangerous gamble which we will regret (2018)
#28Oh 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.
The industry has standardized on Kubernetes for the orchestrator. If anything we are starting to see other container runtimes other than Docker as K8s added the CRI (Container Runtime Interface).
Re: Docker is a dangerous gamble which we will regret (2018)
#29Oh 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…
Fewer than half the number of engineers with hundreds of unique services. We aren't "just" using a common set of bash scripts, but we do have few. It's not a disaster, and it just works. What we deploy to a testing environment is what we deploy to production. Not a disaster. Deployments are a single button push.
Building the framework for a new services is filling out a form, and everything needed gets generated, including automated documentation, life cycle jobs, repos in github, properly configured security groups, etc.
We are exploring Docker, and while Docker offers some nice advantages, the added complexity and additional points of failure needs to bring some major benefits, and need to solve real problems we have. Not imagined problems.
Re: Docker is a dangerous gamble which we will regret (2018)
#30don't gitlab/azure devops pipelines make docker irrelevant?
Aren't those orthogonal (i.e. have little to do with each other)? Why would Gitlab/Azure DevOps Pipelines (CI/CD tools) make Docker (a container engine) irrelevant?