从数据库、应用配置、计费、域名绑定、平台服务对比了 BAE、SAE 以及 GAE 的优劣，最后给出云平台选型的建议。
数据库
SAE 不支持 InnoDB（可申请支持），BAE 默认支持。
BAE 不支持数据库连接池（c3p0、BoneCP 已测不支持），数据库连接不能长时间保持。
GAE 使用 Datasotre 存取数据，最近也提供了云 SQL（MySQL），但申请比较困难，配额/性能笔者未测试过。
另外，SAE 显式给出了主从库的访问方式，应用可以比较灵活地设计存取策略，例如读写分离。并且 SAE 是每个应用都拥有自己的数据库，而 BAE 是所有应用共用一个库。
应用配置
BAE 的 duapp-web.xml 基本是抄袭 GAE 的 appengine-web.xml，元素基本一致。
比较奇葩的是 BAE 静态资源配置默认所有后缀为静态文件类型（例如 .html）的请求路径都默认假设为静态资源，需要在 duapp-web.xml 中指定排除。
计费与配额
SAE 按应用天计费“云豆”，服务也按流量计费、CPU 时间、调用次数计费。注册或活动送配额，否则需要购买。
BAE 目前还没有详细的计费，只限定了应用数。公测结束后应该会细化计费模型。
GAE 目前的计费模型主要是按 API 调用计数，流量分为 In/Out 配额。每天会定时刷新免费配额。
综上，GAE 的计费一目了然，主要就是 API 调用次数；SAE 的计费比较复杂，不同服务有不同的计费策略；BAE 还没有明确的计费模型。
域名绑定
GAE 开通企业套件后随便绑，企业套件有免费版。
SAE 目前可以随便绑，但没备案的话绑定域名的请求走海外中转，流量计费翻倍（原二级域名请求计费不变）。
BAE 目前可以随便绑，但没备案的后果自负。
平台服务
SAE 提供了 SDK 包，包含了开发需要的本地服务实现。
BAE 则分别提供了服务 Jar，调用方式按不同服务而异。
GAE 提供了完整的 SDK 包，包含了开发需要的本地运行环境和配置客户端。
综上，GAE 提供了完整的平台化服务，覆盖了从开发到上线运维的一系列工具；SAE 则提供了部分工具，平台化不完整，增加了开发、运维难度；BAE 则是分别提供不同服务给开发，没有统一的 SDK 与调用方式。
另外，值得一提的是 BAE 虽然服务没有整合到一个 SDK 中，但其分散的服务也比较适合应用自己选择。 其中云消息（消息服务）以及云触发（数据变更通知）是 GAE/SAE 没有提供的服务，某些业务场景应该会非常适用。
结论
SAE 与 BAE 主要还是面向应用部署托管，普通应用修改后易迁移部署到 BAE 或 SAE。
新应用开发可以选择和平台绑死（依赖平台服务）或按照普通应用开发。
使用配置工具来上传、更新应用配置其实是非常好的方式，但目前 SAE/J、BAE/J 都没有提供客户端配置工具，这增加了使用者的维护工作量。
GAE 提供了比较完整的服务平台，覆盖了应用的生命周期，最近也提供了云 MySQL 服务以吸引更多开发者。
需要根据应用类型来考虑平台选型，例如 GAE 基本以 API 计数的配额就不适合做社交应用，‘墙’的问题也需要考虑解决方案。 |
