4 ms·
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
by hguhghuff 8y ago
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.
- talonx 8y agoSurface 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.
- placebo 8y agoNo, 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.
- blunte 8y agoThis 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.
- n0w 8y agoI 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.
- hguhghuff 8y ago“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?
- n0w 8y agoI'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.