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上运行，因为它们需要关系数据库。

Answer 1

优点：

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

缺点：

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

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

Answer 2

（巨大的新）PRO：GAE现在支持MySQL ： https ： //developers.google.com/cloud-sql/

Answer 3

优点：

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

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

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

缺点：

• 松散的日志非常快

• 非常贵

• 非常贵

• 非常贵

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

• 更长的开发周期。 有时候你只是想把一些东西拼凑起来，在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立伟大的产品！

Answer 4

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

Answer 5

骗局：在一些国家（阿根廷）不可用。

编辑

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

Answer 6

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

Answer 7

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

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

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

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

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

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

Answer 8

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

（我讨厌手机，而我的妈妈或同事也不会收到短信）

Answer 9

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

Answer 10

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

…在一个严肃的说明：

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

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

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

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

常识的东西真的。

Answer 11

Con：仅限于Java和Python