Google App Engine – 新時代來臨的震撼

April 28, 2008 (Monday) Leave a comment Go to comments

Google App Engine (GAE) 月初在公開發表,announce 的那幾天每天都佔據了各大技術網站的版面。一個全世界都在看,全世界都在玩的產品,一定有它獨到之處,當然一定要來研究研究。Download 了 SDK,試著開發了一個簡單的程式,其實我對 python 並不熟,加上對 Django 一無所知,但卻不會覺得開發很困難,反而覺得比開發 Java 還要快還要順。雖然使用 GAE 的經驗很淺,不過 GAE 給人一種新時代來臨的感受。

在 Business model 方面,其實有太多太多的討論跟介紹了,一定很容易找到。會覺得是一個新時來的來臨,不是因為這是一個可以跟 Amazon S3 / EC2 對抗的 service,而是在開發技術上面 GAE 也做了一些突破。

跟 Java web development 比較起來,GAE 在開發上讓人覺得最驚艷的地方就是修改 code 的 feedback 速度。一般的 Java web development 在修改 code 之後,需要 compile -> deploy -> restart web container 才能看到修改,但使用 GAE,基本上你的修改馬上可以 apply,沒有 compile、沒有 restart server。這個說法也許有點落伍,很多人馬上就會想到 Ruby on Rails (RoR);也有人會想到這不是本來 Python + Django 就有的能力?就算是 Java 界,Groovy / GrailsJRuby 等也可以做到同樣的事情,何必大驚小怪呢?

GAE 當然不是只是拿 Python 跟 Django 出來騙騙小孩的玩意,真正強大的就在 Big Table 的部份。不要問我 Big Table 是什麼,我答不出個所以來,但站在 GAE developer 的角度而言,沒有 DB 這個東西。使用 GAE 在開發時,你的 code 中的 domain model 就是唯一的 model,沒有 DB,也沒有 DB schema、版本等問題。修改 domain model 的 code 馬上反應在下一次執行裡。GAE 的 domain model code 建立在 Django data model 之上,用起來很方便,類似 RoR 的 Active Record,但是少了 DB 的麻煩。

即使使用 RoR,在 domain model 上還是有得頭痛,因為 DB 的 schema 如何跟 code 裡的 domain model 保持同步就是一個大問題,一般 DB Migration 可以應付這個問題,在 domain model 改變的同時,準備一段 migration 的 code / description 就可以讓開發架構幫你把 DB 改到同一個版本。在 Java 也有 liquibase 可以做到這件事。但免不了要下去改東西,更嚴重的是,這個修改很可能沒有辦法即時反應 (至少在 Java 應該還是免不了要 compile -> db migration -> restart),所以又掉回了比較慢的 development lifecycle。

那麼用 Big Table 有什麼 trade off 嗎?有的,就是大家熟悉的 SQL / relational model 等等武功全廢。雖然 GAE 提供了一個叫 GQL 的東西,語法類似 SQL,但沒有 join 等等在 SQL 裡威力最強大的功能,思考也不宜使用 relational model 去想你的 data,因為這樣會完全想不通要怎麼辦。會不會有什麼事變成做不到了?我想有可能,但絕對不會太嚴重,因為絕大部份講究 OO 的 code 本來就很少直接運用 relational model 在操作,所以才有 OR mapping 的出現。如今 GAE 一不做二不休使用了 Big Table,除了宣示它在 scalability 上舉世無雙以外,也帶領 GAE 的 developer 進入一個新的時代,一個不去用 relation model 思考的年代。

我不是花了很多的時間在 GAE 上,寫進階的系統會不會出問題我沒有辦法知道,但以基本 web 常見的功能而言,很容易開發。Big Table 完全不會影響到我的思考,反而在 development lifecycle 上給了很大的進步,幾乎所有修改都能馬上看到 feedback。Agile development 中,fast feedback 佔了很重要的一個地位,愈快有 feedback 代表了開發的速度愈快。拿 Java 作比較,在 code 的修改上 Python + Django 的 feedback speed 就已經快了一大段,再加上 Big Table 又勝過了所有使用 DB 的 solution (包括 RoR、Django、Grails and JRuby 等等)。這個開發速度上的震撼讓我一直在想,用 Java 開發 web 是不是已經過時了呢?在 GAE 的範圍以外又如何去趕上這個突破,跨入這個新的時代呢?我想世界上有其他更多的人已經在想這個問題,新的工具、機制我想很快就會出現,open source big table 的技術也慢慢的浮上來了,新時代也許會靜靜的到來。至於這個新的突破跟誰會有關?是不是只有如 Google 般大的公司才適合用 Big Table?這個就留待日後驗證好了。

Advertisements
  1. April 29, 2008 (Tuesday) at 9:59

    因為沒玩過,所以我想問的是:
    1) GAE開發出來的applications可以像Google OpenSocial一樣,放在自己的server上嗎?
    2) Scalability這點它如何做?因為若是不能自己host applications,我們大可不理會這點,讓Google去操心,我們只要乖乖付費享受就好。但若是可以自己host,就勢必免不了RASP的老問題。

  2. April 29, 2008 (Tuesday) at 23:06

    1) GAE 目前只能 hosting 在 Google. Download 的 SDK 內建 development 用的 server, 但拿來 deploy 應該不行.
    2) Scalability 應該是 Google 吃飯的傢伙~ 不會隨便講了~ 不過應該也可以猜了得出來~ MapReduce?

  3. May 5, 2008 (Monday) at 23:27

    Google App Engine 中文儲存之心得與實作網站
    http://mywoo.com/wordpress/?p=32

  4. Tony
    October 22, 2010 (Friday) at 13:56

    Hello

    在查詢GAE時看到了你的Blog, 寫著對GAE及Big Table相關應用的分享, 先自我介紹一下, 我們總公司在美國台灣有分公司,最近我們公司大力推展公司的自有產品, 雲端電視的應用,想直接用目前最熱門的GAE,Html5來做開發,我們正在找詢對於這樣新工具有一定了解的人,能一起加入,不知你是否有認識這樣對這方面熟悉的朋友可以推薦的呢?

    也許可以聊一聊分享一下我們對GAE的一些想法, 希望能找到一群有創意及熱情的人一起共襄盛舉,我們預計參加明天的Google I/O 2011 展示我們的產品,如果有人選推薦的話,請Email給我,謝謝!

    Tony

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: