IaaS與PaaS服務對開發的助益

將應用程式遷移至雲端計算平臺上運行，除了趕上流行之外，本質上還是有具體的好處。

當你打算在雲端計算平臺上開發自有的應用程式時，有兩種選擇。第一種是選擇在所謂的IaaS（Infrastructure as a Service）層次上，而第二種則是在PaaS（Platform as a Service）之上。

在這二者之上建構雲端應用程式，究竟存在什麼樣的分別呢？

在IaaS上開發：開發者可量身打造所需環境及架構
所謂的IaaS平臺，像是Amazon AWS（Amazon Web Service）中的EC2（Elastic Compute Cloud），提供的是運行在雲端之上的計算基礎設施。這些就和你自己能夠建置的計算基礎設施沒有太大的分別，包括了：能夠執行應用程式的伺服器及作業系統、連網環境、磁碟儲存空間、還有可能會需要的軟體系統組態，例如HTTP伺服器、資料庫伺服器。

但是最大的差別是，這些計算基礎設施現在都不在你的機房裡，而是在「雲端」之上，你只要刷卡付費，隨時都能夠從「雲端」上取得這些計算資源，進而將你的應用程式部署上去。

對於基於IaaS的應用程式而言，開發本身並沒有什麼太大的不同，使用和之前一樣的程式語言、程式庫，也用同樣的模式開發應用程式。「雲端」所帶來的好處是，計算資源雲端化了，由負責管理「遠在天邊那片雲」的業者幫你處理掉種種的細節，為你帶來種種的便利。

基於IaaS來發展應用程式的優點是，應用程式開發者有很大的彈性，因為在雲端上僅提供最基礎的計算資源及環境，開發者可以自己針對應用程式的需求，完全量身打造出所需的環境及架構。

但是，這是一體的兩面。當開發者可以很有彈性的依據需求，建立自己所需的系統架構，也意謂著，開發者必須自己花費力氣去處理和系統架構相關的各種議題。

其中最重要的，莫過於開發者要自己處理和系統規模擴充性有關的各種問題，像是允許系統在需要提升服務的規模時，透過增加相關的計算資源（例如伺服器、主記憶空間、儲存空間），便可以達到所需的規模。也需要處理各種計算資源的負載平衡以及容錯的問題。

而和系統規模擴充性相關的議題，可以說是在建立系統架構時不大容易處理的一個環節。雖然說，在IaaS上開發可以得到最多的彈性，但同時間，開發者需要自行負責的部分也更多，而且，需要更好的技巧。

在PaaS上開發：獲得更高階的執行環境，不需處理基礎設施相關的細節
而在PaaS層次上開發應用程式，和在IaaS層次上開發則有著相當大的不同。在PaaS上，相較於IaaS所提供的原始設施，它所提供的運行環境，則高階許多。在PaaS這個層次上，主要的目的是要提供一個更高階的執行環境，將諸多和基礎設施相關的細節予以封裝起來。因此，開發者不需要面對如何處理伺服器應如何擴展才能達到應有的服務規模，也不需要考量如何在眾多的伺服器之間處理負載平衡、容錯的技術議題。

開發者所面對的，就是一個被高度抽象化的執行環境，PaaS平臺可能提供若干組滿足不同用途的API、各種開發工具、甚至整合開發環境，讓開發者能據以開發應用程式，但是，開發者無法、也毋需碰觸到各種系統運行的細節。

PaaS平臺的提供者，通常都對於建構超大型系統架構有著豐富又純熟的經驗。他們歸納出在大型系統架構上處理系統規模擴充性的經驗，將這些經驗萃取出精神，進而打造出PaaS層次的雲端計算平臺。其中最典型的例子，當然，莫過於Google了。

Google目前主推的PaaS雲端平臺名為GAE（Google App Engine）。Google強調，當你將應用程式部署至GAE之上運行時，就和Google自有的所有應用程式執行在一樣的基礎設施之上。

可以想像的是，原先Google打造這個被人稱為「Google Infrastructure」的平臺，單純只是滿足自身應用程式所需的超大型全球性系統規模。但是，他們也注意到，雲端計算做為如同傳統電力設施一般販售的可能性及潛力，於是才以原本僅供自家用的計算設施為基礎，打造出適合應用程式開發的平臺，成了在PaaS層次上的一個雲端服務。

若是沒有PaaS，可以問問自己，如果想要擴展系統規模，你可能會考慮投入額外的計算資源，例如，增加主機、增加主記憶體、增加儲存空間、增加網路頻寬，但是，倘若你的系統架構設計無法透過增加這些計算資源，來擴充系統規模，或者是，透過增加這些計算資源可以擴充系統規模，卻有其極限時，那麼你可能就必須設計、建立系統架構。

舉例來說，我們很常見到的Web應用系統架構，就是前端有一個HTTP的分派器（例如Apache的httpd），承接來自於使用者端的HTTP協定連線請求，接著將這些連線請求平均地分派到中間層的Web應用程式伺服器，而應用程式便執行於Web應用程式伺服器之上。應用程式難免需要操作資料，而典型的架構下，資料都儲存在後端的資料庫伺服器上。基於容錯或負載平衡的需要，在架構中可能允許一個以上的資料庫伺服器，彼此之間形成一個群集。

當系統的規模不足以應付來自於使用者端的連線請求時，通常擴充系統規模的方式，便是增加中間層的Web應用程式伺服器數量。因為一開始，可能是系統缺乏足夠的CPU資源或主記憶體資源，於是，透過增加中間層的Web應用程式伺服器數量，便可以得到足夠的CPU資源或主記憶體資源。

好的分派器能承受足夠高的請求流量，能平均地將流量導到中間層的各個Web應用程式伺服器，並且自動偵測出發生異常無法再運作的Web應用程式伺服器，進而不再將請求流量導到發生異常的Web應用程式伺服器。

透過擴充應用程式伺服器數量，只能解決一部份存取問題
這樣看起來很理想，不過有一些問題無法解決。除了容錯的機制可能不盡理想之外，這樣子的架構，也很難無止盡地透過增加中間層的應用程式伺服器，來擴展服務規模。為什麼呢？

在這種架構下，一開始的確可以透過增加中間層的應用程式伺服器來擴展服務規模，那是因為，一開始的系統效能瓶頸，是在伺服器的CPU計算能力或主記憶體量。但是，當持續增加中間層應用程式伺服器來提升規模之後，慢慢地，系統效能瓶頸便會開始移轉。通常，效能瓶頸會移轉到資料存取上。因為資料庫在系統架構中通常是一個集中化的資源，即使系統中可能有多個資料庫伺服器，但是它們在本質上仍然是集中式。當同時間要處理的資料存取請求夠多時，集中式的資料庫伺服器就會變成效能瓶頸，接著就會需要在資料存取的架構上進行各種調整，以便提升效能。

上述是典型Web應用程式在擴展系統規模時，我們時常可以看到的情境。那麼，在雲端平臺上有什麼不同，又能得到什麼幫助？我們下回繼續談。