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

51–60 of 134 posts

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

#51

Post by Already__Taken »

smoe wrote: post #43
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.)

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

Even just setting up a new laptop it's a win. I could develop across my laptop, office pc, chromebook and home pc with a project and the only dependencies to keep up to date are docker and git pull/push.

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

#52

Post by vorpalhex »

SaasDeveloper12 wrote: post #28
leecarraher wrote: post #13

Earlier quoted context omitted.

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).

Well everyone at least wants to use Kubernetes. I'm not sure any organization really knows how to best use it yet, and nobody has a set of standards that have seen adoption.

Both the pro and the con of K8s is that it's exactly what you make of it and it's extremely flexible.

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

#53

Post by rjkennedy98 »

Plenty of companies:

a) do not want to give people/scripts access to the machine.

b) do not want to employ a bunch of people whose sole purpose is to manage these machines.

Being able to provision (for instance) an Openshift project in a click to deploy docker containers solves those problems.

Yes, those are not problems that a startup or a small business has, but these are problems that all large enterprises with sensitive data have.

Docker is a standard that anyone knows. Is it the best standard? Who knows, but it is a platform and a standard that has built an ecosystem. That fact alone will make it better than any product or custom-built deployment solution that has to be maintained by a team of engineers.

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

#54

Post by sh87 »

I notice that once you're invested, time and effort wise, in doing something one way, and it works, the general unwillingness to learn different or newer ways of doing the same things increases rapidly. Overcoming such prejudice requires understanding and accepting the incentives for further investing time and effort to accustom with newer technology.

Use-case driven technology fit is just one incentive. There are other incentives like resume enhancement, participation in communities where there is rapid development, FOMO / fear of being a dinosaur, the reputation of being known as someone well versed with the latest technologies, monetization via online courses/tutorials. These are just a few I could think of, I'm sure there are more.

In my relatively short career, I saw this playing out with NoSql databases, microservices architecture, SPA (AngularJS), NodeJS, responsive websites, blockchain and more recently, ReactJS, data-science (AI/ML) and containerization.

Each one of these, at some point or the other, have been used in cases where the problem space was completely solvable without using said technology but was introduced for some other incentive.

Say what you will but this rapid change is what makes and keeps this space moving, interesting, inspiring and well-paying.

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

#55

Post by pm90 »

busterarm wrote: post #26
shadowgovt wrote: post #25

Earlier quoted context omitted.

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.

Using managed kubernetes solutions alleviates most of the hair pulling.

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

#56

Post by pm90 »

alxlaz wrote: post #33
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…

That hasn't been my experience with docker at all. Except for pretty simple projects, I can't remember a single project I've worked on where I could just follow the README/"Here's how to set it up" email/whatever and have it work the first time. Every time a new developer came in, we'd find out that some implicit assumption was baked in somewhere, and finding out where took hours or days because debugging the damn th…

I don’t wanna gaslight you but this doesn’t match my experience at all. I’ve literally never run into issues with something compiling info one version of docker but not another. Image pulling has been a problem sometimes on Kubernetes but you just need to configure the creds correctly and boom it works.

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

#57

Post by darkwater »

The author has the boldness of saying that anything that does not produce a single artifact (golang binary or fatjar) is a language that should not be used an that they were errors of the past and we should get rid of them (citing explicitly PHP, Ruby and Python).

Now, if we want to think that languages and whole ecosystems (libraries, bugs and edge cases fixed, developers and companies whose code base is written in such language) can be changed easily, then the author take on Docker is right. In such a world Docker doesn't add anything useful. But the real world is quite different and it's not going to change for the author, so Docker (or "containers") is still adding something valuable and it's not a "bet" to me, at all.

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

#58

Post by GhettoMaestro »

rjkennedy98 wrote: post #53

Plenty of companies: a) do not want to give people/scripts access to the machine. b) do not want to employ a bunch of people whose sole purpose is to manage these machines. Being able to provision (for instance) an Openshift project in a click to deploy docker containers solves those problems. Yes, those are not problems that a startup or a small business has, but these are problems that all large enterprises with se…

Great points. Makes me think of the old saying “don’t allow perfect to be the enemy of good enough”

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

#59

Post by jpochtar »

By expecting Docker users to know more than they do, the author thinks they're dumber than they are.

Docker users are mostly folks who specialize in other areas of programming, to whom Docker popularized affecting "fat binaries" out of PHP/Ruby/Python/node apps via chroot. Chroot was already well known to ops folks, but was arcane to most webapp devs.

We're not ops experts who have been confounded by marketing, we're ops amateurs for whom Docker cracked the nut of chroot legibility.

The author hates on Docker in comparison to other fat binary techniques; he ignores that pro-Docker advocates are comparing it to not using fat binaries at all.

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

#60

Post by judge2020 »

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…

> side note

I imagine a devops person as someone who manages IDE licenses and possibly the company's docker registry and SCM server.

Post reply on HN