Google App Engine的优缺点

[更新的清单2009年8月21日]

帮我编译在Google App Engine上构建应用程序的所有优缺点清单

优点：

1. 无需购买服务器或服务器空间（无需维护）。
2. 使解决缩放问题变得更加容易。
3. 释放一定程度的消耗资源。

缺点：

1. 锁定了Google App Engine？
2. 开发人员对App Engine上的文件系统具有只读访问权限。
3. App Engine只能执行从HTTP请求调用的代码（预定的后台任务除外）。
4. 用户可以上载任意Python模块，但前提是它们是纯Python。不支持C和Pyrex模块。
5. App Engine将实体返回的最大行数限制为每个Datastore调用最多1000行。（更新-App Engine现在支持用于访问较大查询的游标）
6. Java应用程序只能使用JRE标准版中的类的子集（JRE类白名单）。
7. Java应用程序无法创建新线程。

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

硬限制

每个开发人员的 应用程序-
每个请求10个时间-
每个应用程序30秒文件-每个应用程序3,000个
HTTP响应大小-10 MB
数据存储项大小-1 MB
应用程序代码大小-150 MB
更新Blob存储现在允许存储最大50MB的文件

赞成还是反对？
App Engine的基础架构消除了构建应用程序以扩展到数百万次点击的许多系统管理和开发挑战。Google会根据需要处理将代码部署到群集，监视，故障转移和启动应用程序实例的过程。

尽管其他服务允许用户安装和配置几乎所有* NIX兼容软件，但App Engine要求开发人员使用Python或Java作为编程语言和一组有限的API。当前的API允许从BigTable非关系数据库中存储和检索数据；发出HTTP请求；发送电子邮件；操纵图像；和缓存。大多数现有的Web应用程序都无法在App Engine上运行而无需进行修改，因为它们需要一个关系数据库。

优点：

• 可扩展
• 简单且便宜（短期内）。
• 对于初创企业/个人来说不错的选择。
• 适用于仅存储和检索数据的应用程序。

缺点：

• 不适合CPU密集型计算。它们较慢且昂贵。
• 如果应用程序能够在Google规模上运行，那么可伸缩性并不重要，那么它可能赚到足够的钱来在自己的服务器上运行。
• 它们到处都有很多限制，因此很难进行深入的数据分析。就像您无法使用GAE生成社交图一样。

我要说的是，这并不意味着认真的业务，从长远来看并不昂贵。

（一个新功能）PRO：GAE现在支持MySQL：https : //developers.google.com/cloud-sql/

优点：

• 内置用于统一日志的ui

• 任务队列的内置Web界面

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

缺点：

• 松散的日志非常快

• 非常贵

• 非常贵

• 非常贵

• 无法入侵。可扩展，因为您有义务以可扩展的方式进行编码。

• 更长的开发周期。有时，您只想一起砍东西，然后经过5个工作小时就扔掉。使用appengine，您必须对其进行适当的编码并编写大量内容以确保其可扩展。您不能只执行“查找。| grep .avi | xargs ffmpeg -compress ....” :)

• 您将花费大量时间尝试执行最简单的任务，例如将推送通知发送到APNS（iPhone）。尽管如果您将来只想支持android，那是很好的。

• 很难对数据库进行清理。修复数据库中的行非常麻烦，主要是因为速度非常慢，但是它还需要大量代码才能在时间限制内正确循环。

• 移植Lucene来开发其“文件系统”是一件痛苦的事情。

• 支付的速度慢。

• 如果您的应用流量高峰，则价格甚至更高。如果有很多关注者的用户采取行动，而我们必须将通知推送给他的关注者，则我的应用就会出现高峰。因此，我必须保持10台不活动的服务器始终处于运行状态（$$$$$）以处理峰值。

Appengine并不太糟糕，因为我可以选择刻录$$$$，而不用担心可伸缩性和修复瓶颈以减少服务器使用率。有时值得。

我对开始新产品的人的建议是与hetzner.de一起使用，这是我托管其他产品服务器的地方。它便宜且极易破解。我在hetzner拥有一台服务器，该服务器处理的流量比我在appengine上拥有的产品多3倍。价格差异为每月100美元，每月2700美元！

我具有系统管理员的经验，因此最重要的是，我永远不会选择拥有自己的ROOT服务器的appengine。不必是无聊的软件工程师想要尝试新事物而不是开发出色的产品！

优点：可无限扩展到您的应用程序，并随需求扩展。

缺点：在某些国家（阿根廷）不可用。

编辑

全球可用，但仅通过Google Groups for App Engine提供。

在评估利弊时，我认为弄清一个代表的市场很重要。寻求经济有效的解决方案以帮助他们解决计划的曲棍球杆增长曲线中陡峭部分的开发人员将在已经列出的不利因素中占很大的比重。对于小企业主来说，GAE是天赐之物。这些人最经常将“云”作为一种手段来更有效地经营自己的业务（即出售实物产品和服务）。对于中小型企业来说，GAE已经列出的专家比曲棍球棒寻求开发者更有价值，而缺点只占开发者的一小部分。我没有看到GAE团队做任何与SMB定位有关的事情，所以我想像这样的答案是我只是拉超人的斗篷，随风而去。确实，GAE现在应该绝对统治SMB空间。如果不是（我对用户群没有任何见解），那么这将是一个可悲的失败。

我相信，GAE在为严肃的业务提供基本功能（例如具有复杂主键的数据存储，java.awt。*支持）方面仍未成熟，这些只是我要列举的几个。

除了免费空间和建立一些“爱好”网站之外，我强烈认为GAE不是Java人士应该去的地方。

我正在基于JSP / Servlet和MySQL构建应用程序，考虑迁移到GAE，但我发现我将在迁移上花费更多的“宝贵时间”，而不仅仅是从EATJ等Java托管提供商那里购买空间。 （对不起，不是行销，只是一种经验）。

我遇到的另一个大问题是将现有的mySQL数据迁移到GAE中，bulkupload确实是可悲的，并且没有客户端支持。

不支持本地Db到服务器数据库的上载。

一旦GAE准备好了上面提到的“所有缺点”，那么我认为我们可以考虑进行此迁移。

您被迫拥有一条手机线，并且您所在的国家/地区的运营商必须能够接收国际SMS。

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

缺点：没有其他RDBMS或NoSQL数据库是不可能的....

缺点：您所有的基地都属于我们

……请注意：

缺点：您无法控制应用程序在其中运行的环境。与外包任何组件相同的缺点。玩具的乐趣，而不是商业的恕我直言。

诸如Google专有后端的API之类的各种东西，例如它们的数据库系统以及其他“锁定”和框架，意味着您的代码受到束缚，从某种意义上说，与他们的系统绑定在一起，如果您想从GAE迁移，则会在以后造成成本问题。当然，您可以抽象这些。

我喜欢GAE，AppJet等。他们很酷。但是，一切都有它的位置。如果您想要自由并具有控制语言模块，API，语法/ stdlib版本等的能力，请不要将控制权交给服务提供商。

缺乏适用于应用程序的环境标准和规范，这令我在云计算领域感到担忧。

常识的东西真的。

缺点：仅限于Java和Python