平臺即服務(PaaS)是一種新的橫向擴展型平臺，便于開發、測試和部署應用程序。它可供公有云和私有云使用，為多種編程語言提供了可擴展性、敏捷性和支持。

早在2011年，斯坦福大學的兩位研究生Bobby Murphy和Evan Spiegel靈光乍現，對文本消息有了精辟的認識：堆積的文本消息是個嚴重問題。Murphy和Spiegel從朋友那里聽到了一個個的故事：由于被不該發現的人發現了仍敞開的可讀消息，結果搞砸了關系、敗壞了聲譽、丟掉了飯碗。他們于是想到了開發Snapchat，這個應用程序可以迅速忘記通過它傳送的所有消息。

決定開發這個應用程序很容易，不過實際構建應用程序卻很難，如果他們倆走這條傳統路子：買來服務器在后間搭建服務器，那就更困難重重。僅僅為了維護網站服務器、內容分發網絡和數據庫順暢運行，他們倆就需要一個團隊。而這在當時不可能。

于是，Murphy和Spiegel決定求助于谷歌應用引擎(Google App Engine)，這個框架可以將應用程序必不可少的所有基礎設施組合到一個產品中。這個PaaS(平臺即服務)讓他們能夠致力于為應用程序編寫邏輯，而這個框架處理安全存儲數據和高效管理交付方面的細節問題。

如今，Snapchat的用戶多達數百萬。不過，這家公司仍然很小，只雇有幾十名員工。該公司的小規模很有迷惑性，因為在某種意義上，從事谷歌應用引擎開發的所有谷歌人員也是其團隊的一員。

如今，成千上萬個應用程序構建在眾多PaaS解決方案上。其中一些應用程序依賴PaaS滿足幾乎各個要求，而另一些應用程序只使用幾項功能特性，依賴專有的軟件堆棧來滿足其余要求。不過最終，每個PaaS提供了一樣的東西：一個完整的環境，便于開發、測試和部署應用程序。PaaS提供了一種服務豐富的高可用性平臺，另外還有兩大優點：云可擴展性以及(在大多數情況下)支持多種語言。

PaaS的優點和弊端

動態擴展能力至關重要。如果新的客戶大批量涌現，計量體系要運轉得更快。如果需求因某個產品或服務很流行而激增，這家服務公司就進入上升通道。應用開發人員沒必要為核心應用程序之外的任何東西而操心。

許多PaaS解決方案只在公有云中運行，包括Amazon Elastic Beanstalk、CloudBees、Force.com、谷歌應用引擎、Heroku和Windows Azure――更不用說諸如Parse之類的MBaaS(移動后端即服務)解決方案了。公有云PaaS的用戶往往依賴軟件開發商(比如Netflix或Snapchat)，這類軟件開發商構建和部署面向公眾的Web或移動應用程序。

然而，企業開發人員通常更喜歡在內部開發和部署應用程序。他們可以使用所謂的“企業PaaS”解決方案，包括Active State Stackato、Apprenda、Pivotal Cloud Foundry、Progress Pacific和紅帽OpenShift。雖然PaaS駐留在企業數據中心，但它提供了使用大眾化硬件的同樣的橫向擴展型架構。

無論公有還是私有，所有PaaS解決方案都有許多共同的特點。下面介紹其中兩個最重要的特點:

API

PaaS解決方案(公有云或私有云)都隨帶自己的一套API，可用于訪問數據和各項特性。如果這些預制的API以一種合適的方式提供開發人員所需要的一切，那它們很好。要不然，就會出現挑戰。服務提供商不可能必寫每個應用程序來迎合每個客戶。而如果服務提供商決定改變API，可能與你的應用程序保持向后兼容性，也可能不是這樣。

如果是內部部署型企業PaaS，你不會受到可能導致應用程序無法正常運行的API變化。私有PaaS還為你提供了更大的靈活性，因為你可以配置自己的API，以便本企業中的服務進行會話。一旦這項工作完成，私有PaaS上的所有應用程序都能充分利用那些API。

開發和部署工具

在許多情況下，PaaS僅僅提供了用于測試、部署和管理應用程序的平臺。至于實際的代碼編寫工作，開發人員通常使用本地機器，像平常那樣上傳代碼。除了自助服務和動態橫向擴展功能外，與傳統應用服務器最大的區別就是，運行時環境支持多種語言。

然而，一些PaaS解決方案實際上包括集成開發環境(IDE)――或者在一些情況下，甚至讓非開發人員也能夠使用可視化應用程序開發工具來組裝應用程序。這些工具很適合一些應用程序，但是經驗豐富的編程人員往往更喜歡自己的工具，很可能會覺得預定義的工具功能有限。

一大好處是與Git和Jenkins集成，管理軟件版本控制和持續集成。此外，一些PaaS解決方案包括提供了某種應用程序生命周期管理機制的工作流程工具。這相當有用，尤其是在組織管理多個應用程序開發項目時，但是它們需要異常靈活，足以適合目前的流程。

PaaS方面要考慮的問題

為你的應用程序選擇合適的PaaS需要全面評估自己的要求。如果你構建的是僅僅交換短暫狀態更新的輕型應用程序，可能不需要事務符合ACID(原子性、一致性、隔離性和持久性)的復雜數據庫。不過，一個銀行應用程序需要牢不可破的SQL數據庫，有異地備份，還要有一整套報告工具確保一切都受到了追蹤和審計。

一旦你大致了解了想要構建的應用程序，就要問清楚這些問題：

這家公司的生存能力多強?

這個問題主要適用于公有云PaaS提供商。一旦你選擇了PaaS，你可能會被提供商鎖定，具體取決于你使用的PaaS的特定功能。如果PaaS被收購或破產，你辛辛苦苦的工作成果可能轉移不出去。這種依賴性可能是許多企業不太愿意選擇公有云PaaS的主要原因。

哪些語言得到支持?

有幾個PaaS解決方案相當專業化，其中大多數是在公有云。比如說，Salesforce的Force.com只支持其自己的類似Java的語言Apex，而CloudBees僅僅面向Java開發人員。然而，一個總的趨勢是擴大支持語言的種類。紅帽OpenShift目前聲稱覆蓋范圍最廣，支持Java、Node.js、Ruby、Perl、PHP和Python等語言。

提供哪些數據庫?

幾乎每一個公有云PaaS都提供MySQL數據存儲區;許多還提供PostgreSQL。這年頭，你還有可能找到支持MongoDB等NoSQL數據庫的功能。NoSQL工具通常提供更高的性能和更靈活的架構，可以支持迅速演變的應用程序。比如說，很容易為一些記錄添加新字段和特定數據塊，開發人員還能迅速適應新需求。

雖然NoSQL數據庫的周轉時間短，但缺點是確保數據一致性方面相對缺乏保障。數據通常正確存儲和檢索，但是奇怪的差錯或崩潰有時會帶來錯誤和故障。對社交網絡應用程序而言，這種缺點可以接受，客戶可以原諒偶爾出現的故障。

SQL數據庫提供了較可靠的機制，確保數據一致性，因而對使用關鍵任務型數據的復雜應用程序來說具有更大的吸引力。這種數據庫更成熟，常常能夠支持功能更豐富的分析和報告。

平臺提供一些備份和鏡像也很常見，而且常常橫跨大片區域。關鍵任務型數據可以自動存儲在世界上不同地區，那樣萬一發生重大事件，就能提供彈性。

改換有多容易?

不是說與每家提供商都能保持永久的關系。有時候，一段時間后，提供商滿足不了你的要求。有時候，你的要求會變化。有時候，改換新平臺很容易，有時則不然。所有平臺都會帶來某種程度的鎖定現象，因為僅僅遷移和重新配置很麻煩――但是有些遷移起來比另一些更困難。一些提供商使用Linux和Windows的自定義版本;另一些擁有專有層，一旦你離開，會迫使你改寫所有的自動化代碼。

最大的障礙就是專有的語言包和API。如果你使用某一家提供商的一些服務，如果你想換成另一家提供商，可能不得不改寫這些代碼，因為兩家的API會不一樣。這可能是積極采用一些最復雜的工具和服務面臨的一個重大的、又常常隱藏的風險。一旦你選擇了它們，圍繞它們構建你的應用程序，切換成本就會相當高。

你能運行自己的副本嗎?

企業PaaS解決方案在你自己的數據中心運行，提供了更高的安全性、靈活性和控制性。不過切記：在大多數情況下，你需要將PaaS部署到自己的私有IaaS基礎設施(比如OpenStack或VMware的vCloud)上，才能獲得可擴展性的全部好處。在一些情況下，PaaS提供商同時提供公有云版本和內部部署型版本;這樣一來，就很容易在兩者之間遷移應用程序。在這種混合場景下，你可能將不大敏感的信息移到公有云，將比較重要的數據保留在自己的數據中心中。

是否有足夠的支持?

PaaS可以為你節省大量的時間和精力，但是它無法為你編寫應用程序。你需要逐漸深入了解產品，找到使用API的最佳方式。最優秀的公司提供了在線說明文檔和示例代碼。比較好的公司定期提供課程，以便用戶了解基礎知識。在線支持必不可少。一些最優秀的公司還提供工程師，他們可與你的項目團隊合作，甚至編寫一些最復雜的代碼。

最前沿的差異化優勢

大多數PaaS提供商提供一樣的基本的大眾化服務，用于存儲信息、構建和部署應用程序。最優秀的提供商在添加下一層特性，以便為客戶簡化工作。這些額外特性值得一提，因為它們對于部署速度大有影響，如果你重新構思應用程序，它們還能適應變化。

插件生態系統：沒有哪家服務提供商能開發出滿足每個人要求的系統。一個穩定成熟的插件生態系統讓別人編寫的代碼能夠為你的應用程序添加功能。某些插件對一些任務來說必不可少，這取決于你是什么樣的用戶和所處理的任務。

一些用戶依賴插件存儲和檢索來自其他云中其他服務的數據，以此擴大應用程序的積極影響。比如說，他們可能將備份副本發送到遠地云，或者可能依賴轉換工具，比如在線外語翻譯工具。其他用戶使用插件來增添另外的合規邏輯層，以便篩選審查進入系統的數據。這方面有許多選項。

這些工具的復雜性對服務和用戶來說都是個挑戰，因為插件開發人員實際上成了編程方面的合作伙伴。如果用戶犯了錯誤或者造成死循環，整個服務就可能岌岌可危。同樣道理，用戶必須依賴插件，才能在與PaaS本身相符的層面交付服務。如果雙方都為這個過程投入了足夠多的時間，這可能是富有成效的合作關系。

大數據探查：由于越來越多的應用程序依賴復雜的分析，一些服務提供商在提供復雜的統計數據處理工具。比如說，音樂服務依賴統計模型來推薦新歌。

優秀的數據分析工具是PaaS脫穎而出的一個方面。一些在構建可供這項任務租用的Hadoop集群。另一些在為內置到數據庫層的報告程序包添加更復雜的分析功能。最優秀的工具提供了復雜的統計模型，它們能夠適應裝入數據的響應，讓系統功效大大增強。

事件處理：許多Web應用程序很復雜，結合了數據庫更新信息和數據轉換。點擊一下應用程序，就會觸發一連串動作：數據從一個機器流動到另一個機器，從一項服務流動到另一項服務。

控制這多個步驟的一個好辦法就是，事件管道或消息傳遞服務。這種工具安排安在機器之間流動的消息，讓編程人員沒必要處理棘手的通信問題。一旦數據庫更新了事務信息，數據庫就會向數據倉庫發送一個新的事件，附有發送方面的信息。這一連串事件有效地將大批服務連接起來。應用程序用戶可能只要按一下按鈕，就會觸發精心設計的按順序操作的事件，它們讓許多服務可以協同運行。如果為你做好了事件傳遞工作，開發優秀的應用程序要容易得多。

安全性和可用性：編程人員往往對安全性和可用性問題習以為常。這是PaaS本身必須內置安全性的一個原因。如果系統出現故障或泄漏重要信息，可能會釀成嚴重后果。你可能期望企業級私有PaaS與傳統的企業目錄和驗證系統集成起來，并提供基于角色的訪問控制。公有云PaaS提供商還在添加安全層，在一些情況下，針對資源使用，提供異常精細化的控制。

彈性、冗余性和高可用性是PaaS的幾大關鍵特點。PaaS本身在設計時應該能經受得住基礎設施層面的故障，并提供分布式機制，那樣萬一出現孤立的服務器、存儲或網絡故障，照樣能確保平臺服務順利運行。

安全標準：一部分安全和合規標準包括如下：FIPS 140-2(聯邦信息處理標準)、ITAR(《國際武器貿易條例》)、ISO 27001、PCI DSS Level 1(支付卡行業數據安全標準)、FISMA Moderate(《聯邦信息安全管理法案》)和SOC 1/SSAE 16/ISAE 3402。如果你的應用程序要處理敏感的個人數據或交易數據，更需要PaaS提供商遵守一整套標準。雖然標準本身并不是萬無一失的保障，但是它們充分證明了工作人員在關注細節，并制定了一套增強安全的體系。

訪問控制：服務提供商提供許多不同的解決方案來控制對PaaS及工具的訪問。最復雜的方法使用公鑰加密技術，對針對重要變化的所有請求進行簽名。對服務的訪問則使用SSL和SSH來加密所有通信，確保只有擁有相應私鑰的人才能進入系統。

不是所有事件都需要此類措施。針對一些API的較簡單請求使用更靈活更高效的令牌來限制用戶。令牌還用來衡量一些計量服務的使用情況。

故障追蹤和SLA：雖然所有服務提供商都旨在獲得最佳結果，但是錯誤和異常難免會發生。最好的服務密切追蹤故障，那樣用戶和公司就能盡量減小故障引起的麻煩;有些服務提供記錄服務故障或異常的公共網頁。

大多數PaaS提供商還提供服務級別協議(SLA)，保障正常運行時間或性能達到一定的級別;如果實際提供的服務未達到指定級別，提供商就會給予退款或積分。在云領域，SLA往往是分層次的，較高的服務級別收取較高的費用。如果某應用程序很重要，萬一發生嚴重故障，提供商再怎么彌補可能都無濟于事。這是全面審查PaaS提供商的又一個原因。

PaaS迎來爆炸性增長

如今，如果開發團隊坐下來計劃開發一個新的應用程序，他們常常期望獲得Snapchat那樣的發展。這家公司聲稱，它每天處理的“snap”(該術語指短暫的文本消息)多達上億個。文本消息進來后，公司存儲起來，有人讀取后，它們就會消失，從此不會再次看到。

要是沒有一個優秀團隊在處理繁重任務，Snapchat不可能從一無所有，變成每天處理數億個文本消息。雖然Snapchat依然規模很小，但他們利用了整個應用開發團隊的能力和洞察力。

如今的開發團隊有好多選擇，許多團隊在競相提供最靈活的最佳服務?，F在正是你將作為簡單服務而提供的復雜基礎設施連接起來，發揮創造力的大好時機。

作者簡介：Peter Wayner是《InfoWorld》雜志的特約編輯，出過的圖書超過16本，涉及眾多課題，包括開源軟件(《Free of All》)、自動駕駛汽車(《Future Ride》)、增強隱私的計算(《Translucent Database》)、數字化交易(《Digital Cash》)以及信息隱藏(《Disappearing Cryptography》)。他的著作經常出現在《InfoWorld》雜志上，并為大大小小的軟件項目提供咨詢服務。關于自動駕駛汽車的著作《Future Ride》的第二版現已出售。他還為惠普公司的TechBeacon營銷網站撰稿。