為什么需要PaaS？對Deis，Heroku，Flynn的一些觀察
為什么需要PaaS？一句話，現在的應用程序從源代碼到運行階段太復雜，沒有標準的，通用的方式。
整個過程及產出如下：
- 開發階段：源代碼
- 構建階段：發布包/可執行程序
- 部署階段：可運行的鏡像（發布包+配置）
- 運行階段：進程、集群、日志、監控信息、網絡
不論是Deis，Heroku，Flynn或者其他PaaS的目標，都是為了讓2-4這3個階段盡可能的簡單。看了他們所設計的產品，簡單到了什么程度？通過一個客戶端命令行工具，實現了：
開發到構建：
用戶通過git提交源代碼，由PaaS自動構建鏡像，并提供版本的管理——用戶可以創建新版本(提交新代碼或修改部署配置)、回滾老版本等。
部署到運行：
自動選擇運行機器，為每個進程副本部署啟動單獨的容器，解決請求路由和負載均衡，并提供進程的管理——用戶可以做擴縮容、查看日志、監控狀態等、回滾歷史的發布
為什么是這些功能？為什么這些功能不能分別由各種工具實現？
在我看來，代碼從發布到運行由兩根軸組成。
縱軸： 源代碼——發布包——可運行的鏡像——進程
這里的關系是一步接一步，順序往下，不論你用什么工具什么平臺，這4步都是流水式的向下。
橫軸： 負載均衡、集群部署擴容縮容、健康檢查、日志
線上的應用，有以下幾種情況
- 發布新功能：全量更新和部署
- 性能壓力：通過健康檢查或手工觸發，進行擴容和縮容
- 保證業務連續性：在上面的更新中，通過負載均衡，把新請求導入到更新后的容器上，等待舊的處理完后進行更新
所以，上面這4項是一環扣一環，橫向的互相關聯，如果不在一個工具內同時提供這4項功能，就需要人工去填平這里面的信息交互，手動的整合這4個工具，從而帶來復雜性。
約束及實現
縱向編譯：buildpack
buildpack填平的是從源代碼到發布包的坑，就是一組編譯腳本。
PaaS平臺自己提供一些編譯腳本，但也允許用戶按照規范自己寫編譯腳本。
（腳本需要自己下載合適版本的編譯器！）
如果使用Docker，用戶提供的就是一個DockerFile或者Dockerimage地址，拿了直接就能跑起來的東西。
縱向運行：Procfile
buildpack讓PaaS知道怎么編譯程序，Procfile讓PaaS知道怎么運行程序。
一個典型的Procfile就是像這樣
- cat ./Procfile
- web: bundle exec rails server -p $PORT
后面可以通過命令行來動態擴容程序
- deis ps:scale web=4
縱向配置：環境變量
運行的發布包在不同的環境下有不一樣的配置，Deis的方式是通過環境變量。客戶端的命令行工具上設置環境變量后，就直接發送給所有容器，重設這些環境變量，然后重啟。
橫向負載均衡：ngix
橫向日志：集中化的syslog獲得日志
橫向部署：go寫的小程序，用于部署Docker的Container
