<story><title>Goodbye Docker and Thanks for all the Fish</title><url>https://technodrone.blogspot.com/2019/02/goodbye-docker-and-thanks-for-all-fish.html</url></story><parent_chain><item><author>baybal2</author><text>&amp;gt; What’s wrong with Docker?&lt;p&gt;What&amp;#x27;s wrong with &lt;i&gt;not&lt;/i&gt; using Docker? Outside of cloud&amp;#x2F;SOA&amp;#x2F;webscale sector, people having hard time to simply comprehend the drama.&lt;p&gt;I have not seen any justification for using containers on any scaleable system on real hardware for example.&lt;p&gt;In &amp;quot;ad-farm&amp;quot; world, running ad farms on pure hardware with netboot provisioning has been the &amp;quot;gold standard&amp;quot; since time immemorial.&lt;p&gt;Few points:&lt;p&gt;1. Netboot with root at tmpfs takes less time to boot, seconds over 10G (most of the time is spent on POST and DHCP actually.)&lt;p&gt;2. Netboot images can be stripped to the barest minimum of life-sustainance. Less software running — less problems.&lt;p&gt;3. Less attack surface for hackers.&lt;p&gt;4. Hard lockup proof - hardware watchdogs are more or less foolproof.&lt;p&gt;5. Linkup to the real network is as simple as it gets, you can use broadcasts for self-configuration and service discovery on the network.&lt;p&gt;6. If you deal with RDMA, well, you will be already spending most of your efforts on just getting software work as advertised on the bare system, and the additional troubles of containerisation will not worth dealing with.</text></item><item><author>zenexer</author><text>I’m failing to see the argument here. The author suggests that the advent of viable Docker competitors will inevitably bring about Docker’s death. Why would that be the case? Competition is great, but it’ll be a while before others can match Docker’s maturity and ubiquity. Even then, there’s no guarantee that any of them will be better than Docker, never mind good enough to warrant switching.&lt;p&gt;What’s wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?&lt;p&gt;The author doesn’t actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.</text></item></parent_chain><comment><author>ex_amazon_sde</author><text>Former Amazon engineer here. Despite the downvotes, you are making an excellent point.&lt;p&gt;Amazon, among other FAANG companies, never needed containers shipping entire bundled OSes.&lt;p&gt;Deploying a &amp;quot;base OS&amp;quot; (using PXE or netboot) can be done very reliably both on a hypervisors and VMs.&lt;p&gt;A simple build system can then generate traditional packages and push them into VMs allocated for a specific product.&lt;p&gt;It provides better security isolation and the ability to receive security updates on OSes and also on dynamically linked libraries.&lt;p&gt;Building and deploying new versions of you product is also much faster, especially at large scale: only your application package is rebuilt and deployed.</text></comment>
<story><title>Goodbye Docker and Thanks for all the Fish</title><url>https://technodrone.blogspot.com/2019/02/goodbye-docker-and-thanks-for-all-fish.html</url></story><parent_chain><item><author>baybal2</author><text>&amp;gt; What’s wrong with Docker?&lt;p&gt;What&amp;#x27;s wrong with &lt;i&gt;not&lt;/i&gt; using Docker? Outside of cloud&amp;#x2F;SOA&amp;#x2F;webscale sector, people having hard time to simply comprehend the drama.&lt;p&gt;I have not seen any justification for using containers on any scaleable system on real hardware for example.&lt;p&gt;In &amp;quot;ad-farm&amp;quot; world, running ad farms on pure hardware with netboot provisioning has been the &amp;quot;gold standard&amp;quot; since time immemorial.&lt;p&gt;Few points:&lt;p&gt;1. Netboot with root at tmpfs takes less time to boot, seconds over 10G (most of the time is spent on POST and DHCP actually.)&lt;p&gt;2. Netboot images can be stripped to the barest minimum of life-sustainance. Less software running — less problems.&lt;p&gt;3. Less attack surface for hackers.&lt;p&gt;4. Hard lockup proof - hardware watchdogs are more or less foolproof.&lt;p&gt;5. Linkup to the real network is as simple as it gets, you can use broadcasts for self-configuration and service discovery on the network.&lt;p&gt;6. If you deal with RDMA, well, you will be already spending most of your efforts on just getting software work as advertised on the bare system, and the additional troubles of containerisation will not worth dealing with.</text></item><item><author>zenexer</author><text>I’m failing to see the argument here. The author suggests that the advent of viable Docker competitors will inevitably bring about Docker’s death. Why would that be the case? Competition is great, but it’ll be a while before others can match Docker’s maturity and ubiquity. Even then, there’s no guarantee that any of them will be better than Docker, never mind good enough to warrant switching.&lt;p&gt;What’s wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them?&lt;p&gt;The author doesn’t actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.</text></item></parent_chain><comment><author>1337shadow</author><text>Containerization is a cost effective alternative to building and running immutable VM images, which is a best practice in terms of CD. Another way to put it is: don&amp;#x27;t build in production, instead build in CI, test your image and then just deploy it on your environments (you probably should have at least two: staging and production).</text></comment>