Google Cloud Platform: Deploying with Google App Engine

• Google Cloud Platform: Getting Started with Google App Engine (Part 1)
• Google Cloud Platform: Deploying with Google App Engine (Part 2)
• Google Cloud Platform: User Management (Part 3)
• Google Cloud Platform: Mobile Endpoints (Part 4)
• Google Cloud Platform - Google Cloud SQL (Part 5)
• Google Cloud Platform - Google Cloud Datastore (Part 6)
• Google Cloud Platform - Google Cloud Storage (Part 7)

Part 2: Actual Cloud

In Part 1 of this series, we took a quick high-level look at the various parts of Google Cloud Platform, then dove into getting a "Hello World" app up and running in Google App Engine. Google App Engine being a Java Servlet-based environment, it was pretty much an exercise in writing a simple Servlet and making sure the Servlet deployment descriptor has the necessary elements for Google App Engine. But we left out an important part of that story.

We, uh ... we never actually deployed it to the cloud.

Cloud-ifying

Assuming the local machine has the code running from last time (see Google Cloud Platform: Getting Started with Google App Engine (Part 1) if you didn’t read the first part), the code is running in a local copy of Google App Engine environment. To get it into the cloud, we have to do a couple of things first; in particular, we need to get a Google Cloud Platform account up and running, then configure an environment in which this application will be deployed.

It starts by signing up with your Google account (what developer doesn’t have a Gmail account by now?), and then heading over to http://cloud.google.com/console and creating a project. The dialog will ask for two bits: a project name, and a project identifier, which Google will generate for you. The identifier is the important part as far as Google is concerned—this is the unique value that identifies the project among all of the other projects running on the cloud, hence the reason Google suggests a value. It will end up being the default domain (<identifier>.appspot.com) the application is accessed through, if no DNS CNAME records are set up to alias it (which is a little beyond the scope of this article).

Once that’s done, the project is created, and waiting for code.

Deploy

The Ant script from Part 1 can push the application into the cloud, but the local tooling needs to know a few things before it can successfully do so. Specifically, it needs to know the application identifier, and it needs to know that the fingers in front of the keyboard belong to the party who actually owns the space in the cloud. To do the former, we need to edit the <application> element in the appengine-web.xml descriptor to read the application identifier; thus, since my sample application was given the identifier "summer-scion-375", the <application> element should read:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>summer-scion-375</application>
  <version>1</version>
  <threadsafe>true</threadsafe>
</appengine-web-app>

The <version> element is also important, by the way, but we’ll get to that in a moment.

Once that’s done, run a shell script/batch file that comes from Google SDK called "appcfg" (appcfg.sh on MacOS/*nixes). This little tool will scan the appengine-web.xml file for settings (application and version), then ask for your Google credentials, and then promptly pull all the code into the cloud. The same script gets called from "ant update", so use whichever makes more sense. (I prefer to do everything through Ant, since then I can automate certain tasks before doing the update, such as a commit to source control or processing configuration files to set for development-vs-production settings, and so on; choose as you wish.) The first time, however, it must be called from the command-line, so fire up "appcfg update war", where the first parameter is to upload the app, and the second is the location of the WEB-INF directory in which appengine-web.xml can be found. It will prompt for the Google account email and password, then upload the application.

If something should go wrong with the deploy, by the way, such as a network timeout or something similar during its processing, do an "appcfg rollback war" to clean up local files and try again. For those who are curious, appcfg has a slew of command-line parameters to customize the experience (including the "--passin" command, which requires the password to be typed in every time), and are discovered in the usual manner: "appcfg help". (Or you could read the page on it at http://developers.google.com/appengine/docs/java/tools/uploadinganapp, but where’s the fun in that?)

Once the update is done, the app is good to go: head over to the browser, fire up "http://summer-scion-375.appspot.com/hello", and bask in the warm goodness of yet another "Hello, World" application running on the Internet. (Bear in mind there’s actually two hello’s here—one at the root, the index.html file we created last time, as well as the servlet behind the "/hello" URL pattern.)

Dashboarding

Before we move off of this, take a second and look again at Google Cloud Console, where you created the project. Click the link for your created project so you’re in the Console view for the project alone, and on the left side, about halfway down the sidebar is the "Google App Engine" link, which opens a new browser tab to the App Engine dashboard. These are two separate consoles—the Console is the "big picture" view of the project, with links to the different parts of Google Cloud Platform that your application touches, including Google App Engine, Google Cloud Storage, Google Cloud SQL, and so on. By itself, it’s not a particularly data-filled dashboard, but it’s the hub for all other dashboards.

Google App Engine dashboard, on the other hand, is a metric-lover’s delight. Immediately upon being loaded into the browser page, Google App Engine dashboard presents the developer/administrator with a ton of data about the running application, including a lovely graph in the center of the page (with a variety of settings in the dropdown under "Charts" to change what data is displayed) and—perhaps the most important information an application owner needs—a grid of resource consumption statistics under the section labeled "Billing Status". See Figure 1 for the view of my example app. More importantly, hiding behind the "Settings" link next to "Billing Status" is the all-important "Enable Billing" and "Enable Billing Administrators" buttons to configure how, when and to where Google will charge money in exchange for more cloud resources.

However, one other thing needs noting: right above the "Charts" section in the Dashboard is a dropdown labeled "Version", and currently it’s set to "1", which is also marked as "(Default)". Google App Engine recognizes that developers often want to have different versions of the code (at the very least, we have the current version "n", the previous version "n-1" that represents a quick fallback-in-case-we-screwed-something-up-version, and the next version "n+1" that represents the we-want-to-try-this-out-and-see-if-we-screwed-something-up version). This value is controlled by the <version> tag in appengine-web.xml, so if we make a change to the Java code (perhaps we look for the "name" query parameter, and use that to customize the greeting a little) and mark <version> as 2, and "ant update", versions 1 and 2 will be available in said dropdown.

Having said that, once version 2 is uploaded successfully, something seems wrong: pointing the browser to the http://summer-scion-375.appspot.com URL again reveals that nothing’s changed. This is because Google App Engine won’t automatically route traffic to version 2 until told to do so, which is done by clicking the "Versions" link in the left-hand sidebar, and selecting "2" in the table displayed there, then making it the default application by pushing "Make Default". This is by design; version 2 won’t be active until it is the default.

"Default" implies that there’s other ways to see that version of the application. Google App Engine will keep several versions of the code on the server simultaneously, and point traffic to the version marked "default". You can, however, craft a URL to visit any given version of an application by browsing to "http://<version>.<identifier>.appspot.com". Since version 2 is the default for summer-scion-375, that’s what is displayed without the version prefix, but we can still visit version 1 (or version 3, when we later enhance the application again to include something truly radical, like the current date and time) by going to "http://1.summer-scion-375.appspot.com".

A little something ... more

Although the Web originally was born of hyperlinked documents, complete with <blink> tags, animated GIFs, imagemaps and home pages that played your favorite music clip (see http://www2.warnerbros.com/spacejam/movie/jam.htm for a quick peek into that lovely past), over the last few years the Web has slowly turned into a collection of data, rather than documents. Going by the "Web 2.0" moniker, it’s becoming more common for cloud-deployed "applications" to actually be nothing more than data endpoints accessed over HTTP and serving up XML or JSON to a variety of endpoints: single-page HTML/JavaScript/CSS, mobile, or (sometimes) desktop applications. So while we could certainly explore one or more of the various Java toolkits/frameworks that will generate HTML on the server and hand that back, 2003 called, and it wants its code back. This is 2013, and we want to build a "Web 2.0" application.

One approach to doing so would be to take the existing servlet application, create a series of endpoints ("/greeting") that accept an incoming JSON packet (something like "{name:’Fred’}"), parse it, process it, and hand back an outgoing JSON packet ("{message:’Hello, Fred!’}"), all by hand in Java, but that’s a lot of work. In particular, parsing and preparing the JSON endpoints are going to bog a lot of this down, since we would be serializing and deserializing to a text format, complete with lack of type-checking and verification. (Remember how much fun this was to do with XML back in the WS-* web service days?)

Fortunately, Google App Engine provides a "backend" specifically for building these kinds of endpoints, and we’ll look at how to use it to create a greeting service that provides this kind of data-driven functionality. Before we can do that, though, we have to figure out who the user is, in order to greet them properly, which will be the subject of the next article. In the meantime, however, should you ever feel alone, there’s a web application waiting to say hello to you, so keep a browser tab open, and happy coding!