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...
Angular 3 will have better tooling and will generate less code; Google also is promising a new major...
With recurring and new problems in spades, Win10 Anniversary Update is still not ready for prime time
A convoluted user interface and crippled mobile features limit the conferencing tools' utility, but...
Google's co-founder admits he didn't pay attention to AI in the 1990s because he didn't think it would...
The challenge: AWS, Google, Microsoft, and IBM own the market, enterprises want to drop Oracle...
Ransomware has become the scourge of the internet 28 years after it first appeared. Here's how to...