Enabling Google App Engine to run in the Private Cloud with CapeDwarf

We hear consistently from developers that they want to see more portability of their apps when working in the cloud.  The Google Cloud Platform team has been collaborating with the Redhat/JBoss Application Server team to help them provide an alternate implementation of Google App Engine running on top of JBoss to facilitate portability and openness.



The bulk of the collaborative work between Google and Redhat is really around the open source Test Compatibility Kit (TCK) project:

Google engineers provided many of the tests of the internal App Engine product, and RedHat engineers added many tests to verify that their implementation of App Engine is correct. These collections of tests have been tested against a local App Engine SDK, a CapeDwarf implementation, and the real Google App Engine running in the Google cloud.



In my previous life in the Java Enterprise, portability across different application servers was a very important feature. But it was never 100% achievable due to lack of some specifications (how do you specify load balancing, auto-scalability, NOSQL access or even simple APIs like caching). Compliance certification was done via a reference implementation (RI) and a Test Compatibility Kit.



Why is providing an App Engine TCK in the open source so important? A few reasons:



First reason: JBoss is one of the key leaders in the Java EE API specification and implementation: JPA, CDI, Beans validation, JAX-RS. JBoss working on implementing Google App Engine on top of their existing APIs helps customers address portability and testing concerns and helps validate our approach.



Second reason: If you are considering using App Engine but have had technical or business constraints for making the move to Google Cloud Platform, you now can when using CapeDwarf on your private cloud (or even private machine), on OpenShift or Google Compute Engine.



Third reason: If you are an existing Java EE JBoss customer, but are looking for easier and more “cloud ready” APIs than Java EE, you can start discovering the simplicity of App Engine APIs. The DNA for these APIs is not from Java EE, it is from the cloud.



Accessing the Datastore is as simple as writing:

DatastoreService ds = DatastoreServiceFactory.getDatastoreService();

No more non portable resource definition, funky XML files or command line tools, JNDI configuration and injection. An App Engine application comes with a complete runtime environment: a datastore, a user service, a mail service, a task queue system, a blob service, a chat service, and more.

An App Engine application does not need to specify load balancing parameters, autoscaling rules, failover across data center settings, replication configuration. It just works and scales automatically.



Fourth reason: If you are an App Engine customer and you love the App Engine APIs, but would like to deploy a new App Engine application on your private farm of servers, you now can with CapeDwarf.



Google has always been committed to the open web.  We are looking forward to moving these tests to open source.  But, of course, we know this is a two way street - we would love for you to provide new tests to us and the community so we can all grow together and improve our applications.  Adding such customer centric tests in the open source TCK would help provide a quick turn around (nobody wants to see a failing TCK build), and also help prevent future App Engine versions (we release the product once a month) from breaking customer tests.



Check it out for yourself: get the TCK code, run the tests and contribute new tests that match your App Engine Application, we are open!





-Posted by Ludovic Champenois, Software Engineer