2008 年 4 月 7 号，Google 在 Campfire One 上介绍了一种简化创建、运行和构建伸缩性Web 应用的工具—— Google App Engine 。简而言之，Google App Engine 允许你本地使用 Google 基础设施构建 Web 应用，待其完工之后再将其部署到 Google 基础设施之上。
这次发布的是没有包含全部特性的预览版，提供了一个配额系统，它限制了在预览期间应用免费可用的存储、CPU 和带宽。一旦预览期结束，配额仍将免费，但是开发者需要按需购买额外资源。额外资源的价格尚未公布（甚至可能尚未确定）。
预览版的配额包括：3 个应用 / 开发者、500MB 存储 / 应用、2000 封邮件 / 天（连续 24 小时）、10 GB 入站带宽、10 GB 出站带宽、200M CPU 兆周、650k HTTP 请求、2.5M Datastore API 调用和 160k URL Fetch API 调用。
技术：开发环境和 API
尽管 Google 说‘未来将支持更多的语言’，但是目前技术栈是基于 Python 的，它是 Google 认同的语言之一。出于安全和伸缩性的目的，Google 提供了一个运行在安全沙箱中的 Python 运行时环境，它提供对底层操作系统有限制的访问。该环境包括标准库，并可通过模块进行扩展，编写模块的语言目前不支持 C 语言。
该环境包括 Python 标准库。当然，调用那些违反沙箱限制的库方法（如打开 socket 或写文件）将不会成功。为了方便起见，几个核心特性不被支持的标准库中的模块被禁用了。那些引入它们的代码会出错。
应用代码只能用 Python 书写。不支持使用 C 来编写扩展。
其他安全限制包括：出站通信（outbound communication）只能通过所提供的邮件和 URL fetch API 进行，通过 HTTP 和 HTTPS 作为传输的入站通信（inbound communication）使用标准端口，禁止文件系统写操作和禁止子进程或代码在请求 / 响应循环外执行（例如后台操作和批操作）。
此外，Google 提供了访问一个 Datastore、Google 用户帐号、URL fetch 和邮件服务的 API。App Engine 还包括一个简化的Web 应用框架和Django 0.96.1，尽管App Engine Datastore 不是关系型的，而且也不能使用全部的Django API。
Datastore API 背后由 Google 的 BigTable 支持，但是它与一个简单的对象持久化 API（或一个对象关系映射框架，即使 Google 强调这个 Datastore 不是关系型的）有很多相同之处：
你们中的大多数，在使用这个 Datastore 时可能会有点不习惯：如我所说，它不是 SQL。这是个巨大的区别。然而，我们想了一下之后，认为这个 Datastore 可能会引起你们的兴趣，因为它让一些事情变简单了。比如说，我们的 Datastore 没有模式，这意味着它可以支持任意的新属性或列，你可以用代码创建，无需把所有事情预先设计好并创建一个模式。这就回到了我们尽可能简化 Web 应用编写的目标：只需开始编码就好了。你的数据模型可以随你应用的演变而演变。
即使 Datastore 违背了 SQL，我们仍然支持你想要的传统关系数据库的许多强大功能。对于任何你提供的单个属性或属性集合，Datastore 都提供了高效查询。它还支持对查询结果的排序，包括按多属性进行排序。它对写操作支持事务，通过事务分组来控制。对于提取或创建大量实体，它也支持批操作。它给你机会让你来控制你实体的主键，以获得更好的查询效率和更短的 URL。
并且，即使 Datastore 不是 SQL，我们也为你提供了类 SQL 查询以简化查询的表达，叫做 GQL。GQL 受到了 jQuery 和 FBQL 的启发：底层的存储不是 SQL，但是几乎你想要的所有查询仍然可以完成。
你可能已经注意到我们的 Datastore 缺少一个大特性，那就就是连接（join）。这是因为连接通常是分布式系统效率问题的根源，当你有不止一台机器时：很难在跨多个机器和多个硬盘的分布式系统上进行连接操作。
尽管 Datastore API 支持事务，但是它们有严格的限制，而且和实体组关联：
每个实体都属于一个实体组，在一个事务内可以操作一个或多个实体。实体组关系告诉 App Engine 在分布式网络的同一部分保存几个实体。一个事务为一个实体组设置 Datastore 操作，所有这些操作按组实施，如果事务失败就全部撤销。
当应用创建一个实体时，它可以分配另一个实体作为新实体的父。给一个新实体分配父时，将使它进入父实体所在的实体组。
没有父的实体是根实体。一个实体的父实体也可以有父。从一个实体到根的父实体链就是这个实体的路径，路径的成员是实体的祖先。实体的父只能在创建时定义，之后就不能修改。
祖先是同一根实体的所有实体都在相同的实体组中，组中的所有实体存储在同一 Datastore 节点中。单个事务可以修改单个组中的多个实体，或通过将组中现有实体变成为新实体的父来把一个新实体加到组中。
因为 App Engine 迫使你以一种特殊的方式（如 Datastore on BigTable，而不是数据库）来处理你的开发，Google 声称你的应用将更易于伸缩，而且这种伸缩性几乎是透明的：
当一个 Web 应用变得流行起来时，突如其来的流量可以压垮各种规模的应用，从创业公司到大公司都发现需要一年几次的重新架构他们的数据库和整个应用。通过自动复制和负载均衡，利用 Bigtable 和 Google 的可伸缩基础设施中的其他组件，Google App Engine 使得应用可以从一个用户伸缩到百万级用户。
User API 允许通过 Google 帐号进行用户验证和登录，以及访问帐号的绰号和邮件。其他更多的用户信息可以从应用保存在 Datastore 中的用户信息直接获取。
URL fetch API 能通过提取 HTTP 和 HTTPs URL（支持 GET、POST、HEAD、PUT 和 DELETE，因此这似乎可以支持 REST 功能）检索远程服务器的信息。
Mail API 允许 App Engine 应用异步发送邮件，如果邮件服务器不可用时允许重试。
App Engine SDK 包含模拟 App Engine Python 运行时环境的服务器，以及：
- 模拟模块引入限制，只允许处理程序引入被许可的模块，它们来自标准库、包含在 App Engine Python 环境中的第三方库，以及应用目录中的模块
- 模拟应用缓冲行为
- 使用本地文件模拟 App Engine Datastore
- 模拟包含有登录和注销页面的 Google 帐号，登录参数可以是任何邮件地址。
- 通过提取你计算机的 URL 模拟 URL fetch 服务
- 使用你选择的 SMTP 服务器或 Sendmail 配置模拟邮件服务
乍一看，绝大多数的应用配置似乎可用YAML 来写。
动机和竞争
Google 的公告称他们的动机是，简化 Web 应用的构建、部署和伸缩性：
嗯，我们构建 Web 应用是因为我们想要更多的 Web 应用被创建出来。我们注意到，目前创建一个 Web 应用真的很难：即使部署一个最简单的 Web 应用也有巨大的前端挑战。你需要做很多事情。当然，首先你必须为你的应用编写代码。
但是接着，你还需书写你的 Apache Web 服务器配置和启动脚本，安装你的数据库，创建所有表和设置口令，安装监视器来了解你的流量和日志，决定你如何推出代码的新版本等等。
那只是我们注意到的技术方面的挑战。然后，一旦你完成了所有那些系统管理员的工作，你就有了另一个挑战：你必须着手去找你能使用的机器来运行你的应用，不论是物理的还是虚拟的提供商。现在，就要花钱了：即使是最简单的应用，一周用几次，你都必须支付一大笔预支费用来让它在一个传统主机托管提供商处运行。
那么，这就是财务或物理方面的挑战。然后，一旦你搞定了整件事情并且运行了，而且找到地方并为此付费来测试它，你又面临了另一个挑战：随着你应用的成长，你必须去维护它。你的机器崩溃了，你的配置有错误，你的硬盘坏了，你的流量开始增长，你必须重新分享你的数据库，安装更多更多的机器。随着应用的成长，任何事情都象是一场激战。
所有这些激战正是我们试图通过 App Engine 避免的。它们是我们正试图解决的问题。
其他人已经揣测出了言外之意。很多人指出了 Google 与 Amazon 和微软在未来云计算和 Web 服务方面的竞争，常常将 App Engine 与 Amazon 的 Web 服务 EC2 、 S3 、 SQS 和 SimpleDB 相提并论：
-
自从 Amazon Web 服务有这么好的开局之后，我们都知道这只不过是时间问题（我们可以有把握地假定下一个将会是微软）。尽管拿 AWS 与 GAE 作对比是显而易见的，但是它们真的不是同一类工具。Amazon 已发布的一组独立服务可以被用来创建一个通用的计算平台。尽管这些服务可以一起工作，但是它们没有作为整体打包在一起。
另一方面，App Engine 是一个驱动 Web 应用的引擎。它将 AWS 提供的许多特性进行了整体打包：存储类似 S3、自动伸缩性和处理能力类似 EC2，Datastore 类似 SimpleDB。App Engine 还提供了 AWS 没有的特性，如 Python 运行时，Google 特定的 API，以及可能是最吸引人的免费服务部分。
-
VentureBeat：“ Google App Engine 准备与 Amazon 竞争”
其他人暗示微软也正携一些工具向这个方向挺进，比如 Ray Ozzie’s Mesh strategy 和 SQL Server Data Services ，但是可能已经太晚了：
- Network world 说，“Google 再次领先微软”
- ZDNet 问：“ Google App Engine：微软将何时围捕竞争者？”
看看事情的另一角度，某些人暗示这会使 Google 在收购方面棋高一着，这是一种风险基础设施（venture infrastructure）形式：
-
Business Week 认为Google 和 Amazon 间的竞争没有提及这一点：鼓励创业公司在 Google 的基础设施上开发他们的应用，这使 Google“不仅可以很好地了解人们想要的应用和需要克服的问题，而且能敏锐地发现 Google 想收购的有前途的新创业公司”。
-
ZDNet 补充：它可以节约 Google 在收购方面的金钱：“想象一下，如果收购一家已经使用 Google 技术的公司会省下多少时间和努力？”
-
GigaOM 说：“这种亏本销售的服务将那些创业公司带进了 Google 的大门，这使得这家公司可以访问最新的想法并可从天才企业家池中做出选择”
-
在“Google 如何吃掉 Amazon 的午餐”中，Kevin Kelleher称这为投资：
在这次采访中，我大声地推测 Amazon 所做事情很像公司风险投资的（如 Intel 投资部）做法——投资和他们以后要合作（或者要收购）的创业公司。只是不用硬通货，而是基础设施。我得说，非常精明。
高管的反应是：Amazon 根本没这么做，而且永远不会用 Web 服务那么做。我心里想了一下，但是没说：嗯，如果你们不这样做，有人会这么做的。
现在，有些人正在说 Google 正在这么做。随着有价值的 Google 员工整理他们的桌子并启动一家新的创业公司，推出 GAE 是 Google 将他们重新召回的最好策略。这也是从 Amazon 身下抽走地毯的绝佳方法，战略上明智而且盈利上也明智。
反馈、分析和资源
- 遍布网上和博客的其他分析：
- Jaiku，a Google 新近收购的公司，宣布它将移植到 App Engine 。
- TechCrunch
- news.com
- Farhan Mashraqi 说：这大大推进了 Python 语言，和 blist 所做的一样。
- fuzzmeister 在 Digg 上的评论暗示这会有重大影响，“这会演变成对 Web 站点托管和运行方式有根本性改变的事情”
- Wayne Pan 认为‘免费’角度是最大的新闻，App Engine 要真正吸引人需要支持其他语言和外部服务模型。
- Nate Koechley 指出 Guido Van Rossum 是 GAE 团队成员之一。
- FaceReviews 指出 Robert Scoble 在公告发布之后与 Pownce 进行了交谈，他们觉得没有什么特别的。
- Adnans 记录了一些 API 相关的笔记。
- Technosailor 说他没看出有什么新意，既没有创新，也不令人感到震撼。他是个怀疑论者。
- 以下论坛已经就 App Engine 开始了一些讨论：
- 预了解更多关于 Google App Engine 的信息：
- 访问 Google Code 上的 Google App Engine 站点。
- 观看 YouTube 上的视频。
- 参与官方论坛的讨论。
- 访问官方博客
- 研究 application gallery 或 Jaiku 上的一些 App Engine 应用。
- 阅读 google 代码知识库上的 FAQ。
- 阅读一些关于 App Engine 的文章，包括
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论