为什么Docker != Containers，Docker OSS != Docker Inc.
去年VMware启动了一个称为 Bonneville 的项目，之后演进为 vSphere Integrated Containers 。
最近我调动到VMware Cloud Native Application Business Unit（VMware 云原生应用程序业务部门），Bonneville和VIC是我的日常工作内容。
如果你懒得阅读上面给出的博客链接，那么简单来说，vSphere Integrated Containers是一种技术，允许用户预配VM的同时保留Docker的体验（API/CLI，镜像格式，公开的registry，等等）。这么做的好处是，简单来说，有利于开发人员（他们“需要Docker”），并且有利于IT（因为大多数IT部门都具备围绕VM的标准化运营能力）。
这样的理念不容易理解，因为业界存在一个流行的基本误解：Docker = 容器。
这是必须改变的观念。
进入“unikernels”。
从这里开始，本篇博客的所有内容都仅仅是我的个人观点，和我的公司无关（仅仅提醒一下）。
几天前，Unikernel Systems发表声明，他们会加入Docker（Inc.）。 这里 有谈论这一事件的简短视频。
视频里有一些有意思的点。
其中，“能够使用相同的Docker工具，该工具在开发人员中应用广泛，将快速加速unikernels的使用”，这个说法很重要，大家需要在理解Docker !=容器的基础之上加以理解。
可以进一步将这句话改为（在Bonneville的上下文里）：“能够使用相同的Docker工具，该工具在开发人员中应用广泛，将允许用户利用传统的IT已经标准化了的VM设施”。
或者放在下幅图里理解（图中架构有所简化）：
无需干扰用户的前端体验，就可以为合适的工作选择正确的后台支撑（可以使用Unikernel，容器或者VM）。
这个想法非常强大。
上图还需要注意，VM并不代表是在VM之上运行OS，然后运行容器。也就是说，我们讨论的不是在纯物理机OS上初始化容器还是在VM里的OS上初始化。
上图展示的是由Docker初始化的VM（这正是 vSphere Integrated Container 技术所实现的。）
如果你想更进一步，我建议大家看一下 Ben Corrie去年在QCon上有关Bonneville的演讲 。非常值得花50分钟看一下这段视频。
现在回到Unikernels。
博客圈里已经有好几篇文章深入探讨 unikernel为什么不适合生产环境 （这些文章需要辩证地对待，取决于你问的是谁，你可能也听说过VM不适合生产环境；不确定这些对于容器的判断是否公正）。
还有几次相关主题的在线讨论，其中一次是Hacker News的 超长讨论 。
大量评论中真正吸引我注意力的是Solomon Hykes（Docker的创办者和CTO）所说的：
“计算机一次只运行一个unikernel。只不过有时候它们是虚拟机。记住虚拟化越来越趋向硬件辅助，这里的软件部分是成熟的。因此大多数情况下应该将这些担忧隔离开，假定VM只是一种特殊类型的计算机。
在hypervisor不够安全的其他用例下，可以转而使用物理机。
我得承认我并不是100%确定他在这里想表达的意思。有时候大家都使用的指代IT堆栈里的某个东西的术语会变化，从而造成混乱。如果你也觉得我们这里还处在初级阶段，方案还有些混乱...那么你的整体感觉是对的。
我从这段话里学到的是Docker意图提供解决方案。可以是纯物理机上的容器，VM上的容器，hypervisor上的Unikernel，等等。
我认为VIC（我喜欢用hypervisor上的“containerVM”来指代VIC）是Solomon暗示的另一种解决方案。
因此未来很可能的替代解决方案的更为详细的架构图类似：
Docker收购Unikernel Systems的事实应该唤醒大家这方面的意识，这对整个业界有深远的教育意义。
当然这也会给一些人带来困扰：
我认为这是好事，因为给了大家选择最适合自己使用场景的后台的权利。但是，不管Docker是否收购，unikernel都会继续存在。也就是说，用户可以选择unikernel并且一直使用它。
我身体里的阴暗小人建议我们应该透过Docker Inc.的视角来看待这一切，它是Docker OSS（Open Source Software）项目背后的商业公司。
Docker Inc.渴望位于“堆栈的顶层”。这样他们会是“大家看到并且与之交互的接口”，这会让其处在十分有利的地位。
他们尝试确定“控制点”。这本身不是什么坏主意，这是所有商业公司都希望达到的保持差异化的方式。
我从来没有看到哪一家商业公司的策略是停留在堆栈的最底层，等待由其上能够轻松使用的技术上帮助其实现商业价值。这个领域有很成熟的业界实践和模式。
现在假象一下如果Docker不去收购Unikernels Systems会怎么样。
如果unikernels在未来成功了，我们就会看到两种独立并且平行的堆栈（一个Docker/容器堆栈，和一个unikernel堆栈），很可能有不同的接口。
这时会出现一个第三方（比如，Kubernetes），屏蔽掉后台运行时及其接口，提供部署到这两种堆栈的单一入口点。那么，结果是，商业化Docker（Docker OSS项目和Docker Inc.商业实体）。
Joe说堆栈中位置越高价值越大，这是对的，但是我认为，在尝试并且使用它时，需要确定正确并且稳固的控制点。
到这里，希望Docker != 容器这个观点应该更加清楚了，还有个大家未来需要熟悉的另一个核心概念。
这个核心概念是： Docker OSS != Docker Inc.
这样的摩擦已经发生在一些公司和项目之间，比如，Kubernetes，Mesos和Docker（Inc.）。他们（还有其他很多）都在为成为这样的“入口点”而“激烈竞争”。
事实上，当所有人都在使用Docker（OSS）标准化时，Docker Inc.只是尝试围绕Docker构建业务模型的众多公司中的一个。
Docker Inc.有（明显）优势，但是大家得记住Docker OSS != Docker Inc.
总之，我想要澄清我并不是想妖魔化Docker Inc.
他们是一家伟大的公司，我非常喜欢它的理念，并且它正在做所有商业公司（包括我就职的公司）都会做的事情：产生利润。
原文链接： Why Docker != Containers and Docker OSS != Docker Inc. （翻译：崔婧雯 校对：）＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译者介绍
崔婧雯，现就职于IBM，高级软件工程师，负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化，中间件技术，业务流程管理有浓厚的兴趣。
</div>