Hacker News Reader

Comment by hguhghuff | Hacker News Reader

I don’t like docker, it’s a complex kludge, but it now pervades every aspect of development and operations. I just don’t want to work with it, which means I don’t want to work in most computing environments.

View on HN

There are plenty of non-Docker environments still out there. Gee wiz, are there ever. I have no idea where you'd get the idea that "most computing environments" are Dockerized.

Have you read any job ads lately?

Job ads in general are very depressing if you're somewhat older and more experienced. There are about 6 bandwagons rolling along, with various ropes tied between them. If you're not a fan (or you even dislike) one or two of those wagons, chances are one of the other wagons you can accept is tied to it.

Node.js, Docker, DevOps, TDD, Agile, blah blah blah. Yes each of those can be quite useful in the right situation, but it is a symptom of lack of experience (particularly where management and tech leadership is concerned). A good many of the actual jobs and work environments is probably being held back or otherwise limited by the companies' need to have some of the more common popular tools in their list. But they don't know that, and there's no point arguing it. If the job still attractive, one's best hope is to get in there, get some seniority, and quietly start moving things in the right direction. Or maybe you find out that their buzzword-soup is actually seasoned right for their situation...

But to be fair, part of our problem industry-wide is the so many choices we have. You could argue that choice is good, but it creates fragmentation which eventually self-organizes into bandwagons. The huge question is, "In the end, are we better off?" I greatly suspect the answer is, "Not much..."

I sympathize with you and have also found this frustrating, but note that job ads are first, speculative, and second, seen as marketing material. Many ads will list fads because they think it makes the company seem like it's on the cutting edge and they believe it will attract candidates. Most such companies will end up not doing anything significant with the tech.

"In the cloud" has become such a thing these days that companies that explicitly avoid the cloud on the technical side end up writing job ads that say things like "help us transition to the cloud!" I don't know if this is now considered standard marketing/HR mumbo jumbo or what, but just like a resume, a job ad should not necessarily be taken at face value.

Those very definitely depend on where you're planning to take a job, and what part of the field you plan to work in. Upon your suggestion, I went and scrolled through some job ads and was satisfied that "most" were still not yet Dockerized.

Here's what I tried: https://www.indeed.com/jobs?q=software+engineer&l=New+York%2...

Have your read any job advertisements lately?

Did you feel the same way about Solaris zones?

Zones are backed by ZFS, so thats 90% of my headaches gone.

Not that I want to manage solaris though...

"I don't like technology, it's a complex kludge, but now it pervades every aspect of development and operations" See how silly this sounds?

All new technologies are inherently more complex than the last ones, solving some problems and introducing others...

I totally disagree.

I think that technology is driven mainly by waves of simplification, not added complexity.

Indeed this is exactly why I don’t like docker because it introduces fresh new deep complexity.

Surface simplicity often comes at the cost of hidden complexity underneath. As long as users are not exposed to the underlying complexity, everything is rosy. But for things like Docker, I don't think that's a reasonable expectation.

No, surface simplicity should not mean sweeping the complexity under the rug. It should mean exposing the bare minimum in the level of abstraction being used, and doing same for the level beneath it, etc. This is how you get a scalable and maintainable structure which can do very complex things.

I only know Docker from a high level (the concepts and the problem it tries to solve) so I'm not in a position to give an opinion about it's implementation, but I think a reasonable expectation from every technology is that it should be as simple to use as the use case requires.

Of course, sometimes the problem isn't the technology but the way it it used. You won't try to make a commercial airliner suitable as a quick means of transportation to your local convenience store. It's not even overkill - it's just the wrong tool for the job. The problems start when that's considered the cool thing to do. Unfortunately, technology isn't always about what's good, but many times about what is trendy, but things will eventually converge to what works best, even if they have to go through the longer path.

This is well stated. But as anyone who has used a framework or other higher level tool knows, at some point you need something it can't do... and you're forced to dive under the pretty cover and get dirty. Sometimes, often even, the time you save with the simple exterior is totally offset by the time spent dealing with the edge case. Then special kludges are built to deal with those issues, until eventually you have 10x as much complexity in your kludges than the original fancy tool saved you in effort. Then you ask yourself, "Why did we do this?"

So there is the challenge - finding the tools which give enough advantage without imposing too many future burdens. I'm not one of these people, but there are people who still use C and Make and bash and build huge, impressive systems. Sometimes narrow and deep means capable and happy.

I don't want to come across as disagreeing with you, but can someone explain the complexity they see in docker/containerization?

It's always seemed to me as nothing more than a way to package a (mostly) preconfigured piece of software.

“Storage containers”, “network port mapping”, “layers”, I don’t even know the terms for actual images versus instructions to build images.

Containers aren’t even encapsulated like virtual machines, they are tightly bound to the kernel of the host. Ugh, nightmare.

Then management of all this. Ugh.

Complex, complicated and has necessitated effectively building operating system infrastructure within an already complex operating system to facilitate all this complexity.

Which bit of this is simple?

I've never felt like any of this was "added" complexity though, just different complexity. Managing a full operating system inside a virtual machine or packaging an application for installation with dpkg/rpm/etc is not any simpler, it's just the complexity we have suffered with to date so we are more familiar with it.

I more or less decide whether I dislike working with some specific technology by how much time I have to spend fucking about with configuration and troubleshooting instead of actually writing code.

I'm currently developing Sitecore websites and working with the CMS is pretty demoralising.

I actually agree with that statement. Tech is such good money though.

But if you knew, going in, that you likely would end up hating your career and wishing you had chosen otherwise, then why not aim for a career that you KNOW will pay incredibly well, also knowing that it may be soulless... but that you'll be able to retire much earlier and then do something useful? Aiming to be a hedge fund manager would be a much wiser choice, I think.

I make six figures and work remotely in a low cost of living area that I happen to really love. My work may be fairly pointless on net, but it's interesting and challenging.

Then you're doing it right!

Reply on news.ycombinator.com