优点＆amp; Google App Engine的缺点

Question

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

帮我编制一份所有优势列表＆amp;在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将实体返回的最大行数限制为每个数据存储区调用1000行。 （更新 - App Engine现在支持用于访问更大查询的游标）
6. Java应用程序只能使用JRE标准版中的类的子集（JRE Class White List）。
7. Java应用程序无法创建新线程。

已知问题!! ：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的基础架构消除了构建应用程序以扩展到数百万次点击的许多系统管理和开发挑战。 Google会根据需要将代码部署到群集，监控，故障转移和启动应用程序实例。

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

Answer 1

<强>优点：

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

<强>缺点：

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

我认为它不适用于严肃的企业，长期来看也很昂贵。

Answer 2

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

Answer 3

优点：

• 统一日志的内置ui

• 任务队列的内置Web界面

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

<强>缺点：

• 非常快速地记录日志

• 非常昂贵

• 非常昂贵

• 非常昂贵

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

• 更长的开发周期。有时候你只想把东西放在一起，然后在5个小时后把它扔掉。使用appengine你必须正确编码并写下很多东西，以确保它可以扩展。你不能只做一个“发现。| grep .avi | xargs ffmpeg -compress ....”：）

• 您将花费数小时尝试执行最简单的任务，例如向APNS（iPhone）发送推送通知。虽然如果你想在将来只支持android，这很好。

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

• 让Lucene移植它的“文件系统”是一件痛苦的事。

• 你支付的费用很慢。

• 如果你的应用程序有流量高峰，那就更贵了。如果有许多粉丝的用户采取行动并且我们必须向他的粉丝发送通知，那么我的应用就会出现这些高峰。因此，我必须始终打开10个非活动服务器（$$$$$）来处理峰值。

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

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

我有系统管理员经验，所以最重要的是我永远不会选择引擎来拥有自己的ROOT服务器。不要那个无聊的软件工程师想要尝试新事物而不是制作出色的产品！

Answer 4

Pro：对您的应用程序进行无限制的可扩展性并根据需求进行扩展。

Answer 5

Con：某些国家/地区不适用（阿根廷）。

修改

全球推出，但仅限Google App for App Engine。

Answer 6

我相信，GAE在提供严肃业务的基本功能方面尚未成熟，例如具有复杂主键，java.awt。*支持的数据存储区，这些只是我正在命名的几个。

除了免费空间和建立一些“爱好”网站之外，我强烈认为GAE不是java家伙应该研究的地方。

我正在构建基于JSP / Servlets和MySQL的应用程序，考虑迁移到GAE，但我发现我将在迁移上花费更多的“超值时间”，而不仅仅是从一些java托管提供商那里购买空间，比如EATJ等（抱歉不是营销，只是一种体验）。

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

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

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

Answer 7

在评估利弊时，我认为澄清一个人代表的市场很重要。寻求经济有效的解决方案以帮助他们完成计划的曲棍球棒生长曲线的陡峭部分的开发人员将严重影响已列出的缺点。然而，对于小企业主来说，GAE是上帝派遣的。这些人通常将“云”视为更有效地运营业务的手段（即销售实体产品和服务）。对于SMB，GAE，已经列出的专业人士与曲棍球棒寻求开发者相比可能更有价值，而重量比仅为开发者的一小部分。我没有看到GAE团队做任何与SMB定位相关的事情，所以我想这样的答案就是我只是拉着超人的斗篷，然后随地吐痰。真的GAE现在应该绝对统治SMB空间。如果没有（我没有见解：用户群），那么它是一个非常可悲的失败。

Answer 8

骗局：你所有的基地都属于我们

......严肃地说：

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

各种各样的东西，比如谷歌的专有后端，比如他们的数据库系统和其他“锁定”和框架，这意味着你的代码与他们的系统在一些松散的意义上是捆绑在一起可能会在以后造成成本问题你想从GAE迁移。当然，你可以抽象这些。

我喜欢GAE，AppJet和其他人。他们很酷。但一切都有它的位置。如果你想要自由并且能够控制你的语言模块，API，语法/ stdlib版本等等......不要放弃对服务提供者的控制。

对于您的应用可以预期的环境和规格缺乏标准让我在云领域感到担忧。

确实

常识的东西。

Answer 9

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

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

Answer 10

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

Answer 11

Con：仅限于Java和Python