开源简史基础：CNCF的诞生

云原生作为计算机技术近几年内炙手可热的一个词汇，这篇文章介绍一下在此基础之上的CNCF的诞生过程。

最小构建单位的变迁

• 2000年：应用程序的运行还是在物理机上运行的时代，以sun的非虚拟化的硬件为代表，当我们需要启动一个新的应用时，往往需要购买一台或者多台新的物理服务器来解决所需要的资源问题，物理机器是构建应用的最小单元。
• 2001年：vmware的虚拟技术使得构建应用的最小单元变成了一台虚拟机，可以通过在一台物理机器上运行多个VM，意味着使用者需要更少的硬件资源投入。
• 2006年：在这一年，Amazon的AWS（Amazon Web Services）通过EC2（Elastic Compute Cloud）在IaaS获得成功，虽然构建应用的最小单元仍然是VM（被成为AMI：Amazon Machine Image），已经可以做到按小时来出租服务器。
• 2009年：在这一年Heroku在PaaS（Platform-as-a-Service）获得成功，构建应用的最小单位被成为buildpack，在buildpack中应用满足12要素，部署新的版本在Heroku上已经非常简单，只需要执行git push heroku即可。
• 2010年：OpenStack召集了大量的供应商提供了开源的IaaS与AWS和VMWare来进行对抗，而构建应用的最小单位仍然是VM。
• 2011年：Pivotal提供了一个开源的可以与Heroku的PaaS相抗衡的开源PaaS，这就是后来2014年启动的CF（Cloud Foundry），在这种方式下，构建应用的最小单位被称为Garden containers，其中可以包含Heroku的buildpack、Docker容器甚至非Linux操作系统。
• 2013年：Docker将LXC、Union File System和cgroups结合起来形成了容器标准，得到了全世界数百万开发者的极大认可，几乎是一夜之间红遍大江南北，使得隔离、重用性以及一致性得到了保证，构建应用的最小单位变成了容器。
• 2015年：CNCF成立，云原生计算通过使用一系列的开源软件实现了三个主要的目的
  • 将应用拆分为微服务方式
  • 将每一部分打包形成各自的容器
  • 提供动态编排机制从而对容器的资源利用率进行优化

虚拟化技术与标准的变迁

• 2006年：在2006年12月19由Avi Kivity宣告了KVM的诞生，而在2007年2月，KVM发布到内核2.6.20中
• 2007年：cgroups最早是由Google的工程师在2006年发起，早期名称为proccess containers，为了和其他Linux内核的名词产生混乱，2007年被重命名为cgroup，合并到了2.6.24版的内核中。LXC正式在cgroups和namespace的基础上实现的隔离与控制。
• 2013年：docker诞生。
• 2014年：coreos与docker分道扬镳，另起炉灶起了一套容器的机制Rocket，并得到了Google等公司的大力支持。而随后也直接成为CNCF的项目之一，然而现在已经由于无人更新淡出人们的视野了，也成为了CNCF第一个剔除的项目。
• 2015年：在2015年，由Docker和Linux基金会携手发布了OCP（Open Container Project），后来此项目被Linux基金会的执行董事Jim Zemlin宣布更名为开放容器计划OCI（Open Container Initiative），后续有更多的公司诸如CoreOS、Redhat等加入一起支持该计划，维护并推进Docker的规范，以建立一个容器的通用标准。
• 2015年：CNCF成立，建议以Kubernetes为中心的云原生解决方案。

技术的发展带来了什么

技术的发展带来的变迁

• 基本构建单元的变迁
  我们可以看到应用构建单元的变迁过程：物理机 -> 虚拟机 -> Buildpacks -> 容器
• 隔离方式的变迁
  隔离方式从重量级变为轻量级，速度更快，尺寸更小
• 提供上的变迁
  服务商的变迁也实现了从闭源到开源，从单一开源服务上到多服务商提供服务的过程。

与原生的发展带来的价值

• 避免Vendor Lock-in：完整和逐步完善的开源软件技术栈使得在任何公有云、私有云以及混合云上的部署的能力得到了落实，避免了Vendor的Lock-in。
• 无限的横向扩展性：可以获得从几台节点横向扩展至数千台具有自愈能力的多租户节点，以Google为例，仅仅根据2014年的统计数据信息，Google每周启动20亿个容器，这意味每秒钟的数量是3300个左右，已经有企业在这个方面做出了强大的示例，以这个统计数据为例，基本上对绝大多数的企业来说，这份能力就是无限的横向扩展性。
• 速度和可维护性的同时提高：通过将应用进行分割为微服务化，从而使得速度和可维护性都能有所提高。
• 获得弹性的能力：无论是容器、机器甚至是数据中心级别的故障，弹性的能力都能够有相应的机制和方式得到保障，很多企业已经在这方面作出了很多实践。
• 提高效率和资源利用率：通过对编排机制，能够对微服务进行动态的管理和调度，从而更好地提高了效率与资源的利用率。

总结

这个时代技术的发展速度越来越超过我们的想象，Docker现在已经几乎无所不在，但是从它的诞生到现在仅仅只有六年，Kubernetes的影响越来越大，而Kubernetes的1.0版本从2015年7月份发行到现在仅仅4年，云原生的服务网格已渐成气候，但是从概念的提出到现在不过三年，技术的发展也来越快速和有趣了。