<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 3:35 PM, Martinx - ジェームズ <span dir="ltr"><<a href="mailto:thiagocmartinsc@gmail.com" target="_blank">thiagocmartinsc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hey Stackers! Wait!   =)<div><br></div><div>
Let me ask something...</div><div><br></div><div>Why are you guys using Docker within a VM?!?! What is the point of doing such thing?!</div><div><br></div><div>I thought Docker was here to entirely replace the virtualization layer, bringing a "bare metal-cloud", am I right?!</div>


<div><br></div><div><br></div></div></blockquote><div><br></div><div>Although this is getting somewhat off-topic, but it's something the containers service seeks to support... so perhaps it's a worthy discussion. It's also a surprisingly common sentiment, so I'd like to address it:</div>
<div><br></div><div>The advantages of Docker are not simply as a lightweight alternative to virtualization, but to provide portability, transport, and process-level isolation across hosts (physical, or not). All of those advantages are seen with virtualization just as well as without. Ostensibly,<font color="#878787" face="arial, sans-serif"><span style="line-height:15.6000003814697px"> t</span></font>hose that seek to use Docker to replace virtualization are those that never needed virtualization in the first place, but needed better systems management tools. That's fine, because Docker seeks to be that better management tool.</div>
<div><br></div><div>Still, there plenty of valid reasons for virtualization, including, but not least, the need for multi-tenant isolation, where using virtual or physical machine boundaries to provide isolation between tenants is highly advisable. The combined use  of Docker with VMs is an important part of the Docker security story.</div>
<div><br></div><div>Years ago, I had founded an IaaS service. We had been running a PaaS-like service and had been trying to move customers to IaaS. We were offloading the problem of maintaining various application stacks. We had just gone through the MVC framework hype-cycle and were tired of trying to "pick winners" to provide support for. Instead, we wanted to simply provide the hardware, the architecture, and let customers run their own software. It was great in practice, but users didn't want to do Ops. They wanted to do Dev. A very small minority ran Puppet of CfEngine.  Ultimately, we found there was a large gap between users that knew what to do with a server and those that knew how to build applications. What we needed then was Docker.</div>
<div><br></div><div>Providing hardware, physical or virtual, isn't enough.  A barrier of entry exists. DevOps works for some, but it's a culture and one that requires tooling; tooling which often wedges the divide that DevOps seeks to bridge. That might be fine for a San Francisco infrastructure startup or the mega-corp, but it's not fine for the sort of users that go to Heroku or Engineyard. As an industry, we cannot tell new Django developers they must also learn Chef if they wish to deploy their applications to the cloud. We also shouldn't teach them to build to some specific, proprietary PaaS. Lowering the barrier of entry and leveling the field helps everyone, even those that have always paid the previous price of admission.</div>
<div><br></div><div>What I'm really saying is that much of the value that Docker adds to the ecosystem has little to do with performance, and performance is the primary reason for moving away from virtualization. Deciding to trade security for performance is a decision users might wish to make, but that's only indicative of the flexibility that Docker offers, not a requirement.</div>
</div></div></div>