1 2013年,我在做什么？
时间回到2013年，那会我还在读大学，刚学完计算机基础，好像还学习了一点Java。课程安排里还有C、C++，平时去图书馆里还能看到Visual Basic,C#等语言的书籍。当时听别人说技术变化很快，但是自己还没有太深的体会。
现在，再去看下编程语言历史
2 编程语言历史
从可追溯到的编程语言至今，涌现了太多的语言，有些我没听过，有些我也没见过，有些我听过但没见过，有些见过没用过..
整理了一部分眼熟的
| 语言 | 年代 |
|---|---|
| 机器语言 | 1940年以前 |
| 汇编语言 | 1940年年代 |
| FORTRAN | 1954 |
| LISP | 1954 |
| COBOL | 1959 |
| Simula | 1962 |
| BASIC | 1964 |
| Pascal | 1970 |
| Smalltalk | 1972 |
| C | 1972 |
| SQL | 1978 |
| C++ | 1982 |
| Erlang | 1986 |
| Perl | 1987 |
| Python | 1991 |
| Visual Basic | 1991 |
| Lua | 1993 |
| Java | 1995 |
| JavaScript | 1995 |
| PHP | 1995 |
| C# | 2001 |
| .Net | 2001 |
| Scala | 2003 |
| Go | 2009 |
| Swift | 2014 |
| Rust | 2015 |
内容引自维基百科: 编程语言历史
大概列举了20几种语言，有些至今还活跃在各个领域，有些已逐渐沦为历史，通过编程语言的变化感受计算机技术的变迁。我们熟悉的语言可能已存在很久，近几年比较热门的Go都已经有十几年的历史了，就有一种总跟不上技术脚步的感觉，过了几年才后知后觉。
让我不禁联想到，容器技术又发展多久了呢
3 容器技术风起云涌
云计算领域
说起云计算，我第一次接触这个术语的时候就感觉，好牛逼！虽然不知道它是干啥的..
云计算：Google中给出的定义就是指通过互联网，以按需服务的形式提供计算资源。这样企业就无需自行采购、配置或管理资源，而且只需要为实际使用的资源付费
我的理解是企业无需再自己去花费金钱、精力，去部署服务器，搞机房这些，只需要买买买...
当然这是按需购买的计算资源。
而云计算服务模型又有三种:
- 基础设施即服务(IaaS)
- 平台即服务(PaaS)
- 软件即服务(SaaS)
而之后崛起的Docker与PaaS之间又有着剪不断理还乱的关系。
时间线回到2013年，在当时，虚拟机和云计算已经是比较普遍的技术和服务了，主流用户的普遍做法就是租一批AWS或者OpenStack的虚拟机，像以前管理物理机那样，只要用脚本或者手工的方式部署就可以了。
这个我也有体会，在我第一家公司时用的是自己的服务器，有自己的物理机房，所以需要将程序打成jar包手动在物理机上部署。而当我们用云商的机器以后，就会有本地环境与云端虚拟机不一致的问题。所以云计算服务就是谁能更好的模拟本地环境，更好的提供“上云”体验。而PaaS就是解决这个问题的一个方案，只要将这个PaaS项目部署在云端的服务器上，开发者只需要一条命令把本地的应用部署在云端
例如以Cloud Foundry为主的PaaS项目，通过下面一条命令即可
cf push "我的应用"
由此可对当时的PaaS项目有一个初步的了解。
沙盒机制
是一种隔离应用的机制，利用Linux操作系统的Cgroups机制和NameSpace机制，将应用隔离在其他应用看不到的地，叫做沙盒或者镜像
- Cgroups
- NameSpace
PaaS时代的开始与结束
当时云计算的从业者都意识到，PaaS的时代要来临了
可是正当人们以为PaaS时代来临时，这些PaaS大佬们就被宣告出局了
而发生这件事的原因就是Docker
Docker项目如何冲出来的
当时还叫dotCloud公司，也是PaaS浪潮下的一份子，相比于当时以Cloud Foundry为主的PaaS大佬，dotCloud微不足道，但是它选择开源了自己的容器项目Docker，起初没人在意，因为容器技术不是一个新鲜的词汇，在其他的PaaS项目中也只是基础设施中偏低层的部分，但是完全出乎意料的，Docker就火起来了，以至于其他公司都没参与就已经出局，而引起这个事件的究其原因就是镜像。
为何Docker镜像能冲出重围
既然Docker镜像能冲出重围，俘获开发者的心，一定是解决了某些痛点问题，这就要从PaaS提供的能力说起了。 PaaS提供了一套应用的打包与分发机制，运维只需要在云端部署PaaS项目，开发者就可以通过一键部署在云上了。
但是就是这个一键，前期需要很多的准备工作
要为每种语言，不同版本都维护一个包，包含一些应用可执行文件和启停脚本，但是就是这个包也可能本地运行的很好，到了云端就各种各样的问题。关键解决问题的方法也没有什么可以借鉴的，只能自己摸索。
Docker镜像，打包了整个操作系统的可执行文件，本地环境与云端环境的高度一致，基本有了这个压缩包就可以利用某种技术创建沙盒，然后运行你的应用程序，而且用起来也非常简单
只需要几个命令，就可以把镜像打好，把容器运行起来
docker build "我的镜像"
docker push "我的镜像"
Docker真正发力点
但是dotCloud并没有满足于此，在2013年底将公司名改为Docker，也就意味着任何商业性的活动都不能再使用Docker的商标，在2014年推出Swarm项目，之前悉心运作的Docker项目，其实也是为了让Swarm收获果实。
但是Docker项目已经如此成功，为何还要重新回到PaaS的老战场呢，原来Docker的管理层和股东已经意识到，Docker毕竟只是负责容器启停和创建的小工具，只能充当幕后英雄。而用户真正想部署的还是他们的应用、数据库、集群，这种平台级的能力才是用户真正愿意付费的地方。
Swarm与容器编排
Swarm集群呢，因为用的是Docker容器原生的API，对于开发者来说上手成本很低，原来的命令在集群下也很容易，比如在集群中运行
docker push -H "我的集群"
此时，大红大紫的Docker已经不差钱了，围绕在小🐳周围的技术圈生机勃勃，Docker又接连收购了很多容器相关的优秀项目，比较成功的案例是对Fig项目的收购，Fig项目第一次提出了容器编排的概念，后改名Compose，很熟悉..
Mesos双线作战
此时之前在大数据领域比较出名Mesos项目和它背后的公司Mesosphere看到了机会，也准备分一杯羹。虽然没有Docker容器原生API的支持，但是它在几年前就有过过万节点的验证，在大规模的集群部署有很强的优势，这对一些大公司很有吸引力。
容器其他玩家坐立不安
其他容器玩家此时地位有些尴尬，Core OS的Rocket容器，开发者并不太买账，Red Hat也只剩下和Cloud Foundry同时代的OpehShift一张牌可以打。
Google推出Kubernetes项目
这时，基础设施领域巨头Google开始发力，推出Kubernetes项目，依托于Google自身在容器技术领域多年的沉淀和积累，并为了区别与Swarm和Mesos，Google的应对方式是Borg。从而在项目一开始就避免了与Swarm和Mesos同质化。而合作伙伴Red Hat又很懂开源社区的运作，Kubernetes在Github上逐渐远超Swarm，而在这种形式下，Kubernetes又推进民主化架构，鼓励开发者参与，社区一片繁荣。
落下帷幕
最终，Docker在2015年宣布将企业版内置到Kubernetes项目中，Docker公司的CEO辞职彻底落下帷幕！
4.说明
本篇文章大量引用张磊老师在极客时间的专栏《深入剖析Kubernetes》里的小鲸鱼大事记故事系列，非常精彩，推荐去学习。
有个问题就是，既然已经有这么精彩的文章了，为啥我还再折腾一遍，直接去读不就好了吗
对于我来讲，在学习的过程中就是看一遍感觉学会了，结果过几天就会忘记。人有个记忆遗忘曲线，如果我按照遗忘曲线的规律去复习巩固，确实可以加固知识，但是当我想给别人讲的时候，我发现又不知道从何讲起。就像大家都知道费曼学习法很好，但又不知道能讲给谁听..
而写作呢是一个与自己对话的过程，在这个过程中把知识讲给自己听，我在脑海里整理了一遍，怎么讲才能更容易理解。写的时候给自己又说了一遍，接受信息的我又听了一遍。
为了能更好的消化这部分内容，这四篇文章我反复读了十多遍，这过程还有一些细碎概念的Google，以及为了验证一些内容去动手实践，所以收获还是蛮大的。
可是有限于自己的水平和认知，很多理解的可能并不全面(一定会很多..)，但是嘞，只要勇于开始，逐步去提升自己的认知，精进技术，就没什么可怕的。
5.鼓励语
这篇文章梳理了容器技术兴起的历史，从云计算中PaaS到容器化技术，到Docker崛起将PaaS巨头们拍在沙滩上，再到Kubernetes发力将Docker拍在沙滩上，了解技术的发展才能在之后更好的理解设计，而不是上来就扎入到源码细节中，虽然梳理这篇文章用了很长的时间，但是对容器技术的理解又深了，接下来就要真的冲入到技术中了，加油！
