了解雲端應用程式執行的兩種環境

想將應用程式遷移至雲端計算平臺上運行，可以在兩個層次上進行。第一種是選擇在所謂的IaaS（Infrastructure as a Service）層次上，而第二種則是在PaaS（Platform as a Service）之上。

IaaS提供最多開發上的彈性
在IaaS層次上開發，基本上是將計算的基礎設施「雲端化」。基於IaaS來開發應用程式的優點是，應用程式開發者在開發時能獲得較高的彈性，而且可以自己針對應用程式的需求，完全量身打造出所需的環境及架構。但是，雖說在這個層次上開發最有彈性，但這是一體的兩面，這也意謂著所有的軟體架構，開發者必須自行建造，而這有時候並不是一件簡單的工作，尤其是當你想處理的是系統架構的容錯及規模擴充性的議題時。

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

PaaS提供現成的程式開發與執行平臺，平臺本身會受到高度專業管理
對比之下，在PaaS層次上的優勢就浮現出來了。PaaS的提供者，基本上提供的不只是「雲端化」的計算基礎設施，而是「雲端化」的運行平臺。

平臺和基礎設施最大的差別，在於平臺提供的是一個更高階的應用程式開發及執行的環境。在PaaS開發、管理、運行應用程式，並不需要、也無法碰觸到底層的計算基礎設施，這些基礎設施都被更高階、更抽象的平臺給隱藏、包裝起來。開發者在開發時，能運用所使用平臺的專用開發工具，包括API、SDK、甚至是整合開發環境。但是，關於系統的規模擴充性、容錯、安全性、效能最佳化等議題，都是由平臺處理掉。也正因為碰觸不到，所以也毋需理會。

你可以想像，平臺本身是這些議題的專家，由他們來處理這些問題，通常會比你自己處理來得好。

運行平臺「雲端化」省去了應用程式開發者自行建構平臺的力氣及時間。大多時候，你可以說這是讓更專業的人士、用更集中的資源，去完成平臺構建的工作。這些人將焦點放在平臺之上，因而能打造出最好的平臺，便可以讓所有在這個平臺上開發應用程式的開發者，都藉以得到好處。

從這種角度來看，「雲端化」就是一種分工的方式。IaaS提供者所負責的就是基礎設施構建、經營、管理的專業及服務，而PaaS提供者更進一步把所負責的範圍擴展到平臺的層次上。這樣的分工下，應用程式開發者可以更專注在本身應用程式的開發，而不需耗費太多成本及資源在應用外的事務之上。

免於自建平臺或系統架構是PaaS能提供的重要價值。或許當你開始嘗試著將應用程式雲端化時，首先你遭遇到的問題是計算資源的缺乏。你需要更多的伺服器、大量的儲存空間、還有更重要的──大量的頻寬。利用雲端上的計算資源，省時省力又省錢。在一般的系統架構上，你可以解決系統規模擴展的問題。

如何克服資料存取上的效能問題
可是，慢慢的，當你的系統規模愈來愈大之後，你會發現，並不是繼續擴增這些計算資源，就有辦法繼續面對更大的服務規模。因為，系統運作上的效能瓶頸已經不是在這些資源的缺乏，而是源自於系統架構上的限制。這其中最常見到的，莫過於資料存取的效能問題了。

許多應用程式一開始的系統效能瓶頸，會發生在各種計算資源的缺乏之上，例如伺服器的CPU計算能力、主記憶體量、儲存空間量、或是網路頻寬。不過，隨著投入更多的計算資源，這些瓶頸都會被解除，而且到了一定規模之後，瓶頸還會移轉到別的地方，而這通常就是資料的存取。

就像許多人會採用的系統架構中，都有集中化的關聯式資料庫。在這樣的架構下，無論有多少實體的資料庫伺服器來做負載平衡及容錯，因為關聯式資料庫的天性，到達一定的規模（無論是服務規模或資料規模）之後，想要擴展其規模，就會變成一件不簡單的工作。

並不是說關聯式資料庫不能達到很大的規模，而是，這會需要更為高超的技巧及經驗，才有辦法做到。這一直都是不容易的技術議題。

若是觀察一些PaaS層次上的平臺，你會發現解決資料處理的規模議題，往往是它們著墨的重點之一，例如Google App Engine上的Datastore，或是Hadoop裡的Hbase。

當你使用像Google App Engine這樣子的平臺時，處理永續性資料的方法可以說是只有一種選擇，就是使用它的Datastore，而它正是一種非關聯式的資料儲存方式，之所以要把眾多應用程式開發者所慣於使用的關聯式資料操作模型，在PaaS的平臺上，轉變成為僅能使用非關聯式資料操作模型，我想主要就是基於規模擴充性的考量。

立足於此種平臺之上，操作資料的模式，直接就是以處理超大型「海量」規模資料的等級來處理。因為這些平臺上所用的資料操作模型及機制，就是能夠因應此種規模的資料。

因此，當你在這種PaaS平臺上來開發應用程式時，如何動態地依據服務規模，來配置相關的計算資源，會由平臺自動幫你處理掉、當相關的計算資源發生錯誤時，平臺的容錯機制，也會盡可能地協助你的應用程式仍能繼續正常運作。而當你所操作的資料規模或服務規模夠大時，因為平臺所能承受的資料存取規模更大，所以不致於讓資料存取成為擴展系統規模時的瓶頸所在。這就是PaaS平臺所能提供的助益──讓你能真正專注在自己的應用程式上，把平臺甚至是程式設計模型的事，都交給PaaS提供者。

PaaS平臺上的開發限制
不過，當你開始著手開發基於PaaS平臺的應用程式時，你可能會發現許多技術限制，例如，在Google App Engine上的應用程式，除了HTTP/HTTPS URL存取以及發送電子郵件之外，不能夠進行任何對外的網路連線動作，也無法接受來自於外部的網路連線。

你的應用程式也無法對檔案系統進行任何的存取，甚至你的應用程式不能產生額外的執行緒，而且執行的時間長度還有限制。而且，更重要的是，有些程式設計模型也會受限，好比在前段中所提到的，資料存取的模型可能會受限──只能使用非關聯式的資料存取模型。

應用程式開發者或許一開始時面對這些限制，會覺得綁手綁腳，甚至覺得很不合理。但是仔細想想背後的原因，就不難明白這些限制，對於要將運行平臺「雲端化」，是在所難免的先天本性。

運行平臺想要「雲端化」就勢必進行計算資源的虛擬化，也就是將實體的資源切割成虛擬的數份，讓同時運行的多個應用程式，彷彿擁有實體、獨立的計算資源一般。因為虛擬化的關係，平臺必須確保資源都妥善利用，以便最佳化資源。同時，也不能允許應用程式對其他的應用程式產生干擾，甚至衍生安全性的問題。

我們可以說，這些限制都是平臺必須做的，否則，在虛擬化的前提下，就無法善用資源，也可能會存在安全性的問題。

雖說在PaaS上開發應用程式會有這些限制，但也因為有了這些措施，平臺才有辦法做到它想提供的種種技術上的好處。