从物理服务器到虚拟机再到容器技术的应用，逐步提高了我们对计算、存储等资源的利用率。虚拟机和容器的编排调度工具的应用极大的简化了运维人员的操作，降低了工作量。

今天，我们分别从开发人员和运维人员视角讲述虚拟化和容器技术为我们带来的改变。

开发人员视角：

我是一名开发人员，我使用Windows操作系统进行软件开发，本地部署了自己最擅长的软件开发环境。客户要求使用CentOS作为服务端软件的运行环境。在虚拟化技术诞生前，这可难倒了我。我是该放弃熟悉的Windows操作系统改装CentOS系统进行系统开发还是再买一台计算机安装CentOS系统进行服务端环境部署？显然这两种方法我都无法接受，一方面，CentOS不一定有我熟悉的开发软件，上手成本太高；另一方面，买台计算机经济成本太高啊！！！

虚拟化技术出现

现在有了虚拟化技术并且已经相当成熟了，Windows 10自带hyper-v虚拟化（其他版本可以安装vmware workstation等），创建1台虚拟机再简单不过了。安装上系统就可以拥有CentOS操作系统了，然后再在CentOS系统内部署服务端所需的环境即可，一台计算机就把所有环境全部搞定了。但虚拟机占用了很大的系统资源，导致我的Windows偶尔会有卡顿现象。

容器技术出现

为解决虚拟机占用大量系统资源的问题，容器技术应运而生。现在Windows10可轻松部署docker容器。现在我需要一个以CentOS为基础的web服务环境，只需要2部操作，1拉取镜像，2开启容器，方便、简单、便捷，甚至我都不用懂CentOS怎么安装、web服务器怎么部署（web环境配置还是要知道一些）。容器相对于虚拟机占用更少的系统资源，不用创建专用的虚拟硬盘，同样的硬件配置可比虚拟机部署更多的“独立服务”。

如果客户已经部署了容器环境，我只需要把我的系统和环境制作成1个镜像文件，简单几条命令就可以完成部署，完全不用去考虑再次部署环境的问题，减少了不确定性。

作为开发人员我很开心，我可以把更多的精力投入到提升软件开发能力上，同样的计算机我可以部署更多的软件环境，只要我够强，我就可以做全栈开发了！

运维人员视角

我是一名企业的运维人员，我管理着几十台物理服务器，但每台服务器都跑着专门的业务，我的职责是让这些服务安全、稳定、不间断地为内外网用户提供服务。

现在有新的业务系统要部署，我肯定不能让新业务和老业务跑在同一台服务器上，不然老业务出了问题影响会很大，这个锅我可不能背。我要打申请买一台新的服务器，层层审批我不怕，我只要系统稳定运行。服务器到位后，我和公司开发人员联系，“服务器到位了，来部署吧”。开发人员兴奋的坐高铁来了，到机房见到服务器后尴尬的跟我说：“哥，我这个系统需要装在Linux上，免费的CentOS就行！”。“WTF？我这服务器可是预装的正版Windows啊，价值不菲啊，我给你装免费的CentOS。。。我给你装”。。。。。。经过一番折腾系统终于上线运行了，但每月总有那么一次宕机事故，怎么也查不出原因。。。难道我还要再申请1台服务器做热备或者负载均衡？慢着，负载均衡我岂不是要再买（或者部署）1台负载均衡器？多么痛苦的工作。。。

虚拟化技术出现

我们企业部署了虚拟化集群，现在部署新业务系统只需要按照模板新开个虚拟机就可以了。物理服务器宕机？那不叫事，我可以让虚拟机自由漂移。关键业务不稳定？只要资源充足，我再复制个新的虚机，做双机热备，再不行我再搞一套负载均衡服务。只要我能行我可以把环境搞的很健壮，但关键是我得能行！！！

容器技术出现

容器技术出现了，这东西确实很节约资源，就像是个超轻量化的虚拟机。但如果没有很好的编排调度工具，仅使用原生的容器技术，我现在还不能升级容器，不然我的工作会一团糟。后来，k8s（kubernetes）出现了，完美解决了容器的编排调度问题。

现在开发人员要部署新的业务系统，我会要求他制作专门的服务器镜像，协商好存储、网络资源和副本数量，然后编制一份yaml文档，提交到k8s就好了。k8s自动创建负载均衡环境，副本故障自动重启，始终保持要求的可以数量。系统升级也只需要一个yaml文档，并且可以轻松实现滚动升级和回退。

运维工作从没有像现在这么轻松过！！！

----完----