Google App Engine的『錢』景好嗎？
 

最近想要找專業的公司把網站GAE化，
順便把WEB AP弄成GAE的版本

不過目前有專注於GAE的公司、工作室好像不多，
即使規格寫的很清楚了，還是有一堆寫ASP、PHP的公司來報價

我們目前也在學習GAE的東西，
很擔心這樣下去會不會做白工......

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

只是一個服務器而已，本質還是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.

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

說明一下個人的看法。

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目前除了免費外，誘因實在太小，所以沒有太多公司在願意這階段投入是合理的。