There are also a number of restrictions on the classes you can use. Google's version of the JVM isn't fully stocked. You won't be able to spin off a thread to handle processing and you can't write to the disk -- ever. You have to use Google's data store if you want to save the data.
All of these changes have some advantages. Google's data store is stripped down and optimized for working with many machines at once. The Memcache service saves calls to the data store -- something to be wary about because the meter is clicking whenever your servlet is churning. The image processing tool handles some of the work with native code, another advantage.
For all of these reasons, I think App Engine will be most attractive to projects that need to give people shared access to several big tables filled with data. It's not really for all Java programmers, but for people who are familiar with Java and like to use it to write some glue code to wrap around a big table. You can't do too much to the data on the way in or the way out because there are limits on the amount of time that each request can spin the meter.
I think these restrictions will mean that there will be relatively few applications that just pick up and migrate to the App Engine. All of the data access will need to be rewritten and some of the common tricks that use flat files will need to be re-engineered. Moving your application out of the App Engine will probably be a bit easier, but it will require changing your mindset because the App Engine used to handle some of the scaling and synchronization issues for you. It may be technically possible to run the App Engine debugging environment on your own server, but the Terms of Service say Google is giving you a license for the "sole purpose of enabling you to use and enjoy the benefit of the Service as provided by Google, in the manner permitted by the Terms."
Google is well aware of this issue and is trying to address it as it encourages people to use the system. IBM is even offering tips on how to migrate App Engine code to its platform. It's just a matter of getting the JDO (Java Data Objects) calls to talk with IBM's DB2 instead of Google's back end. I'm guessing that IBM hopes to grab customers who build the first rev in App Engine and then decide that some threading or slow cron jobs are absolutely necessary.
I built several JSPs that deliberately sucked down a large amount of computation time, and it was pretty easy to push them hard enough to reach the limit. I don't think most Web 2.0 applications will run up against Google's CPU and memory limits, which are liberal from the standpoint of the typical Web application, but they could be a problem for anyone that wants to do much heavy processing. The image toolkit, for instance, will only work with images smaller than 1MB -- something that's a bit tight for serious photographers. My pocket camera, for instance, can turn out images that take up 4MB.
These limits might squeeze an application in unexpected ways. cron jobs are just URLs that are called at set times. That's a nice abstraction but it's definitely a bad fit for some of the massive reports that corporations generate every evening. It's more for housekeeping than any kind of asynchronous heavy lifting.
You may still be better off sticking with Win7 or Win8.1, given the wide range of ongoing Win10...
Early results look promising: the many-hours-long Win7 waits may be behind us
Now that we're down to the wire, many upgraders report that the installer hangs. If this happens to...
Google Cloud SQL performance may beat Amazon Aurora at low thread counts, but Aurora owns the high end
Translation is not a detail you add to a SharePoint site after deployment, especially because the tools...
Taking a page from its push for hybrid Azure clouds, Microsoft suggests cloud-enhanced versions of SQL...
Budget cutbacks, overworked employees, and out-of-date systems lead to a middle-of-the-night emergency...