Cloud Foundry 是開放源碼的 PaaS 解決方案，支援多種程式語言、開發框架及資料庫等服務，而且更容易開發、測試及佈署。本系列文章將從零開始，和學習者一起開啟雲端應用程式開發的大門。

今天不談實作～純粹閒聊～
最近連續三天瘋狂的 Coding，在一天睡不到五個小時的狀態下，終於把新系統的雛形給打造出來。為什麼要這麼拼命呢？因為明天就要啟用了＠＠

全新的系統在上星期著手規劃，當時考慮的開發框架選項有：

1. Java/Groovy + Grails
2. PHP + CodeIgniter
3. Node.js
4. Ruby on Rails

以上的排序是依照我個人對技術的瞭解程度。

至於 Production Site 則是以租用 VPS 或 PaaS，考慮的選項有：

1. Linode
2. Amazon EC2
3. MiCloud

這個排序也是依照個人的使用經驗值。

為什麼沒有 Cloud Foundry 呢？

主要的原因是 Cloud Foundry 提供的開放平台 cloudfoundry.com 並不支援 custom domain name，目前也沒有明確的付費方案。其他以 Cloud Foundry 為基礎建立的 PaaS，同樣也是沒有明確付費方案或是還在發展中。

框架的部份最後做出的選擇當然是目前掌握度最高的 Grails，因為熟悉加上它的開發過程相當敏捷，大概用三天時間就把新系統的主要核心功能都做出來。以使用者及權限來說，雛形網站只接受 Facebook 登入，使用 Grails 的 Spring Social + Facebook 驗證套件，大約只要 10 分鐘就能把 FB 登入按鈕搞定（包含 User Role 控管）。使用 Grails 簡易的 Custom Tag 實作，並使用 Bootstrap Plugin，打造基礎介面的時間也幾乎縮到最短。

很快地，今天就面臨要正式佈署的準備。

雖然目前以 Grails 打造的專案是 Cloud Foundry Ready，但各種因素考量下，還是決定先沿用手邊現有的 Linode VPS，我先將原本的 512MB 方案升級至 1024MB（記憶體）。這個升級過程大概花費 20 分鐘，但過程相當無痛，只要修改 Linode 的方案，然後等待擴充、磁碟無損 Resize 完成。

接下來又花了一個多小時完成從開發端自動發佈到 Linode 的機制，有了 Grails 的幫忙，Java EE 專案的痛苦指數其實已經降到相當低。

不過可怕的問題就在正式佈署成功後，發現系統速度其慢無比，比開發機器上面跑得還慢上 N 倍。

直到找到兇手：原本 Tomcat 配置的 Heap Size（記憶體）不夠兩個 Grails 專案吃。

修改了 $JAVA_OPTS 的 -Xmx 選項，從 128MB 調整到 512MB，終於讓系統恢復正常速度。

雖然解決了問題，但這也是不幸的消息，因為以後很快就需要再次升級 VPS 記憶體容量，這代表著每月帳單又要大失血了！

所以我想在 Cloud Foundry 的教學文章中，多介紹一些 Node.js 的開發，它比起 Java EE 真是太省太省太省資源了；因為在用多少算多少的雲收費時代，選擇輕量化的開發工具，對於剛起步的 startup 很重要阿！