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

[[154735]]

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

決定開發(fā)這個應(yīng)用程序很容易，不過實際構(gòu)建應(yīng)用程序卻很難，如果他們倆走這條傳統(tǒng)路子：買來服務(wù)器在后間搭建服務(wù)器，那就更困難重重。僅僅為了維護網(wǎng)站服務(wù)器、內(nèi)容分發(fā)網(wǎng)絡(luò)和數(shù)據(jù)庫順暢運行，他們倆就需要一個團隊。而這在當(dāng)時不可能。

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

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

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

PaaS的優(yōu)點和弊端

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

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

然而，企業(yè)開發(fā)人員通常更喜歡在內(nèi)部開發(fā)和部署應(yīng)用程序。他們可以使用所謂的“企業(yè)PaaS”解決方案，包括Active State Stackato、Apprenda、Pivotal Cloud Foundry、Progress Pacific和紅帽O(jiān)penShift。雖然PaaS駐留在企業(yè)數(shù)據(jù)中心，但它提供了使用大眾化硬件的同樣的橫向擴展型架構(gòu)。

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

API

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

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

開發(fā)和部署工具

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

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

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

PaaS方面要考慮的問題

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

一旦你大致了解了想要構(gòu)建的應(yīng)用程序，就要問清楚這些問題：

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

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

哪些語言得到支持?

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

提供哪些數(shù)據(jù)庫?

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

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

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

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

改換有多容易?

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

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

你能運行自己的副本嗎?

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

是否有足夠的支持?

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

最前沿的差異化優(yōu)勢

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

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

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

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

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

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

事件處理：許多Web應(yīng)用程序很復(fù)雜，結(jié)合了數(shù)據(jù)庫更新信息和數(shù)據(jù)轉(zhuǎn)換。點擊一下應(yīng)用程序，就會觸發(fā)一連串動作：數(shù)據(jù)從一個機器流動到另一個機器，從一項服務(wù)流動到另一項服務(wù)。

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

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

彈性、冗余性和高可用性是PaaS的幾大關(guān)鍵特點。PaaS本身在設(shè)計時應(yīng)該能經(jīng)受得住基礎(chǔ)設(shè)施層面的故障，并提供分布式機制，那樣萬一出現(xiàn)孤立的服務(wù)器、存儲或網(wǎng)絡(luò)故障，照樣能確保平臺服務(wù)順利運行。

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

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

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

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

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

PaaS迎來爆炸性增長

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

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

如今的開發(fā)團隊有好多選擇，許多團隊在競相提供最靈活的最佳服務(wù)。現(xiàn)在正是你將作為簡單服務(wù)而提供的復(fù)雜基礎(chǔ)設(shè)施連接起來，發(fā)揮創(chuàng)造力的大好時機。

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

[[154736]]

【本文來源：《InfoWorld》|云頭條編譯(未經(jīng)授權(quán)謝絕轉(zhuǎn)載)】