It is still in beta but select developers are being added and developers allowed in will be expanded, I got in as I made the request so it looks like it is still filling up.
Both Java and C# were top requests on AppEngine desired languages/platforms. They have low level support for specific Google features and infrastructure and wrappers around these features to mimic common java libraries like JPA, JCache and java.net around google urlfetch. So it is still a bit locked to the platform or changes will need to be made to run on Google AppEngine and other environments.
Many of the changes made to apps really are due to the scalable nature of the cloud architecture without such things as joins and limits on bulk processing, but in the end these points are really better for scalability from the start. As for being locked to a platform we are already seeing copies such as AppScale that is an open source implementation of Google AppEngine. So software architecture, data architecture and how we prepare for the terabytes upon terabytes of shared data in the future might be changing.
Some unsupported features of major Java libraries…
java.net Features Not Supported
The URL Fetch service does not support persistent HTTP connections. When the app accesses response data using the URLConnection object, App Engine calls the URL Fetch service to complete the request. After the response data has been accessed, the request data cannot be modified.
The app cannot set explicit connection timeouts for the request.
Unsupported Features of JPA
The following features of the JPA interface are not supported by the App Engine implementation:
Owned many-to-many relationships, and unowned relationships. You can implement unowned relationships using explicit Key values, though type checking is not enforced in the API.
“Join” queries. You cannot use a field of a child entity in a filter when performing a query on the parent kind. Note that you can test the parent’s relationship field directly in query using a key.
Polymorphic queries. You cannot perform a query of a class to get instances of a subclass. Each class is represented by a separate entity kind in the datastore.
JCache Features Not Supported
The JCache listener API is partially supported for listeners that can execute during the processing of a app’s API call, such as for onPut and onRemove listeners. Listeners that require background processing, like onEvict, are not supported.
An app can test whether the cache contains a given key, but it cannot test whether the cache contains a given value (containsValue() is not supported).
An app cannot dump the contents of the cache’s keys or values.
An app cannot manually reset cache statistics.
Asynchronous cache loading is not supported.
The put() method does not return the previous known value for a key. It always returns null.
High Level Cloud Provider or Low Level Cloud Provider?
With other cloud providers like Amazon EC2, Mosso, SliceHost and others you can choose your platform. But Google has an amaxing infrasturcture and taking advantage of BigTable and automatic scaling is nice expecially with a 300MB transfer free quota per app. There are probably times when each type of provider might be beneficial, lower level like Amazon or higher level like Google AppEngine.
Cloud based architectures I believe will be more mainstream and used for development even if on self-hosted environments because the data architecture is setup for maximum horizontal scalability from the beginning. BigTable, SimpleDB, HBase, even couchDb type databases will become more prevalent as we move into terabytes and terabytes of data. Data is growing at an alarming rate and this is a natural software evolution to address that.
Google AppEngine is finally allowing applications to go beyond the quotas. Mainly the 500 GB transfer limit was the killer because you hit a brick wall if your app was popular, unless you got a special quota which was the case on some apps helping to promote GAE. Now, to help highlight the cloud scale rather than look like a small beans hosting account with limits, it will go beyond the quotas. Of course,you will have to pay beyond that.
The pricing for space beyond the free quotas is fairly decent. About the numbers that were put out earlier around .10 to .15 a GB.
Making the limits larger with a pay version is great for many reasons. First for Google shareholders and most of all developers that want to develop real applications and services on GAE without the fear of hitting the brick wall when the quotas are up. But now that wall is a payment. I was hoping they would lift the quotas a bit more before they rolled in pricing, instead they lowered the quotas…
The pricing for resources beyond those free quotas is:
$0.10 per CPU core hour. This covers the actual CPU time an application uses to process a given request, as well as the CPU used for any Datastore usage.
$0.10 per GB bandwidth incoming, $0.12 per GB bandwidth outgoing. This covers traffic directly to/from users, traffic between the app and any external servers accessed using the URLFetch API, and data sent via the Email API.
$0.15 per GB of data stored by the application per month.
$0.0001 per email recipient for emails sent by the application
The big bummer in all this is the comment that they are reducing the free quotas:
App Engine remains free to get started. However, along with many performance improvements over the past ten months, we’ve learned that we overestimated our initial free quota values. Therefore, in 90 days we will be reducing the free quota resources. We believe these new levels will continue to support a reasonably efficient application serving around 5 million page views per month, completely free.
The free quota on transfer rate is currently 500GB but will go down to approx 300GB transfer. This will probably support a 2-5m request app monthly but the old quotas were almost double that. So it may change some economics that were being planned for GAE. Let’s hope the free quotas only go up like gmail from now on.
Now we just need full support for full text search, which will become the Google feature benefit I believe, hopefully soon.
Great video from Google on building for scale in Google AppEngine. The cloud by nature gives you upwards scaling easily but the data structures and techniques to get data efficiently is much different than RDBMS type optimization. Therefore the more experience and information you can gain on this topic will help you in the future when terabytes of data is the norm.
They have remove limits on high CPU calls, raised the request timeout to 30 seconds, and raised the per file limit to 10MB!
Now we just need it to get out of beta in some format for getting clients loaded up on it.
We’re very excited today to announce that we’ve raised limits on several App Engine operations:
No more “High CPU Requests”! App Engine Apps were once allowed no more than 2 CPU-intensive requests per minute. We’ve made some adjustments to the way we handle requests, and have eliminated this limitation altogether. To learn more about how this works and the implications for your app, see our documentation.
Response deadline raised to 30 seconds. The amount of time an App Engine app can take to respond to an incoming request has been raised from 10 to 30 seconds! There are limits on the number of simultaneous active requests an application can process at any given moment–see our docs to learn more.
Size limits on code files, static files, and requests/responses raised to 10MB! App Engine apps can now receive requests and send responses of up to 10MB in size, and users can upload 10MB code and static files as well. Note that API requests (e.g. memcache.set(), db.put()) are still limited to 1MB in size.
I have been saying for some time that cloud based offerings with great tools will win out. Making it simple to setup and manage cloud tools, with tools and hopefully APIs to the tools so that these can be aggreated, will win over hosting clients and be a value add for the cloud providers of today Google App Engine, Amazon AWS, Mosso, Joyent, SliceHost etc.
Today we’re announcing the availability of the Web-based AWS Management Console, which in this first release provides management of your Amazon EC2 environment via a point-and-click interface. A number of management tools already exist: for example a popular Firefox extension known as Elasticfox; however as you read more of this post I believe you’ll agree that the new console is compelling–especially when it’s time to log in as a new AWS developer.
Microsoft launched the Azure cloud based platform at the PDC today. Microsoft has launched many file storage services that were their cloud offerings to date in Mesh, Foldershare, Groove and more. Azure is what appears to be a real cloud platform to compete with Amazon and Google rather than just storage hosting.
Build new applications in the cloud – or use interoperable services that run on Microsoft infrastructure to extend and enhance your existing applications. You choose what’s right for you.
It appears so far that it is pretty Microsoft centric for tool support. Of course the software and servers will be Windows. This week and last, Microsoft platforms have made their way into the cloud platforms at Amazon and now Microsoft. Google also recently announced the support of Java. Another set of aquisitions at Rackspace in the buying of Slicehost and JungleDisk also seem to show the space heating up and the companies all believing in the cloud platform emergence and evolution that seems to be happening.
Amazon EC2 is officially out of beta, it is about time some of these services actually launched. It is hard to convince people to use the cloud layer without being out of beta (AppEngine when’s it gonna happen huh?).
Amazon also launches with windows support, SQL Server support and much more. This is great news in times where budgets are tight and people want to start scalable businesses but want to only pay for what is used. The cloud layer will be a very attractive option to many.
Learn more about the Elastic Computing Cloud (EC2) at Amazon. There are already lots of great simple toos like ElasticFox (Firefox EC2 Extension) to help manage your AMIs from a browser. You can start and stop armies of configured servers from a little extension in your browser.
Developers are getting many tools to build great things. We hope more products are out of beta soon like AppEngine.
Google AppEngine is alot of fun, not only is it a good excuse to use Python but it is a touch of the future and lots of possibilities for programmers and engineers from all sized businesses to use. When they opened the gates I was one of the lucky 10,000 to get in. So what did I do, I setup three apps before I even knew that was the limit. Then I was stuck. Well today you now have up to 10 apps that you can run on appspot or your own domain. Make sure to update your SDK.
Next question is, when are they going to launch this out of beta? I want to start using it for business.
We’re happy to announce we’ve released some small updates to Google App Engine. Among the more significant changes:
More apps: Want to create more than 3 applications with your App Engine account? Now you can now create up to 10!
Time windows for Dashboard graphs: Zoom in on the data in your dashboard to get a more accurate picture of whats going on. You can zoom in to see graphs for the last 24, 12, and 6 hour periods.
Logs export: You can now use appcfg.py to download your application’s logs in plaintext format. Use appcfg.py –help for more information on how to download your logs.
Send email as logged in user: If you’re using the users API, you can now send email from the email address of the currently-logged-in user.
Be sure to update your SDK and check the release notes for a full list of changes. Have more changes you’d like to see with App Engine? Let us know in our Google Group!
CloudFS is new, untested but a bit cheaper than Amazon Simple Storage Service (S3). This is where mainly ‘buckets’ of data of any content type can be stored and retrieved by a unique key across all resources. This is useful for image, content and media hosting and charges by the GB usually less than .15 cents per GB.
About CloudFS
Scalable, dynamic storage. Use as much or little as you want and only pay for what you use.
Straightforward, basic design offering one level of containers (non-nested) for your data.
Per-account container and file namespace (not a global namespace as with other systems).
Store files as small as a few bytes or as large as 5GB.
Add additional metadata along with each file you store.
Google AppEngine now runs Python AND Java
Amazon EC2 is officially out of beta
