Google App Engine的优点和缺点

[更新名单2009年8月21日]

帮助我编译在Google App Engine上构build应用程序的所有优点和缺点的列表

优点:

  1. 无需购买服务器或服务器空间(无需维护)。
  2. 使解决扩展问题更容易。
  3. 释放达到一定水平的消耗资源。

缺点:

  1. locking到Google App Engine?
  2. 开发人员只能访问App Engine上的文件系统。
  3. App Engine只能执行从HTTP请求中调用的代码(预定后台任务除外)。
  4. 用户可以上传任意的Python模块,但前提是它们是纯Python; C和Pyrex模块不受支持。
  5. App Engine将实体返回的最大行数限制为每个数据存储区调用1000行。 ( 更新 – App Engine现在支持用于访问较大查询的游标)
  6. Java应用程序只能使用JRE标准版本的子类(JRE类白名单)。
  7. Java应用程序不能创build新线程。

已知的问题!! : http : //code.google.com/p/googleappengine/issues/list

硬限制

每个开发者的应用 – 10
每次请求的时间 – 30秒
每个应用的文件数 – 3,000
HTTP响应大小 – 10 MB
数据存储区项目大小 – 1 MB
应用程序代码大小 – 150 MB
更新 Blob商店现在允许存储高达50MB的文件

Pro还是Con?
App Engine的基础架构消除了构build应用程序的许多系统pipe理和开发挑战,以扩展至数百万次点击。 Google会根据需要将代码部署到集群,监控,故障转移和启动应用程序实例。

虽然其他服务可让用户安装和configuration几乎任何* NIX兼容软件,但App Engine要求开发人员使用Python或Java作为编程语言和一组有限的API。 当前的API允许存储和检索来自BigTable非关系数据库的数据; 发出HTTP请求; 发送电子邮件; 操纵图像; 和caching。 大多数现有的Web应用程序无法修改就无法在App Engine上运行,因为它们需要关系数据库。

优点:

  • 可扩展
  • 简单和便宜(在短期内)。
  • 对初创/个人来说是不错的select。
  • 适用于只存储和检索数据的应用程序。

缺点:

  • 不适合CPU密集型计算。 他们更慢,更昂贵。
  • 可伸缩性并不重要,如果一个应用程序在Google的规模工作,那么它可能足够的钱在自己的服务器上运行。
  • 他们在这里和那里都有很多限制,因此深度数据分析是困难的。 就像你不能用GAE生成一个社交图。

我认为这并不意味着严重的企业和长期的昂贵。

(巨大的新)PRO:GAE现在支持MySQL : https : //developers.google.com/cloud-sql/

优点:

  • 内置的统一日志用户界面

  • 内置的任务队列的网页界面

  • 内置主要对象列表中的索引。

缺点:

  • 松散的日志非常快

  • 非常贵

  • 非常贵

  • 非常贵

  • 未破解的。 缩放,因为你有义务以一种规模的方式进行编码。

  • 更长的开发周期。 有时候你只是想把一些东西拼凑起来,在5小时后扔掉。 随着appengine你必须正确的代码,并写了很多的东西,以确保它的规模。 你不能只做一个“find。| grep .avi | xargs ffmpeg -compress ….”:)

  • 尝试执行最简单的任务,例如发送推送通知到APNS(iPhone),您将会失去工作时间。 虽然如果你只想在未来支持Android,那也没关系。

  • 糟糕的是在数据库上进行清理。 修复数据库中的行是一个很大的麻烦,主要是因为速度非常慢,但是它也需要很多代码才能在时间限制内正确地循环。

  • 将Lucene移植到“文件系统”上是一件很痛苦的事情。

  • 慢你付出的东西。

  • 如果你的应用程序有stream量高峰,甚至更昂贵。 我的应用程序有这样的尖峰,如果有很多追随者的用户做出了行动,我们必须推送通知给他的追随者。 因此,我必须保持10个不活动的服务器($$$$$)来处理尖峰。

Appengine不算太坏,因为我可以select刻录$$$$,而不是担心可伸缩性和修复瓶颈以减less服务器的使用。 有时候值得。

我对开始新产品的人的build议是与hetzner.de一起,这是我的其他产品服务器托pipe。 这很便宜,非常可靠。 我在hetzner上有一台服务器,处理的stream量比我在appengine上的产品多3倍。 价格的差异是每月100美元,每个月2700美元!

我有系统pipe理员的经验,所以底线是,我不会select有自己的ROOT服务器的appengine。 不要成为一个无聊的软件工程师,想要尝试新的东西,而不是build立伟大的产品!

临:无限扩展到您的应用程序和需求扩展。

骗局:在一些国家(阿根廷)不可用。

编辑

全球范围内可用,但只能通过Google Groups for App Engine。

在评估利弊时,我认为重要的是要澄清一个人所代表的市场。 开发商寻求一种具有成本效益的解决scheme,以帮助他们计划曲棍球棒增长曲线的陡峭部分,将大大减轻已经列出的缺点。 然而,对于一个小企业主来说,GAE是上帝派遣的。 这些人往往把“云”看作是更有效地经营业务(即销售实物产品和服务)的手段。 对于中小企业来说,已经上市的专业人士可能比曲棍球寻求开发者更有价值,而在开发者的措施的一小部分的重量。 我没有看到GAE团队正在做与SMB定位有关的任何事情,所以我想这样的答案是我只是拉着超人的斗篷,随风而去。 真的GAE现在应该是绝对统治SMB的空间。 如果没有(我没有洞察重新:用户群),那么它是一个非常可悲的失败。

我相信GAE在提供Datastore这些严肃商业的基本function方面还没有成熟,主要包括复杂的主键,java.awt。*支持,这些都是我命名的。

除了免费空间和build立一些“爱好”网站之外,我强烈地感觉到GAE不是java们应该研究的地方。

我在JSP / Servlets和MySQL上构build了应用程序,考虑迁移到GAE,但是我发现我将在迁移上花费更多的“有价值的时间”,而不仅仅是从一些Java托pipe提供商(如EATJ等)购买空间(对不起,没有营销,只是一个经验)。

我得到的另一个大问题是将我现有的mySQL数据迁移到GAE,bulkupload是非常可悲的,没有客户端的支持。

不支持本地数据库服务器数据库上传。

一旦GAE准备好上面提到的“所有缺点”,那么我会认为我们可以看看这个迁移。

您强制拥有手机线路,您的国家+运营商必须能够接收国际短信。

(我讨厌手机,而我的妈妈或同事也不会收到短信)

Con:否其他RDBMS或NoSQL数据库是不可能的….

骗子:你的基地都属于我们

…在一个严肃的说明:

Con:你不能控制你的应用程序运行的环境。与把任何组件外包的情况一样。 乐趣的玩具,而不是商业(还)恕我直言。

像谷歌专有后端API(如数据库系统和其他“locking”)和框架,这意味着你的代码是捆绑在一起,从他们的系统松散意义上来说,如果你想从GAE迁移,以后会产生成本问题。 当然,你可以抽象这些。

我喜欢GAE,AppJet等。 他们很酷。 但一切都有它的位置。 如果你想要自由和控制你的语言模块,API,语法/ stdlib版本以及什么的能力…不要把控制权交给服务提供者。

对于您的应用程序可能预期的环境和规范的缺乏标准 ,我担心在云计算领域。

常识的东西真的。

Con:仅限于Java和Python