大家都是趁現在學著轉型做這個吧
程度應該都還半斤八兩的

只是一個服務器而已，本質還是Python JAVA，
這幾年用JAVA實現的動態網頁一直沒有起色，
所以這個服務器前景堪慮，
目前來看GAE似乎不考慮其它語言實現，
拿去跟阿帕契比較一下，再考慮投入比較適當

那如果WEB APP可能會有『臨時巨量使用者存取』的情況，
採用GAE合適嗎？還是乾脆換到 EC2比較省事？

選一個當主一個當副，還有一個GoGrid可以考慮，
服務器沒有提供的功能，由副服務器支援，
不過要根本解決臨時高併發的問題，
就要花錢了，要把租用的成本攤提，
才能知道究竟選哪個當主

用Java實作動態網頁也算是主流之一吧,怎麼可能前景堪慮...

基本上GAE在Java上的版本就是一般的Java Servlet container加上google自家的套件而已..

所以在GAE上用Java開發的程式很容易移植到其他的系統上來執行,不會跟GAE綁死

相反的GAE本身限制太多了,尤其資料庫限制更多,所以舊友Java Servlet的程式要移植到GAE上反而問題多....

但是GAE本身的好處就是,不用自己管理伺服器和load balance的問題,可以減少公司的一些時間和成本,而且GAE本身對程式的限制就是要確保網站有很高的scalability.

我是用市佔率來評估的，市佔率拉不上去開發商就虧錢，
虧錢就收起來，收起來用該雲的開發商就會哭哭
可以實現的功能其實差不多，對於使用者而言其實也差不多，
但是市佔率對於開發商而言就差很多，
轉移系統可是曠日廢時的大工程呀

說明一下個人的看法。

Java當紅，主要是因為當初提供J2EE(現在改叫Java EE)的分散式架構，所以很多大企業認為擴充性足夠，因此投入Java的懷抱中，這些企業到現在也都沒有後悔，像許多銀行的大型網站，背後都是跑J2EE，用的是高檔的Application Server(如Weblogic)，因其本身就提供可擴充性，這部分除非成本考量，否則一時半刻是不考慮轉到雲端的。

回過頭來看，許多中、小型的網站，也用了J2EE架構的「一部分」，就是用了JSP, Servlet或Structs、Spring等基礎架構，但沒全面用到Application Server(就是直接用Apache啦！)，這時，轉移到雲端就有其利基了，因為不必再維護伺服器的基礎架構，而且可以無限擴充，當然主要是省錢。

再看看Google App Engine提供的的Java版本，主要有三大功能，我剛看完，一、資料的儲存、二、快取的應用、三、Google權限的整合。後兩者，如同樓上所說，Google的作法是，找到JSR(Java社群共同討論的規格)並加以實作，所以的確要轉換並不難。

問題出在一、資料的儲存，大家都知道，過去放在資料庫的檔案，在Java中，除了透過JDBC外，還有使用OR(Object Relation) Mapping的工具，先前當紅是EJB，最近當紅的就屬Hibernate，後來這些慢慢整合入JDO的規格之中，也就說是，如果符合JDO的最新規格，原則上舊程式只是換換語法，改變OR Mapping層的機制，其他部分程式自然不需太多更改。

不過，目前Google App Engine的JDO支援，少掉了最重要的JOIN及多對多的對應，如此一來，如果要轉換的程式中，使用到JOIN或多對多對應的功能，那麼在轉換上就要花很大的工夫，這工夫大到要改掉整個資料層的結構，把JOIN變成物件關聯，把多對多換成二個一對多，同時，所有相關的資料存取Query/Update/Delete都要全部跟著改寫一遍。這工夫太大了，幾乎只有UI部分留下，而且一旦改動資料層，所有測試都要重來一遍，客戶要付出的代價也相對慘痛。

所以結論是，舊有案子，轉換要花的工夫，約當等於重來一遍，這部分利基真的很小，而如果是新案子，一開始講明架在Google App Engine上，那麼方案算可行，不過這部分的競爭對手又是Amazon EC2跟其他的雲端平台，Google App Engine目前除了免費外，誘因實在太小，所以沒有太多公司在願意這階段投入是合理的。