這次發(fā)布的是沒有包含全部特性的預(yù)覽版，提供了一個配額系統(tǒng)，它限制了在預(yù)覽期間應(yīng)用免費(fèi)可用的存儲、CPU和帶寬。一旦預(yù)覽期結(jié)束，配額仍將免費(fèi)，但是開發(fā)者需要按需購買額外資源。額外資源的價格尚未公布（甚至可能尚未確定）。
預(yù)覽版的配額包括：3個應(yīng)用/開發(fā)者、500MB存儲/應(yīng)用、2000封郵件/天（連續(xù)24小時）、10 GB入站帶寬、10 GB出站帶寬、200M CPU兆周、650k HTTP請求、2.5M Datastore API調(diào)用和160k URL Fetch API調(diào)用。
技術(shù)：開發(fā)環(huán)境和API
盡管Google說‘未來將支持更多的語言’，但是目前技術(shù)棧是基于Python的，它是Google認(rèn)同的語言之一。出于安全和伸縮性的目的，Google提供了一個運(yùn)行在安全沙箱中的Python運(yùn)行時環(huán)境，它提供對底層操作系統(tǒng)有限制的訪問。該環(huán)境包括標(biāo)準(zhǔn)庫，并可通過模塊進(jìn)行擴(kuò)展，編寫模塊的語言目前不支持C語言。
該環(huán)境包括Python標(biāo)準(zhǔn)庫。當(dāng)然，調(diào)用那些違反沙箱限制的庫方法（如打開socket或?qū)懳募⒉粫晒Α榱朔奖闫鹨姡瑤讉€核心特性不被支持的標(biāo)準(zhǔn)庫中的模塊被禁用了。那些引入它們的代碼會出錯。
應(yīng)用代碼只能用Python書寫。不支持使用C來編寫擴(kuò)展。
其他安全限制包括：出站通信（outbound communication）只能通過所提供的郵件和URL fetch API進(jìn)行，通過HTTP和HTTPS作為傳輸?shù)娜胝就ㄐ牛╥nbound communication）使用標(biāo)準(zhǔn)端口，禁止文件系統(tǒng)寫操作和禁止子進(jìn)程或代碼在請求/響應(yīng)循環(huán)外執(zhí)行（例如后臺操作和批操作）。
此外，Google提供了訪問一個Datastore、Google用戶帳號、URL fetch和郵件服務(wù)的API。App Engine還包括一個簡化的Web應(yīng)用框架和Django 0.96.1，盡管App Engine Datastore不是關(guān)系型的，而且也不能使用全部的Django API。
Datastore API背后由Google的BigTable支持，但是它與一個簡單的對象持久化API（或一個對象關(guān)系映射框架，即使Google強(qiáng)調(diào)這個Datastore不是關(guān)系型的）有很多相同之處：
你們中的大多數(shù)，在使用這個Datastore時可能會有點(diǎn)不習(xí)慣：如我所說，它不是SQL。這是個巨大的區(qū)別。然而，我們想了一下之后，認(rèn)為這個Datastore可能會引起你們的興趣，因為它讓一些事情變簡單了。比如說，我們的Datastore沒有模式，這意味著它可以支持任意的新屬性或列，你可以用代碼創(chuàng)建，無需把所有事情預(yù)先設(shè)計好并創(chuàng)建一個模式。這就回到了我們盡可能簡化Web應(yīng)用編寫的目標(biāo)：只需開始編碼就好了。你的數(shù)據(jù)模型可以隨你應(yīng)用的演變而演變。
即使Datastore違背了SQL，我們?nèi)匀恢С帜阆胍膫鹘y(tǒng)關(guān)系數(shù)據(jù)庫的許多強(qiáng)大功能。對于任何你提供的單個屬性或?qū)傩约希珼atastore都提供了高效查詢。它還支持對查詢結(jié)果的排序，包括按多屬性進(jìn)行排序。它對寫操作支持事務(wù)，通過事務(wù)分組來控制。對于提取或創(chuàng)建大量實體，它也支持批操作。它給你機(jī)會讓你來控制你實體的主鍵，以獲得更好的查詢效率和更短的URL。
并且，即使Datastore不是SQL，我們也為你提供了類SQL查詢以簡化查詢的表達(dá)，叫做GQL。GQL受到了jQuery和FBQL的啟發(fā)：底層的存儲不是SQL，但是幾乎你想要的所有查詢?nèi)匀豢梢酝瓿伞?/P>
你可能已經(jīng)注意到我們的Datastore缺少一個大特性，那就就是連接（join）。這是因為連接通常是分布式系統(tǒng)效率問題的根源，當(dāng)你有不止一臺機(jī)器時：很難在跨多個機(jī)器和多個硬盤的分布式系統(tǒng)上進(jìn)行連接操作。
盡管Datastore API支持事務(wù)，但是它們有嚴(yán)格的限制，而且和實體組關(guān)聯(lián)：
每個實體都屬于一個實體組，在一個事務(wù)內(nèi)可以操作一個或多個實體。實體組關(guān)系告訴App Engine在分布式網(wǎng)絡(luò)的同一部分保存幾個實體。一個事務(wù)為一個實體組設(shè)置Datastore操作，所有這些操作按組實施，如果事務(wù)失敗就全部撤銷。
當(dāng)應(yīng)用創(chuàng)建一個實體時，它可以分配另一個實體作為新實體的父。給一個新實體分配父時，將使它進(jìn)入父實體所在的實體組。
沒有父的實體是根實體。一個實體的父實體也可以有父。從一個實體到根的父實體鏈就是這個實體的路徑，路徑的成員是實體的祖先。實體的父只能在創(chuàng)建時定義，之后就不能修改。
祖先是同一根實體的所有實體都在相同的實體組中，組中的所有實體存儲在同一Datastore節(jié)點(diǎn)中。單個事務(wù)可以修改單個組中的多個實體，或通過將組中現(xiàn)有實體變成為新實體的父來把一個新實體加到組中。
因為App Engine迫使你以一種特殊的方式（如Datastore on BigTable，而不是數(shù)據(jù)庫）來處理你的開發(fā)，Google聲稱你的應(yīng)用將更易于伸縮，而且這種伸縮性幾乎是透明的：
當(dāng)一個Web應(yīng)用變得流行起來時，突如其來的流量可以壓垮各種規(guī)模的應(yīng)用，從創(chuàng)業(yè)公司到大公司都發(fā)現(xiàn)需要一年幾次的重新架構(gòu)他們的數(shù)據(jù)庫和整個應(yīng)用。通過自動復(fù)制和負(fù)載均衡，利用Bigtable和Google的可伸縮基礎(chǔ)設(shè)施中的其他組件，Google App Engine使得應(yīng)用可以從一個用戶伸縮到百萬級用戶。
User API允許通過Google帳號進(jìn)行用戶驗證和登錄，以及訪問帳號的綽號和郵件。其他更多的用戶信息可以從應(yīng)用保存在Datastore中的用戶信息直接獲取。
URL fetch API能通過提取HTTP和HTTPs URL（支持GET、POST、HEAD、PUT和DELETE，因此這似乎可以支持REST功能）檢索遠(yuǎn)程服務(wù)器的信息。
Mail API允許App Engine應(yīng)用異步發(fā)送郵件，如果郵件服務(wù)器不可用時允許重試。
App Engine SDK包含模擬App Engine Python運(yùn)行時環(huán)境的服務(wù)器，以及：
- 模擬模塊引入限制，只允許處理程序引入被許可的模塊，它們來自標(biāo)準(zhǔn)庫、包含在App Engine Python環(huán)境中的第三方庫，以及應(yīng)用目錄中的模塊
- 模擬應(yīng)用緩沖行為
- 使用本地文件模擬App Engine Datastore
- 模擬包含有登錄和注銷頁面的Google帳號，登錄參數(shù)可以是任何郵件地址。
- 通過提取你計算機(jī)的URL模擬URL fetch服務(wù)
- 使用你選擇的SMTP服務(wù)器或Sendmail配置模擬郵件服務(wù)
乍一看，絕大多數(shù)的應(yīng)用配置似乎可用YAML來寫。
動機(jī)和競爭
Google的公告稱他們的動機(jī)是，簡化Web應(yīng)用的構(gòu)建、部署和伸縮性：
嗯，我們構(gòu)建Web應(yīng)用是因為我們想要更多的Web應(yīng)用被創(chuàng)建出來。我們注意到，目前創(chuàng)建一個Web應(yīng)用真的很難：即使部署一個最簡單的Web應(yīng)用也有巨大的前端挑戰(zhàn)。你需要做很多事情。當(dāng)然，首先你必須為你的應(yīng)用編寫代碼。
但是接著，你還需書寫你的Apache Web服務(wù)器配置和啟動腳本，安裝你的數(shù)據(jù)庫，創(chuàng)建所有表和設(shè)置口令，安裝監(jiān)視器來了解你的流量和日志，決定你如何推出代碼的新版本等等。
那只是我們注意到的技術(shù)方面的挑戰(zhàn)。然后，一旦你完成了所有那些系統(tǒng)管理員的工作，你就有了另一個挑戰(zhàn)：你必須著手去找你能使用的機(jī)器來運(yùn)行你的應(yīng)用，不論是物理的還是虛擬的提供商。現(xiàn)在，就要花錢了：即使是最簡單的應(yīng)用，一周用幾次，你都必須支付一大筆預(yù)支費(fèi)用來讓它在一個傳統(tǒng)主機(jī)托管提供商處運(yùn)行。
那么，這就是財務(wù)或物理方面的挑戰(zhàn)。然后，一旦你搞定了整件事情并且運(yùn)行了，而且找到地方并為此付費(fèi)來測試它，你又面臨了另一個挑戰(zhàn)：隨著你應(yīng)用的成長，你必須去維護(hù)它。你的機(jī)器崩潰了，你的配置有錯誤，你的硬盤壞了，你的流量開始增長，你必須重新分享你的數(shù)據(jù)庫，安裝更多更多的機(jī)器。隨著應(yīng)用的成長，任何事情都象是一場激戰(zhàn)。
所有這些激戰(zhàn)正是我們試圖通過App Engine避免的。它們是我們正試圖解決的問題。
其他人已經(jīng)揣測出了言外之意。很多人指出了Google與Amazon和微軟在未來云計算和Web服務(wù)方面的競爭，常常將App Engine與Amazon的Web服務(wù)EC2、S3、SQS和SimpleDB相提并論：
-
自從Amazon Web服務(wù)有這么好的開局之后，我們都知道這只不過是時間問題（我們可以有把握地假定下一個將會是微軟）。盡管拿AWS與GAE作對比是顯而易見的，但是它們真的不是同一類工具。Amazon已發(fā)布的一組獨(dú)立服務(wù)可以被用來創(chuàng)建一個通用的計算平臺。盡管這些服務(wù)可以一起工作，但是它們沒有作為整體打包在一起。
另一方面，App Engine是一個驅(qū)動Web應(yīng)用的引擎。它將AWS提供的許多特性進(jìn)行了整體打包：存儲類似S3、自動伸縮性和處理能力類似EC2，Datastore類似SimpleDB。App Engine還提供了AWS沒有的特性，如Python運(yùn)行時，Google特定的API，以及可能是最吸引人的免費(fèi)服務(wù)部分。
-
VentureBeat：“Google App Engine準(zhǔn)備與Amazon競爭”
其他人暗示微軟也正攜一些工具向這個方向挺進(jìn)，比如Ray Ozzie's Mesh strategy和SQL Server Data Services，但是可能已經(jīng)太晚了：
- Network world 說，“Google再次領(lǐng)先微軟”
- ZDNet問：“Google App Engine：微軟將何時圍捕競爭者？”
看看事情的另一角度，某些人暗示這會使Google在收購方面棋高一著，這是一種風(fēng)險基礎(chǔ)設(shè)施（venture infrastructure）形式：
- Business Week認(rèn)為Google和Amazon間的競爭沒有提及這一點(diǎn)：鼓勵創(chuàng)業(yè)公司在Google的基礎(chǔ)設(shè)施上開發(fā)他們的應(yīng)用，這使Google“不僅可以很好地了解人們想要的應(yīng)用和需要克服的問題，而且能敏銳地發(fā)現(xiàn)Google想收購的有前途的新創(chuàng)業(yè)公司”。
- ZDNet補(bǔ)充：它可以節(jié)約Google在收購方面的金錢：“想象一下，如果收購一家已經(jīng)使用Google技術(shù)的公司會省下多少時間和努力？”
- GigaOM說：“這種虧本銷售的服務(wù)將那些創(chuàng)業(yè)公司帶進(jìn)了Google的大門，這使得這家公司可以訪問最新的想法并可從天才企業(yè)家池中做出選擇”
-
在“Google如何吃掉Amazon的午餐”中，Kevin Kelleher稱這為投資：
在這次采訪中，我大聲地推測Amazon所做事情很像公司風(fēng)險投資的（如Intel投資部）做法——投資和他們以后要合作（或者要收購）的創(chuàng)業(yè)公司。只是不用硬通貨，而是基礎(chǔ)設(shè)施。我得說，非常精明。
高管的反應(yīng)是：Amazon根本沒這么做，而且永遠(yuǎn)不會用Web服務(wù)那么做。我心里想了一下，但是沒說：嗯，如果你們不這樣做，有人會這么做的。
現(xiàn)在，有些人正在說Google正在這么做。隨著有價值的Google員工整理他們的桌子并啟動一家新的創(chuàng)業(yè)公司，推出GAE是Google將他們重新召回的最好策略。這也是從Amazon身下抽走地毯的絕佳方法，戰(zhàn)略上明智而且盈利上也明智。
