开发者抛弃Google App Engine的13个原因
转载自:http://www.bityun.com/archives/341
yunster很遗憾,第一次发表GAE的文章就是负面的。虽然yunster前半年一直在搞GAE,但还是选择了中途放弃。原因多种多样,有 GAE在中国性能的问题,有稳定性的考虑,也有对开发通用性的前景担忧,当然还有更主要的原因是个人的坚持不够(呵呵,这个是主因)。yunster本人 是很羡慕像Livid这样的高手能够在GAE上开发出像V2EX这样的优秀项目,说到底yunster对GAE还是很期待的,毕竟是谷歌的服务,它的长久发展是毋庸置疑的。闲话少说,还是介绍这篇文章。
Carlos Bie是西班牙的一个开发人员。他的公司在几个月的延期后放弃了使用Google App Engine(GAE)。
在本周早些时候,Ble在他的博客中列了十三个原因关于他的公司为什么决定放弃Google App Engine。该博文在一天之内获得了89000个点击量和15个留言。一些是很同情他的遭遇,另一些则斥责他羞辱了Google,当这家公司已经做出很 多努力帮助他和他的团队更好利用这个平台。
一则留言来自Patrick Chanezon,Google的云计算及应用工具经理。出自对Chanezon的尊重和澄清他的观点,Ble更新他的博文但仍然觉得对他的批评中仍然有太多漏洞。
这里有Ble列出的关于他的团队遇到的五个问题:
1、GAE需要Python2.5, 这个版本太老了。使用Ubuntu的话就意味着你需要使用virtualenv或者chroot去保证可以正确使用SDK。 好吧,这不算什么。
2、你不能在你自己的域里用HTTPS, 因此一个安全的链接必须是建立在yourname.appspot.com上的,这太糟了。
3、没有请求可以超过30秒,否则就被强制断掉。天啊,这是最痛苦的事了。当我们上传数据到到数据库中(在no-sql 环境中叫datastore),上传的数据在30秒后被中断了。我们不得不分割文件和所有针对这种情况的挑战。运行后台任务(cron)不得不做得非常谨 慎,因为要遵守同样的规则。对于网站管理员来说,有太多的任务需要超过30秒了。你能想象么?
4、每个服务器发起的到其它站点的GET或POST请求如果5秒内没有完成将被中止。你可以配置到最多十秒。这就使得频繁访问Twitter或者Facebook变得不可能,所以你需要中间服务器。再一次,这加倍了你完成一个简单任务的时间。
5、你不能使用基于C语言的python库,只能是原生库。忘掉那些你用过的强大的第三方库吧。
Ble写道十月份GAE再次挂掉了。他说他们遇到了500错误代码,60%的时间系统宕掉了。用户不能访问或者注册该站点。
Ble承认他应该更小心一些但他曾信任的Google。
“对于我们来说,GAE已经象Wave或者Buzz一样失败了。我们已经在经济上付出了代价。我曾经很固执因为有这样伟大的公司做后盾。然而我学到了重要的一课。好公司一样会犯错。我应该在花掉这么多钱之前事先做一些调研和收集一些证明。我太瞎了。”
很多批评家们并不同情Ble的遭遇,他们说他应该做更多研究,肯定有设计的缺陷。
然而接下来是Eugene Ciurana的留言,一本GAE书籍的作者。
“Carlos, 我在很多年前写过关于GAE的第一本书,出版后我有很多机会去讲述python和Java的平台。我比较早地意识到关于”GAE是如何工作的”变成”如何 当心GAE”,最终建议大家不要在重要的应用上使用GAE。我欣赏你的博文,并发推推荐它,因为这是一个非常重要的警示。我工作中的大部分内容是如何扩展 和提高可用性。我曾很喜欢它是因为它提供了RESTful服务。真实的应用仍然是基于数据中心的或者放在Amazon或Rackspace上的。关于 NoSQL系统,Datastore很难成为一个成功的例子,它对GAE是够用的但你现在知道了它的缺点。记住! 永远用正确的工具做正确的事。我的建议是,你应该区分到底要基于文档还是基于列的数据存储,还要适应检索的需要,你应该看一眼mongoDB和HBase。我们正在大企业客户的生产环境中同时使用它们,没有什么问题。祝你好远,Eugene Ciurana”
Chanezon在他的留言里说Google已经了解到Ble的很多观点,他说公司正在修复这些问题。
Chanezon强调读GAE文档的重要性。他说局限性已经列出来了。这个服务设计的初衷就是了为了高扩展性的应用,即需要快速扩展到大量用户或数据。他提到Gri.pe就是一个典型的例子。
你觉得如何?Ble说的有道理吗?
原文翻译:atutest

