App Engine应用响应网络请求。当一个客户端（典型的是用户的Web浏览器）使用HTTP请求（比如获取在URL上的网页）连接上应用的时候，网络请求就开始了。当App Engine接收到请求时，它会从地址的域名中识别应用，.appspot.com子域名（为每个应用免费提供的）或你在Google Apps中已经注册创建了的自定义的子域名。App Engine从众多可能的服务中选择一个服务来处理这个请求。选择的依据是哪个服务最可能提供一个快速的响应。然后它使用Http请求的内容调用应用，从应用中获取响应的数据，并且将响应返回给客户端。
从应用的角度看（perspective），这个运行时环境在请求处理开始的时候存在（spring into existence），在请求处理结束时消失。App Engine提供了几种在请求之间保存数据的方法，但是这些机制在运行时环境之外存在（live outside of the runtime environment）。在运行时环境中请求之间的状态不保留，或者至少不希望在请求之间保留状态，App Engine可以在众多的需要用的服务间分发流量来给予每个请求相同的对待，而不管它一次处理的流量是多少。
从全局来看（in the complete picture），App Engine 允许运行时环境在请求处理之后还存在，并且尽可能地重用环境来避免不必要的初期化。你的应用的每个实例都拥有本地内存来缓存导入的代码和初期化的数据结构。App Engine会按需创建或销毁实例来适应你的应用的流量（traffic）。如果你允许多线程的特性，那么一个实例可以充分利用它的资源并发地处理多个请求。
传统意义上，应用代码不能访问运行它的服务器。一个应用可以从文件系统中读取它自己的文件。但是不能向文件中写，也不能读取属于其他应用的文件。应用可以看到App Engine设置的环境变量，这些变量的操纵在请求之间没有必要继续存在。尽管应用可以使用服务来执行网络操作，但是应用不能访问服务器硬件的网络设备。
总之，每个请求存在于它自己的沙箱中。这允许App Engine使用最快的响应服务器来处理这个请求（估算的）。对于我们的向这个应用发出的请求，无法保证同一个应用实例来处理两个请求，尽管这些请求来自于同一个客户端并且都相对很快地到达了。
沙箱也允许App Engine在同一个服务器上运行多个应用而不会出现一个应用影响另一个应用。除了限制对操作系统的访问，运行时环境也限制了时钟的数量以及一个请求可以得到的内存。App Engine使得这些限制有伸缩性，并且对应用使用了更严格的限制，防止应用耗尽资源来保护共享资源。
一个请求处理器（request handler）最多有60秒（up to 60s）的时间将响应返回给客户端。尽管看上去对于一个Web应用来讲这是相当多的，但是App Engine还是会优化应用使其响应时间小于1秒。并且（also），如果一个应用使用了很多的CPU周期的话，App Engine 可能会使它慢下来，那么在提供多个应用的机器上这个应用不会强占处理器（processor）。对于一个CPU密集型的请求处理器，如果它需要很多的处理的话会使用比本来更多的时钟时间（clock time）。当App Engine侦查出CPU的使用方式时时钟时间会响应地改变，分配。（A CPU-intensive request handler may take more clock time to complete than it would if it had expensive use of the processor,and clock time may vary as App Engine detects patterns in CPU usage and allocates accordingly）
Google App Engine为应用提供了三种可用的运行时环境：Java 环境，Python环境，Go环境（Google开发的新的系统语言）。你选择的环境取决于你开发应用使用的语言和相关的技术。
Java环境在Java 6 VM上运行应用。一个应用可以使用Java语言开发，或者大部分其他的可以在JVM上编译或运行的语言，比如PHP（使用Quercus），Ruby（使用JRuby）,JavaScript（使用Rhino 解释器），Scala，Groovy和Clojure。应用使用基于Web工业标准的接口访问环境和服务，包括Java Servlets和Java Persistence API （JPA）。任何在沙箱约束中起作用的Java技术都可以在App Engine中运行，使得许多存在的框架和库适用于它。尤其是，App Engine完全支持Google Web Tookit(GWT)，一个富Web应用程序框架，使我们可以用Java语言写所有的应用代码（包括在浏览器中运行的用户接口），并且使富图形应用能够在绝大多数浏览器上工作而不需要插件。
Python环境运行由Python2.7编程语言编写的应用，使用自定义的CPython版本，官方的Python解释器。App Engine使用WSGI调用Python 应用，一个广泛使用的应用接口标准。应用可以使用大部分Python的大型的杰出的标准库，以及访问服务和模型数据（modeling data）的富APIs和库。许多开源的Python web应用框架和App Engine一起工作，比如Django，web2py，Pyramid，Flask。App Engine 甚至有一个自己的叫做webapp的轻量级的框架。
这三个运行时环境使用相同的应用服务模型：一个请求路由到app server，应用实例初期化（必要的话），应用代码被调用来处理这个请求，生成响应，响应返回客户端。每个环境都在沙箱约束中运行应用代码，所以任何使用语言本身或某个库来访问沙箱以外的东西都会返回一个错误。
你可以配置实例的创建、销毁和初期化的任何一个方面。如何配置应用取决于花费与性能之间的平衡点。如果倾向于性能，就可以多配置一些运行的实例。开启多个实例处理需要。如果预算有限就调整限制，使用最少的实例来控制请求的排队等候。（if you have a limited budget,you can adjust the limits that control how requests queue up to use a minimum number of instances）
现在还没有说到任何关于App Engine使用的操作系统和硬件配置。有办法知道一个服务器使用的操作系统和硬件，不过这是没有必要的：运行时环境是操作系统之上的一个抽象。允许App Engine管理资源的分配、计算、请求处理、规模扩大（scaling）、负载分布而没有应用的参与。那些需要用到操作系统的特性是由运行环境之外的服务提供，由标准库的调用来提供或仿真，或者在沙箱的定义中以理智的方法（in sensible way）限制。
上述内容描述了App Engine会根据应用的流量动态地分配应用实例来扩展。你也可以在指定的手动分配的实例上运行代码，这些实例就是backends(or simply,"servers")。这些指定的实例十分适合于后台作业和自定义服务，有它们自己的参数来执行代码（have their own parameters for how they execute code）。然而它们不会自动扩展（scale）。当达到了一个服务器的容量时，它根据你的代码来决定下面怎么做。Backends是App Engine的一个新特性，这个体系结构正在演化。在这个版本的书中不会详细谈及这个特性。