Doing IT the App Engine Way

Using Google's App Engine, you can develop Web applications in Python or Java and deploy them on Google's infrastructure for free—until you hit five million page views per month.

My Development Platform: Fedora 12

For this article, I'm using
Fedora 12. I used to eat, sleep and breathe Red Hat Linux (then Fedora),
but like a lot of other Linux users, I was tempted away
by the promise and then delivery of a friendlier desktop experience with Ubuntu.
As luck would have it, I recently received the latest edition of Mark G. Sobell's
book (see Resources), which includes Fedora 12 on DVD. Installation,
as expected, was straightforward. However, Fedora 12 comes with Python
2.6 pre-installed, and I needed the 2.5 release.

A feature of Python that I love is that multiple versions of the
interpreter can happily co-exist on your system. On my systems (desktops
and laptops), I have releases 2.5, 2.6 and 3.1 installed. Only one of
these releases is symbolically linked to the /usr/bin/python
(usually the 2.6 release), but I can invoke the other releases using
one of these command lines:

python3
python2.5

Deploying release 2.5 of Python on Fedora wasn't an issue. It's the
usual tar -zxvf, configure,
make and make-install four-step. As expected,
the Fedora DVD pre-installed all the development tools required to
let me build Python 2.5 from source without any issues.

Configuration

Unlike technologies, such as Ruby on Rails or Django, which provide
a collection of helper scripts to get you up and running quickly, App
Engine forces you to do all the work yourself. Thankfully, this is not a
huge effort. To demonstrate, let's create a new project with
the rather imaginative name, myapp. Create the initial directories
and files required in your HOME directory with these commands:

mkdir myapp && cd myapp
mkdir templates && touch app.yaml

The above commands create some required directories (more on these later)
as well as the main App Engine configuration file: app.yaml. You
edit this file to tell App Engine all about your webapp. Add the following
configuration directives to your YAML file:

The application line identifies your webapp, and the value needs
to match the name of the directory you just created to house
your project. Use the version value to indicate the release of
your webapp to which this YAML file refers (this value also is used by
Google's cloud to refer to different versions of your webapp, should
they exist). The runtime line tells the App Engine
for which platform
you are coding, and the api-version value indicates
what
version of the API you are using.

The remaining three lines tell App Engine what to do with any Web requests
destined for your webapp. It is useful to think of these handlers in
the YAML file as high-level, application “routing directives”. The bit
after url is a regular expression that (as all regex gurus will tell
you) matches anything that starts with a /, followed by any string
(or nothing at all). What's happening here is that any URL received by
App Engine on behalf of your webapp is going to be redirected to the
script identified on the script> line, which in this case is called
myapp.py. At the moment, no such script exists, so let's fix that.

Writing a Request-Handler Script

To demonstrate how an App Engine webapp is put together, let's build
a simple Web page that lets users submit their e-mail addresses
with a message. These two pieces of data are stored
in the Google cloud. A second page displays the e-mail addresses and
messages on-demand. Granted, this isn't a hugely exciting webapp, but
it's enough to demonstrate the basics of the technology and for you to
get started with something “real”. Of course, it is possible to build
this using App Engine's CGI mechanism (which works exactly as you would
expect), but as this application is destined for greatness, let's
code to Python's WSGI standard instead. Let's also build the webapp
to conform to the MVC pattern.

Defining the Model

As you plan to store some data in this webapp, you need somewhere
to put it, which means you need a model. App Engine provides an API
to Google's “cloud” datastore. All you need to do is define a Python
class that inherits from db.Model, then create the required data
fields. For the webapp, you need a field for the e-mail address and
the associated message. To keep things manageable, let's put your model
code in its own file, called myappDB.py:

There's not much to this model code. It simply imports
the db module from App Engine, creates a new class called
UserComment and creates class instance variables for each data
field. As App Engine's StringProperty type is limited to 500 bytes,
you need to specify TextProperty for the user message, just in case
someone has a lot to say.

Comment viewing options

This has to be one of the two best intro-level tutorials on appengine. Thanks so much for writing it and putting the time into the explanations. It all works, makes sense, and your efforts are very much appreciated!

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.