Heroku for Java
blog.heroku.com
blog.heroku.com
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?
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.
Awesome.
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.
I've tried a few others. Both Dotcloud and Duostack (before the acquisition). But I always ran into one or two little sticking points or things it couldn't do or things it could do but not easily.
I keep coming back to Heroku, for both Ruby and now Clojure. (And now that their Node.js hosting isn't awful, I'd probably use it for that too if I did something in Node). It makes it so easy for me to get an app out, even with little wrinkles like needing some configuration variables that I don't want to check in to my codebase.
until then there's a good list for django http://www.quora.com/What-is-the-Heroku-equivalent-for-Djang...
CloudFoundry Beta has some really bad limitation right now, ie. no pricing, cannot assign point an external domain name, etc.
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.
> 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).
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.
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.
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).
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.
Plug: if you are interested in Java deployment and do not anticipate to write bug-free code just yet, you might want to look at CloudBees: this is not just a production PaaS but it also provides a complete Continuous Integration SaaS based on Jenkins and many other services.
Glad to see more action around Java in the cloud!
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-...
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! :)
:)
PS: FYI, so far none of the cloud solution support Java EE6
Not knocking, really just curious about your opinion.
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.
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.
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).
PS: I saw someone from JRebel did a presentation about ClassLoader before, you guys really know what you are doing. Respect man! :)