3 ms·

There's a scene in Major Payne: === [Marine has been wounded] Marine Private: AHHHH my arm, my arm! Major Payne: Want me to show you a little trick to take

by wegs 6y ago

There's a scene in Major Payne: === [Marine has been wounded] Marine Private: AHHHH my arm, my arm! Major Payne: Want me to show you a little trick to take your mind off that arm? [Marine nods and Payne grabs the private's pinky finger] Major Payne: Now you might feel a little pressure. [Major Payne breaks the Marine's pinky] Marine Private: AUGGGGH! My finger, my finger! Major Payne: Works every time. ==== That's kind of how I feel about Docker. Before, you had a problem. With Docker, you have a new, bigger problem (and most of your old problem hasn't gone away; it's just been masked for a while). (And yes, I know I'm in the minority here)

RyanHamilton 6y ago
Snap! I feel the same seeing people use docker for dependency management. Now you have two problems.
- wegs 6y ago
  On a more serious note, most uses of Docker that I've seen push problems back, and have accumulating technical debt (with interest). * Robust systems shouldn't be tied to pinned versions. If your code works with PostgreSQL 9.6.19, and doesn't work with 9.6.20 or 9.6.18, that's usually the sign of something going very, very wrong. * In particular, robust systems should always work with the latest versions of libraries. In most cases, they should work with stock versions of libraries too (whatever comes with Ubuntu LTS, Fedora, or similar). It's okay if you have one or two dependencies in a system beyond that, but if it's a messy web, that's a sign of something going very, very wrong. * Even if that's not happening, as much as I appreciate having decoupled, independent teams, your whole system should work with the same versions of tools and libraries. If one microservice only works with PostgreSQL 11.10, and another with 12.07, that's a sign of something having gone way off the rails. These aren't hard-and-fast rules -- exceptional circumstances come up (e.g. if you're porting Python 2->Python 3, everything might not land at the same time) -- but these should be rare enough to be individually approved (and usually NOT approved) by your chief architect/architecture council/CTO/however you structure this thing. For the most part, I've seen Docker act as an enabler of bad practices: * Each developer can have an identical install, so version dependencies creep in * Each team has their own container, and it's easy for versions and technologies to diverge * With per-team setups, you end up with an uncontrollable security perimeter, since you need to apply patches to a half-dozen different versions of the same library (or worse, libraries performing the same function) The docker/microservices/etc. mode of operating gives a huge short-term productivity boost, but I haven't actually seen a case on teams I've been on where the benefits outweigh the long-term costs. That's not to say they don't exist, but they're in the minority. For the most part, I use Python virtual environments and similar, but by the time you hit docker, I back away.

by wegs 6y ago

RyanHamilton 6y ago

Snap! I feel the same seeing people use docker for dependency management. Now you have two problems.

wegs 6y ago
On a more serious note, most uses of Docker that I've seen push problems back, and have accumulating technical debt (with interest). * Robust systems shouldn't be tied to pinned versions. If your code works with PostgreSQL 9.6.19, and doesn't work with 9.6.20 or 9.6.18, that's usually the sign of something going very, very wrong. * In particular, robust systems should always work with the latest versions of libraries. In most cases, they should work with stock versions of libraries too (whatever comes with Ubuntu LTS, Fedora, or similar). It's okay if you have one or two dependencies in a system beyond that, but if it's a messy web, that's a sign of something going very, very wrong. * Even if that's not happening, as much as I appreciate having decoupled, independent teams, your whole system should work with the same versions of tools and libraries. If one microservice only works with PostgreSQL 11.10, and another with 12.07, that's a sign of something having gone way off the rails. These aren't hard-and-fast rules -- exceptional circumstances come up (e.g. if you're porting Python 2->Python 3, everything might not land at the same time) -- but these should be rare enough to be individually approved (and usually NOT approved) by your chief architect/architecture council/CTO/however you structure this thing. For the most part, I've seen Docker act as an enabler of bad practices: * Each developer can have an identical install, so version dependencies creep in * Each team has their own container, and it's easy for versions and technologies to diverge * With per-team setups, you end up with an uncontrollable security perimeter, since you need to apply patches to a half-dozen different versions of the same library (or worse, libraries performing the same function) The docker/microservices/etc. mode of operating gives a huge short-term productivity boost, but I haven't actually seen a case on teams I've been on where the benefits outweigh the long-term costs. That's not to say they don't exist, but they're in the minority. For the most part, I use Python virtual environments and similar, but by the time you hit docker, I back away.