Google App Engine has been a fantastic disrupter in the technology industry. It's quickly driving innovation among developers and is starting to facilitate a different type of thinking and planning in the enterprise space. App Engine enables you to build enterprise-scalable applications on the same infrastructure that Google uses. The release of Java as the second official language for App Engine marks a tremendous shift in the way that applications are being built.
In this chapter, we'll cover the basics of App Engine and how it's structured. We'll discuss the major features and benefits of using a platform like App Engine as well as some of the major design considerations (for example, application quotas) that must take place in a multitenant environment.
App Engine Architecture
App Engine is structured differently from the typical Web application server. At its core, App Engine restricts your application from any access to the physical infrastructure, preventing you from opening sockets, running background processes (although you can use cron), and using other common back-end routines that application developers take for granted in other environments. Take a look at Figure 2-1 below. Remember, App Engine is designed to address your concerns about scalability and reliability. It is built on the concept of horizontal scaling, which, in essence, means that instead of running your application on more powerful hardware, you would run your application on more instances of less powerful hardware.
In this figure, you can see your App Engine application running as an isolated entity within the structure of the multitenant environment. App Engine shares resources among multiple applications, but isolates the data and security between each tenant as well. Your application is able to use some of the Google services, like URL Fetch, to execute processes on its behalf. Because you can't open ports directly within your application, you have to rely on this service, for example, to request Google to open a port and execute the fetch on a URL for the application.
Breaking it down a bit more, consider an apartment building (App Engine) with central air and heating controls. You are a tenant (your App Engine application) in this building. You can't directly adjust the temperature because that would affect the other tenants (other App Engine applications). So, you have to send a request to the building super to change the temperature on your behalf (URLFetch, Bigtable query,
Memcache, mail, XMPP, any other Google App Engine service). This is essentially what is happening with App Engine.
If you take a step back, you'll see the long-term implications of this approach. As a developer, you now get to ignore scalability concerns like execution time on methods after you have increased data in your datastore. In exchange, you get a fixed duration on execution no matter what your scale becomes. App Engine's response times will be steady from your first request to your millionth request.
Notice that no file system or components of the architecture represent the physical machine. With App Engine, you have access only to the application layer. There are some open source projects, for example, Google Virtual File System, that allow you to host an emulated virtual drive on App Engine, but these are not part of the product offering at this time.
Being a Good Neighbor With Quotas
App Engine is a multitenant platform. This is far different from hosting your application on a dedicated server or in your own data center. The fundamental difference is that you're not alone! Thousands of other developers are using the same network, hardware, and computing power that Google is offering for use with your applications. At first glance, this might create concern about scalability. Keep in mind that Google is the third largest e-mail provider on the planet and your free App Engine account can scale to 5 million hits per day. Plus, if you need more than that, you can always pay for more resources.
What if you shared a water source with your next-door neighbor? You wake up on Monday to get ready for work, turn on the shower, and nothing happens. You take a look out the window and notice that your neighbor left the hose on all night after washing his car that afternoon. This shared environment with no restrictions or quotas can be risky. How do you know if you're using too much or if you're neighbor is taking
more than his allotment? To protect users from this similar situation with respect to computing power, multitenant platforms use application quotas or governor limits to enforce application restrictions on users. For example, you can have a maximum of 7,400 secure incoming requests per minute on a free App Engine application. With billing enabled (more on that later in this chapter) you can have 30,000 secure
incoming requests per minute. The point is, there's a limit on what you can use. This protects other users on the same platform from being affected by applications that have significantly more traffic and resource needs. (This is known as 'the slashdot effect.')
Billable and Fixed Quotas
App Engine defines two different types of quotas, as you can see in the table below..
App Engine Quota Types
|Quota Type ||Description|
Most applications, and surely everything we show you in this book, will fit well within the fixed quota limits of the free version of App Engine. Enabling billing on your App Engine application increases your quota limits beyond what is provided with the free version. You'll see an increase in the fixed allotment of resources. And, if you still need more, you can define a budget and allocate resources from there.
You may be saying to yourself, 'So, I run outnow what?' Quotas roll over each night at midnight. Whatever usage you had starts over with the new calendar day. (App Engine uses Pacific Standard Time for billing and quota measurements, so it may not be midnight in your location.) You have the option to set daily quota budgets. If your resources exceed what your budget allows, App Engine considers those resources depleted and you'll have to either increase your budget or wait for the next calendar day to get replenished. Except for data storage, which is a rolling metric, all resource measurements are reset at the beginning of each day.
In addition to the daily quotas we've already discussed, App Engine measures a few per-minute quotas. These are subsets of your daily allotment of resources but have unique restrictions for per-minute usage. This is intended to protect your application from using its daily allotment in a short period of time. And, of course, being a multitenant environment, it also prevents other applications on App Engine from monopolizing any one resource and affecting your application's performance. If your application consumes a resource too quickly, the word 'Limited' will appear next to the quota line item in the Quota Details screen of your App Engine Administration Console. Once a particular resource has been depleted, App Engine
will deny requests for that resource, returning an HTPT 403 Forbidden status code. This may mean that your application will no longer function until the resource has been replenished. The following resources have this type of behavior:
For other resources that are depleted, the application will throw an exception of type OverQuotaError. This can be caught and handled and you can respond accordingly. For example, you may want to display a more friendly error message.
You're probably wondering whether you can query your application usage through the API. Unfortunately, if you're using Java on App Engine, it's not possible (yet). For Python applications on App Engine, you can query your application's CPU usage by calling the Quota API.