近期携程网站由于程序员登录生产现场误操作导致整个网站长期无法访问，这些现象反映了国内很多大型网站的应用部署运营还是停留在2005年的阶段，该文展示了2015年的生产现场运营现状。
在过去十年中，构建和发布应用程序的方式已经发生显著变化，这篇文章比较了2005年和2015在Java/JVM上应用部署的不同。
2005 = Multi-App Containers / App Servers / Monolithic Apps
2015 = Microservices / Docker Containers / Containerless Apps
2005 年我们基本都是以WAR文件作为项目结果，其包含Java的Web应用和有关依赖库包，这个应用被部署到一个单个的应用服务器，称为容器，因为它包含一个或多个应用，这个应用服务器提供了很多基础服务比如HTTP服务器，服务目录或共享库包等等，不幸的是部署多个应用在一个容器中在扩展性 部署性和资源使用上有很多磕磕绊绊，应用服务器将应用和底层系统依赖隔离开来，这样避免“it works on my machine” 问题(只在我机器上能够运行)，但是事情变得不是很平滑，因为系统依赖和配置游离于应用服务器也就是容器之外。
在2015年，应用能够以作为自我包容单元的方式部署，应用自身包含一切，它直接运行在标准的系统依赖之上就可以，在Java世界，一个无容器containerless应用是一个ZIP文件，其包含包含基于JVM运行需要的一切依赖库包，大多数开发框架已经切换到这种containerless方式，比如Play框架， Dropwizard和Spring Boot等等。
系统级别的更完整可移植的自我包容单元有 Docker 和 LXC，不同于过去将很多应用部署到一个应用服务器容器中，一个个单个应用加入到Docker image，然后可以部署到一个或多个服务器中。
微服务在这里扮演了重要角色，因为以一个个微服务部署可以分离独立，而传统的应用服务器当部署其中一个应用时需要重启整个服务器，这也就是企业部署速度是蜗牛的原因，部署应用是一件非常危险的工作，必须提前几个月与众多团队协调好，热部署只是一个承诺，从来没有在生产环境实现过。
而微服务激活了独立团队部署自己的应用的愿望，微服务能够快速准备 快速部署和扩展服务的能力，这些需求正好能够将containerless应用运行在底层Docker容器中实现。
2005 = 手工部署
2015 = 持续提交 /持续部署
2005年是手工部署，多个整体单一monolithic应用捆绑在一起，通过手工配置上传到生产环境。
2015是持续递交和持续部署，每天可以部署提交几百次。
2005 = Persistent Servers / “祈祷它不会当机”
2015 = 不变的基础设施/ Ephemeral Servers
今天，Netflix的Chaos Monkey能够随机关闭服务器，以确保我们各自准备工作完成就绪，然后启动，可以瞬间进行应用实例的增加和减少，因为基础设施的不变性，我们解决生产问题再也不需要SSH登录到主机(banq注：近期携程停机事件是由于程序员登录生产环境误操作导致，采取微服务+Docker+不变基础设施环境，这种情况能够避免)，日志服务被导出到外部服务，能够以实时流方式查看。
2005 = Ops Team运营团队
2015 = DevOps 开发运营合一
在2005年运营团队拿到WAR文件，负责部署 管理和监控它，开发人员手机无需24小时开机，因为运营人员可以在生产环境凌晨3点出现问题时做一些事情解决，但是***的风险就是在软件交接时造成了很大的缓慢。
今天开发人员将会对投入生产的代码一直负责到底，类似New Relic, VictorOps, 和 Slack这样服务能够帮助开发人员负责起运营职责，DevOps文化正在逐渐普及。
