Heroku Java Support: Simple? or Simplistic?
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.