我应该在Google App Engine上运行业务流程管理应用程序,还是切换到更常规的平台

时间:2011-11-21 11:07:10

标签: java .net google-app-engine architecture

我目前正在为当前在Google App Engine上运行的业务管理平台制定路线图,该平台执行以下任务:

  1. 通过Google文档API读取信息,以便将提交内容提取到Google表单。该表格用于用户申请成为指导计划的一部分。 (对于像这样的事情,超时和请求限制有时会有点棘手)

  2. 针对电子表格中的问题执行匹配/加权算法,以便申请人可以相互匹配。这些权重现在存储在数据库中,以便在电子表格更改时控制

  3. 如果用户匹配,则会发送一系列电子邮件,并使用各种AP​​I授予用户访问各种Google服务的权限(所有用户都必须使用Gmail地址注册)

  4. 要求用户每月登录以报告他们在指导计划中的表现,然后系统会计算他们的指导关系的绩效得分。

  5. 有一些明显的改进,例如交换Google表单的一些灵活性以获得良好的验证和保存进度的能力(这是一种巨大的形式)但除了像这样的明确升级之外,是GAE像这样的应用程序的正确平台。

    以下是GAE的优点

    • 正常运行时间
    • 无手动服务器管理
    • 可扩展性(虽然这个应用程序不可能每月需要超过1500个用户,但不经常使用它)
    • 此流量水平基本上免费

    GAE的缺点

    • 不是很好的IDE调试支持(如果错误,请纠正我,我使用的是NetBeans + Python,我知道这是可能的,但看起来有点hacky)
    • 没有专门的数据管理工具(令人烦恼的是为本地测试降低实时数据,反之亦然)没有自动备份数据,导致应用程序损坏。
    • 目前在App Engine上运行Django,将来有可能在新版本的GAE中出现这种情况吗?

    我不确定我是否已经讨论过所有问题。问题的症结在于:

    对于这种应用程序,切换到更标准的业务平台(如.Net或Java)是有意义的,还是对现有平台的投资(约70,000英镑)意味着只有在绝对必要时才进行切换?

    从本质上讲,我觉得拥有这样一个只会变得更复杂的应用程序可以从更标准的应用程序堆栈中受益,因为GAE是为相对简单的web-app设计的(twitter,{{3} })

    然而,我永远不会想要重新发明轮子,GAE从减少管理开销中获得了很多好处。

1 个答案:

答案 0 :(得分:1)

我的2美分评论:继续使用GAE 。缺点:

  1. 同意。代码try-catch-finally(或Python中的except)和logging.info有帮助。
  2. 在appengine控制台的datastore admin链接下,您可以Copy to Another App(不确定您的应用是否会在此过程中停止)。可以更轻松地在克隆数据上测试修改后的代码,而不会影响实时应用或用户。
  3. 新版本需要对标准Python2.7库进行最少的更改(截至编写),但是如果您使用的是相当数量的Google API,则需要将API更新为较新的v3.0方法。结构保持不变。
  4. 我还希望通过Google API添加它,这使得GAE比其他平台更具通用性。