從一個方面來分析，開發云應用程序的平臺即服務模式有兩種：一種是專用模式，托管在本地或私有云中;另一種是公共模式，由第三方提供商來托管，并采用訂閱支付模式。那只是問題的一個方面。還可以以一種全然不同的方式來分析PaaS：這種方式基于與云環境的聯系。

[[162962]]

據長期的IT和云計算顧問Judith Hurwitz聲稱，從這種聯系的角度來分析PaaS，會發現存在兩種不同的模式。其中之一是，PaaS與某個特定的軟件即服務(SaaS)環境聯系在一起，比如Salesforce的Force.com和Heroku Enterprise。另一種是PaaS受制于某個特定的云操作環境，以亞馬遜網絡服務(AWS)的Elastic Beanstalk為代表。另外還有可以自由添加的PaaS解決方案，它們并不與任何一個云聯系在一起。這些包括Apprenda、CloudBees、Engine Yard及其他PaaS解決方案。

隨著公眾對云提供商安全的信心不斷加強，對PaaS的依賴程度也隨之提高，用于開發云應用程序。雖然PaaS支出僅占總體云環境的一小部分，但正以驚人的速度增長。MarketsAndMarkets公司在最近一項研究中預測，到2018年，全球PaaS市場會增長到69.4億美元，而五年前還僅僅只有12.8億美元――年復合增長率高達32.54%。

作為Hurwitz提出的兩種模式中的第一種，將PaaS綁定到SaaS讓提供商得以“通過提供一個完整的、受保護的生態系統，延伸品牌，”她說。“這是獨立軟件開發商或企業開發人員構建旨在完全在該環境中運行的自定義應用程序的最容易、最快速、最安全的方式。”這不是什么新的想法：2011年――按云計算行業的標準來看那已是很久以前，Workday發布了自己的受制型PaaS，采用的品牌名是Workday集成云平臺(Workday Integration Cloud Platform)。這家公司位于加州普萊森頓，專門開發基于云的人力資源和財務管理應用軟件。

在第二種模式中，PaaS解決方案與整個云操作環境、而不是與某個特定的應用服務緊密聯系起來。她說：“如果你打算編寫只在AWS、微軟Azure或IBM Bluemix上運行的應用程序，選擇它們的PaaS解決方案是合理的選擇。”她表示，比如說，如果某家企業組織在.NET框架方面有扎實的專長，或者有一大批應用程序在使用.NET框架，那么選擇微軟的Azure開發和部署生態系統將是自然而然的選擇。

據Hurwitz聲稱，這個PaaS領域勢必會出現重大變化。她說：“雖然我們仍然看到與某個特定平臺綁定的PaaS解決方案，但現在我們更多地看到Pivotal的開源Cloud Foundry受到追捧，作為實施PaaS的一種標準方法。” EMC旗下的VMware部門在2011年推出了Cloud Foundry。兩年后，EMC將那些資產作為Pivotal Software拆分出來。

Dave McCrory是Basho科技公司的首席技術官，這家公司專門開發Riak開源數據庫。他表示，想選擇合適類型的PaaS來開發云應用程序，關鍵因素是了解手頭的項目。沒有哪一種類型的PaaS適合所有情形，而這勢必需要開發人員的工具包中同時有幾個PaaS。

McCrory說：“由于應用程序開發場景不同，所以有眾多不同的PaaS類型。”他贊同Hurwitz的觀點，表示一種就是SaaS式樣，以Force綁定到Salesforce這種方式為代表。他表示，Heroku不一樣，就在于“你上傳想要運行的各個組件，然后將應用程序上線。它并不像Force那樣緊密地綁定到Salesforce。”

McCory表示，其他PaaS解決方案允許開發與基礎設施更緊密結合的云應用程序，他提到Mesosphere就是個例子。“這是一種PaaS式樣的服務，更接近網絡物理層。”

最近云計算領域新增的一個角色是AWS Lambda，它自稱是“構建和運行云端應用程序的一種全新方式。”McCrory表示，雖然它不是典型的PaaS，但基于這個想法：編寫極小的代碼片段，以便將其他小小的代碼模塊連接起來。McCrory說：“你不是構建一個龐大的程序;相反，你是構建一系列小小的組件。” McCrory表示，與其他PaaS模式一樣，其目的也是加快開發、簡化維護。

無論最終選擇哪種類型的PaaS來幫助開發人員加快開發和部署，McCrory表示，仍要認識到PaaS只是整個開發環境里面的一個組件而已，這點很重要。他說：“當前的趨勢就是，擁有從頭到尾的綜合工作流程、實現測試和部署自動化，即從基于云的IDE(可以在其中編寫代碼)，到源代碼庫(比如GitHub)。”

McCrory表示，對于開發人員來說，轉移到PaaS模式最終是為了加快開發應用程序和更新應用程序(一旦部署到生產環境中)。“優點在于，你不需要升級龐大的整體式應用程序，而是只要進行小幅的增量變化。”

系統可能順暢地運行幾個月，結果卻在軟件變化后出現崩潰，無論是大變化還是小變化。推特已經在2016年1月出現停運，幾乎遍及全世界，公司將這六小時的停運歸咎于“內部的代碼變化”。后來代碼回滾消除了那個問題。McCrory說：“如果你在更新后遇到了問題，若使用PaaS模式，可以輕松回滾，并檢查導致問題的增量變化。這要比另一種方法：六個月的升級周期好得多，因為那樣可能進行了數千處變化，你在查找導致問題的代碼時，可能要停運好幾天。”

Hurwitz表示，雖然由于性能和安全方面的問題，PaaS概念沒有迅速流行起來，但現在這個概念普遍得到了接受。她說：“從單槍匹馬的個體開發人員，到小型部門，再到大企業，PaaS可能是開發云計算應用程序的一種必然選擇。你幾乎可以馬上搭建并運行起來，測試現有代碼，或者用你選擇的一種語言來編寫新代碼。作為一種開發方法，PaaS已站穩了腳跟。”

原文標題：Choose the right PaaS for developing cloud applications

【51CTO.com獨家譯稿，合作站點轉載請注明來源】