横空出世的江湖少侠：Docker
2013年，后端的江湖并不平静。Clound Foundry为代表的开源PaaS项目正在辛辛苦苦普及概念，培育用户，吸引了百度、京东、华为、IBM等国内外一线大厂。当他以为四海安固，应用托管和虚拟机云计算组合，天下无敌，可为武林盟主之时，一位少侠横空出世，来者不是别人，正是Docker。
说起当时还叫dotCloud的Docker公司，出道时平平无奇，相比于Heroku、Pivotal、Red Hat等江湖大侠而言，docker还只是个名不经传的毛头小子。但是docker出手不凡，直接就是降维打击，短短几个月在这些江湖大佬还没反应过来之时，就已经赢得了开发者的青睐，在所有的PaaS社区还没有意识到真正危机的时候，就被提出局了。
那么docker到底是怎么降为打击，怎么一出山就打败各大江湖名宿的呢？
有人会说docker是用了容器，cgroup, namespace等技术，所以出手才这么猛。其实不管是容器技术还是cgroup, namespace等linux技术，并不新鲜，也不是docker公司发明的，07年的时候cgroup就已经合入linux主线了，“容器”的概念早已使用多年。Docker项目和Cloud Foundry容器并没有太大不同，在docker发布不久后， Cloud Foundry首席产品经理James Bayer就在社区里做了对比，说明Docker只是使用Cgroup和Namespace的一个沙盒实现而已，并没有什么“黑科技”，不需要特别关注。那么到底是什么使得这位PaaS界征战多年的大佬James Bayer判断失误的呢？
任何技术或者产品被人们所青睐，除了易用性、好用等产品逻辑做的好之外，能对业内形成降维打击的，往往是解决了用户的某个核心痛点。而Docker就解决了开发运维的核心痛点，这个痛点就是测试、线上、开发环境问题，而Docker使用的方法就是镜像。
作为一个开发，比如使用python，有pip的依赖, 上线时需要解决的一个问题是，依赖环境等能同步到线上机器。常见的解决方法是各种黑脚本、黑配置or ansible playbook，太麻烦，太糟心了。而cloud foundry所代表的PaaS项目，虽然提供了所谓的“应用托管”能力，但是，适配起来需要额外的工作量，而且各家有各家的玩法，不同的环境也不易复用。
对于这个痛点，docker的提供了新的解题思路，这个思路也很简单，能不能创建一个压缩包，这个包里包含程序运行所需要的环境，让我的程序在这个环境里运行。这样不管是在线上、测试等任何环境下都可以正常的运行。
Docker Image这个产品就是解决上述痛点，它最厉害的地方就在于只要有这个压缩包在手，不需要任何配置或者修改就可以达到本地环境和云端环境高度一致。
自古英雄出少年，Docker通过镜像这个小小的创新，一举打破了江湖的平衡，开发者纷纷用脚投票，加入了Docker阵营。但事情并未如此简单的截止。
有人的地方就有云，有云的地方就有江湖，而江湖从不平静，解决了项目打包，隔离环境等基本问题后，PaaS还有新的高山等待攀登。
高山既是险阻，也是巨大的机遇，各大厂商为此又开启了纷争。
一统江湖 kubernetes
镜像技术只是PaaS之路的起点，客户最终要部署的还是网站、服务、数据库甚至是云计算业务。解决了单个服务的打包问题，剩下的路要如何走呢？
Docker公司在这条路上经验并不丰富，比不了Could foundry或者是Red Hat, Mesos等业界大拿。所以他收购了fig，SocketPlane等项目，推出Docker Compose，Swarm，Machine三件套。此时，大数据最受欢迎的资源项目管理Mesosphere公司，也发布了一个名为Marathon的项目，成为了Docker Swarm的有力竞争对手。
武林传奇谷歌也不甘寂寞，推出了他的杀手锏，kubernetes。k8s源于谷歌内部的项目Borg，是谷歌多年内部资源调度，任务编排实践的成果。并不是常见的开源社区实践反馈到理论的路线，而是谷歌内部大量实践的基础上，形成的理论，直接投放到开源社区。上来就是pod, sidercar等功能和设计模式，一时间，大家纷纷表示过于“超前”，理解不鸟。
由于现在k8s一统天下，形成了事实上的基础设施，所以大家觉得k8s背靠谷歌，所以一定是一出山就不同凡响。其实并不是这样，k8s早期还是很弱鸡的，在17年的时候，k8s的早期展示的时候还是各种问题，非常差劲，当年旷视做私有化平台组件的时候没有选择k8s，虾皮也是根据Mesos自研，并没有看出k8s的神奇之处。这是因为再好的指导思想也需要代码的落地实现。而k8s初始团队很小，投入的工程能力也很紧张，直到red hat下场，与谷歌形成联盟参与和主导k8s演进。同时成立了CNCF基金会，以k8s为核心孵化了Prometheus和Istio等十分给力的项目。
k8s设计之初就留下了Operator等便于二次开发的方案，同时社区鼓励二次创新，打造了繁荣的开源社区。
尾声
在这里我要根据我的亲身经历说一下，我们很多开发同学，尤其是做平台类开发或者是定规范的，都喜欢留下文档或者接口表示公司其他团队可以这样对我们的平台做二次开发，接入平台。然后发现各部门平台组大家都是这么想，公司里留下一堆所谓平台或者公共组件的烂摊子。
想做一个好的平台，让别人愿意使用，甚至愿意再次基础上做二次创新，那么平台必须做好如下几点：
平台必须提供足够好的抽象或者能力，解决别人的痛点。
提供足够好的工具（组件）比如Prometheus。
产品有一定的易用性，做好产品文档。
唯有这样其他部门或者同学才有意愿接入扩展。当你抱怨别人为什么不愿意使用你的东西的时候，除了部门墙这样的问题，最大的可能就是没有解决别人的核心痛点，易用性也非常差劲。
