雖著雲端服務越來越成熟 , 相關的服務供應商也逐漸增加 , 對於微型企業來說 , 代表有更多的機會可以降低成本並提高競爭力 。「 影化身科技 」 主要專注在 Java 平台的應用服務 , 對於某些應用 , 尤其是 Web 應用 , 可以利用現有的 PaaS 供應商來免除初期投入成本以及服務器維運的負擔 。 本文收集幾個適合用來部署 Java 應用的 PaaS 供應商 , 作為未來部署時的參考 。 本文是 「 運用雲端服務建構企業基礎建設 」 系列文章之一 。

何謂 PaaS?

PaaS 是 Platform-as-a-Service 縮寫 , 中文常稱為 「 平台即服務 」。PaaS 是一種雲端服務 , 提供應用程式基本的執行環境 , 但讓開發者可以免於處理可用性 (availabiility)、 擴充性 (scalability)、 服務主機與網路等等相關的問題 。 由於不需要處理系統的基礎設施 (infrastructure), 開發人員可以比較專注在應用本身的開發上 。 對於雲端運算架構 , 請參考 Wikipedia

選擇 「 平台即服務 」 供應商的考量

跟其他選擇一樣 , 對於判斷採用哪一家的 PaaS, 只有適不適合 , 沒有最好的答案 。 以下是山姆鍋在選擇 PaaS 會做的考量 。

支援 Java 應用 。

「 影化身科技 」 主要是採用 Java 平台來提供服務 , 使用的 PaaS 自然要支援 Java 應用 , 至少要支援 Java web 應用 。

部署的形式 。

有些 PaaS 支援標準的 WAR 應用部署形式 , 像是 Google App Engine; 有些則需要連同執行中介軟體一起包裝 , 像是 Heroku。 熟悉傳統 Java web 應用部署的人 , 可能會覺得可以直接部署 WAR 檔比較好 , 但是 , 通常這也表示您可能面臨更多的執行時期限制 。

部署的難易度

由於現在的 Java 應用越來越龐大 , 夯不啷噹裡面包一大堆第三方的程式庫 , 林林總總也是不小 。 如果 PaaS 要求每次部署時都要將整個應用全部重新上載 , 自然是有點不實際 。 所以 , 應用如何部署到平台也是一個相當重要的考量因素 。 與部署相關的是 : 部署時是否要將原始碼 (source codes) 上傳到平台進行編譯 。 某些 PaaS 的部署方式是上傳原始碼 , 對有些人來說可能無法接受 。

延伸的加值服務

除了應用的執行環境本身 , 雲端應用往往也需要其他服務才能實現完整功能 。 有些應用需要寄送大量電子郵件 , 有些需要使用雙向即時連線 , 不是所有 PaaS 供應商都能夠完整的加值服務 。 因此 ,PaaS 本身是否存在足夠的第三方加值服務以及整合的難易度便成為重要考量 。

供應商套牢 (Vedor Lock-in) 的問題

為了提供雲端等級 (cloud-scale) 的應用 , 很多設計自然無法採用傳統的設計方式 , 這也是為何很多新技術產生的根本原因 , 其中 , 要以 NoSQL 跟 BigData 引人注目 。 為了讓您的應用可以隨著用戶數量無縫地擴充 , 您希望一開始就使用 NoSQL 技術 , 但如此會面對一個難題 : 是否該使用 PaaS 供應商專屬的 NoSQL 資料庫 ? 如果供應商提供的 NoSQL 屬於開源軟體 , 那問題會比較小 ; 但如果像 Google App Engine 的 DataStore 這樣的專屬 API, 您就必須擔心未來轉換供應商的障礙是否太高 。

基礎設施的因素

雖然 PaaS 讓開發人員可以不用花太多心思在底層的基礎設施上 , 但 PaaS 供應商所使用的 IaaS 供應會有不同面向的影響 。 如果您的應用需要底層的平台或基礎設施符合一定的安全規範 , 例如 :CSA, HIPPA 等等 。 如果您的應用需要符合這樣的規範 , 自然會影響可以選擇的 PaaS 供應商 。 另一個基礎設施會影響選擇 PaaS 供應商的因素是支援的資料中心普及性 。 例如 : 您的 web 應用預計使用的人都在亞洲 , 但 PaaS 使用的基礎設施卻在美國 , 這種情況下 , 就要考慮之間的頻寬與延遲是否符合需要 。

Java 以外的支持

除了 Java, 如果 PaaS 能夠支援其他語言自然更好 。 雖說 「 影化身科技 」 主要是以 Java 平台為主 , 但也不是純 Java 的公司 , 所以 , 這點也是要納入考量 。

支援 Java 的 PaaS 供應商

底下是網路比較知名的 PaaS 供應商 , 山姆鍋無法對它們進行太深入的瞭解 , 所以請當作是一個參考列表就好 。

Google App Engine

Google 提供的 PaaS, 您可以假設您部署的應用會跟 GMail, Google Calendar 等 web 應用採用相同的基礎設施 。

對於擔心被 GAE 套牢的人有福了 , 最近發現 AppScale 可以提供跟 GAE 相容的執行環境 , 但可以部署在自己的服務主機或其他 IaaS 供應商 , 如 Amazon。

  • 使用 Google 自己的基礎設施 。
  • 支援 Pyton, Java, Go 以及 PHP。
  • 執行環境有眾多限制 , 例如 : 不能建立新的執行緒 。

Heroku

一開始主要支援 Ruby, 但後來延伸到其它眾多的平台 , 像是 Java, Python 等等 。 跟 GAE 不同 , 它使用的是 Amazon 提供的基礎設施且只在美國區域 。 除了以 PostgreSQL 為基礎的 Database-as-a-Service 外 ,Heroku 依賴其他供應商來提供應用需要的加值服務 。

  • 支援多語言平台 。
  • 使用 Amazon 的基礎設施 。
  • 提供免費使用額度 。
  • 目前為止 , 整合最多的第三方加值服務 。

dotCloud

  • 支援多種語言平台 。
  • 提供免費使用額度 。

Jelastic

算是少數一開始就鎖定 Java 平台的 PaaS, 不知道是不是因為使用 Java PaaS 的人太少 , 後來加入了 PHP 的支持 。

  • 可以自行調整節點數量 。
  • 有整合第三方加值服務 。

AppFog

  • 同樣支援多種語言平台 。
  • 使用 Amazon/HP 的基礎設施 。
  • 有提供免費的使用額度 。

小結

不少 PaaS 供應商都有提供免費試用 , 對於微型企業自然是一大利多 。 但天下沒有白吃的午餐 , 不要貪圖一開始的免費 , 而讓自己以後難脫身 。 最好要有隨時轉換供應商的假設跟準備 !