云應用開發(fā)不會在一夜之間完成。開發(fā)者必須仔細的，根據云資源的需求來設計云應用的使用，運行和規(guī)模。此外，云應用的開發(fā)過程往往比傳統(tǒng)的應用開發(fā)更加靈活，通常遵循DevOps的原則和做法。

一些開發(fā)者開始轉向開源平臺即服務(PaaS)，以支持快速的云應用開發(fā)和部署周期。但是，開源開發(fā)平臺也會給開發(fā)者和企業(yè)帶來了新挑戰(zhàn)。以下是開源PaaS可能會產生的六個問題，以及如何克服它們的步驟。

成功的開源PaaS需要管理層支持

開發(fā)者的投入對于開源PaaS的成功至關重要，但更重要的是獲得業(yè)務上層和管理團隊的認可。企業(yè)內部應對DevOps原則和云軟件開發(fā)有著共同的愿景，并且了解遷移到開源PaaS的好處和風險。

企業(yè)方需要以DevOps的目標來監(jiān)督團隊重組，并且在必要時批準增加工作人員。企業(yè)領導者還應該幫助制定開發(fā)日程，并合理計算出平臺的集成和支持費用。

如果缺乏企業(yè)方面的支持，會阻礙云軟件的發(fā)展目標。你最不希望的事情是部署一個云開發(fā)平臺，然后，在六個月到一年之后，企業(yè)卻決定要使用別的方式。

一些PaaS平臺發(fā)展緩慢

云計算相對來說仍然還不成熟，新服務和功能會一直出現。云開發(fā)平臺和PaaS也會在新的功能登場時不斷演變。然而，由于用戶社區(qū)對開源軟件的影響很深，因此無法保證新功能會以足夠快的速度出現以滿足你的開發(fā)需求。

雖然每個PaaS產品都有著類似的功能，但具備這些功能的速度卻有所不同。例如，Pivotal的開源PaaS產品Cloud Foundry以其對語言的支持，服務整合，以及與其它如Chef，Puppet，Jenkins和NoSQL這樣的開源工具的集成著稱。然而，Cloud Foundry上只提供初步的容器支持，用戶界面主要靠命令行，支持數量有限的軟件部署商業(yè)模式以及在應用的性能指標衡量上偏弱。

監(jiān)控一個平臺的發(fā)展路線圖然后再作出決定。那些發(fā)展緩慢或者正在經歷某種艱難的發(fā)展模式的平臺可能會為你的應用開發(fā)團隊和你的業(yè)務帶來問題 。

為PaaS項目找到相關文檔

開源云開發(fā)平臺有著復雜且要求很高的框架，承載著大量的詳細文檔。隨著這些平臺的發(fā)展，它們的文檔必須不停更新，每一個文檔必須提供一致的功能和特性的信息。

那些支持他們各自開源項目的商業(yè)機構，如Pivotal對Cloud Foundry，Red Hat對OpenShift以及Salesforce對Heroku的支持，有助于對更新的簡化和劃分優(yōu)先級。例如，Cloud Foundry在網頁中提供了大量的文檔鏈接，介紹關于其命令行接口，部署和集成，管理，故障排除，服務創(chuàng)建等等的內容。相比之下，紅帽也為OpenShift提供了類似的文檔。

然而，在開源PaaS的發(fā)展過程中，我們無法保證所有的改動和更新都能夠被明確或及時的記錄下來。這可能會使開發(fā)者失去許多機會，伴隨代價高昂的錯誤和混亂。

從開源社區(qū)獲得PaaS支持

圍繞一個開源PaaS展開評估，部署，整合和建立一個軟件的開發(fā)計劃是很艱巨的任務。對于內部的專家來說，肯定會碰到不少難以解決的集成，性能和自動化上的障礙。這意味著你會需要平臺的技術支持。

開源社區(qū)通常負責支持開源平臺。但是，盡管社區(qū)可以幫助解決不尋?；蛐”姷膯栴}，沒人能夠保證你一定會得到可行的解決方案。例如Pivotal和Red Hat之類的母公司以論壇，wiki和可搜索的知識庫來提供一些基礎的支持，但仍然無法做出提供一個快速解決方案的承諾。

在某些情況下，企業(yè)可以選擇開源平臺的商業(yè)版本，來結合開源代碼的可擴展性與企業(yè)級的技術支持。例如，Pivotal為Cloud Foundry的商業(yè)版本提供高級和開發(fā)者的支持。然而，一定要考慮這種方法的利弊和成本。

衡量免費軟件的成本

開源軟件通常不需要花費就能獲得，但從長期來看并不總是免費的。大多數企業(yè)都做好了廠商提供企業(yè)級別支持的費用準備，但還有一些其他不那么明顯的隱性開源成本。

額外的開銷可能包括了服務器，存儲，初始評估，概念證明項目，部署和與第三方工具的整合。組織還需要將維護，管理和報表的成本也算進來。

開源PaaS可以簡化云軟件開發(fā)，同時最大限度地降低企業(yè)的采購成本。但平臺非常復雜，需要大量的專業(yè)知識來部署，集成和高效的使用?；〞r間慢慢選擇滿足你當前和未來需求的合適工具。