隨著Docker的興起，基于Docker構建適合企業內部的應用開發平臺(PaaS)，成為一個熱門話題。公有PaaS由于要做到通用和普適性，所以往往很難真正滿足企業業務開發需求。
PaaS最終應該是解決方案，適應客戶需求的解決方案，而且是需要隨著業務需求的變化可以不斷演變。而不是客戶削足適履去適應PaaS這個工具
私有PaaS相比公有PaaS最大的區別在于，其規范是自己根據需求來定制和實施。那么PaaS究竟有哪些規范，又如何結合企業自身需求和業務特點來制定規范?
首先，明確引入私有PaaS解決什么問題?
開源中間件軟件的提供，比如Tomcat、MySQL、PHP等
應用部署自動化，快速升級或者回滾
運維平臺化和自動化，提升運維效率
資源池化，共享運行，提升服務器利用率
面向應用的管理，包括應用創建、監控、報表等
提升DevOps水平。PaaS的特點是更加標準化和自動化
對于擁有應用開發部門的企業，需要能夠將開發、測試和生產三個環境打通，更快的開發、更快的測試、更簡單的部署和管理。
對于應用外包給第三方的甲方企業而言，其IT部門希望生產環境的應用更好管理，并希望在開發、測試階段，就考慮到應用如何在生產環境的運行，避免企業的信息化建設雜亂無章。相比于擁有應用軟件開發的企業，維護難度更大。因為這類企業面對的軟件開發商，開發能力、開發語言和工具差異較大。
當然每個企業對PaaS的需求肯定都會有不同，上面只是一個籠統的概括。具體到案例，需要結合具體需求分析。
PaaS包含哪些規范?
開發、運維在過去都形成了很多方法論。比如ITLE流程規范、SOA面向服務的軟件架構，以及最近幾年流行的DevOps實踐、CI持續集成、CD持續交付、甚至最近流行的微服務架構。
這些令人眼花繚亂的名詞概念背后其實都是對于軟件如何開發、如何交付以及如何運行維護的實踐總結。
那么PaaS的規范應該包含哪些內容，又具體細到什么程度，這個度如何把握?
比如開發規范可以包含代碼編寫規范、開發協作規范，運維規范如果按照ITLE，包括：基于配置管理和工單管理的事件管理、問題管理、變更管理、發布管理等等。
我們認為，PaaS規范的粒度需要把握好。這個粒度，和PaaS的使用者/管理者的需求有關。
對于私有PaaS平臺使用者需要關心：
支持的編程語言、web服務器或者應用服務器
支持的數據庫軟件類型
支持的數據庫模式，cluster還是主從
數據庫主從分離是否透明
支持的文件存儲類型，如何操作
其它類型服務，如何訪問?是否有SDK或API文檔
如何部署應用
代碼目錄路徑和布局的規范
名字服務，代碼如何訪問這些服務(connect)，是通過環境變量，還是通過域名，或者通過封裝的類或者庫，還是通過kv名字服務的查詢獲取?
對于PaaS平臺的管理方需要關心：
統計報表
監控報警
面向應用的監控
如何給開發人員提供一致的開發環境
如何給測試人員提供一致的測試環境
容量管理，如何增減節點
數據保障，備份管理和災備管理
消息發布管理，如平臺對某個軟件進行升級的通知
工單管理，處理使用方提出的疑問
上面描述的這些需求，其實就是PaaS平臺的開發規范/運維規范，說白了就是如何用和如何管。
如何制定規范
我們說需要結合企業自身特點來定制規范，那么具體到細節層面，我們應該考慮哪些因素呢?
組織結構
是否擁有軟件開發部門。如果軟件都是外包開發，那么如何讓外包開發快速了解并立即可以開發?如果是自己內部部門開發，那么如何做好培訓讓他們理解更深刻才能更好地在PaaS上開發。
同時也需要考慮開發和運維是在一個部門、還是一個公司，他們的績效管理模式，是否會導致部門推諉扯皮。這些都會影響PaaS規范具體包含哪些，開發和運維的邊界線在哪里?
人員結構
人員的技能水平，對PaaS的設計也有很多影響.一般而言，技能越好的團隊，希望的自由度越高。但又需要考慮好開發和運維團隊的技能是否能夠相匹配。如果開發方能力過強，運維方在管理生產環境時可能就吃力。如果運維方能力強，開發方就能更省事。
企業已經存在的IT資產
這些資產包括硬件和軟件兩個方面。引入的私有PaaS平臺，過去的資產哪些可以繼續使用避免過去的投資浪費，這是CIO關心的問題。
硬件方面的資產如交換機、存儲往往標準化程度很高，比較容易復用。軟件方面，比如企業過去購買過一套監控系統，如果想將PaaS平臺的監控對接進去，難度可能就比較大，技術上也很可能失敗。這些都需要根據實際情況評估。
可定制和修改的PaaS
PaaS的規范絕不是一成不變，隨著組織、技術棧的變化，PaaS的規范也應該能夠不斷修改適應。
基于docker的PaaS能夠勝任這一點。docker本身的特點是輕量靈活。基于docker構建PaaS，不僅可以提供“可定制實施”的PaaS，特別是可以簡化PaaS平臺的運維管理。
京公網安備 11010502049343號