达维营-前端网今天看到了一篇文章，感觉这个应该是写的对Docker最真实的认识：
虽然文章是15年写的，我个人认为现在这么说依然很对。docker除了对开发友好，部署友好了？但业务性能友好了么？或者说会DOCKER都很有优越感！对于网络与磁盘IO，是doker能解决的么？那我想问下他能做点啥？所以一些高大尚的应用不就是用了就很高级，而是要用好才行，关键怎么是用好？不是能熟练的使用它的命令就好，而是应该真正的能给实际的业务应用带来实质性的性能提升。以下是原文：
最近Docker非常火，以至于和圈里朋友聊天的时候，如果不提Docker，都不好意思打招呼。于是就补习了下Docker的基本知识：《Docker入门与实践》。有了个大致的感觉。
有个云计算的产品经理问我，你对Docker怎么看？我的回答是：很不错，但是现阶段还不成熟，我不看好。总体来说，对开发很友好，对运维是个灾难。我不知道那些鼓吹Docker具有优秀“可运维性”的人，是否真正做过Docker的运维？
这个观点可能来自于很多个理由，其中最大的理由是“碎片化”。我的前一个微博讲运维的本质是可控。那么Docker的碎片化，就是让这个“可控”变得“失控”。为什么这样讲，Docker有个很大的优点，就是灵活，他可以非常灵活的部署，迭代和引用。但这个也是个双刃剑。
举个例子：我们现在做了一个Docker img。这个img可能会被很多业务通过Docker hub 灵活的引用。但若干时间后，这个base img发生了bug或者漏洞，而修复这些东西可能会造成上层引用的img故障，这个时候怎么办？
1：选择重新build img，所有的引用全部重来，这个。。。业务系统稍微复杂一点，这种做法，就是要累死运维了。。。。
2：不做任何强制性约束，哪个业务系统可以改，就改，不能改就算了。反正docker可以灵活的引用，没关系。时间长了，生产环境中就会充斥各个不同的“版本”，运维的同学既不能控制风险，也不能控制稳定性和性能，完全又是要死的节奏。
这个例子很典型，也是Docker对运维影响的其中之一。另外，Docker相对复杂的网络配置，container之间的通信，都是需要攻破的难题。磁盘IO，quota本身也是Docker的弱项，就更不用提了。
所以，Docker的优点，都是针对于开发来讲，而非运维。要说运维的优点，很多人会说Docker非常轻量级，效率高，实际上Docker带来的效率提升，远不及业务系统逻辑和代码优化那么一点点。。。。。。
当然也有人会说Docker的发展很快，以后有很多运维性的提高，没错，但到了那个时候，也许会有更新的容器技术出现，就像nvdimm之于SSD~