So, you’re a Java developer who’s sold on the idea of deploying your next app on the cloud. First order of business is likely to check out to see if that PaaS your friends have been recommending can actually support your framework and the either common, obscure or cutting edge features your app makes use of. For many of you, the follow up question will likely be: “How easy will it be to get my app running on this PaaS and how painful will it be to get off it if things go South?” In this blog post let’s quickly work through this scenario when decided whether to deploy your Java app on Google App Engine or OpenShift.
JPA & RDBMS: The Java Persistence API provides developers with a framework for managing relational data in applications. This is a critical piece for developing Java applications because it provides the bridge between the RDBMS and code. JPA is almost mandatory on Java web applications and the most popular implementation of the JPA specification is Hibernate. GAE supports DataNucleus as opposed to Hibernate. Since both projects are implementations of JPA this shouldn’t necessarily prevent you from doing what you need with GAE.
Where things get complicated is when you introduce an RDBMS. The database support that comes out of the box with GAE is based on Big Table. This is great if you already use Big Table as your datastore. But I’m guessing you don’t – you more than likely use MySQL or one of those shiny new NoSQL datastores like MongoDB. You could go through the process of migrating your application to work on GAE’s datastore, but why would you want to go through that process? Doing that migration further ties your application to Google and reduces your portability. You could connect to a remote datastore hosted out on Amazon but then you suffer the latency problem.
OpenShift supports JPA/Hibernate out of the box. If you’re developing your application with a MySQL backend, cloud deployment should be a snap. In fact, OpenShift supports MySQL out of the box as well so not only do you get the JPA you want, you also get a database with low latency. What this means for application deployment is that you don’t have to go to two places to deploy a Java application that uses a MySQL backend.
Both GAE and OpensShift support Seam. The biggest difference is that OpenShift supports it out of the box without any tooling. In order to get Seam working on GAE, some arguably ugly workarounds are necessary. I’ll leave it up to you to determine if the workarounds are worth it but my opinion is that running a Seam application on GAE is akin to trying to fit a square peg into a round hole. More information on the workarounds required can be found here.
Observations: If you are looking for a Platform-as-a-Service to make your cloud deployments as seam(no pun intended)less as possible, my advice is to do your homework, run some experiments, and try not to bend your application to the PaaS. For more information about what will and will not run on GAE, you can review the list here.
On OpenShift, we have gone to great lengths to ensure that users don’t have to change to run on our platform. As an open source company, we want the technologies to shine through and we want the integration points to be built on open standards. We think that helps the user’s transition to the cloud and it reduces their risk of being locked in to a proprietary solution. That openness makes us work harder to ensure we are delivering value each day or risk a user moving to another solution. However, we believe in this approach and built our offerings that way since that is what we would want as developers.
Check out Issac ‘PaaS Master’ Roth’s blog where he takes a deeper dive into the importance of avoiding lock-in when making technology choices, especially in the cloud.
Other helpful resources for consideration: