One Lap Around Google Cloud Platform with Photo Scavenger Hunt

At a recent hackathon, a small group of us wrote Photo Scavenger Hunt — A simple mobile game that gives you four clues that you have to take pictures to match. The harder the clue, the more points you get.

At GCP NEXT today we got a chance to demo how to build, deploy, scale and diagnose the server side of this app hosted on App Engine.

The server is very simple. App Engine frontend written in nodejs, storing the clues in a mongoDB and of course using the Vision API to automatically check images for matching clues.

The code is very simple. We use the gcloud-node library to store the images uploaded into Cloud Storage (line 6).

Next, we use the vision API to get the list of what things are in the uploaded image. While we are there, we verify there are no naughty images.

Now let’s run that from the command line with a cute image

Here we see that the Vision API found raccoon correctly (with 94.3% confidence). BTW, for the curious a procyonidae is the family that raccoon, coatis, kinkajous, and olingos are members of.

Now we just need to deploy this app to the server. That could be a complex process of spinning up machines, figuring out OS, database, load balancers, security groups, etc.

But App Engine lets me just code, so all I have to do is gcloud app deploy

What’s happening behind the scenes is we’re pushing the source code into GCP. That’s standard App Engine.

But what’s really powerful and new here is that for our newest languages — NodeJS, Ruby, Java 8 and others — it’s also being packaged as a docker container and stored in a private Google Container Registry before being deployed.

I was even able to do that without having docker locally installed on my machine!

Not only that, the containerized app we built can be deployed anywhere within the container ecosystem: in our cloud or on-prem. And of course it can be orchestrated by Kubernetes!

This makes App Engine developers first class participants in the world of containers.

Let’s go to the load test VM already running in our cloud project. It is simple to find the VM with search built right into the cloud console.

We can now just click right in the browser to SSH right into the machine. No passwords that can easily be guessed, no keys to leave around your machine, just quick seamless access right from the browser.

While that loadgen script is running, let’s go check that image we uploaded. As you recall, we stored it in Cloud Storage. We can just navigate to the storage section in the cloud console and we see… oh no, permission denied.

Of course I don’t have permission. I am logged in here as the developer. As the developer, I don’t need to access the production data — users pictures that are uploaded. This is a feature of Cloud IAM — a powerful feature that gives administrators fine grained control of who can access which resources in GCP.

Luckily, I am logged in as the admin in this window, so I can grant Greg the developer access to read images.

Now, I am paranoid when it comes to security of my projects, so I want to verify I have done this correctly. As the admin, I can use Activity Stream to see all the changes in the project — handy for tracking down production issues or compliance concerns. You can fully audit activity on your project with Activity Stream.

Now, back as the developer, I can see the images in cloud storage. Here is a cute baby hippo we photographed earlier.

Now let’s see how the load script is going. In the App Engine section, we can see a spike in the number of requests per second.

But I wonder how many VMs we are up to now.. How is the load balancer doing? I could look at some graphs, but as a developer, I like to have more control, directly from the command line.

Clicking the cloud shell icon gives me access to a free, persistent machine. pre configured with all the latest tools, already authenticated and up to date, and of course, accessible from anywhere right in the browser.

All you need is a browser.

I can use it to list all instances being spun up. Given this is a full power linux box, I can grep and format this data in cool ways. Here you can see the number of instances spinning up.

Looks like I have gotten an error from Stackdriver Error Reporting. Let’s check out what is causing that error.

You can see the error just started happening on the alpha2 version of the application I just deployed, but it is happening a lot. “Error:twitter rate limit exceed”. Seems like something I should take care of.

Error Reporting is a new service we are launching today that gathers all the errors from all services in your project and does advanced grouping and frequency analysis to show you only the most relevant server errors and some diagnostics information (stacktrace, logs) to help track down the root cause.

Looks like that is the only one that is new, but we should really look at the others later.

The right thing to do in this case is to rollback first and ask questions later. We know the version I pushed had issues, so let’s roll back to a known good state. App Engine makes this simple to do with route all traffic.

But now I want to know what really happened here. We have Alpha1 that seems to be working but errors coming to Alpha2. Let’s use Stackdriver Trace to compare the RPCs from each to see what the differences are.

Stackdriver Trace is a distributed tracing utility that helps you track down exactly where your server time is being spent. You can see in this Trace report page that our new “buggy” version Alpha2 labeled as B in orange also has longer latencies.

If we check out one of these sample traces from the 99 percentile, we see call to the vision API and before that a call to GCS — that makes sense, we wrote those calls, but what are all these calls to twitter… Oh, they are part of this doQuestionableInitialization().

method! I knew I should have been suspicious of that. You will recall our initial code looked like:

So that doQuestionableInitialization() code is make a few spurious calls to twitter. While you never want errors to happen, Goole Cloud Platform made it easy for us to handle this error. We were able to:

— Spot this issue and get an alert with Error Reporting
— Rollback our change instantly with App Engine Versions
— Track down the root cause with Trace

I hope this quick lap around Google Cloud Platform has given you the desire to try it out on your own app! Get a $300 Free Trial at https://cloud.google.com.

Please let me know if you have questions or comments.