3 ms·

The article focuses on Hadoop, but the generalization to containers is spot on. Containers have become the first stop method to hide overly complicated build p

The article focuses on Hadoop, but the generalization to containers is spot on. Containers have become the first stop method to hide overly complicated build processes. When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip. It seems to me that containers are useful for deploying final setups, but should be a no go for packaging tools.

apexalpha 7y ago
I would see it more as to dividing your wiring into segments with breakers in between so that one rogue device doesn't bring down the whole network. Seems a good thing, to me at least.
indigochill 7y ago
>When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip. On the other side of the coin, putting stuff in boxes is the essence of architecture. CPU opcodes? Boxes. Compiling readable code into bytecode? Boxes. Objects? Boxes. Functions? Boxes. Sure, it can be abused. There might be spaghetti in those boxes. The spaghetti should be chopped into digestible chunks (smaller boxes!). But putting it in a box makes that an implementation detail. Putting stuff in boxes is still progress.
- bluGill 7y ago
  All problems in programming can be solved by adding another layer of abstraction (ie a box) - except too many layers of abstraction. Good architecture is not about putting things into boxes, but about figuring out what boxes you need and which you do not. Sometimes a box is good, sometimes a box is bad. It isn't the fault of the box that it does't contain the right thing.
hvidgaard 7y ago
I don't think it's fair to blame containers for that. Just because someone programs a shitty product in Visual Studio, does not mean it's a problem with Visual Studio. What containers does beautifully is dependency containment. I make something and put it inside a container, with the exact dependency it needs and it'll work alongside other containers with a program that might have a different incompatible dependency. What we're seeing is not so much that developers suddenly decides to throw best practice into the wind. They just do not have to put the same amount of effort into fixing the broken process exactly because we have dependency containment. I believe we would see the same mess without containers, and the process change that would fix one would fix the other.
darkwater 7y ago
Containers are great, for example, to internally deploy some internet-facing web component your company wrote but they are not that great as a mean of generic software distribution. But things get complicated when to build the first type of containers you usually need software from the second type. In my case I just mirror good/proven docker images in my internal repo(s) and rebuild images from scratch in the most reproducible manner I can find when the software is badly packaged.
peterwwillis 7y ago
Containers are fantastic for packaging tools. What problems do you see with it?

apexalpha 7y ago

I would see it more as to dividing your wiring into segments with breakers in between so that one rogue device doesn't bring down the whole network. Seems a good thing, to me at least.

indigochill 7y ago

>When you've noticed your wiring has become a complete mess of knots, just put it in a box so no one will trip. On the other side of the coin, putting stuff in boxes is the essence of architecture. CPU opcodes? Boxes. Compiling readable code into bytecode? Boxes. Objects? Boxes. Functions? Boxes. Sure, it can be abused. There might be spaghetti in those boxes. The spaghetti should be chopped into digestible chunks (smaller boxes!). But putting it in a box makes that an implementation detail. Putting stuff in boxes is still progress.

bluGill 7y ago
All problems in programming can be solved by adding another layer of abstraction (ie a box) - except too many layers of abstraction. Good architecture is not about putting things into boxes, but about figuring out what boxes you need and which you do not. Sometimes a box is good, sometimes a box is bad. It isn't the fault of the box that it does't contain the right thing.

hvidgaard 7y ago

I don't think it's fair to blame containers for that. Just because someone programs a shitty product in Visual Studio, does not mean it's a problem with Visual Studio. What containers does beautifully is dependency containment. I make something and put it inside a container, with the exact dependency it needs and it'll work alongside other containers with a program that might have a different incompatible dependency. What we're seeing is not so much that developers suddenly decides to throw best practice into the wind. They just do not have to put the same amount of effort into fixing the broken process exactly because we have dependency containment. I believe we would see the same mess without containers, and the process change that would fix one would fix the other.

darkwater 7y ago

Containers are great, for example, to internally deploy some internet-facing web component your company wrote but they are not that great as a mean of generic software distribution. But things get complicated when to build the first type of containers you usually need software from the second type. In my case I just mirror good/proven docker images in my internal repo(s) and rebuild images from scratch in the most reproducible manner I can find when the software is badly packaged.

peterwwillis 7y ago

Containers are fantastic for packaging tools. What problems do you see with it?