Skip to main content

Heroku Java Support: Simple? or Simplistic?

Posted by jjviana on August 29, 2011 at 12:58 PM PDT

Heroku, the PaaS cloud owned by salesforce.com, announced a few days ago support for the Java language. In the process they declared Java EE to be irrelevant in the cloud world. Is that so?

I try to embrace anything that helps me develop, test or deploy code faster. Cloud Computing has the potential to bring radical improvements to all these areas, hence I have been following its developments closely over the last couple of years.

Cloud platforms come in different flavours, the main ones being IaaS (Infrastructure as a Service) an PaaS (Platform as a Service). IaaS clouds, like Amazon EC2 or Rackspace Cloud, provide infrastructure building blocks (CPUs, storage space, ip addresses, firewalls, etc.) in a programatic way. In a way, they transform infrastructure in code. You can then lay the software stack you need over these building blocks: operating systems, databases,virtual machines, programming languages etc. Lots of decisions to make.

PaaS clouds, like Google AppEngine or Heroku, would like to make some of these decisions for you.They restrict the menu of available stack components to a few supported configurations. In return, they relief you from the burden of having to manage these components. You stop thinking about "servers" and think instead about "applications" , "components" or other logical deployment units.

I am a big fan of IaaS clouds, but have yet to be convinced of the usefulness of PaaS. Take Heroku for example: their announcement about Java support revolves around the revolutionary idea of embedding Jetty inside your application so that your web application contains the web server, and not the other way around. They go to some lengths in criticizing Java EE for its complexity and to show how this containerless approach is going to make your life easier.

The problem is, this approach is not new: I have personally written applications using this architecture for a while now, going as far back as 2002. The idea of going containerless has a certain lure, but as the application grows  you start to realize its drawbacks. The moment you need a connection pool, or  transaction control, or manageability, or security, you start to recreate the container inside your application, one third-party library at a time. Fast forward a few releases and now your application is a collection of 150Mb of conflicting jar files.You have recreated something like the Java EE container inside your application, at a great cost and zero standardization.

PaaS vendors: as a User, I don´t want my platform to be simple, I want it to make my life simpler. These are different goals.

Simple != Simplistic.

 

 

 

Related Topics >>

Comments

Funny -- the pot calling the kettle black :-). It seems to ...

Funny -- the pot calling the kettle black :-). It seems to me that PaaS is yet to have much relevence to server-side Java :-). The same goes for supposed Spring "simplicity" as compared to Java EE :-).

Hmm... with the premise that whenever a service vendor ...

Hmm... with the premise that whenever a service vendor quickly dismisses something else's technology as irrelevant I get annoyed, I must say that the scenario is interesting.

Some time ago I would totally agree with you. Today I'm puzzled and probably very soon I won't agree. Or probably it's the matter to better define the context.

The moment you need a connection pool, or  transaction control, or manageability, or security, you start to recreate the container inside your application, one third-party library at a time.

You don't need to reinvent this stuff, as e.g. Spring provides all what you need. For small applications, you're effectively going simpler if you don't put into your project what you don't need.

Fast forward a few releases and now your application is a collection of 150Mb of conflicting jar files. You have recreated something like the Java EE container inside your application, at a great cost and zero standardization.

True (apart from the "zero standardization" with isn't true if you go the Spring way). Summing up, this to me means that there are situations in which Heroku-like approach makes sense, and a threshold in which you start to lose the advantage, and Java EE is a viable approach.

Giving that IT is spreading and there are more and more simple webapps, in addition to the old, corporate-style ones, I think that Oracle should really care of this, anyway.

Hi Fabrizio, Spring is nice, but its not really a ...

Hi Fabrizio,

Spring is nice, but its not really a standard...Currently it is a VMWare product. You can pick and choose what you need from it, but the problem is evolution - as I said, as the application grows it becomes more and more bloated with third-party dependencies that implement common services. I have had sutiations where one third-party framework would depend upon a specific version of a library (like ASM) and another one would require a newer version of the same library, which would then bring on its own set of dependencies... commonly known as Classpath Hell.

Maybe the situation is different for web applications - but Java EE has already acknowledged this fact in the form of the Web Profile, aimed at simpler applications. And I have difficulty separating Web Applications from Enterprise Applications: in my experience most Enterprise applications are born as Web Applications that over time become central to the business. Where does one draw the line?

 

It's not a standard as a specification, but it's a set of ...

It's not a standard as a specification, but it's a set of standard knowledge. I mean, if people want to do transactions with Spring, there's a small set of "standard" ways to do that in Spring.

The classpath hell can be a problem, right. It's when the application grows up in complexity. As I said, it makes sense that the gap between the "simpler" approach of Spring and Java EE shrinks to zero for complex applications. But there is a growing room for simpler applications around.

small typo:  "this approach is now new" ...

small typo:
"this approach is now new" => " this approach is not new" (somehow I make that mistake often myself)
I think it's hard to disagree with you about the services that eventually every PaaS service will need to offer.
I suppose the debate is more around the programing model and I'm hoping that we can still work with Heroku on Java EE (after all they've dismissed J2EE, an ancient technology :)

Thanks for the tip! Thats what you get when you try to write ...

Thanks for the tip! Thats what you get when you try to write too fast :)

 

 

Hi Juliano. Note that there's nothing named ...

Hi Juliano.

Note that there's nothing named "JEE". You probably meant "Java EE".

Bill Shannon

Java EE Spec Lead

http://www.java.com/en/about/brand/naming.jsp
http://www.theserverside.com/news/thread.tss?thread_id=35561

Hi Juliano. Note that there's nothing named ...

Thanks for the tip!

Fixed.