Goodbye Docker: Purging Is Such Sweet Sorrow
I’ve managed to resist the hype and still not ever used docker for anything ...<p>I still really struggle to understand what the practical benefits to this kind of containerization actually are ...<p>It seems like people reach for it because they want to have some kind of “compile target” into which they can stick “all the things” their application needs to run — which is supposed to then help them “deploy” into their development environment or onto their production infrastructure in a way that serves the goal that the applications within the image should behave the “same way” in either location ... but does anything about this kind of container abstraction actually help with doing this?  Don’t you still inevitably end up having to manage assumptions about the differences between these environments in order to make this work in practice (oh if you are in development environment make sure you don’t actually submit payment to stripe, if you are deploying to this cloud provider make sure you get secrets from &lt;here&gt; instead of &lt;here&gt; ...) ...?<p>Do you actually get any good abstractions out of the container which empower better solutions to deployment challenges?  “I don’t have to think about which hosts the (random) http client used in my application is configured to talk to because I can just magically retarget it at the container level by manipulating networking configuration” — is that a thing — does it actually work?  To my understanding the extent to which you _can_ do that requires you to write your application a certain way with a crazy service discovery layer like istio — and you’ve got to make sure you build your application completely to use service discovery fabric ... but if you built your application to use a service discovery fabric do you gain anything extra by also using docker at that point ...?<p>And what about the impact to developer ergonomics?  Is it easy and smooth to use debuggers to quickly edit code running in an image ...?  Do people regularly run production docker images locally to debug production application issues ...?  Are there solutions that allow one to say, attach to a remote qa testers chrome instance and then automatically attach debugger to the set of production containers handling the requests associated with that browser ...?<p>Those are the kind of features I want ... I’m not sure exactly if the containerization abstraction model would really help me get there or just create another set of configuration knobs that _also_ have to be correctly aligned for me to get the right environment specific behaviors out of my application ...