對於雲端技術中的PaaS一些看法 / Thinking of PaaS
對於雲端技術中的PaaS一些看法 / Thinking of PaaS
最近在研究雲端技術時，開始興起朝PaaS去研究的想法。以下是整理一下最近看的東西，以及對PaaS的一些發想。
I have studied the cloud technology for some time. Recently I was interested in PaaS. The following is some relevant information of PaaS, and my thoughts on PaaS.
雲端服務的三層次 / Three Levels of Cloud Service Structure
目前大家對雲端技術的三層次大概都很明確了。簡單來說，在使用工具的時候，我們只想關注、調整我們需要的重點（層次），而其他更基礎的東西則交給雲端系統去自動化處理，讓後面系統包裝成服務給我們使用。
雲端技術發展到現在，重點層次已經凝聚成共識，目前可以分成三層次：
- IaaS 設備即服務：重點在於電腦主機伺服器，而它的架設、管理與使用都可以用雲端系統提供服務的方式操作。這是雲端架構的基礎。
- PaaS 平台即服務：重點在於要運作一個系統，類似網頁或是Java程式。系統所需要的運作環境跟資料庫則由雲端系統提供。這是給應用程式開發者使用的層次。
- SaaS 軟體即服務：重點在於可以用的工具。現在許多以網站提供的工具都算是SaaS。
為了管理大量伺服器，我一開始踏入的是IaaS。我研究了VirtualBox，也研究Proxmox VE，現在也想用OpenNebula (Ezilla)。但是這些只能說是方便整合那堆放置難以管理的實體伺服器，還不能達到我想要解決的問題。
開發之前還要配置環境的痛苦 / Preparing Development Environment is Very BORING
到了現在，實驗室許多學生在開發時，他們只需要環境，不需要從整個伺服器開始學起。他們只需要搞懂PHP、JSP跟MySQL、PostgreSQL之間怎麼運作，不想要再學Linux的bash如何操作。
儘管對於ssh的遠端登入、chmod修改權限、設定cron等Linux指令對我們這些習慣管理Linux的人來說駕輕就熟，但對於連PHP跟資料庫要怎麼連線都還在摸索的程式入門學生來說，要如何操作作業系統又會是一大難題。
「現在的學生怎麼這麼不耐操？連這點小事情都不肯學？」
旁觀者肯定會說出這種風涼話，但簡單地想一下就知道：開發能解決研究問題的系統工具，跟搞懂Linux伺服器，哪一個是優先要處理的事情呢？答案當然是前者，而且我寧願學生把搞懂Linux所花的時間全部投注在主要系統的開發，專心做好能跟研究直接相關的工作。
好吧，老實說，這也是我懶啦。每次都在幫人家配置那些環境很煩耶！就算駕輕就熟還是很麻煩啊！身為程式人員的耐心在重複的事情出現第二次之後就會按奈不住了啊！
所以我需要一個方案，能自動幫我把環境配置好。我們只要專心投入在開發工作上即可。
自行架設私有PaaS / PaaS Services
現在提供PaaS服務的公司很多。但是因為我是在學校，我想要長久使用，所以基本上並不考慮收費方案。扣掉這點，能剩下的選擇就很少了。
再來就是要找尋提供我所需要運作環境的平台。Google知名的PaaS Google App Engine在少數流量下可免費使用，勉強納入我的考量，但是他只能用Python跟JAVA開發這點讓我又把它移出了考量清單。同樣的，RedHat的OpenShift也只是支援Java，但它用Git儲存庫來佈署這點我蠻喜歡的。不過上述這些都只有公司提供服務，不能架設在自己的單位。
Stackato是架設私有PaaS的另一個選擇，也有免費方案，蠻符合我自行架設的需求。Stackato以ownCloud來佈署開發程式，可以跑Java跟PHP，也能支持許多資料庫。就功能來說我很感興趣，可是這不是開放原始碼，免費版本的Stackato的限制令我卻步。
WSO2可真的是開放原始碼的PaaS架構了，而且也支援PHP、MySQL與Tomcat插件。其中提到一個特點：
Traditional, non-cloud-aware application platform containers, such as PHP and MySQL, can be extended into a multi-tenant cloud deployment.
傳統上，非雲端的應用平台程式，像是PHP與MySQL，可以發展成「多用戶雲端佈署應用」。
我想像多重租貸模式會是一個框架，它把應用程式（也就是網站）的對外窗口跟抽象化之後的服務接軌。但是細節的部份我還沒仔細摸，不知道能不能提供我需要的服務，有待研究。
一開始在摸的時候，我一直在想，PaaS不就是很久以前很流行的「免費架站空間」嗎？我們向公司請求一個可以運作PHP的空間、MySQL資料庫與網站連線的網址，然後透過FTP上傳我們的程式碼，然後就能夠正常運作。不過意外的是，這些傳統的架站空間似乎都不被當做是一種PaaS，大概是作法實在是太傳統了吧。
我對PaaS的期許 / My Expectation of PaaS
我是希望未來我的網站可以打包成一個像上面WSO2所講的多用戶模式。這個框架會是標準格式，我只要在我的開發環境做好、將框架打包好，然後就可以透過Git之類的程式碼儲存庫佈署到任意的PaaS當中。
應用程式中的設定將不會在開發時寫成固定值，而是做成需要透過框架去向外面服務請求設定的對外窗口。這些對外窗口包括資料庫連線與建置調整、排程工作的需求（開關機時執行的指令、定期執行的指令）、大量資料的儲存位置。舉例來說，我在本機開發時，對外窗口向本機端請求了MySQL的服務；而移到PaaS上的時候，對外窗口則是向PaaS提供的服務要求MySQL的位置。
而PaaS提供的服務則是可擴充的、可動態分配的架構。當對外窗口要求一個MySQL資料庫的時候，它其實是連到提供MySQL負載平衡的中介伺服器上，然後依照框架設定、背後有複數的MySQL資料庫來提供穩定的資料庫服務。同樣的，資料儲存位置使用的服務背後也可能是整合性的機制，不會因為單一機器毀損而遺失資料。
跟一般把服務全部包在虛擬機器裡面的IaaS比起來，PaaS把服務拆得更細，因此就能夠提供更穩定的服務架構。
從PaaS回到IaaS來看 / Deploy IaaS Like PaaS
PaaS把應用程式與服務拆開來，以提供更穩定的架構。不過反過來說，因為服務拆得更細的關係，在有個標準之前，恐怕常常還是會覺得要做什麼事情都是綁手綁腳的不自由。
舉例來說，我的PHP程式想要用命令列來控制FFmpeg轉檔程式，那我就得在Liunx安裝FFmpeg套件，但是在現在PaaS的架構中這應該是不太可能做得到的事情，必須要在IaaS的層級中才有這般自由。
是的，有權限控制一整台伺服器就是網管人員最開心的事情。我在想，如果我們可以在IaaS層級中使用PaaS的作法，那應該會很方便。我的網站架設在虛擬主機中，預設是以虛擬主機自身提供的服務來運作。不過如果我有需要，我可以透過對外窗口自動將設定改成外部的服務，像是使用另一台虛擬主機架設的資料庫。
因此，IaaS層級的虛擬機器就會分成三種類型：一種是多租貸模式的主機，它必須提供對外的窗口供統一管理與設定，讓管理者不必登入到IaaS的主機中修改設定檔；第二種是專門運作資料庫、檔案伺服器的主機，但是它們並不是直接給多租貸模式的主機使用，而是隸屬於第三種主機底下；第三種類型真正提供服務的中介主機，像是資料庫的負載平衡器、分散式檔案系統的管理器，可將背後大量的實體服務集叢化。
以MySQL舉例來說，上圖的(1)是運作Drupal的PHP伺服器，(2)是重複多個的Slave MySQL資料庫伺服器，而(3)則是統一管理這些資料庫伺服器的Master主要MySQL資料庫伺服器。圖片的架構參考自ㄚ忠的MySQL Replication(Master Slave負載平衡)，我一直想做做看，可是目前並沒有這個機會。
另一方面，資料庫架構(schema)自動配置的功能目前並沒有統一。我也需要找一些方便來進行資料庫架構配置，像是Database version control這個。
如果這些架構都要以獨立主機來進行開發的話，虛擬化的負載肯定是很令人頭大。因為現今主流的KVM、VMware雖然號稱效能直逼實體主機，但老實說，一台普通的伺服器跑3、4個KVM，能順利運作就謝天謝地了。
這邊我又再度提到我最喜歡的虛擬化技術OpenVZ。反正每個虛擬機器提供的服務都很單純，根本就不需要像KVM那樣包山包海，那以OpenVZ為基礎建設這些服務不就好了嗎？跟現在主流的KVM、VMware相比，限定運作Linux的OpenVZ檔案小又高效率，非常深得我心。我現在已經把很多應用系統打包成OpenVZ，方便讓實驗室成員輕易建置一個可以用的應用，這包括了DSpace-DLLL。
然而IaaS最大的問題：網路，至今依然沒有很好的解法。我們沒有無限的IP可以使用，可是又想要建設大量的虛擬機器並同時提供服務，那就得要倚賴DHCP加上Port Forwarding。如果能夠搭配DNS的話，那就能做到DNS、DHCP與reverse proxy。不過我找到現在，還是沒看到DNS、DHCP與Reverse Proxy能夠完美搭配的組合。所以最近我想要自己來寫就是。
哎呀，我寫到這邊真是令人手癢，可是不行不行，我的本務好像不是在摸這個啊……
(more...)
Comments