霧裡看花 巧辨真假PaaS

雲計算已經刮起了流行旋風，隨著其不斷成熟，應用不斷增長，新使用者湧現。 在IT業界軟體即服務和基礎架構即服務愈發如魚得水。 但是因為雲洗白和市場不成熟，平臺即服務仍舊處在黎明前的黑暗中。

對軟體即服務(SaaS)這樣特定類型的應用，以一種方式訪問複雜應用輕而易舉，而且無需大量現金支出，只需要很低的管理支出即可。 同樣，基礎架構即服務(IaaS)吸引了越來越多的企業，提供了一種訪問多種且大量計算、存儲和頻寬資源的能力，而且可以像本地基礎架構那樣受到控制，無需先期投入。

平臺即服務(PaaS)則是完全另一幅光景。 主要受到前瞻性的開發者的擁戴，PaaS的主要價值定位在於增加了生產率以及更快的部署時間。 PaaS也提供了內置的自動擴展和故障恢復，如果開發者想要在其應用中增加這些功能，則不需要學習這些複雜的代碼。

「結合了預製OS和開發平臺，應用部署就變得輕而易舉，」Roger Jennings說道，他是OakLeaf Systems的首席諮詢師，同時也是一位. NET開發者。 儘管大多數IT人士自然而然的趨向于用IaaS滿足自身需求，但是在微軟的Windows Azure PaaS上只需要十分之一的時間即可搭建一個網站。

霧裡看花 巧辨真假PaaS

當今，PaaS市場只是整個公有雲市場的一小部分。 但是如果PaaS飛黃騰達，很多專家也確信會是這樣的結果，它將對IT人士產生廣泛的影響，他們的角色和職責也會發生轉變。 但是市場仍舊處於初期，對於企業IT而言，很難預測會有多少應用、什麼類型的PaaS平臺，以及PaaS內置的應用是他們可能需要落地的。

PaaS剖析

大多數IT部門需要做的第一件事就是了解真正的PaaS和假冒的PaaS之間的區別。

「你否記得我們過去看到的所有的雲洗白都是來自基礎架構供應商?」 James Staten說道，他是Forrester Research的以為分析師，「在PaaS領域其實更為糟糕。 」

Staten解釋道，他經常看到一些廠商嘗試將IaaS的上的老一套，在增加一點服務就變成了PaaS，讓開發者和運維人員甘傲困惑。

從核心觀點將，真正的PaaS平臺必須包含抽象的運行時環境、應用伺服器、緩存層、整合開發工具，增加自動擴展以及故障恢復功能。 用一個老一點的術語——中介軟體，它可以在公有IaaS之上運行，或者通過在本地硬體上運行實現交付。

真正的PaaS包括但不僅限於，比如微軟Azure、Engine Yard、Heroku、CloudBees和Google App Engine。 亞馬遜Web服務(AWS)的Elastic BeanStalk，儘管經常說自己是PaaS，卻完全對不起自己的帳單，不符合PaaS的規則。

「Elastic BeanStalk就一個如何在IaaS上部署複雜應用的腳本，增加了一些故障恢復和可擴展的腳本，」Staten說道。 相反，真正的PaaS並不提供腳本，但是暴露出可以為應用所調用的元件。

真正的PaaS和假冒PaaS之間的區別不止是學術上的差異;對於開發團隊會產生實際的影響。 對於那些相信自己就是在PaaS上開發的開發者來說，期望是「我編寫我的代碼，我來部署，可以自動化擴展而且能夠自動化實現故障恢復，」Staten說道，而假冒的PaaS則是「應用無法真的擴展和實現故障恢復。 」

PaaS平臺來源

很多PaaS平臺都起源于具體的程式設計語言。 隨著時間推移，大多數PaaS廠商都開始超越單一的語言，提倡多語言。 然而，值得我們銘記的是，要找到適合你的環境的最適合的選擇。 下面是一些PaaS廠商以及他們的原始開發環境的不完全清單。

AppFog——PHP

CloudBees——JAVA

CloudFoundry——Ruby on Rails

Engine Yard——Ruby on Rails、PHP

Google App Engine——Python

Heroku——Ruby

Microsoft Windows Azure——.Net