Rancher创始人谈Docker，创新愈发困难，未来将何去何从？
导读:本文由Rancher Labs CEO及联合创始人梁胜博士在参加DockerCon之前和之后写的两篇文章综合整理而成。从各家容器编排方案均很不成熟的初期到三足鼎立的编排之战，到如今kubernetes似已全面胜利，梁胜博士作为整个发展历程的参与者与见证者，回顾这几年容器领域发展和Rancher的发展与选择，分享了他的一些看法。
Docker近日宣布支持Kubetnetes，拥抱昔日对手，让业界大为震惊。其实，这一点在回溯过去时就早有苗头。纵观Docker在编排领域的发展之路，大概这一决定是历史的必然。这篇文章或许能从另一种视角带你看看这个业界目前最热议的话题。
目前Docker技术得到了广泛应用，在大量需求的驱动下，我们创造了Rancher，在过去三年DockerCon上，Rancher都得到了很多来自用户的热情欢迎和积极反响。
DockerCon的特别之处不仅在于它将主要行业玩家全都召集到了一块，更是因为DockerCon是为数不多的、参会者中用户数量远超供应商数量的技术大会。能够一下子遇到这么多用户，无论是参会还是赞助都十分值得。和我们的用户交谈，听取他们的想法，这激励并启发着我们更好地改进Rancher产品。
Docker的技术革新正处于关键期，最近我们发布了Rancher 2.0 Tech Preview，该版本中我们把Rancher从基于Docker的产品转变成基于Kubernetes的产品。虽然Docker作为一个应用程序打包和运行的标准取得了极大成功，而Kubernetes在容器基础设施、编排和生态系统方面都已经超过了Docker，这也是我们选择Kubernetes的原因。
容器基础设施
基础设施所涵盖的范围不仅只是打包和运行，它还包括存储、网络、负载均衡和安全。三年前,当我们刚开始研发Rancher时，我们认为Docker将会给容器网络和存储定义行业提供标准插件接口。尽管Docker和其他诸如SocketPlane（后被Docker收购）、Weveworks和ClusterHQ等早期先驱做了许多出色的工作，并且还得到了如思科、EMC和NetApp等行业领导者的大量支持，然而Docker接口，像libnetwork、容器网络模型（CNM）和Docker volume插件还是没能成为可行的标准。我们在Rancher中仍然在CNM和Docker volume插件方面做努力，不过还是遇到了难以逾越的挑战：
1、我们还没有实现让CNM在Docker的内置网络实现之外工作。比如，现在还不能创建一个脱离Swarm Mode的CNM实现。
2、我们没法让Rancher上的Docker volume插件在Docker守护进程下保持可靠性。我记得有一个极具挑战性的issue，#18504，它导致Docker守护进程会不时地锁住。暂时还不能解决它，也还没找到解决方案。
在Rancher 1.2（2016年12月发布）中，通过切换到Kubernetes容器网络接口（CNI）和Kubernetes Flexvolume存储框架，我们已经解决了这些问题。因为Rancher2.0是基于Kubernetes的，任何与Kubernetes集成的网络、存储、负载均衡和安全性方案都可以在Rancher上开箱即用。
我们为Rancher开发了名为Cattle的容器编排器来填补Docker Swarm早期缺失的一些功能，包括服务发现、DNS、服务升级和负载均衡器,希望当Swarm更加完善之后，能够最终替代Cattle。
然而，在2016年3月Rancher 1.0发布时，Swarm还没准备好。那个时候Kubernetes还未成熟，容器编排的未来也不是很明朗。因此我们决定，Rancher 1.0要同时支持多编排器：Cattle、Swarm、Kubernetes和Mesos。这样一来，用户便不会受限于某个特定的容器编排器，且Rancher的用户都十分喜欢这一设计。
2016年6月时，Docker公布了Swarm Mode，我们都很为此而激动。Swarm Mode提供了早期Docker Swarm中缺少的许多功能，并且非常接近于Cattle所做的工作。于是我们很快在Rancher中添加了Swarm Mode的支持。
可是直到2017年初，Swarm Mode都没有得到重视。或许是早期的Swarm Mode实现上存在质量问题，也可能是Kubernetes的发展已经遥遥领先。绝大数Rancher用户都在使用Cattle和Kubernetes。
Rancher 2.0建立在行业标准Kubernetes之上。Cattle不会消失——它将成为一种内置的Rancher体验，我们也会持续改进它。通过2.0，我们提供了简单的基于Kubernetes的Docker和Docker Compose用户体验。任何对Docker有基本了解的人都可以快速上手，等用户熟练掌握之后还能体验到更进阶的原生Kubernetes体验。
容器生态系统
DockerCon Europe汇聚了大量响当当的赞助商，也无疑吸引了越来越多的Docker用户。我一直从DockerHub上寻找最新的用户数据作为Docker增长的基准。在2017年4月的DockerCon Austin上，这个数字是120亿，并且在那之后还在增长。
构成Kubernetes生态系统的公司其实差不多，不过参与模式却完全不同。大多数的生态系统合作伙伴像我们一样，认为Docker是一种成熟的技术，且拥有大量的用户。而Kubernetes生态系统更加活跃，因为在这一生态系统中有很多积极的发展、创新和整合。
Docker将何去何从？
早在2016年的12月份，我就曾注意到Docker之父、Docker公司CTO Solomon Hykes在他的一篇blog中，将Docker的定位放在了和OpenShift（以及Rancher 2.0）同样的层级，这层级是位于Kubernetes之上的。看来从那时起，Docker就已计划构建一个全新的、基于Kubernetes之上的Docker产品了？
在DockerCon EU上，我遇见的DockerCon的用户、供应商以及Dokcer公司的员工都给我留下了非常友好和亲切的印象，与他们的交流也让我收获了很多。毫无疑问，这是一次组织充分的大会，对我而言也是一段有趣的经历。
在启程参加大会之前，我曾对Docker公司的未来计划与发展走向提出了一些疑问。而这次大会上，Docker之父、Docker公司CTO Solomon Hykes在他在keynote中的分享正好解答了我上面说的这些问题，这也毋庸置疑成为了演讲中引起业界震动的焦点——Docker决定拥抱Kubernetes，而这也是此次DockerCon上最重磅的新闻。
押宝“现代化传统应用”项目MTA
然而，除此之外，如果说Docker公司还有一个动态就是他们非常希望参会者及业界知晓的，那一定是“现代化传统应用”项目（MTA，Modernize Traditional Applications）。MTA的想法很简单，将传统的Windows或Linux应用程序打包成Docker容器，然后将应用部署到现代云基础架构上并且实现一些资源节约。大会花了三场keynote（整整一天半的时间）来介绍MTA，Docker似乎把整个业务都押在这单一价值主张上了。
然而令我惊讶的是，MTA居然是DockerCon中唯一聚焦的业务案例。DockerCon的参会者和我说，他们期望Docker能够描绘出一个更加完整的Docker商业机会的愿景和版图。然而MTA并没有吸引到大多数参会者，即使是我遇到的一些企业嘉宾也有比MTA更大的计划。其实我更希望Docker能够花更多的时间来加强容器在改变应用程序开发方面上传递的价值，因为在我看来这是一个更大的商业机遇，不过有点可惜，Docker似乎并没有这么做。
Docker技术是一种应用打包的方式，它也是Docker公司从创立之初便开始的实践，MTA便是建立在Docker这一最基础的功能之上。但是Docker EE究竟有哪些具体的功能，能够使得MTA工作得比以前更好？为什么Docker要专门为MTA提供解决方案？客户还需要哪些工具来完成他们的MTA之旅？关于MTA的keynote并没有解答以上这些疑问。（事实上，我相信大家还有更多未得到解答的疑问。）
几点遗憾的地方
另外让我感到遗憾的一点是，除了宣布支持Kubernetes外，Docker再没发布什么和Swarm相关的动态和信息了。Rancher Labs作为Docker生态系统的合作伙伴，在这一情境下，我个人深感在基于Docker技术组件上实现创新愈发困难。我至今记得曾经Docker发布一个又一个杰出的、创新的技术与产品的日子，像Docker Machine、Docker Swarm、Docker Compose、Docker network以及volume插件等等。那时的我们，在Docker发布这些新的创新之后，便会马不停蹄地开始投入相应的工作。时至今日，在容器技术领域依然有许多创新，只不过这些创新大多发生在Kubernetes以及CNCF生态系统中了。
我真心地希望，在整合Kubernetes之后，Docker能够回到过去的状态，为业界带来更多的技术创新。我依然认为很少有公司像Docker这样，既具有出色的创新能力，又专注于产品的可用性。我很期待Docker在下一次DockerCon的表现。
Rancher at DockerCon
Rancher Labs全新发布的新产品Rancher 2.0，一方面，把Rancher 提供的Kubernetes分发版的用户体验，从原生的Kubernetes UI修改到被全球客户广泛接受的Rancher UI，解决了业界遗留已久的Kubernetes原生UI易用性差的问题。另一方面，在产品中增加了可以纳管其他厂商提供的Kubernetes分发版功能，如Ubuntu Kubernetes、Dell EMC Kubernetes、Google GKE等等，从而具备了同时管理多个Kubernetes集群的能力。
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点拒绝访问 | www.codesec.net | 百度云加速
请打开cookies.
此网站 (www.codesec.net) 的管理员禁止了您的访问。原因是您的访问包含了非浏览器特征(3c7aeff-ua98).
重新安装浏览器，或使用别的浏览器你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
【编者的话】Docker现在火的发红发紫，从传统软件企业到互联网企业，从商业巨舰到初创公司，大家都饱含热情的投入到这个充满想象力的技术中来。本文根据本人在云行业的感知和对客户在云时代的困惑和痛点的理解来和大家一起探索一下Docker的未来发展方向。
Docker现在火的发红发紫，从传统软件企业到互联网企业，从商业巨舰到初创公司，大家都饱含热情的投入到这个充满想象力的技术中来。俗话说：外行看热闹，内行看门道；在表面热闹的背后我们要探索如何把Docker从充满想象力的技术转化为先进的生产力。本文根据本人在云行业（暂时这么称呼吧）的感知和对客户在云时代的困惑和痛点的理解来和大家一起探索一下Docker的未来发展方向。
1. 应用产品云中交付：
Docker在自身的定义中并没有涉及到云，其主要是要打造一个统一、快捷、全面、一站式的应用部署容器（个人理解）。不过现在在建设实践中通过容器间的集群还将某个应用分布式部署，以此来应对大规模的业务访问和数据、事务处理的需求，当然集群还有一个重要的意义就是保证应用的高可用性。之前在DockOne.io交流中，大家都在集群中遇到各种各样的坑的，我认为出现这个问题的原因就是Docker容器本身的非主机架构属性所决定，换句话说Docker缺少对于硬件资源的控制和管理。因此，我们可以设想如果在Docker容器和硬件设备之前能够有一个统一池化并管理硬件资源的平台，而Docker只专注与解决应用部署、扩容等问题，那么当前Docker的困境都会迎刃而解。统一池化并管理硬件资源平台目前处在云计算的IaaS层， 而目前 IaaS层的主流技术在HA、容灾、存储等方面都做的非常成熟。如果Docker能够与一个轻量级或者简化版的IaaS云平台相融合，交付应用跑在Docker容器上，Docker容器跑在IaaS的私有云上，这种硬件、云平台、Docker容器的三层架构就可以满足云信息化时代的所有应用场景。
2. 非操作系统的个人工作空间：
这段使用这个拗口的12字是因为我自己实在想不好用什么准确词去形容，因为当前大家也没有这么个说法。其实这个标题的意思是打造一个非Windows、非Mac OS、非Android的但又可以满足所有信息化办公需求的个人工作空间，当然这个目前在saas公有云上已经在做了，像云端个人pc之类的应用等。我觉得如果利用Docker来做会更有效果，但是需要形成一个比较强大的Docker应用开发生态圈。如果我们再往深处假想一下的话，是不是可以将Docker进行可视化界面集成开发后，将Docker 平台打包形成一个可以运行在pc的类操作系统的东西。
3. Docker容器移动互联网化：
这个想法其实来源与在DockOne.io微信交流群一个小伙伴提出的一个问题，就是AppC和Ubuntu使用Snappy应用进行打包的规范有什么区别。这个问题让我关注一下Ubuntu这个当前云计算行业最火热的操作系统，在研究了其使用Snappy应用打包后意图后，我想到了Docker。当前主流的开源的手机操作系统Android最大的问题就是对应用的权限管理不够，例如经常应用后台偷跑啊、容易被应用传染病毒啊等等，这些都搞大家对Android系统不信任。那么如果基于Docker容器这种天然良好的框架，不管进行应用资源的隔离还是进行安全的防护以及进行应用后台运行的管理都是非常具备优势和想象空间的。
最后，我认为Docker 就目前来看是最具想象空间的技术，但是Docker如果要在云时代发挥变革性的作用，Docker必须要借助与一个平台级技术的融合.让擅长的技术做自己擅长的方向，Docker负责向上面向应用，平台负责向下面向硬件。
要回复文章请先或
企业私有云产品顾问主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
CSDN &《程序员》研发主编，投稿&纠错等事宜请致邮
你只管努力，剩下的交给时光！
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
个人大数据技术博客：
作为IT圈的人，在云计算如日中天的时代，如果今天您还不知道Docker的话，那就太OUT了！作为一个2013年正式诞生的开源项目， Docker的发展速度和火爆程度着实令人惊叹。Docker虽然面世时间只有3年多，却发展迅猛，每年都有大的变化。仅就其核心的容器管理部分来说，2013年刚出道时使用的还是LXC，2014年即推出了独立开发的libcontainer作为替代。2015年则向标准化方向更进一步，将libcontainer贡献给RedHat发起，多家公司参与的容器标准化组织OCI（Open Container Initiative），成立了独立于公司或平台的新的容器管理工具开源项目：runC。并且在Docker 1.11版本中已经开始使用runC。Docker已经从容器的后来者，发展成为事实上的标准，以及未来的领导者。Docker——它是真正的未来
发表于 09:44|
摘要：微服务、持续集成、容器云、大数据、电商、传统行业、创业公司等12个专题，Docker、Kubernetes、Netflix、Mesos、CoreOS、阿里巴巴、京东等公司的核心技术负责人现场独家揭秘，容器化和微服务化，详情请点击阅读原文链接。
本文从产业技术发展的角度论述了容器目前存在的问题和为什么它是技术的未来。Docker目前虽然从技术上来讲还不成熟，但是它从真正意义上解决了过去若干年在软件行业存在的诸多问题。文章鼓励大家去尝试容器这个新的技术，在实践中获得经验和教训进而迭代式的前进来改善和提升我们的产业。
这真的是未来
上周我写了一篇文章讽刺容器生态系统的文章《It&s the Future》（/blog/its-the-future/）轻微的嘲笑了一下Docker、谷歌、CoreOS和其它一些容器技术。众多的Docker拥趸把这当成了笑柄，但也有很多人喜欢并分享说&我早就告诉你这一切都是垃圾&。
非常容易理解为什么人们会认为容器的生态系统是垃圾，就像我在文章里讽刺的那样，但当我们第一眼看到Docker是什么的时候并不能很明显看到这一点。容器化有点像虚拟化但又不完全一样。Dockerfile有点像Chef但是它里面包含了一个诡异的分层文件系统。它解决了AWS、Heroku、VMware和Vagrant类似的问题，但是又以一种难于捉摸的方式跟其中的每一个有细微的差别。它有27个竞争的工具而且你从它们的名字完全不能理解它们是干什么的，例如Machine、Swarm、Flannel、Weave、etcd、rkt、Kubernetes、Compose 和Flocker。它们都或多或少的跟闪亮的微服务有关联，但是使得运行一个简单的微服务变得如此复杂不得不说这是一个伟大的傻点子。不仅如此，这还使得众多的初创公司和大公司都在竞争&开发人员青睐&，这在古老的年月里看上去是跟钱相关的，而且还有大量的人在追随着一切。
在你仔细观察Docker和容器之后得出结论说着一切都是垃圾并非不合理。但是也有例外，这是我们未来构建应用的方式。
为什么要仇视呢？
很多人对It&s the Future的反应是认为这是100%精确的，根本不是讽刺，也有人在怀疑围绕容器的大肆宣传。为什么呢？
Docker和容器生态系统（后文简称为&Docker&）借用了应用开发者世界的多个概念，例如虚拟化、SOA和操作系统；然后以不同的目的和好处进行了包装。然而它这么做也带来了开发者社区的大部分问题：坏脾气的人痛恨一切。
在软件行业，跟你期望的不同，里面充满了痛恨进展的人。这些人会在米开朗基罗做完了（译者注：创世纪）之后走进西斯廷教堂声明自己早就有了一副完美的上帝的画像,他们期望天花板是白色的，那些壁画本来也不好。（译者注：指这些人看不起别人的成果。）
同时，绝大部分的软件行业的决定看上去也像一个高中生一样：他们在自己的圈子里过分看重那些看上去很酷的技术，或许根据从Instagram和Facebook上获得的信息而盲从。在这些技术当中他们组成小的团体,他们甚至在自己的笔记本上贴上他们团体的标志，而痛恨那些看上去陌生或者不同的技术。
回到Docker的世界：一种几乎可以做任何事情的新的方式。可以抛弃关于操作系统、部署、运维、打包、防火墙、平台即服务和其它一切东西的规则。有一些开发者立刻爱上了它，有时是因为一些有效的原因例如它真的解决了他的问题，而有时仅仅是因为这是一个闪亮的工具可以使他们看上去很酷，其他人还没有接触到。另外一些开发者则痛恨它 & 这仅仅是过度宣传，它跟以前的技术并没有区别，不知道为什么所有人都在关注它，仅仅是因为一些并不合理的理由。
因为对Docker的反应不仅仅是基于技术本身的。大部分的反对者不是在反对Docker处理重要和复杂问题的方案。大部分情况下是因为他们并没有碰到诸如扩展大的系统的问题。如果你们没有直观和深入的理解&cattle not pets&的含义以及这为什么重要，那么Docker及其相关的工具所做的选择对你来讲会看上去很奇怪和可怕。
合并的世界
Docker处在两个学科的交汇点：Web应用和分布式系统。在过去的十年，我们所在的Web社区使得我们相信只要我们懂得如何编写代码就可以实现Web应用。我们通过写一些HTML、JavaScript和Rails的代码就可以实现一个网站。我们添加了一些表单以及处理程序或者一个API就完成了：这足以发布一个产品、获得关注和客户、赢得利润并改变世界！
同时，在过去的20年间，分布式计算的同仁们也在做类似的无聊的事情。他们实验了一些复杂的协议例如CORBA和SOAP，并学者处理一些诸如大数定律、时钟同步的问题，这些问题对大多数人来讲是太过理论了。这些问题及其方案对任何人来讲都是无趣的，人们只是想着如何利用他们的知识去写代码来实现Web应用。
但是接下来有趣的事情发生了。Web应用已经大到不得不横向扩展，来自Internet的大量访问使得Web应用无法在一个单独的机器上运行，即使通过纵向扩展也无法实现。当我们开始横向扩展的时候，我们开始碰到那些分布式系统中的问题例如&竞争条件&、&网络分裂&、&死锁&以及&拜占庭将军问题&。分布式系统的同仁们已经致力于处理这些问题很长时间了，但是这些问题的解决方案是非常复杂的，甚至在理论上都是不可能实现的。
在早期，Heroku碰到了这个横向扩展的危机。Heroku通过一种极其简单的方式实现了基础设施的横向扩展，这使得我们再次假装这只是在运行一个简单的Web应用。而这种情形使得整个业界被欺骗了至少5年的时间。
我们现在已经走出了这个欺骗的情形，我们发现不得不试着进行横向扩展，需要去重新架构那些不能工作的软件使得它可以横向扩展，我们也逐渐了解了单体架构的问题，理解了为什么单个的数据库无法解决这种问题。这造就了一些新的概念例如&不可变基础设施&、& Pets vs Cattle（译者注：指基础设施在架构中扮演的不同角色，宠物意指小心呵护不能碰触的基础设施，牲畜指Design for fail的基础设施）&、微服务以及一整套最好和最坏的实践方法试着让这些问题变得简单。
在当前变化的形势下，Docker来了并试着解决所有问题。它没有告诉我们继续假装横向扩展的问题根本不存在我们可以继续使用已有的方式处理，跟Heroku所做的类似，Docker告诉我们分布式系统从根本上讲是我们一直以来都在处理的，因此我们需要接受它并开始使用分布式的模式。它没有继续处理一些简单的事情例如Web框架、数据库和操作系统，我们现在有了很多的工具例如Swarm，Weave，Kubernetes和etcd等，这些工具不在继续假装一切都很简单，而是要求我们不但去解决问题，而需要试着深入了解我们正在解决的问题。
这样做的好处是我们获得了去构建横向扩展架构的能力而不是假装我们可以抽象它。我们需要知道网络分裂是什么以及要怎样处理它，如何选择AP还是CP系统，如何构建可以在真正的网络和服务器上进行横向扩展的系统。有时在弗吉尼亚会有电子风暴、有时会着火、有时鲨鱼会咬断海底电缆、有时会有延迟、有时机器会死掉等等。（译者注：指我们需要处理这些异常）
所有的东西都需要更加有弹性、更可靠，我们需要承认这些是我们在开发程序是需要考虑的问题。我们要做不是因为这很酷，或者因为它是虚构的最佳实践，而是因为像亚马逊、Netflix和谷歌已经花了15年的时间来告诉我们如何构建真正能横向扩展的系统。
真正的问题被解决了
因此Docker真正为我们解决的问题是什么？我们在构建Web应用时所做的一切都是脆弱的，Docker强迫我们保持清醒和理智：
到目前为止我们还在将部署机器（DevOps中的运维部分）和部署应用（DevOps中的开发部分）分开来做，甚至是由不同的团队维护的。 这非常滑稽因为应用依赖于机器、操作系统和代码，分开来考虑这些问题完全没有道理。容器在开发者的工具箱层面将OS和应用进行了统一。
到目前为止，我们在AWS、Heroku和其它的IaaS以及PaaS平台上运行我们的SOA架构时缺少管理这些SOA服务的工具。Kubernetes和Swarm 管理和编排了这些服务。
到目前为止，我们在使用这个操作系统去运行我们的应用，暴露了所有的安全问题而不是使用尽量少的资源和暴露尽量少的安全漏洞。容器允许你仅仅暴露你需要的端口，应用可以小到一个单一的静态二进制程序。
到目前为止，我们都是在机器安装完成后使用&配置管理&工具或者多次向同一个机器上部署应用. 因为容器可以通过编排工具实现弹性伸缩，只有不变的镜像被启动，运行的机器从不被重用，因此可以去除潜在的单点故障。
到目前为止，我们都在使用被设计为在单个机器上运行的单个应用程序。Rails的SOA等价物以前并不存在，现在Kubernetes和Compose允许你定义跨服务的拓扑。
到目前为止，我们都在AWS提供的特定尺寸的基础上部署虚拟机。我们不能说&我需要0.1CPU和200MB内存&。我们在浪费虚拟的开销和使用更多的资源。容器需要的资源更少，也能更好的进行资源共享。
到目前为止，我们都在多用户环境的操作系统中部署应用。Unix被设计为有大量用户共享操作系统上的二进制程序、数据库、文件系统和服务。这完全不符合我们构建Web服务的需求。再次，容器可以保留简单的二进制程序而不是整个操作系统，结果就是程序和服务不需要考虑更多的问题。
唯一不变的就是改变
我们的业界迅速的发展，人们在新技术真正成熟之前就迫不及待的追随和使用。Docker正以惊人的速度发展，这也就意味着它还完全没有稳定和成熟。容器运行时、镜像格式、编排工具和宿主机操作系统都有多种选项，每种选项都有自己的实用性、范围、推动力和社区支持。
反观其它产业，事物往往是在老旧和无聊之后才会真正的变得稳定。举个例子，在我们得到REST标准之前有多少协议被废弃？我们踩在SOAP和CORBA的尸体上构建了REST、AJAX和JSON，利用了曾经的经验教训构建了这些新的事物。这是过去十年两个重要的技术转换，但是我们到目前为止REST API还是没有十年前的SOAP那样有众多的工具，而SOAP现在还没有真正意义上的消亡。
在前端开发领域也存在同样的现象，很多人拿我的Docker生态系统文章跟shit-show that&s going on in frontend development（/@boopathi/it-s-the-future-7a）做对比。 在编程语言方面也存在类似的情形，在10年前出现了Java之后，开发人员一直在发明新的方案去解决新的问题。容器生态系统也有很多问题需要解决。
因此我们可以预期Docker现在还不成熟，在你尝试Docker的时候还会碰到很多的边界问题和奇怪的事情，而其中的某些决定在未来几年再往回看的时候是完全的错误。最佳实践就是一个反复试错的过程知道它变得正确。
这个过程会需要几年直到我们解决了所有这些问题。但是这并不意味着容器是垃圾，或者我们可以忽略它。我们会面临一个选择，是坚持使用已有的技术，或者尝试新的技术获取经验教训后迭代前进来改善和提升我们的产业。
如果你在寻找我，我会在未来等你。
【CNUTCon全球容器技术大会】微服务、持续集成、容器云、大数据、电商、传统行业、创业公司等12个专题，Docker、Kubernetes、Netflix、Mesos、CoreOS、阿里巴巴、京东等公司的核心技术负责人现场独家揭秘，容器化和微服务化，详情请点击阅读原文链接。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章