
Heroku for Java - adamwiggins
http://blog.heroku.com/archives/2011/8/25/java/
======
typicalrunt
If they supported git pushing a war file, then I wonder what the performance
improvements would be with Warble-ing a RoR app and running it on a JVM?

 _Edit_ Oh wait, they already did. But not using a WAR file it seems.

 _For example, JRuby is one of the most frequently-requested languages on
Heroku. Matthew Rodley has already put a Rails app onto JRuby on Heroku by
adding JRuby to pom.xml. Scala, another common request, could be done the same
way. We do look forward to being able to offer the same kind of first-class
support for JRuby and Scala that we offer for Clojure; but in the meantime,
bootstrapping via Java is a reasonable strategy._

Now if we could just get some performance comparisons between the Ruby and
Java platforms on Heroku... pretty please?

~~~
khaless
I'll hook something together this weekend in terms of a benchmark. The nice
thing with JRuby is you get the concurrency features of the runtime.

~~~
jshen
a lot of ruby code isn't threadsafe. I'm pretty sure rails isn't.

~~~
atambo
Rails is threadsafe if you turn it on by uncommenting config.threadsafe! in
your environment initializer.

~~~
jshen
That's not what I mean. That will make it run with concurrent threads per
request. However, I'm fairly certain it isn't threadsafe.

Somewhere around 3.0.6 I made a simple jruby rails app and a sinatra app. They
were both a thin REST layer over data in mongodb (No AR). I did load testing
and the sinatra app ran fine, the rails app would fail on about 7% of requests
with seemingly random stack traces. When I reran the tests with
config.threadsafe! turned OFF it never failed.

Also, on Bob Lee's OSCON talk he mentioned some unthreadsafe code in AR that
he found.

<http://www.oscon.com/oscon2011/public/schedule/detail/21092>

~~~
atambo
I've had good experiences with several jruby on rails apps under tomcat using
warbler and they all seem to perform fine with config.threadsafe! enabled. You
should probably investigate those stacktraces, maybe they were caused by
unthreadsafe gems or application code?

~~~
jshen
It would fail without using any gems other than trinidad. I'll try to
reproduce it tomorrow.

------
Lewisham
Wonderful news. Heroku keeps going from strength to strength. I know a lot of
people who'll be interested in this... I'm very pleased that Scala is
deployable.

Awesome.

------
sriramk
You do have to wonder what the moves of the last few weeks mean for DotCloud.
With Heroku launching support for many non-RoR languages and CloudFoundry
being adopted by other PaaS players, you have to wonder whether small players
like DotCloud are going to get squeezed out.

~~~
gfodor
As far as I understood it, it's apples and oranges. DotCloud provides specific
services, for example, running a Solr cluster, which is a higher level of
abstraction really than providing support for a specific programming language.

~~~
r00fus
I don't. Besides Heroku is supported by salesforce.com, so there's at least
some longevity and synergy between the two.

Also, not all PaaS players will commoditize over the same feature-set. Example
in point, Heroku's Java support doesn't allow you to put a .war file up like
you can do in Amazon's Elastic Beanstalk.

------
arkitaip
Here's hoping that the next language will be Python.

~~~
chedigitz
Python seems to be working on Heroku already, not sure if its officially
supported. <https://gist.github.com/1004844>

until then there's a good list for django [http://www.quora.com/What-is-the-
Heroku-equivalent-for-Djang...](http://www.quora.com/What-is-the-Heroku-
equivalent-for-Django-applications)

~~~
cdr
Last time I tried one of those gists, it plain didn't work. Not sure if the
gist I tried was outdated by then or if things are working now.

------
protagonist_h
Google App Engine for Java is another PaaS option for running Java in the
cloud. I wonder how these two compare?

~~~
tomas_lin
Google App Engine has a fairly restrictive Java implementation. It means that
most libraries that you are familiar with would likely not work there. So you
can't really just take a war file that works somewhere else and stick it on
App Engine. They do provide a few nice built-in service like image
manipulation.

The problem with services like Cloudbees and Amazon's Elastic Beanstalk is
that you end up updating an entire war file that you build locally. This can
take a long time.

Cloudfoundry only serves up deltas, but you still end up having to build the
entire war file on your local machine ( at least for Grails ).

Heroku's approach seems much nicer, you get some initial setup pain, but then
you can just use a standard git workflow.

~~~
SachaLabourey
Tomas, this is not true, at least with CloudBees you have a delta deployer
that makes it a breeze to update your applications as it just sends the delta
from the last upload!

------
Finbarr
This is fantastic news. Heroku is squarely positioning itself as the de facto
cloud app platform.

------
aphexairlines
I don't understand this part:

> In the classic software delivery process (development → packaging →
> distribution → install → deployment), code passes through many hands before
> it finally reaches the end user. Developers build, QA verifies, ops deploys,
> and finally end users can access. In this environment, the feedback loop for
> information about how code behaves in production is slow and inefficient —
> it may take weeks or months for this to make it back to developers, and
> often in a highly-filtered format.

> Heroku is built for the new era of software-as-a-service. An app is built by
> a small, cross-functional, relatively independent team which builds and
> deploys everything itself, with few or no hand-offs to other teams.

What's the difference here? Developers still build and QA still has to verify.
If your code is split up into several repositories, you still want to track
versions (packaging & distribution, even if a package is just a branch +
revision number).

~~~
Volpe
They are talking about 'cross functional' teams. So Devs/QAs/Ops can be in the
same team, even the same people. Because they (Heroku) are handling all the
edge-knowledge of server setup/maintenance etc.

You only need to track revision number, in a single repo (maybe with branches,
sure). I'm not sure what you mean by "code split into several repositories" ?

The difference is deployments become cheap thus "delivering software" becomes
cheaper.

~~~
aphexairlines
By several repositories, I mean libraries. Maybe built by your team, maybe by
another team.

And I still don't see how Heroku hosting your software affects whether you
have dedicated QA staff and whether they're in your team or not.

~~~
bitops
It has to do with how quickly you can iterate on your production software and
what the distance is (in terms of time) between a developer committing a
change and that change making it out in front of an end-user.

In traditional enterprise software (e.g. insurance) the deployment cycles are
long because the organization are large, heavily layered, and extremely
resistant to change. There are many reasons for this, some sensible and some
not. (And then some that are legislated - they fall into both categories).

For a startup that is trying to build a service, or a mid-sized corporation,
particularly in the ecommerce space, the faster you can change a deployed
solution, the better off you are.

Say you're running a large ecommerce website and a bug is discovered on the
user account page. It's a "P1 issue" that needs immediate attention, i.e. as
long as the bug exists, revenue is impacted.

In a situation like this, you want to be able to identify a fix, commit it,
and ship it to production ASAP. This becomes an issue in traditional
organizations where the "developers" are different from "the network people"
who themselves are subdivided into database/network/sysadmin/etc. These groups
are change-averse and tend to gate releases into maintenance windows. Which
makes sense, but can hinder rapid deployment.

If you don't have a traditional Ops team, there's no stakeholder who feels
you're impinging on their fiefdom when you wantonly hit the deploy button.
(Though I don't mean to imply that you shouldn't have discipline around
releases).

The question you're asking is very relevant for teams making the transition to
processes like Agile and infrastructures like Cloud. Because these things are
disruptive, they lead to change and break-down of traditional org structures.
A dedicated QA department always seems to be one of the first things targeted.
(Though I don't necessarily think that's a good idea).

~~~
aphexairlines
I think you will find that even in large organizations with dedicated teams
owning server ops, if a problem is impacting customers in the middle of the
day, there will be a way to get the deployment window open quickly.

Doing away with maintenance windows altogether sounds great from our point of
view as developers, but it shouldn't come at the expense of customers
suffering horrible latency during peak hours because the servers are at
reduced capacity while a significant percentage of them are busy with
deployments.

I understand the benefits of rapid iteration through continuous deployment
(and intensive automated testing), but cloud platforms like Heroku and
Beanstalk don't really help here. Cloud deployment and the ability for
developers to push a button and have their changes show up in production
quickly also doesn't mean you don't need QA anymore. That's a separate
decision.

I understand that making deployment a simpler process through hosted server
farms is great in that it takes off a lot of pressure from your ops team, but
that doesn't change the development process.

------
grandalf
Hey Heroku, please get yourself PCI-DSS Level 1 certified! BTW does anyone
know if any of the ruby cloud providers offer that?

~~~
bitops
That has more to do with the underlying provider (Amazon) than the language
hosting provider. It's a hard problem for cloud providers to solve but I'll
bet you Amazon will get there sooner rather than later.

~~~
cmelbye
Amazon AWS is PCI DSS Level 1 compliant.

~~~
grandalf
Is it? I thought so then looked at the FAQ and it appears that much of the
infrastructure is level 2 compliant.

~~~
troethom
It is: <http://aws.amazon.com/security/>

~~~
grandalf
Ahh ok excellent.

------
panchute
I wish they supported - here is a war file, run it...

~~~
aphexairlines
If you want "here is a war file" then aren't you looking for beanstalk and
appengine?

~~~
mypov
Cloudfoundry as well.

------
bitops
Also, I'd be curious if PHP support is coming at any time. That seems like it
would open the floodgates.

~~~
ryan-allen
Someone's already got PHP working on Heroku [1], the author is swell bloke too
I hear.

[1] <https://github.com/lstoll/heroku-php>

------
jamesgeck0
I don't have much experience with Java, but is that a minimal pom.xml? It
seems rather involved.

~~~
Lewisham
Yeah, it's not a big one, certainly. In practice, you'll almost never do it
from scratch, but use an archetype [1] that you tweak.

Tools like Ivy, Gradle and Buildr will play nicely with Maven repositories to
get dependencies, and I would hazard were all largely born out of a
frustration with the pom syntax. That said, like it or, more likely, not,
Maven is the defacto Java standard, so it tends to cling on.

[1]: [http://maven.apache.org/guides/introduction/introduction-
to-...](http://maven.apache.org/guides/introduction/introduction-to-
archetypes.html)

------
bitops
I've been hoping for this since I first used Heroku for Rails/Sinatra apps. I
feel that with this change, Heroku is really getting serious about their
offering (not that they weren't already).

But as someone who's worked on enterprisey stuff, the thought of push-button
Spring deployment makes me giddy with glee.

Heroku folks - if you're reading this - you just achieved maximum awesome! :)

------
hello_moto
I want my Java EE6 there darn it.

:)

PS: FYI, so far none of the cloud solution support Java EE6

~~~
bitops
Are there times when you prefer Java EE over Spring and the like? Java EE does
some things well, but it seems like lots of comparable libraries/etc are
offered in the open source side of things.

Not knocking, really just curious about your opinion.

~~~
hello_moto
Maybe it's preference/bias but I found the latest Java EE6 offers a lot
simpler programming model than its predecessor or Spring.

I also prefer to stick with 1 container as opposed to mix-n-match Spring
modules + Hibernate + Apache CXF/Axis2 or whatnot. Most libraries out there
boasted that they implement the JSR standard but they don't stop there as they
also added their own extensions + configurations.

There are a few missing parts in Java EE: MVC and dealing with NoSQL which
both will be addressed in Java EE7 from what I know. Spring has SpringMVC and
SpringData so they're ahead right now.

What I don't like from Spring is the complexity of the setup (dependency,
albeit Maven helps) and knowing various Spring modules and how they works with
your preferred app-server. With Spring, at some point, you need to know a few
key integration points between Spring and your app-server. For example:
deploying an EAR solution that contains multiple WARs and JARs would require
to understand Spring lifecycle, setup/configuration if you'd like to behave
according to your requirement.

A plus point using Java EE6 is to trim down your EAR/WAR. Spring pulls many
JARs.

~~~
bitops
That's a fair point, I guess I've been spoiled. I guess I just don't mind
knowing those integration points and working with them, but I can definitely
see how it would put a bad taste in your mouth after a while.

The NoSQL integration I think will be big. I know some folks using SpringData
to talk to MongoDB and they've had positive experiences so far.

Maybe in the future things will get simpler - so far I've found that I'm
pretty happy with either embedded Jetty or Tomcat. And then Spring/Jersey +
Hibernate/JPA.

Have you found that EAR/WAR size has hampered you? I tend not to worry about
how many JARs I'm pulling.

~~~
hello_moto
I use GF3.1 as they are the only one that implement JEE6 in full. There's an
issue with deploy/undeploy app (memory leak due to pushing ClassLoader to the
edge) which is kind of annoying to me personally because we do frequent
build/deploy. I wish we can use Jetty (I used Jetty, Servlet, GWT in my
previous company) since it is way leaner and faster to reboot; especially via
Maven.

Although I've never measured the deployment performance, I'm quite sure the
smaller your EAR/WAR size the faster it deploys because the ClassLoader is
required to scan + load those libraries (again, it depends on the behavior of
your library: up-front or lazy loading).

~~~
shelajev
You definitely want to try jrebel to solve your problems with redeploys and
wasting time. It'll reload your classes and resource as you compile/provide
them. Check it out, <http://zeroturnaround.com> . disclaimer: I work there,
but jrebel is awesome anyway.

~~~
hello_moto
I have heard of JRebel for a while but have not had the case to need this
until now. Is it free for development?

PS: I saw someone from JRebel did a presentation about ClassLoader before, you
guys really know what you are doing. Respect man! :)

------
devth
beauty and the beast

------
chopsueyar
Ah, yes, the SUV of programming languages.

~~~
jinushaun
Their Hello World example looks awful... And the majority of the article is
spent apologising for Java.

~~~
bitops
It's not pretty, but it is the lowest level of abstraction. If they used a
prettier example, they'd have to pick a framework and then people would
complain "hey, why'd you pick X and not Y?"

