cloud-test: 2012

Mobile voucher sales terminal in Africa powered by App Engine

Thursday, December 20, 2012

Today’s guest blogger is Dale Humby, CTO of Nomanini. Nomanini is a startup based in South Africa which provides a platform to sell prepaid products such as airtime, electricity and insurance electronically. In this post, Dale explains how the backend systems of their flagship device, Lula, run on App Engine.
Introduction
In rural markets, it is often difficult to distribute physical vouchers, which can be used to provide access to services such as electricity, insurance, and airtime for mobile phones. Nomanini enables entrepreneurs in Africa to earn income selling prepaid vouchers in their local communities. We do this by distributing a portable, user-friendly voucher sales terminal, known as the Lula, which can be used on-the-go by people ranging from taxi drivers to street vendors.

The Lula, Nomanini's portable voucher sales terminal

Running Lula on App Engine

Nomanini uses Google App Engine to support the backend system for our network of point of sale terminals.

Terminals in the field connect to our App Engine application through the GSM mobile network. The terminals synchronize when a connection becomes available, allowing sales to be processed even when devices are offline.

The devices make an https post to a URL endpoint. Any data uploaded by the device is queued for processing as multiple tasks, and the App Engine application sends information back to the device within the returned body. Often the only responsibility a URL endpoint has is to create a task. If work can be broken into discrete areas we fan out to other tasks which run in parallel on separate App Engine instances. By controlling how many concurrent tasks are run in each queue, we are able to prioritize specific parts of our application ensuring the best quality of service for our customers.

By utilizing cross entity group transactions, transactional tasks and appropriate key naems for entities in the Datastore, we have been able to build an extremely resilient application capable of processing data.

Services we use

High Replication Datastore, NDB and Memcache

Extensive use of push Task Queues

Blobstore for storing file records

Logs API, Mail API and XMPP for reporting and real-time notification of issues to our development team

URL Fetch API to link to third-party API’s such as sending SMS’s and integration to mobile networks for airtime voucher purchase

Google Cloud Storage and Google BigQuery for mining our data for interesting trends

ProdEagle (another application built on top of Google App Engine) for real time metrics visualization

Benefits of building on App Engine

Saves time
App Engine’s High Replication Datastore gives us the peace of mind that our data will be available and accurate to a degree that we couldn’t easily replicate ourselves. As a start up, capital and time are in short supply. With App Engine, we can focus on building our unique application rather than worrying about infrastructure. App Engine Task Queues allow parallel data execution and retrying on failure, with little code overhead for developers.

Scalability
Nomanini has very cyclical traffic patterns: our peak traffic occurs in the early morning and late afternoon, with a monthly peak around payday in South Africa. Google App Engine automatically scales our application so that we don’t have to pay for excess server capacity during off-peak times, but have capacity available when we need it.

Ease of operation
Deployment is a breeze on App Engine. With just a few scripts tied in to our continuous integration server we can:

write the version number and app name into app.yaml

deploy automatically

run data migration scripts

change the default version once all indexes are serving

Monitoring is simplified by using built in dashboards. We can also export logs to Google Cloud Storage and run ad-hoc queries on analytics using Google BigQuery.

Conclusion

To reduce our time to market we used as many off-the-shelf components as possible, including Google App Engine.

We chose App Engine because it offers a platform with a consistent, well documented, ready-to-use set of services and allows our developers to test within an environment that is identical to our production environment - a practice that used to be prohibitively expensive.

Using the Google App Engine platform has saved our small development team time that we would have had to use to design, build and test a highly reliable backend to support our network of vending terminals in farflung places. Instead, we can focus our time on building a device that we hope will impact the way local commerce is done in rural economies.

To read more about the story of Nomanini, check out the post about us on the Official Google Blog.

-Contributed by Dale Humby, CTO, Nomanini

Posted by Zafir Khan, Product Marketing Manager, Google App Engine

App Engine 1.7.4 Released

Thursday, December 13, 2012

The Google App Engine team has been busy putting together our final release of 2012. This release includes a number of features graduating from Experimental status as well as the usual batch of bug fixes and improvements. We’ll be taking a short break from our monthly release cycle over the holidays, but we’ll be back to our normal schedule starting in February.

Expanded EU Support

We’re happy to announce that we are expanding European Union datacenter support, based on positive feedback from early users. You can sign up here. Please note, deployment is currently limited to billing-enabled applications. We understand that data locality and latency are important to developers and are committed to further expanding this support in the coming months.

Java

We've made a new Maven plugin available, added the source to the SDK for easier IDE debugging, and made significant performance improvements to the JSP compilation process. Please see our Java release notes for more information.

Python

We’ve made a big push to bring a number of new features to GA, upgraded the interpreter to version 2.7.3, and added several new experimental features. For more details, please see our Python release notes.

New and Upgraded Features

We also have a handful of notable features in this release:

Task Queue statistics (General Availability): You can see statistics such as the current number of tasks in a queue, the number of tasks executed in the last hour, and more.

Traffic splitting (General Availability): You can split requests amongst different versions of your app.

LogsReader and Logs API (General Availability): You can now fetch requests based on a list of request IDs.

Expanded Datastore query support (Experimental): We’ve added ‘DISTINCT’ support to Datastore queries.

Full release notes and Google Cloud Platform newsletter

The complete list of features and a list of bug fixes for 1.7.4 can be found in our release notes. For App Engine coding questions and answers check us out on Stack Overflow, and for general discussion and feedback, find us on our Google Group.

Finally, to stay up to date with Google Cloud Platform, sign up for our newsletter where you’ll get the latest news, announcements and event information.

- Posted by the Google App Engine Team

Get started at no cost with a faster, larger Google Cloud SQL database

Thursday, November 8, 2012

You want your application to be fast. Databases play a big role in your overall application speed and end-users’ experience. Reads and writes should execute instantly, even as your user base grows to millions of users, and this requires faster, larger databasesGoogle App Engine is designed to scale. And now Google Cloud SQL, a MySQL database that lives in Google’s cloud, is scaling up alongside App Engine to meet that demand for faster access to more data. With the features we are launching today, you can now work with bigger, faster MySQL databases in the cloud:

More Storage: We’re increasing the available storage on Cloud SQL to 100 GB - ten times more than before.

Faster Reads: We’re increasing the maximum size of instances to 16 GB RAM. This amounts to a 4 times increase in the amount of data you can cache.

Faster Writes: We’re adding optional asynchronous replication, which gives the write performance of a non-replicated database, but the availability of a replicated one.

EU datacenter availability: If you sign up to be a Premier customer, you can choose to store your data and run your Cloud SQL database instance in either our US or EU data centers.

Integration with Google Apps Script: We’re making it quick and easy for businesses using Google Apps to use Cloud SQL. Publish and share your data with Google Sheets, add data to your Google Sites pages or create simple Google Forms without worrying about hosting or configuring servers.

Introducing a new trial offer
We’ve received many requests from users for a trial offer to test out Cloud SQL. Today, we’re introducing a 6- month trial offer at no charge, effective until June 1, 2013, and will include one Cloud SQL instance with 0.5 GB of storage. Sign up now to get started.
Posted by Joe Faith, Product Manager, Google Cloud SQL

Upgrading to Python 2.7: simple and practical

Tuesday, November 6, 2012

We launched a major improvement to the Python runtime when we introduced support for Python 2.7 last February. It has since proven to be astonishingly popular – just a few months later more than half of all active Python applications on App Engine are using Python 2.7.

What’s so great about Python 2.7? It isn’t just a language update, it also includes a number of features that can help your apps run much more efficiently.

Increase efficiency with concurrent requests. Now a single frontend instance can handle multiple requests at the same time in separate threads. This means App Engine requires fewer frontend instances to handle the traffic, which can lead to significant cost savings.

Rapidly growing mobile gaming company Pocket Gems reduced the cost of running their front-end instances by 78% when they switched to to the Python 2.7 runtime. “We immediately saw a dramatic difference” said engineering director David Underhill “We only need one third as many instances under Python 2.7 as we did under 2.5 to handle the same traffic”.

Move faster with more native C modules. In Python 2.7 we’ve added more native C modules to App Engine. Core libraries like cPickle run much faster than the equivalent pure Python library available in the Python 2.5 runtime.

Take advantage of popular third-party libraries like PIL and numpy. We’ve greatly expanded the number of third party libraries available for use in App Engine in Python 2.7. So far we’ve added the Python Imaging Library (PIL), lxml, numpy, and several others.

Best of all, upgrading won't require lots of code changes. “It was pretty straightforward,” says Underhill. “We had to be careful, but we ended up needing to change less than 0.4% of the code”.

If you're ready to make the switch, check out our migration guide, find out more about the other great features of the Python 2.7 runtime and get in-depth tips from the App Engine Python team by watching their talk on Migrating to Python 2.7 at Google I/O 2012.

- Posted by Andrew Jessup, Product Manager, Google App Engine

Developer Insights: Teaching thousands of students to program on Udacity with App Engine (part 2)

Wednesday, October 31, 2012

This post is the second of our two-part series discussing how Udacity uses Google App Engine.

Today’s guest blogger is Chris Chew, senior software engineer at Udacity, which offers free online courses in programming and other subjects. Chris shares how Udacity itself is built using App Engine.

Steve Huffman blogged yesterday about how App Engine enables the project-based learning that makes his web development course so powerful. People are often surprised to learn that Udacity itself is built on App Engine.

The choice to use App Engine originally came from Mike Sokolsky, our CTO and cofounder, after his experience keeping the original version of our extremely popular AI course running on a series of virtual machines. Mike found App Engine’s operational simplicity extremely compelling after weeks of endlessly spinning up additional servers and administering MySQL replication in order to meet the crazy scale patterns we experience.

Close to a year later, with ten months of live traffic on App Engine, we continue to be satisfied customers. While there are a few things we do outside App Engine, our choice to continue using App Engine for our core application is clear: We prefer to spend our time figuring out how to scale personalized education, not memcached. App Engine’s infrastructure is better than what we could build ourselves, and it frees us to focus on behavior rather than operations.

How Udacity Uses App Engine

The App Engine features we use most include a pretty broad swath of the platform:

High Replication Datastore with NDB

Memcache

Task Queues - Deferred execution, MapReduce, batch jobs

App Engine Search API -- Indexing both course content and student résumés

Blobstore API -- Lecture videos, résumés, data exportation

Image API - Thumbnail generation

MapReduce API - Daily usage analytics, data migrations, data maintenance

A high-level representation of our “stack” looks something like this:

Trails and Trove are two libraries developed in-house mainly by Piotr Kaminski. Trails supplies very clean semantics for creating families of RESTful endpoints on top of a webapp2.RequestHandler with automagic marshalling. Trove is a wrapper around NDB that adds common property types (e.g. efficient dereferencing of key properties), yet another layer of caching for entities with relations (both in-process and memcache), and an event “watcher” framework for reliably triggering out-of-band processing when data changes.

Something notable that is not represented in the drawing above is a specific set of monkey patches from Trove we apply to NDB to create better hooks similar to the existing pre/post-put/delete hooks. These custom hooks power a “watcher” abstraction that provides targeted pieces of code the opportunity to react to changes in the data layer. Execution of each watcher is deferred and runs outside the scope of the request so as to not increase response times.

Latency

During our first year of scaling on App Engine we learned its performance is a complex thing to understand. Response time is a function of several factors both inside and outside our control. App Engine’s ability to “scale-out” is undeniable, but we have observed high variance in response times for a given request, even during periods with low load on the system. As a consequence we have learned to do a number of things to minimize the impact of latency variance:

Converting usage of the old datastore API to the new NDB API

Using NDB.tasklet coroutines as much as possible to enable parallelism during blocking RPC operations

Not indexing fields by default and adding an index only when we need it for a query

Carefully avoiding index hotspots by indexing fields with predictable values only when necessary (i.e. auto-now DateTime and enumerated “choices” String properties).

Materializing data views very aggressively so we can limit each request to the fewest datastore queries possible

This last point is obvious in the sense that naturally you get faster responses when you do less work. But we have taken pre-materializing views to an extreme level by denormalizing several aspects of our domain into read-optimized records. For example, the read-optimized version of a user’s profile record might contain standard profile information, plus privacy configuration, course enrollment information, course progress, and permissions -- all things a data modeler would normally want to store separately. We pile it together into the equivalent of a materialized view so we can fetch it all in one query.

Conclusion

App Engine is an amazingly complete and reliable platform that works astonishingly well for a huge number of use cases. It is very apparent the services and APIs have been designed by people who know how to scale web applications, and we feel lucky to have the opportunity to ride on the shoulders of such giants. It is trivial to whip together a proof-of-concept for almost any idea, and the subsequent work to scale your app is significantly less than if you had rolled your own infrastructure.

As with any platform, there are tradeoffs. The tradeoff with App Engine is that you get an amazing suite of scale-ready services at the cost of relentlessly optimizing to minimize latency spikes. This is an easy tradeoff for us because App Engine has served us well through several exciting usage spikes and there is no question the progress we have already made towards our mission is significantly more than if we were also building our own infrastructure. Like most choices in life, this choice can be boiled down to a bumper sticker:

Editor’s note: Chris Chew and Steve Huffman will be participating in a Google Developers Live Hangout tomorrow, Thursday, November 1st, check it out here and submit your questions for them to answer live on air.

-Contributed by Chris Chew, Senior Software Engineer, Udacity

Posted by Zafir Khan, Product Marketing Manager, Google App Engine

Developer Insights: Teaching thousands of students to program on Udacity with App Engine, Steve Huffman (part 1)

Tuesday, October 30, 2012

This post is the first of our two-part series discussing how Udacity uses Google App Engine.

Today’s guest blogger is Steve Huffman, founder of Reddit and Hipmunk. Steve recently taught a web development course at Udacity, which offers free online courses in programming and other subjects. Steve shares his experience using Google App Engine to teach the course.

This past spring I had the pleasure of teaching a course for Udacity, an online education company putting high quality college level courses online for free. I was recruited to Udacity by a former college professor and friend of mine, Dave Evans, Udacity's VP of Education.

When I was a Computer Science student at the University of Virginia, I was fortunate to take a cryptology course taught by Professor Evans. He presented us two ways to get an A in this course. We could either do it the old fashioned way--do well on tests and homeworks as well as completing a course-long project of our choosing; or, we could break into his computer and set our grade to an A. Naturally, we pretended to do the former, while spending our evenings huddled outside Professor Evans' house working on the latter. My team received A's.

It was one of the first times where I felt I was not just completing course objectives as a student, but thinking about real-world problems as a computer scientist. When Professor Evans emailed me early this year inquiring whether I’d be interested in teaching a course on Web Developement, I said, “Yes!” long before my brain had a chance to remind me that I already had a full-time job.

The course I taught was CS 253: Web Development, which aimed to teach students the fundamentals of building web applications. I’ve always wanted to teach-- it’s one of my favorite aspects of my job at Hipmunk. Web Development in particular is appealing because not only is it, in my opinion, the world’s most valuable profession, but even starting from scratch it doesn’t take much time to acquire the skills to build a site that can change the world. I wanted my course to leave students with such skills.

Choosing a platform for CS253

The course would be divided into seven one-hour lectures. After completing the seven lessons, students would have the skills to build a fully-functional blog platform from the ground-up, user accounts and all. I knew from experience that there is a dark side to web development: system administration. You can write all the fancy software you want that works on your own machine, but actually getting it online can be quite the pain. Where do you host it? Which database will you use? Do you know how to install such a database? Do you know how to configure a web server?

Learning the basics of web development in seven lessons was going to be challenging enough, I didn’t want students to have to deal with learning how to be system administrators at the same time. Fortunately, we decided in our first meeting that Google App Engine was the right tool for this course. Despite having never used it myself, the idea of it seemed to fit perfectly. Students would be able to write fully-functional web applications without having to deal with the tedium of installing web servers and databases, at least that was the plan. To be honest, I was a little skeptical at first, but I also didn’t have much of a choice--I wasn’t about to waste any time explaining how to get PosgreSQL running in Windows.

Reflections on App Engine

App Engine turned out to be one of the best decisions we made. Here are a couple of reasons why:

Write locally, deploy globally.
With App Engine, you can develop and run your application on your own machine, database and all, and with a simple command, deploy your application to Google’s servers and have it run identically on the Internet. When this worked for the first time for me, I was blown away. I’ve spent a significant, perhaps embarrassing, amount of time deploying code over the years. To see it happen in just a few seconds was astonishing.

Students being able to get their code running on the Internet with almost no hassle was one of the most important aspects of my course. First, it gave the students an immediate sense of power. After the first lesson, they would have their own code running live on the Internet! Second, it enabled a really nice mechanic of the course--each lesson would end with an assignment to add a feature to their live website. We could then grade these assignments in real-time. All the students had to do was submit a URL.

Excellent documentation.
App Engine’s documentation is superb. I tried to focus the majority of the course on high-level concepts common to all web development platforms; however, it was unavoidable that many parts of the course are specific to App Engine itself. For better or for worse, many of the App Engine concepts I taught I had learned only moments before. I got to know and appreciate that documentation very well. Even some of the more subtle concepts, like how the Datastore deals with replication lag, was all there and clearly explained.

The perfect level of abstraction.
A trap many beginner web developers fall into is starting with a very abstract web framework like Rails. While Rails enables a beginner to write simple apps quickly, and allows pros to appear to be wizards, it masks a lot of really important web concepts. App Engine sits at just the right level of abstraction for beginners and pros alike. I think it’s critically important to understand the difference between a GET and a POST, what HTTP headers look like, and how cookies work, for example. These aren’t difficult concepts, and having a deep understanding of them early will carry prospective developers far.

Auto-scaling.
While most of the students’ work in my course was probably used only by themselves and our grading scripts, we did spend a fair amount of time discussing how to design web applications that can support millions of users. Once you understand how to design an application that can run across many machines, App Engine will take care of the challenge of actually launching those machines when required and deploying your code seamlessly. Should the website I built during the course lessons, asciichan.com, ever hit the big time, I can rest assured App Engine will scale it with no effort from me.

Conclusion

Teaching CS 253 was a tremendous experience. To date, over 57,000 students have enrolled in the course! Check out some of the cool sites they built on App Engine after just seven lessons:

This is a project I’m incredibly proud of, and I’m deeply thankful to the folks at Udacity for giving me the opportunity. Furthermore, I’m grateful to Google and the App Engine team for building such a strong product. CS 253 could not have worked without it.

Editor’s note: Stay tuned tomorrow for the second post in this series by Chris Chew, one of the developers at Udacity. He’s going to explain how the Udacity team uses App Engine to power the courses themselves. Also, Steve and Chris will be participating in a Google Developers Live Hangout this Thursday, November 1st, check it out here and submit your questions for them to answer live on air.
-Contributed by Steve Huffman, Founder, Reddit and Hipmunk

Posted by Zafir Khan, Product Marketing Manager, Google App Engine

About today's App Engine outage

Friday, October 26, 2012

This morning we failed to live up to our promise, and Google App Engine applications experienced increased latencies and time-out errors.

We know you rely on App Engine to create applications that are easy to develop and manage without having to worry about downtime. App Engine is not supposed to go down, and our engineers work diligently to ensure that it doesn’t. However, from approximately 7:30 to 11:30 AM US/Pacific, about 50% of requests to App Engine applications failed.

Here’s what happened, from what we know today:

Summary

4:00 am - Load begins increasing on traffic routers in one of the App Engine datacenters.

6:10 am - The load on traffic routers in the affected datacenter passes our paging threshold.

6:30 am - We begin a global restart of the traffic routers to address the load in the affected datacenter.

7:30 am - The global restart plus additional load unexpectedly reduces the count of healthy traffic routers below the minimum required for reliable operation. This causes overload in the remaining traffic routers, spreading to all App Engine datacenters. Applications begin consistently experiencing elevated error rates and latencies.

8:28 am - google-appengine-downtime-notify@googlegroups.com is updated with notification that we are aware of the incident and working to repair it.

11:10 am - We determine that App Engine’s traffic routers are trapped in a cascading failure, and that we have no option other than to perform a full restart with gradual traffic ramp-up to return to service.

11:45 am - Traffic ramp-up completes, and App Engine returns to normal operation.

In response to this incident, we have increased our traffic routing capacity and adjusted our configuration to reduce the possibility of another cascading failure. Multiple projects have been in progress to allow us to further scale our traffic routers, reducing the likelihood of cascading failures in the future.

During this incident, no application data was lost and application behavior was restored without any manual intervention by developers. There is no need to make any code or configuration changes to your applications.

We will proactively issue credits to all paid applications for ten percent of their usage for the month of October to cover any SLA violations. This will appear on applications’ November bills. There is no need to take any action to receive this credit.

We apologize for this outage, and in particular for its duration and severity. Since launching the High Replication Datastore in January 2011, App Engine has not experienced a widespread system outage. We know that hundreds of thousands of developers rely on App Engine to provide a stable, scalable infrastructure for their applications, and we will continue to improve our systems and processes to live up to this expectation.

- Posted by Peter S. Magnusson, Engineering Director, Google App Engine

App Engine 1.7.3 Released

Tuesday, October 23, 2012

For our October release we have a number of offerings, fixes, and small refinements as colorful as the fall season.
General Enhancements

Django 1.4 is now fully supported for Python 2.7

Java classloading priority can now be granted to specific JAR files. This is an experimental feature. More information can be found here.

App Engine SDK support for Java 7
With Java 7, many new language enhancements have been added, including:

The ability to use the String class in Switch statements

Expression of binary literals using simple prefixes 0b or 0B

Single catch blocks that can handle multiple exceptions

Improved type inference for generic instance creation

Auto closing of resources when enclosed within a try-with-resources statement

Simplified varargs method invocation

We’re happy to announce that as of this release the App Engine Java SDK has support for running and testing your applications using a local Java 7 installation. To get started now, developers should download the latest App Engine Java SDK and a Java SE 7 or JDK 7 distribution. From there they can follow the existing documentation for running and testing applications locally.
In an upcoming release, we will be including some of the new Java 7 functionality as well as formal Java 7 support within the App Engine Java runtime. Before this is available, we strongly encourage developers to start testing their applications using Java 7 and the latest App Engine Java SDK.
And while Java 7 support is not yet available within the App Engine Java runtime, developers interested in an early preview can sign up for our trusted tester program.
Want more information?
The complete list of features and bug fixes for 1.7.3 can be found in our release notes. For App Engine coding questions and answers check us out on Stack Overflow, and for general discussion and feedback, find us on our Google Group.

- Posted by the Google App Engine Team

Developer Insights: Building scalable social games on App Engine

Thursday, October 18, 2012

Today’s guest blogger is Hernan Liendo, CTO of Zupcat, developer of social games played by millions of people worldwide. Hernan shares his team’s experience using App Engine to build RaceTown, a multiplayer racing game.

Choosing a cloud service provider

RaceTown is one of Zupcat’s most popular games; it has almost 900,000 monthly unique users, opens more than 40,000 connections via the Channel API per day, processes more than 15,000 queries per second and delivers terabytes of content everyday. When deciding our architecture, we took into account several unique requirements of social games:

High uptime

Short loading time

Flexibility to deal with social network API changes

Ability to manage thousands of players, concurrently, from all over the world

Adjustment to capabilities and performance issues on different users’ computers

Ability to measure user actions to constantly improve the user experience

Hosting and delivering quality, beautiful game art

Complex game domains and algorithms: such as enemy adaptable performance, path finding, and 2D and 3D rendering

App Engine addresses these complicated issues. It provides few tracerouting hops from almost anywhere in the world, great uptime, automatic scalability, no need for infrastructure monitoring and a reasonable price for content delivery.

Implementing App Engine

The diagram above shows a simplified view of our game architecture. We’ve discovered that App Engine is good to use not only as a game backend server, but also as a metrics server and content delivery network. In addition, we periodically synchronize game state and retrieve data to and from the server.

The App Engine Datastore is great because it has high availability and easily handles hundreds of millions of rows of data, which is important for social games. For example, we can easily scan the Datastore to present high score information and gamer stats to the user. Additionally, because gamers tend to spend lot of time during a game session, we’ve found it’s helpful to cache game data. Using Memcache, we have significantly reduced Datastore API calls and lowered users’ waiting time.

Another tip for App Engine developers - although App Engine API failures are uncommon, you must be sure to write proper retrying code to minimize the possibility of exposing users to an application crash. RaceTown performs almost a hundred million operations daily, and proper client side retrying algorithms have enabled us to reduce failure rates to very low levels.

Final thoughts

I believe that today there is no technology that matches App Engine. You can run your code and store your data in the very same servers that Google uses. Migrating your applications to this technology means you have to start thinking in a cloud-centric way and reinvent your architecture to stop working inside a relational database and classic clustered web server.

If you can achieve this, your products will be delivered using the same infrastructure that Google uses, without a huge corporate budget!

- Contributed by Hernan Liendo, @hernanliendo of Zupat, @zupcat

Google Cloud Platform Blog

Mobile voucher sales terminal in Africa powered by App Engine

App Engine 1.7.4 Released

Get started at no cost with a faster, larger Google Cloud SQL database

Upgrading to Python 2.7: simple and practical

Developer Insights: Teaching thousands of students to program on Udacity with App Engine (part 2)

Developer Insights: Teaching thousands of students to program on Udacity with App Engine, Steve Huffman (part 1)

About today's App Engine outage

App Engine 1.7.3 Released

Developer Insights: Building scalable social games on App Engine

Don't Miss Next '17

Free Trial

GCP Blogs

Labels

Archive

Feed

Subscribe by email

Company-wide

Products

Developers