Docker is a dangerous gamble which we will regret (2018) • Hacker News Board

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

#121

Post by LoSboccacc » Tue, Jan 28, 2020, 8:42 AM UTC

LoSboccacc wrote: post #97

busterarm wrote: post #90

Earlier quoted context omitted.

I had that with terraform before Kubernetes anyway.

...aren't them from the same age?

they're bot 2014ish, but hacker news and facts aren't a good match, better a long tirade and snarky comments against the grain, I guess.

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

#122

Post by collyw » Tue, Jan 28, 2020, 8:46 AM UTC

viklove wrote: post #71

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.

You can just... not run the application in docker, can't you? Check out the repo on your local machine and install all the dependencies yourself -- problem solved.

It has a number of moving parts, so it would involve getting all of those working together, which would be a non trivial amount of work.

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

#123

Post by shadowgovt » Tue, Jan 28, 2020, 2:46 PM UTC

_y5hn wrote: post #110

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…

Well-written ksh/bash is extremely light-weight, flexible, concise and easy to maintain. Changing shell or OS would be the headache, but easily outweighted by gains if used for the right jobs.

Unfortunately, maintaining it requires somebody who is familiar with ksh or bash, and they are tools with Byzantine syntax by modern aesthetics. They're also more firepower than needed for the problem domain of building and maintaining deployments---they have features one doesn't need and require library support for key features in the deployment problem domain.

You can code a deployment solution in c++ also, but it's not recommended.

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

#124

Post by busterarm » Tue, Jan 28, 2020, 3:22 PM UTC

LoSboccacc wrote: post #121

LoSboccacc wrote: post #97

Earlier quoted context omitted.

...aren't them from the same age?

they're bot 2014ish, but hacker news and facts aren't a good match, better a long tirade and snarky comments against the grain, I guess.

One was usable in production long before the other. Years even.

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

#125

Post by phendrenad2 » Tue, Jan 28, 2020, 5:37 PM UTC

From what I've seen, Docker usually gets used when someone has a difficult-to-run app, usually due to many dependencies or a cryptic barely-documented jump-through-hoops-of-fire setup. So they dockerize it. Instead of trying to improve the app, they've essentially thrown up their hands in defeat and dockerized it. Which is a legitimate strategy in many cases, but too often it's the lazy way out.

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

#126

Post by phendrenad2 » Tue, Jan 28, 2020, 5:42 PM UTC

5 years ago I dreamed that IT teams would be empowered to offer us developers a heroku-like experience. (Or JVM application server for those of you who remember those). But it seems like Kubernetes, the "new shiny", has distracted them from that goal, so now they're off in Kubernetes land reconfiguring and reconfiguring, never increasing the productivity or security of what they deliver to the rest of the company. Basically, Kubernetes has nerdsniped IT.

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

#127

Post by viklove » Wed, Jan 29, 2020, 6:20 AM UTC

collyw wrote: post #122

viklove wrote: post #71

Earlier quoted context omitted.

You can just... not run the application in docker, can't you? Check out the repo on your local machine and install all the dependencies yourself -- problem solved.

It has a number of moving parts, so it would involve getting all of those working together, which would be a non trivial amount of work.

If only there were a way to prepackage all the moving parts and write a script to spin them all up on your machine!

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

#128

Post by freeone3000 » Wed, Jan 29, 2020, 2:48 PM UTC

matteuan wrote: post #34

freeone3000 wrote: post #18

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

You are assuming that developers have enough knowledge of Docker to deploy in production confidently. Why is it different for other ops skills? What "degree of reliability" does Docker adds over bash, for example?

It adds full environment reproducability. Essentially, "it works on my machine" -- "then we'll ship your machine". Nothing about docker in particular is meaningful, if they shipped VM images this would be identical, but docker streamlines creation and management of the entire OS image. It eliminates all differences between the developer's laptop and the production server.

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

#129

Post by RandyRanderson » Wed, Jan 29, 2020, 8:46 PM UTC

I'm on a project that only needs a single server, and storage. Yet we have k8s, docker, 3 other needless technologies with all their ancillary requirements,Microservices and about 5 more git repos than the entirety of Google needs. Development of simple features take 5-10x of what it should be. But then I understand the developers too: recruiters and team leads urged by their developers to "work on the latest tech or we'll leave" have to adopt and so ask for ppl with those skills.

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

#130

Post by raghava » Wed, Jan 29, 2020, 8:58 PM UTC

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…

>> resume building

Exactly. Every developer is always running a build-resume thread in his mind at the background, which drives choices many a times.

But why does it happen?

May be, there's no way for the developer to claim the value driven, and thus these skills end up being the proxy to be showcased!

If a developer's resume mentioned "got a 40% reduction in total operating cost of the supply-management-pipeline by enabling automated operations and reduced errors by 20% over a year, and helped drive sales up by about 30% over two years", this would NEVER get picked up by a recruiter - who would just be skimming the resumes for specific keywords. Worse, it could be an automated tool scanning the resume.

Also, in the general scheme of things, developers are kept off the real value outcomes for a reason - to prevent them from understanding their true value. Cause, it is good for business! :P

All of these combine to cause developers from not understanding the quantum of value being driven by their efforts, and thus to compensate for the lack of this important info - and to compensate for the shortcomings of the industry standard "job-description" templates that bother only about skills-and-number-of-years (as opposed to value-outcomes-driven-over-unit-time) make it harder for developers to really understand (and then showcase these in their resumes).

Also, an old classic on these lines - http://www.bruceblinn.com/parable.html - The parable of two programmers.

"I don't want to seem like a hack, so I'll do enterprisey things, so that nobody can call me a dumb guy" is another thing running in the background.