現在市場上關于將云服務的級別提升到基礎設施即服務(IaaS)以上的動靜或聲勢越來越大。在云服務層次體系中，價值鏈上的下一個選擇就是平臺即服務(PaaS)。不像IaaS托管運行虛擬機，并要求用戶提供操作系統和中間件，PaaS提供了包括軟硬件在內的完整平臺，應用程序在該平臺上運行。PaaS能實現更多的功能，因此它可以為用戶帶來更多的潛在好處。正是由于這個原因，提供商們有底氣定更高的價位。
PaaS也許是云服務從IaaS自然進化的下一個階段，但是具體實現的方法可能不止一種。微軟的Azure代表了一條途徑，拿來現有的數據中心平臺，然后在云端復制。第二種PaaS方法由諸如Cloud Foundry之類的工具來實現：通過所選擇的工具開發你自己的“平臺”，并部署它。第三種方法得到了亞馬遜網絡服務(AWS)的支持，利用Web服務補充或增強IaaS，從而創建一種“平臺服務”模式。從IaaS到PaaS的這三條途徑都有其可取之處，所以決定走哪一條意味著要進一步深入了解相關細節。
經由微軟Azure走向PaaS道路
想遵循微軟的Azure模式實現PaaS，你那些以云計算為目標的應用程序必須在數據中心中的微軟服務器軟件套件上運行，或者能在該軟件套件上運行。因此，這種方法的優勢在于，能與當前的軟件策略聯系起來;用戶很容易從微軟服務器升級到Azure，因為這家云服務提供商還是內部部署型軟件平臺提供商。確保兩者同步應當簡單又直觀。
Azure方案的缺點在于，很少有數據中心服務器平臺是以一種形式廣泛部署的，因而除微軟以外，很難表明這種方法很實用的一種平臺。微軟拒絕向未來的PaaS競爭對手開放其Windows服務器框架，這意味著一些Azure用戶會覺得被微軟牢牢束縛。還不清楚微軟會如何打造Azure，以添加對Windows服務器來說并不重要的云服務功能，比如現在AWS提供的緩存服務。
這種Azure PaaS模式的其他例子是基于Java虛擬機的云計算平臺，這是一種可在多個架構上運行的便攜式平臺。亞馬遜及其他公有云服務提供商提供托管的Java虛擬機和Java應用程序，它們可以在幾乎任何的數據中心或桌面系統上運行。不過，這種方法只有在目標應用程序使用Java語言編寫而成時才有效，這對許多用戶來說是個嚴重的局限性。
使用第三方工具組合PaaS
實現PaaS的第二種方法更具普遍性。Cloud Foundry和OpenShift等工具讓用戶可以從IaaS入手，并且添加了操作系統和中間件工具以構建云計算平臺。借助這種方法，用戶就能夠讓應用程序在一套可靠的軟硬件組合系統上運行。用戶和應用程序生命周期流程則免于對平臺軟件進行的維護。
組合PaaS的問題在于，需要搞清楚誰來負責構建和維護平臺映像。公有云提供商可以使用組合工具來開發PaaS所依賴的平臺，但提供商不太可能冒這個險。提供商不得不賭一把，看看是否有足夠的應用程序可以在這個平臺上運行，從而獲得切實可行的市場機會。如果組合工具的靈活性被用來構建多個平臺，那么確保每個平臺實時更新就很耗費精力，管理成本也隨之增加。這些任務會被推給云計算用戶。
用戶自己可以使用同樣的工具來組合平臺，并且讓平臺在IaaS上運行。如果這些工具允許用戶自行組織中間件和操作系統組件，并讓它們可用于應用程序部署，用戶將受益匪淺。這是操作系統或中間件發生變化時，重新制作每個機器映像之外的一種替代方案。實際上，這是如今平臺組合工具的最主要的使用場合。不過，為某一個平臺找到小眾市場讓人懷疑這條途徑會不會廣泛用于公有PaaS。
采用平臺服務方法
最后一種選擇就是平臺服務，這是AWS目前實際采用的方法。平臺服務假定PaaS的目標是，添加針對云計算優化的服務或者是云計算特有的服務，并且在通過URL調用Web服務的任何應用程序中支持這些服務。這種方法很獨特，原因在于它針對的是為云計算更改或編寫的應用程序，而不是從內部部署環境遷移過來的應用程序。
這種著眼于未來的方法讓平臺服務成為推動公有云服務發展趨勢的因素。平臺服務模式提供了更高的靈活性――就像組合平臺模式那樣，但是又把新的平臺元素與重要的云計算應用程序特性結合起來。
不盡如人意的地方是，用戶必須維護這些機器映像，因為這種模式并不托管運行操作系統或中間件。添加Cloud Foundry之類的組合平臺工具以管理這些元素，有望為用戶們解決這個問題。
從理論上來說，像AWS這樣的公有云服務提供商可以提供眾多的平臺服務，因而實際上有望定義一個云計算操作系統。如果這么做，如果提供了特定的開發工具，就像針對當前平臺開發應用程序那樣針對該云計算操作系統開發應用程序，內部部署型平臺提供商可能會決定支持它，以便充分利用新的應用程序。那樣，云或者就會出現，將市場由云計算適應內部部署型平臺，變為內部部署型平臺適應云計算。
京公網安備 11010502049343號