Ask HN: What Is the Hype with Docker?
&gt; Am I alone here? Am I doing it wrong? Is it the case that I am not the intended audience, and it&#x27;s meant for larger teams?<p>No. Probably not. Maybe, but also probably not, you may just not have had the &quot;Ah-hah!&quot; moment. A lot of technologies are like that.<p>Take any random Windows or Linux server <i>someone else</i> has built. Log in to it. Now tell me how it was built such that that build can be reproduced on a slightly different platform, e.g.: a different processor or base image.<p>Good luck with that.<p>Traditional operating systems are <i>write only</i>. Trying to get the configuration back out after the fact is effectively impossible in the general case.<p>Even if you have a &quot;scripted process&quot;, &quot;policy&quot;, &quot;documentation&quot;, or &quot;declarative state configuration&quot;, drift occurs anyway because of things such as disk corruption, updates applying out-of-order, different levels of updates, quick fixes&#x2F;tests, etc, etc...<p>It is basically impossible to keep a large fleet of supposedly identical machines identical.<p>As a random example from the Windows world: I&#x27;ve seen Group Policy applied to user accounts such that when an admin user logs on to a server, that triggers an on-login install of some software. Could be anti-virus, a print utility or whatever. Suddenly pristine servers become... not so pristine.<p>People have tried to work around this kind of thing... clumsily.<p>For example, in the Windows world you can build standard operating environment (SOE) disk images for servers using a tool like System Center Configuration Manager (SCCM) task sequences. This can deploy Java runtimes, ODBC drivers, or whatever you business app needs. (Linux has things like Packer)<p>The principle is fine, the implementations however are terrible.<p>A complex SCCM Task Sequence might run for <i>hours</i> and then fail at step number 57 out of 83. Fix it, start from the beginning.<p>Oops, failed again after several more hours. Fix it, try again.<p>Success! Now step #62 is failing. Fix it, try again.<p>This can mean <i>days</i> down the drain. Wouldn&#x27;t it be <i>just awesome</i> if the build system could take <i>snapshots</i> of the VM at each step, so that it could restart at the last known good step, making the edit-build cycle super fast?<p>Docker does that.<p>Build systems like SCCM task sequences or Packer aren&#x27;t typically parameterised, or the parameters are &quot;baked in&quot; at build time, and&#x2F;or get passed at annoying points such as a very early &quot;network boot&quot; step, which has technical and security limitations.<p>Docker does the right thing, simply passing in parameters as environment variables <i>at runtime</i>. This allows one image to be used in many environments, <i>without changing it</i>. If you test something in UAT, then production will by byte-for-byte identical (SHA256 hashed!), except for the minimum required config changes.<p>Typical build systems produce a single opaque binary image. This could contain anything, and the &quot;link&quot; to the source script that produced that build is <i>immediately</i> lost.<p>Docker maintains the step-by-step build script that lead to the final docker image, in the image itself.<p>Typical build&#x2F;deployment systems require &quot;full VMs&quot; and associated images, which start from merely big at ~32 GB and go up to a way-too-big ~127 GB as is the typical case for servers in the cloud. These are mostly blank space, and need the wiggle-room for things such as after-the-fact updates.<p>Docker maintains an efficient content-addressed store of image layers. A small change on top of an existing chain of image layers might need just tens of megabytes. Deploying this to the production environment similarly requires only tens of megabytes, allowing <i>very</i> efficient blue-green deployments rolled out automatically via dev-ops. Existing deployments are maintained as-is and there&#x27;s no side effects of a roll-back. Compared to this, updating <i>any</i> shared framework or system-wide installed component is very risky on any traditional operating system.<p>Traditional server management ends up growing &quot;paperwork&quot; and &quot;processes&quot; like crazy. This is required to work around the risks listed above. So for example, changes have to be submitted to a change control system, but this is <i>not enforced</i> in any mechanical way. The paperwork can say &quot;X&quot;, but the physical change can be &quot;Y&quot;. Or details may not be present. Or whatever.<p>Docker lets you check the &quot;dockerfile&quot; into Git. That&#x27;s <i>authoritative</i>, versioned, and can be made subject to mandatory branch security policy such as forced code review. It can be set up such that <i>no paperwork</i> is needed. The code is the code, and if it&#x27;s in the &quot;main&quot; branch it has been reviewed. The image it builds is the image that is in production, <i>end of story</i>.<p>DISCLAIMER: Having said all of the above, I have literally never deployed containers in production, despite working in the cloud for <i>years</i>. My issue is similar to yours: I&#x27;d have to convince a <i>lot of people</i> to change their fundamental workflow and embrace a &quot;different way of doing things&quot;. This can be challenging, especially in large enterprise with unmotivated staff, unions, third-party support contracts, etc...