Cloud Zone is brought to you in partnership with:

EXECUTIVE SUMMARY Craig S. Dickson is a software development professional with over 15 years of experience. He has proven leadership experience in both domestic and multi-national start-up and Fortune 500 corporations in the United States, Australia and Europe. Craig specializes in enterprise Java development and cloud architecture and holds multiple certifications including Sun Certified Architect for JavaEE and Certified Scrummaster. Craig brings specific expertise in enterprise software architecture and design, refining development processes and building development teams around Agile software engineering principles. Educated in Australia, Craig holds a BSc(Hons) in Computer Science. He is based in Huntington Beach, CA, and Brisbane, Australia. SPECIALTIES Enterprise Java - Software Development Best Practices - Software Development Team Leadership - Cloud Computing Craig is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

Heroku vs. OpenShift - The Battle of the JavaEE FUD

08.15.2012
| 10360 views |
  • submit to reddit

Curator's Note: The following article was originally written in August of 2011. Let us know your thoughts by commenting below!

On the same day that Heroku announced its new support for Java-based applications, it also curiously posted a laundry list of FUD about the platform. Don’t get me wrong, I share some of Heroku’s complaints, but calling out the shortcomings of the platform by linking to documentation related to obsolete versions did not help give Heroku’s arguments credence. Last I checked, the Jetty server, which Heroku’s Java platform is based on, quite clearly states that it is a Java Servlet container, and the Java Servlet specification is part of the JavaEE family of specs. So the specs that Heroku derided are in fact the same specs that their product is running on a subset of. Interesting tactic.

Of course, the team with its OpenShift platform (that does in fact support a full JavaEE stack) managed to take the Heroku post personally and responded in a less-than-dignified fashion. Why RedHat felt they needed to respond at all is the first question that comes to mind. The Heroku post does not call them out by name. The level of animosity in the Redhat response makes me wonder if there is bad blood between these teams.

Personally, I have real concerns about Heroku’s model of non-conformance to the JavaEE specifications. There is a wealth of knowledge and code out there based on those specs (irregardless of how flawed they may be), so expecting people to do some heavy lifting to port their existing standard Java code to run on your platform is a big ask. The tools out there (from IDEs to builders like and Ant to CI environments like ) are entrenched in every team and on every developer’s box. Where do you even get Java Heroku developers? Now, you could argue that Heroku’s model is not that different from standard JavaEE, but it being different at all is the problem. As one commenter on Heroku’s post said, “Any reason you didn’t simply allow for uploading of a .war?“ Precisely.

OpenShift has its own set of issues as well, though. I cannot recall the last time I worked on a project that actually required a full JavaEE stack. I don’t think I have a or WebLogic environment on any computer I own (And I definitely don’t have WebSphere. That’s for sure.). What I do have is about 3 different versions of with multiple applications deployed on each. I also have a couple of packaged pieces of software installed that actually run Jetty internally. Perhaps it’s just the kinds of projects I work on, but I suspect I am most likely in the majority — and even more so if you look at all the Java apps deployed on full JavaEE stacks that could be deployed into a servlet container with no code changes. Arguing that a full JavaEE stack is an essential and technically superior solution when you are a vendor of such a stack (i.e., JBoss) doesn’t really give your argument much objective weight.

So, JavaEE is not what it was even five years ago. It has noticeably improved via evolving in a variety of ways, one of the biggest ways being this: It has watched what the community does to work around the JavaEE shortcomings (see Hibernate, etc.).

That said, a full JavaEE stack is not the answer to every problem, maybe not even a majority of problems.

As with most things in life, the middle ground is probably where the truth will be found. A non-standard Java platform is probably not the right answer, but then again a full JavaEE stack is probably not, either. In my honest opinion, the sweet spot in the Java space is where the vendors allow developers to work as they did before, allowing them to use the tools they know, the development workflow they know, and the architecture they know. Based on that, I think Amazon’s Elastic Beanstalk and CloudBees RUN@Cloud are probably on the right track.

 

Published at DZone with permission of Craig Dickson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Reza Rahman replied on Wed, 2012/08/15 - 11:50am

Less than dignified, perhaps. Or perhaps trying to sell one's wares by attempting to trash random/competing solutions using 10 year old information instead of simply sticking to pointing out the strengths of your own solution is entirely deserving of such a response. Personally, I've developed using Java EE 5 and Java EE 6 for years now (albeit with great add-ons like Arquillian, Seam and CODI), have little complaints and see OpenShift as being much better because it offers the choice of using any Java EE API you like (or not).

Daniel Serodio replied on Wed, 2012/08/15 - 12:28pm

Of course there's a reason for not allowing upload of plain WAR files: vendor lock-in!

Chris Haddad replied on Mon, 2012/08/27 - 2:09pm

The statement " the sweet spot in the Java PaaS space is where the vendors allow developers to work as they did before, allowing them to use the tools they know, the development workflow they know, and the architecture they know."  rings true. 

 

WSO2 Stratos (http://wso2.com/cloud/stratos/ )  provides a Tomcat compatible Java container tuned for the Cloud.   Multi-tenancy is built into the server by using a custom OSGI-base security model and class loader.   Developers don't have to wrestle with a full JavaEE stack, have their choice of application frameworks,  and gain access to a complete set of application platform services.  

 

For a PaaS comparison and scorecard, review our Selecting a Cloud Platform white paper.

http://wso2.com/whitepapers/selecting-a-cloud-platform/

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.