最后GAE VS AWS架构决策 [英] Final GAE vs AWS architectural decision

问题描述

我知道这已经被问这样或那样的面前，但大部分的主要问题做GAE的稳定性似乎已经打听到2008年底，2009年初，或规模没有直接关系到游戏（这是我很感兴趣的）。

I know this has been asked one way or another before, but most of the main issues to do with GAE stability seem to have been asked around the end of 2008, early 2009, or aren't directly related to games at scale (which I'm interested in).

基本上，我一直在扯皮与我有关是否使用GAE和AWS为我们的社交游戏引擎的后端，现在是关键时刻的贸易伙伴。我爱GAE（JAVA）这么多的理由，虽然它曾经是不稳定的，它是pretty的好了。支持AWS的主要论点是，AWS已经证明了自己有多个游戏运行几千万，每天的活跃用户。最明显的迷人的孩子AWS是Zynga的，与它的Farmville的峰值出现在80多万DAU。而这仅仅是在AWS基础设施上运行取得巨大成功的游戏之一。了不起的成就。

Basically, I have been arguing back and forth with my business partner about whether to use GAE or AWS for the back-end of our social game engine, and now it's crunch time. I love GAE (Java) for so many reasons, and although it used to be unstable, it's pretty good now. The main argument in favour of AWS is the fact that AWS has proven itself with multiple games running tens of millions of active users per day. The obvious pin-up child for AWS is Zynga, with its Farmville peaking at 80+million DAU. And that's just one of the hugely successful games running on the AWS infrastructure. Remarkable achievement.

那么，这种或那种方式据了解工作。 GAE在另一方面没有，我能找到做这类数字的任何实例。差远了。 所以，我可以信任它？是否有一个大的社交游戏有200多万日活跃用户，使用GAE一个例子？

So, one way or another it's KNOWN to work. GAE on the other hand doesn't have any examples that I could find doing these sorts of numbers. Not even close. So can I trust it? Is there a single example of a large social game with 2 million+ Daily Active Users, using GAE?

主要考虑因素为我们的社交游戏后端分别是：

The main considerations for our social game back-end are:

1. 在可靠的CDN（亚马逊CloudFront的/ S3是极好的这一点，因为是谷歌显然是出色的数据存储）。
2. 在能力，而不会摔倒（AWS-EC2在这里证明向规模化，GAE似乎不具备的，可以运行到每秒请求的1000大型游戏应用程序的例子。GAE用在这方面相当不稳定，所以我最关心的）。
3. 可靠无SQL数据库。 （AWS-SimpleDB的和谷歌的数据存储都非常适合这一点。我们真的不需要SQL）。
4. 支持/呼叫的人/联系人中，如果出现了问题。 （这是最大的忧虑与GAE之一。我不知道谁，我可以打电话，或者如果它甚至有可能。AWS有一个SLA和支持。）

我期待着你的想法，但也请注意，这不是要启动任何类型的火焰战争。我爱这两个系统，但都有其正面和负面，但我要做出有可能不会被撤消前进的架构决策。

I look forward to your thoughts, but please also note, this is not intended to start any sort of flame war. I love both systems, but both have their positives and negatives, but I'm about to make an architectural decision that likely won't be undone moving forward.

问候，

巴蒂尔

推荐答案

我没有使用过AWS-EC2所以我打算只在谷歌应用程序引擎方分享我的知识。

I've never worked with AWS-EC2 so I'm going to share my knowledge just on the Google App Engine side.

1. 谷歌应用程序引擎是不是意味着是一个 CDN ;虽然它可以通过其强大的基础设施提供静态内容提供缓存贴近用户，它并不能保证同样的高品质和真正的CDN的高可用性服务，因为它不是其职责的一部分。
   进一步的资料：
   • 使用Blob存储服务的文件的最大尺寸：2 GB的
   • 在一个静态文件的最大尺寸：10兆字节
   • 在目前的App Engine 总是返回200状态即使在条件获取静态文件（你必须依靠像 cirruxcache 例如）。

1. Google App Engine is not meant to be a CDN; though it can serve static content through its powerful infrastructure providing caching close to the users, it does not guarantee the same kind of high quality and high availability service of a real CDN because it's not part of its duties.
   Further data:
   • Maximum size of a file using the BlobStore service: 2 Gigabytes
   • Maximum size of a static file: 10 Megabytes
   • Currently App Engine always returns 200 status for static files even on Conditional gets (you have to rely on third party caching library like cirruxcache for example).

近日谷歌应用程序引擎团队已经关闭了应用程序库的原因很简单：太多玩具应用程序！
谷歌希望以抵消这一趋势显示出成功的企业案例研究报告;这里有一些人：

Recently Google App Engine team has shut down the App Gallery for one simple reason: too many Toy Apps!
Google wants to counteract this tendency showing successful businesses case studies; here are some of them:

• BuddyPoke （病毒的Facebook应用程序与6500万的安装）
• WalkScore （提供300万请求每天成千上万的房地产合作伙伴网站）
• Webfillings
• Snapabug
• Optimizely
• 育碧的Facebook的TikTok游戏

• BuddyPoke (viral Facebook app with 65 million installs)
• WalkScore (serves 3 million request a day to thousands of real estate partner sites)
• Webfillings
• Snapabug
• Optimizely
• Ubisoft Facebook TikTok game

其他有趣的案例研究这里

我们深知停机和可靠性问题，并正在努力解决这些问题：改善应用程序引擎的可靠性是我们的首要任务的由谷歌开发者关系最近表示，这里经理。
App Engine上仍处于测试阶段，是一个不断发展的平台，所以你必须要ppared处理停机时​​间和问题，$ P $。

"We are well aware of downtimes and reliability issues, and are working hard to solve them: Improving App Engine reliability is our number one priority" was recently said by a Google Developer Relations Manager here.
App Engine is still in beta and is an evolving platform so you have to be prepared to deal with downtimes and issues.

谷歌应用程序引擎团队刚刚推出的应用程序引擎的商家提供99.9％的正常运行时间的服务级别协议和premium开发商支持提供。

Google App Engine team has just launched a preview of App Engine for Business providing 99.9% uptime service level agreement and premium developer support available.

以下是我认为什么是值得的：
我知道，这是一个艰难的电话;看了很多关于GAE 文章我百感交集它，因为你可以去从最近的灾难性卡洛斯竹叶提取到的花卉园或<一href="http://grack.com/blog/2010/11/23/why-were-really-happy-with-appengine-and-not-going-anywhere-else/"相对=nofollow> Gri.pe 。
应用程序引擎的业务看起来很有希望，我会认为这是在一个严肃的商业项目计划的情况。 新鲜 SDK 1.4.0 是巨大的，它清楚地表明，该团队是真正努力推动解决一些恼人的问题（预热的要求），并放宽一些限制（在任务队列10分钟过程）。

Here is my opinion for what it's worth:
I'm aware that it's a tough call; having read a lot of articles about GAE I have mixed feelings about it because you can go from the recent catastrophic Carlos Ble report to the happy experience of Flower Garden or Gri.pe.
App Engine for Business looks promising and I would consider it in the case of a serious business project plan. The fresh SDK 1.4.0 is huge and it clearly shows that the Team is really pushing hard to fix some annoying issues (Warmup requests) and relaxing some limitations (10 minutes process on TaskQueue).

最后要考虑的：如果你将有大的数字，谷歌App Engine的团队将可能把你的应用程序作为一个全成个案研究，遵循以自由和强大的炒作提振

Last thing to consider: if you are going to have big numbers, the Google App Engine Team will probably take your app as a successfull case study to follow with a boost of free and powerful Hype.

这篇关于最后GAE VS AWS架构决策的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！