做了一个在线分享《为支撑高并发应用的Kubernetes性能优化》，在最后总结了这一点，其实这也是做了很多的容器化之后的一个总结。
如图，左面是经常挂在嘴边的所谓容器的优势，但是虚拟机都能一一怼回去。
如果部署的是一个传统的应用，这个应用启动速度慢，进程数量少，基本不更新，那么虚拟机完全能够满足需求。
-
应用启动慢：应用启动15分钟，容器本身秒级，虚拟机很多平台能优化到十几秒，两者几乎看不出差别
-
内存占用大：动不动32G，64G内存，一台机器跑不了几个。
-
基本不更新：半年更新一次，虚拟机镜像照样能够升级和回滚
-
应用有状态：停机会丢数据，如果不知道丢了啥，就算秒级启动有啥用，照样恢复不了，而且还有可能因为丢数据，在没有修复的情况下，盲目重启带来数据混乱。
-
进程数量少：两三个进程相互配置一下，不用服务发现，配置不麻烦
如果是一个传统应用，根本没有必要花费精去容器化，因为白花了力气，享受不到好处。
什么情况下，才应该考虑做一些改变呢？
传统业务突然被互联网业务冲击了，应用老是变，三天两头要更新，而且流量增大了，原来支付系统是取钱刷卡的，现在要互联网支付了，流量扩大了N倍。
没办法，一个字：拆
拆开了，每个子模块独自变化，少相互影响。
拆开了，原来一个进程扛流量，现在多个进程一起扛。
所以称为
微服务
。
微服务场景下，进程多，更新快，于是出现100个进程，每天一个镜像。
容器乐了，每个容器镜像小，没啥问题，虚拟机哭了，因为虚拟机每个镜像太大了。
所以微服务场景下，可以开始考虑用容器了。
虚拟机怒了，老子不用容器了，微服务拆分之后，用Ansible自动部署是一样的。
这样说从技术角度来讲没有任何问题。
然而问题是从组织角度出现的。
一般的公司，开发会比运维多的多，开发写完代码就不用管了，环境的部署完全是运维负责，运维为了自动化，写Ansible脚本来解决问题。
