2005與2015軟件應用部署方式的比較
近期攜程網站由于程序員登錄生產現場誤操作導致整個網站長期無法訪問，這些現象反映了國內很多大型網站的應用部署運營還是停留在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文化正在逐漸普及。
